Re: Polling http pour récupérer des info en JSON via un script pour parser... et charger un VE :-)
Publié : 10 sept. 2024, 19:52
Bonsoir Flying,
Et merci pour cette présentation MQTT plus que complète ! De quoi, philosophiquement, revoir mes préjugés
Pour répondre à la question de ce timeout très rapide : J'ai pensé que comme le smartEVSE récupère historiquement ces infos de comptage (globalement une lecture de 3 ampérages) via une com. Modbus, l'API avait été "collé" dessus et que ce timeout venait de là (c'est courant, un timeout de 10sec. en com. modbus).
Bah non : Le concepteur m'a éclairci le sujet :
En fait, il s'agit de moduler la charge d'un VE selon plusieurs modalités, panachables :
1- la conso. d'une maison à un moment donné (pour ne pas "dépasser" son forfait 9Kva lorsqu'on cuisine à l'induction ET que l'on vient de brancher son VE)
2- et/ou avec en + une possibilité de prise en compte d'une production solaire (ce qui est "injecté" sur le réseau car non consommé par la maison à un instant T se trouve être disponible pour le VE - précisément lorsque l'on a pas de contrat de rachat par edf, cette énergie produite serait perdue)
3- [mon cas] ne recharger QUE avec du solaire.
Dans ce dernier cas, pas de pb. : Si la valeur de comptage est fausse ou en retard, ce que je risque c'est de "pomper" au réseau plus que sur mon solaire, pas grave mais pas optimal.
Dans les 2 premiers cas, il peut se produire une surcharge de l'arrivé edf :
1) si la lecture de la conso de la plaque à induction est en retard, le smartEVSE n'aura pas le temps de "baisser" la charge
2) si le solaire donne beaucoup, le smartEVSE pourrait "donner à manger" au VE plus que l'arrivée elec edf
c'est élégant et plutôt rarement vu dans le monde de la charge VE, mais fera sauter aussi vite l'arrivée edf au premier nuage venu si la lecture est trop lente ! Et vous avez déjà "vu passer" un nuage dans un ciel bleu : Je peux vous garantir que la chute de production solaire est immédiate !
on a que quelques secondes pour réagir !
// Voilà le pourquoi de ce timeout rapide. Ce timeout coupe purement et simplement la charge, par sécurité !
// petit edit : ce qui plaide bien -comme proposé par fcBourgogne- pour une solution de régulation "hard" plutôt que géré par la supervision...
Et merci pour cette présentation MQTT plus que complète ! De quoi, philosophiquement, revoir mes préjugés
Pour répondre à la question de ce timeout très rapide : J'ai pensé que comme le smartEVSE récupère historiquement ces infos de comptage (globalement une lecture de 3 ampérages) via une com. Modbus, l'API avait été "collé" dessus et que ce timeout venait de là (c'est courant, un timeout de 10sec. en com. modbus).
Bah non : Le concepteur m'a éclairci le sujet :
En fait, il s'agit de moduler la charge d'un VE selon plusieurs modalités, panachables :
1- la conso. d'une maison à un moment donné (pour ne pas "dépasser" son forfait 9Kva lorsqu'on cuisine à l'induction ET que l'on vient de brancher son VE)
2- et/ou avec en + une possibilité de prise en compte d'une production solaire (ce qui est "injecté" sur le réseau car non consommé par la maison à un instant T se trouve être disponible pour le VE - précisément lorsque l'on a pas de contrat de rachat par edf, cette énergie produite serait perdue)
3- [mon cas] ne recharger QUE avec du solaire.
Dans ce dernier cas, pas de pb. : Si la valeur de comptage est fausse ou en retard, ce que je risque c'est de "pomper" au réseau plus que sur mon solaire, pas grave mais pas optimal.
Dans les 2 premiers cas, il peut se produire une surcharge de l'arrivé edf :
1) si la lecture de la conso de la plaque à induction est en retard, le smartEVSE n'aura pas le temps de "baisser" la charge
2) si le solaire donne beaucoup, le smartEVSE pourrait "donner à manger" au VE plus que l'arrivée elec edf
// Voilà le pourquoi de ce timeout rapide. Ce timeout coupe purement et simplement la charge, par sécurité !
// petit edit : ce qui plaide bien -comme proposé par fcBourgogne- pour une solution de régulation "hard" plutôt que géré par la supervision...