J'ai la même chose sur l'un de mes ESP. Est-ce un bug du code, ou une faiblesse de l'ESP ? je ne sais pas.
Mais j'ai eu le cas sur plusieurs ESP.
A part faire un bout de code (au reset ?) qui vient lire les data en EEPROM, et les "nettoie" en filtrant les quelques données aberrantes (par exemple en les remplaçant par la moyenne des deux valeurs qui l'entourent), ou faire un reset complet en changeant la clé, mais dans ce cas on perd l'historique, je ne vois pas.
On peut s'inspirer du module stockage pour écrire ce code. ça ne doit pas être trop compliqué. Quand j'ai le temps, je me penche dessus.
Bon, j'ai instrumenté le code stockage pour comprendre pourquoi les données sont "vérolées".
Dans mon cas, j'ai un serveur Linky, et un serveur UxIx3.
Mon serveur UxIx3 est mon serveur "principal" pour les données de consommation. Par contre, avec tous les plantages depuis la 9.03 et jusqu'à la V11.19 compilée avec la version beta de la bibliothèque cartes qui fonctionne merveilleusement bien, j'ai passé mon ESP Chauffe-eau enfants de UxIx3 à Linky.
SAUF QUE, si je le laisse la nuit sur serveur Linky, alors la donnée de conso enregistrée en EEPROM est celle du Linky, et pas celle du serveur UxIx3 qui n'a pas la même origine/historique.
Du coup, puisque c'est la valeur totale qui est enregistrée chaque jour, et pas la valeur du jour, dans l'historique, alors les calculs effectués pour retrouver la valeur consommée chaque jour deviennent FAUX.
Peut-être aurait-il fallu stocker les conso jour, et pas la conso totale dans l'EEPROM. ainsi, l'intégrité de l'historique aurait été conservée même lorsqu"on bascule d'un serveur à l'autre.
Pas de chance.
Je vais juste corriger ces valeurs "à la main" avec un bout de code pour que tout rentre dans l'ordre chez moi, et je ferai attention à l'avenir de bien revenir à la configuration UxIx3 pour tous mes clients avant d'aller me coucher quand je bidouille.
Mais j'ai eu le cas sur plusieurs ESP.
A part faire un bout de code (au reset ?) qui vient lire les data en EEPROM, et les "nettoie" en filtrant les quelques données aberrantes (par exemple en les remplaçant par la moyenne des deux valeurs qui l'entourent), ou faire un reset complet en changeant la clé, mais dans ce cas on perd l'historique, je ne vois pas.
On peut s'inspirer du module stockage pour écrire ce code. ça ne doit pas être trop compliqué. Quand j'ai le temps, je me penche dessus.
Bon, j'ai instrumenté le code stockage pour comprendre pourquoi les données sont "vérolées".
Dans mon cas, j'ai un serveur Linky, et un serveur UxIx3.
Mon serveur UxIx3 est mon serveur "principal" pour les données de consommation. Par contre, avec tous les plantages depuis la 9.03 et jusqu'à la V11.19 compilée avec la version beta de la bibliothèque cartes qui fonctionne merveilleusement bien, j'ai passé mon ESP Chauffe-eau enfants de UxIx3 à Linky.
SAUF QUE, si je le laisse la nuit sur serveur Linky, alors la donnée de conso enregistrée en EEPROM est celle du Linky, et pas celle du serveur UxIx3 qui n'a pas la même origine/historique.
Du coup, puisque c'est la valeur totale qui est enregistrée chaque jour, et pas la valeur du jour, dans l'historique, alors les calculs effectués pour retrouver la valeur consommée chaque jour deviennent FAUX.
Peut-être aurait-il fallu stocker les conso jour, et pas la conso totale dans l'EEPROM. ainsi, l'intégrité de l'historique aurait été conservée même lorsqu"on bascule d'un serveur à l'autre.
Pas de chance.
Je vais juste corriger ces valeurs "à la main" avec un bout de code pour que tout rentre dans l'ordre chez moi, et je ferai attention à l'avenir de bien revenir à la configuration UxIx3 pour tous mes clients avant d'aller me coucher quand je bidouille.
V12.0 modifiée récurrence d'interrogation serveurs, RTE, et code UxIx3. 1 serveur RMS UxIx3, 1 client Triac CE + 1 client SSR CE. 1 client SSR sur CE tri sur 1 serveur Linky réf. CACSI. Variateurs de fréquence sur Piscine et Spa.
6 panneaux (2 SO 2 S, 2 SE ) 425Wc produisent 13kWh de jour actuellement.
6 panneaux (2 SO 2 S, 2 SE ) 425Wc produisent 13kWh de jour actuellement.