Aller au contenu
KipK

"Délestage"/charge dynamique avec OpenEVSE et MQTT

Messages recommandés

Salut,

 

Après avoir testé différentes approches, je vous partage comment détourner les fonctionnalités Solar/PV d'OpenEVSE pour adapter dynamiquement la puissance de charge en fonction de ce qui est disponible sur votre compteur. 

 

Prérequis :

- une mesure live de la puissance consommée sur le compteur ( info TIC, j'utilise un module  ZigBee pour linky -> Lixee )

- n'importe quelle solution capable de publier sur mqtt ( ici Jeedom avec jMQTT )

- une borne OpenEVSE avec ESP32 connectée à un serveur MQTT

 

Côté Jeedom, je publie sur un topic MQTT la puissance disponible en watt et important en négatif, qui correspond à :

- (puissance totale de l'abonnement - puissance instantanée du compteur  ) 

 

Dans OpenEVSE, onglet Services, activer Solar PV Divert, sélectionner le Feed Grid(+I/-E) , entrer le topic du dessus et laisser les valeurs par défaut pour le reste 

Screenshot_20220527-193905.thumb.png.0d0fdc9cc0791ac72c317a677b7a4ba4.png

 

Normalement ensuite , en activant le mode eco, ça devrait fonctionner tout seul 

Vous pouvez aussi régler des timers pour profiter des heures creuses. 

Screenshot_20220527-193921.thumb.png.f9c49f9a5eb19eab326695496faa397c.png

Partager ce message


Lien à poster
Partager sur d’autres sites

Pour info , j'ai eu un soucis avec le contacteur "US" , livré dans le kit openevse.

en cours de remplacement avec un contacteur "EU".

 

origine du problème non déterminée , peut-être un mauvis serrage.

 

Pourquoi je ne remets pas le même contacteur ? car le 208-240V ne m'inspire pas confiance , car en France , le réseau délivre 207-253V

Et en temps normal , j'ai 236V a la prise.

 

EDIT Après démontage du contacteur , c'est bien le contacteur l'origine du problème , je pense a un défaut de fabrication.

Modifié par alfniev

Partager ce message


Lien à poster
Partager sur d’autres sites

Bon, j'ai rencontré des soucis de priorités avec les timers, plutôt que de bidouiller le Solar Pv Divert, j'ai fais un module à part pour cet usage. Ca arrivera dans la prochaine release. Avec aussi pas mal d'evolutions de la partie MQTT que j 'ai repris aussi, c'était un peu light. 

Si quelqu'un veut une build du firmware beta -> pm

1635185253_Capturedcran2022-06-29155816.thumb.jpg.a8f389a3e1123ec2e311c0b69700ddd3.jpg

 

 

 

Les modifs:

https://github.com/OpenEVSE/ESP32_WiFi_V4.x/pull/382

https://github.com/OpenEVSE/ESP32_WiFi_V4.x/pull/379

https://github.com/OpenEVSE/openevse_wifi_gui/pull/79

 

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Le 29/05/2022 à 16:43, KipK a dit :

J'ai un EmonEVSE , il me semble que c'est aussi un contacteur EU, j'irais vérifier ça. Merci pour l'info. 

 

Pour info , je garde maintenant le boitier ouvert.

En effet , le contacteur aux normes européennes chauffe aussi , et quand on a déja une temperature extérieure de 35°C , la température monte en fleche dans le boitier.

Partager ce message


Lien à poster
Partager sur d’autres sites

Au niveau timer , j'ai eu des soucis en ajoutant ma batterie de stockage.

j'ai du moduler la puissance de charge toutes les minutes au lieu de toutes les 30s.

Car l'intensité mesurée au niveau de la borne n'est pas rafraichie toutes les 10 sec et que la voiture prends qques secondes avant d'appliquer

Bilan j'avais une régulation qui calculait sur des valeurs transitoires => des dents de scie sur la commande de régulation.

Partager ce message


Lien à poster
Partager sur d’autres sites


Bizarre la valeur du courant de charge est rafraîchie toutes les sec, peut être que la modif est récente 

J'ai aussi modifié un truc pour que Pilot soit refresh dès la demande de changement, en effet il était à la traîne. 

 

Sinon j'ai mis en place un moteur de localisation dans le gui, avec la version en Français. N'hésitez pas à corriger mes traductions, je ne suis pas convaincu de tout mes choix :)

 

evse_loc2.thumb.jpg.a4fff003c6ce589bd2cce061ffd2d817.jpg

 

 

La build est dispo ici en attendant merge sur le master:

https://github.com/KipK/ESP32_WiFi_V4.x/releases/tag/latest

 

 

 

 

 

Modifié par KipK

Partager ce message


Lien à poster
Partager sur d’autres sites

Salut @KipK
Je gérais ça directement depuis mon jeedom en abaissant la tension ou en mettant la borne en pause mais ton module directement sur la borne me permettra d'enlever pas mal de scénarios surtout que j'en ai déjà pas mal avec la gestion de puissance de la borne via mes panneaux solaires (pas fan du tout de la gestion mqtt native des panneaux solaire qui me donne des mauvais résultats...).
J'ai installé la dernière master 4.1.4 mais je n'ai pas ton module qui s'affiche. Il y a une manip particulière a faire ?

Partager ce message


Lien à poster
Partager sur d’autres sites

Le 24/08/2022 à 10:13, KipK a dit :

Tiens je l'ai mise ici. C'est le master courant, avec la gestion des langues en plus. 

https://github.com/KipK/ESP32_WiFi_V4.x/releases/tag/latest

Merci.

Je viens de l'installer j'ai bien le module maintenant.

Concernant la puissance en cas de "delestage" ça coupe la charge ou ça diminue l'amperage si la valeur de consigne est dépassée ?
Je test ça dans la semaine et je te fais un retour ;)

Partager ce message


Lien à poster
Partager sur d’autres sites

Salut @KipK.
J'ai découvert un bug assez génant sur ton module.
J'ai configuré une puissance max à 10500W (j'ai un abonnement 12kVA mais je préfère garder un peu de marge pour mes tests). J'ai bien le live power qui arrive via MQTT et qui sort sur le topic shaper_live_pwr quand je visualiser avec MQTT Explorer.
Je pilote en fonction de ma production solaire le On/Pause de ma borne donc j'ai un petit plugin jeedom que j'ai développé qui me permet de faire celà. 
Le soucis c'est que dés que j'active le module "Gestion dynamique du courant" dans OpenEVSE alors que jeedom lui dit d'être en pause la borne switch sans arrêt entre ON/Pause.

C'est assez problématique car derrière la voiture finit par se mettre en erreur (e208) car elle détecte une anomalie au niveau de la borne.

Je n'ai pas encore pris le temps de regarder ton code mais de ce que j'interprête avec le comportement que j'ai, j'ai l'impression que dés que live_pwr est inférieur à la consigne le module tente de mettre la borne sur ON. La seconde qui suit mon plugin jeedom detecte que la borne est sur ON alors que je ne le demande pas et de ce fait elle reforce sur pause.

L'idéal si le problème est bien celà serait que le module ne fasse que diminuer l'ampérage voir mettre la borne en pause si vraiment la puissance dispo est inférieure à 6A mais ne force pas de ON dés que live_pwr est inférieur à Max_pwr (peux être via une option ?)

 

En attendant j'ai arrêté le module et je n'ai plus le soucis ;)

 

Merci d'avance

Modifié par Aberton

Partager ce message


Lien à poster
Partager sur d’autres sites

Comment dis tu à la borne de se mettre en pause? 

 

Tu as une commande Mqtt pour désactiver temporairement le shaper, je te conseille d'utiliser ça si tu mets en pause manuellement. 

Partager ce message


Lien à poster
Partager sur d’autres sites

Ok j'ai trouvé, le shaper a une priorité supérieure au manual override donc il prend le dessus sur la pause.

Je peux prévoir une condition, en attendant désactive le shaper qd tu envoies ta pause.

Mais si tu utilises des panneaux solaires, pourquoi ne pas utiliser le module Solar P/V pour gérer ça plutôt que depuis Jeedom?

Modifié par KipK

Partager ce message


Lien à poster
Partager sur d’autres sites

Le 28/08/2022 à 10:30, KipK a dit :

Comment dis tu à la borne de se mettre en pause? 

 

Tu as une commande Mqtt pour désactiver temporairement le shaper, je te conseille d'utiliser ça si tu mets en pause manuellement. 

Je mets la borne en pause via l'API rest. Je n'ai pas encore fait les modifications dans mon plugin pour faire mes actions via mqtt il faut que je trouve un peu de temps (mais je vais m'y atteler 😉).

 

Pour le coup j'ai testé la partie gestion des panneaux solaires via mqtt mais je n'était vraiment pas satisfait de la gestion native via la borne. Même en jouant avec les variables parfois je surposuisait car la borne ne mettait pas l'ampérage suffisament haut .

En plus quand je demande 6A a la borne elle n'envoie au final que 5,08A. J'ai cette marge jusqu'à 20A environ donc mon plugin gère cela 😉

De plus j'ai un routeur solaire pour le ballon d'eau chaude et suivant la saison je souhaite pouvoir mettre la priorité soit sur la voiture soit sur le chauffe eau et c'était pas forcément l'idéal avec la gestion native de openEVSE.

 

Nickel si tu as trouvé la cause. Tu pourras me renvoyé un build quand ce sera fix pour que je test ? Ce n'est pas pressé !

 

Merci

Partager ce message


Lien à poster
Partager sur d’autres sites

Je viens de revoir mon code et normalement ce n'est pas censé interférer avec une commande de priorité inférieure.

 

Peux tu poster depuis l'API http le contenu des claims et override quand le bug se produit?

 

Aussi les fonctions Mqtt sont aussi accessible depuis l'API HTTP -> post: /shaper 0 ou 1

Pour activer désactiver le shaper sans toucher à la config

Partager ce message


Lien à poster
Partager sur d’autres sites

@Aberton j'ai essayé de reproduire ton problème sans succès. Si j'envoie une pause par ex avec un claim , la charge ne reprend pas toute seule avec le shaper.

 

Peux tu partager le code de ton plugin que je regarde en détail ?

Partager ce message


Lien à poster
Partager sur d’autres sites

Le 30/08/2022 à 09:23, KipK a dit :

@Aberton j'ai essayé de reproduire ton problème sans succès. Si j'envoie une pause par ex avec un claim , la charge ne reprend pas toute seule avec le shaper.

 

Peux tu partager le code de ton plugin que je regarde en détail ?

Ma femme utilise sa voiture pour allé au boulot la semaine donc je ne pourrais tester que ce week end.
Mon plugin utilise les commandes d'un autre plugin (OpenEVSE) tu peux regarder le code de ce plugin si tu as besoin c'est la commande de pause que j'appel.

Partager ce message


Lien à poster
Partager sur d’autres sites

@AbertonOk tout s'explique.

Le plugin openevse utilise le protocole RAPI d'openevse qui envoie des commandes directement au module openevse série. Ce protocole est déprécié car il amène de gros soucis de concurrence sur les ordres venant de differentes sources ( problème que tu rencontres ).

Il est aujourd'hui uniquement dédié à la com entre le module EVSE et le module wifi. 

Il fait utiliser la nouvelle API http qui n'est pas encore supportée par le plugin Jeedom,.ou Mqtt ( qui utilise maintenant aussi la nouvelle api )

 

https://openevse.stoplight.io/docs/openevse-wifi-v4/e3153e2367cb1-open-evse-wi-fi-api

 

Modifié par KipK

Partager ce message


Lien à poster
Partager sur d’autres sites





×
×
  • Créer...
Automobile Propre

Automobile Propre est un site d'information communautaire qui est dédié à tout ce qui concerne l'automobile et l'environnement. Les thématiques les plus populaires de notre blog auto sont la voiture électrique et les hybrides, mais nous abordons également la voiture GNV / GPL, les auto à l'hydrogène, les apects politiques et environnementaux liés à l'automobile. Les internautes sont invités à réagir aux articles du blog dans les commentaires, mais également dans les différents forums qui sont mis à leur dispositon. Le plus populaire d'entre eux est certainement le forum voiture électrique qui centralise les discussions relatives à l'arrivée de ces nouveaux véhicules. Un lexique centralise les définitions des principaux mots techniques utilisés sur le blog, tandis qu'une base de données des voitures (commercialisées ou non) recense les voitures électriques et hybrides.