21-04-2025, 10:11 AM
Sauvegarde "Durée Equiv"
|
23-04-2025, 10:28 AM
Cela va détériorer la flash si on écrit dedans trop souvent.
C'est pour ça qu'il n'y a que la consommation journalière qui est sauvegardée.
23-04-2025, 10:35 AM
Sauvegarder la durée équivalente comme la conso journalière, ça prend trop de place ?
Dans ce cas là, si on ne peut pas, il faudrait pouvoir utiliser cette conso journalière dans les scénarios
4 panneaux 2000Wc
1 routeur F1ATB UxIx2 avec écran pour le CE 2200W V14.22 modifiée 1 routeur F1ATB nomade pour radiateur 2000W V14.22
23-04-2025, 10:40 AM
Le problème, c'est que la coupure de courant peut arriver n'importe quand, et pas seulement 1 fois par jours à une heure précise.
Pour sauvegarder la dernière mesure, il faudrait écrire dans la flash régulièrement (au moins une fois toutes les 30minutes pour ne pas avoir trop d'erreur) (21-04-2025, 10:11 AM)kumy a écrit : Bonjour, Bonjour, C'est en effet un problème auquel je suis confronté de temps en temps. Suivant les versions du routeur solaire que j'injecte sur mon ESP32, j'ai des reboot très réguliers (1 ou 2h), ou au contraire ça peut tenir des semaines (c'est le cas avec la v14.22 actuelle par exemple...). Je n'ai pas encore compris le pourquoi, mais en attendant pour éviter de lancer des actions sur des valeurs erronées renvoyées par le routeur solaire dans ce cas, j'ai mis en place un système de surveillance et de correction palliatif, localisée sur ma domotique (en l’occurrence Jeedom sous forme de scénario, mais c'est applicable sur HA également je pense). Le principe est le suivant : On reçoit une nouvelle valeur d'ouverture du relais de la part du routeur solaire, notée (A). On mémorise une valeur de durée mémorisée, notée (B) et une durée d'ouverture cumulée, notée (C ). A la réception de la valeur (A), et en considérant que cette valeur ne peut être que supérieure ou égale à la valeur (C ) : 1. Avec un simple test, on élimine tout d'abord les éventuelles valeurs fantaisistes de (A) qui sont reçues (avec par exemple (A) > 20h ?). Ça m'est en effet aussi arrivé de recevoir des valeurs bizarres comme une durée d'ouverture supposée de 21900 heures... Il suffit de redéfinir (A) avec la valeur 0 le cas échéant pour que ce ne soit pas pris en compte par la suite. 2. On teste ensuite si la valeur de la durée d'ouverture cumulée (C ) (égale à 0 au départ d'un nouveau cycle quotidien) est inférieure ou égale à la somme de la valeur de la durée d'ouverture reçue (A) avec la valeur de durée mémorisée (B) (égale à 0 au départ d'un nouveau cycle quotidien) et un petit offset (de 0,02 par exemple) pour corriger les éventuelles erreurs d'arrondis. > Si oui : tout va bien, la valeur de la durée d'ouverture cumulée (C ) va prendre directement la valeur de la somme de la durée d'ouverture cumulée reçue (A) avec la valeur de la durée mémorisée (B). > Si non : c'est qu'il y a probablement eu un reboot de l'ESP32 entre-temps. Dans ce cas, la valeur de la durée mémorisée (B) va prendre la valeur de la durée d'ouverture cumulée (C ). Et tous les jours à 06h00, comme pour le routeur solaire, on remet à 0 ces valeurs (B) et (C ). Exemple : On est en début de cycle (il est 06h00), on a donc un cumul (B) de 0h, on a mémorisé pour la journée (C ) = 0h, et on reçoit une valeur d'ouverture (A) de 0,3h : 1. la valeur (A) est OK (valeur cohérente), on continue. 2. on teste si (C ) <= à (A)+(B)+0,02 , soit 0 <= à 0,3 + 0 + 0,02 ? la réponse est OUI, donc (C ) = (A)+(B) = 0,3h. On a donc : (A) = 0,3 / (B) = 0 / (C ) = 0,3 On reçoit une nouvelle valeur d'ouverture (A) avec 0,4h (soit 0,1h de plus par rapport à la dernière valeur renvoyée) : 1. la valeur (A) est OK (valeur cohérente), on continue. 2. on teste si (C ) <= à (A)+(B)+0,02 , soit 0,3 <= à 0,4 + 0 + 0,02 ? la réponse est OUI, donc (C ) = (A)+(B) = 0,4h. On a donc : (A) = 0,4 / (B) = 0 / (C ) = 0,4 Maintenant, l'ESP32 subit un reset. On reçoit maintenant une valeur de (A) = 0,1h (le compteur est reparti de 0, et il a été incrémenté de +6 minutes d'ouverture depuis). 1. la valeur (A) est OK (valeur cohérente), on continue. 2. on teste si (C ) <= à (A)+(B)+0,02 , soit 0,4 <= à 0,1 + 0 + 0,02 ? la réponse est NON (0.4 n'est pas inférieur ou égal à 0,12), donc (B) va prendre la valeur de (C ), soit 0,4. On a donc : (A) = 0,1 / (B) = 0,4 / (C ) = 0,4 On reçoit une nouvelle valeur d'ouverture (A) avec 0,2h : 1. la valeur (A) est OK (valeur cohérente), on continue. 2. on teste si (C ) <= à (A)+(B)+0,02 , soit 0,4 <= à 0,2 + 0,4 + 0,02 ? la réponse est OUI, donc (C ) = (A)+(B) = 0,6h. On a donc : (A) = 0,2 / (B) = 0,4 / (C ) = 0,6 Et ainsi de suite... Il suffit donc de ne prendre en considération dans les calculs sous Jeedom ou HA que la valeur de (C ), qui est la durée d'ouverture cumulée, et non pas directement celle de (A) pour être sûr de s'affranchir de tout reset intempestifs du routeur solaire. Il faut bien penser à remettre à 0 (B) et (C ) tous les jours à 06h00. Ca fonctionne très bien pour ma part, et si cela peut servir...
_________________________________________________
Routeur Solaire en v14.22 Pilotage d'un cumulus de 3kW + Jeedom v4.4.19 + Station solaire 3,5kW
24-04-2025, 09:05 AM
Salut,
J'ai eu la même réflexion sur un projet de compteur d'eau sur ESP32 Voici la solution que j'ai pensé à mettre en place si ça peu donner des idées d'évolution. 1. Sauvegarde EEPROM quotidienne : Les compteurs sont sauvegardés dans l'EEPROM toutes les 24 heures. 2. Synchronisation MQTT avec retain : Les valeurs des compteurs sont publiées sur le Broker MQTT avec la persistance retain. 3. Reprise des valeurs : Prêt pour lire les données à partir du Broker en cas de redémarrage. A bon entendeur ![]()
Enphase -> Node-RED -> Source MQTT
3x IQ7+/3x 375WhC + 4x IQ8MC/4x 400WhC 1x Routeur 12.06_Custom -> CES 2,5kW Domotique gérée sous Jeedom 4.4.19 (DIY VMM Synology) |
« Sujet précédent | Sujet suivant »
|
Utilisateur(s) parcourant ce sujet : 3 visiteur(s)