[Majeur] Le high-water mark publié masque les grandes corrections arrière (contradiction avec la docstring) #84

New issue

Open

opened 2026-08-26 05:32:40 +00:00 by mat · 0 comments

mat commented

2026-08-26 05:32:40 +00:00

Owner

Problème

La docstring de _fetch_device_metrics (coordinator.py:767-773) affirme : « Larger backward corrections are still applied as a snap ». Elles le sont en interne : le snap arrière est bien appliqué à live_total_wh (coordinator.py:819-830)… mais _publish_device_energy (coordinator.py:672-680) refuse de publier une valeur inférieure au max déjà publié.

Le capteur (TOTAL_INCREASING, alimenté par data["devices"][id]["energy"] = published) reste donc sur l'ancienne valeur haute : toute l'énergie réelle entre le total corrigé et l'ancien max est invisible jusqu'à ce que live_total_wh re-franchisse le max — potentiellement des heures/jours. La divergence est persistée (le save re-publie live, published reste le max), donc durable à travers les redémarrages.

Risque

Sous-comptabilisation invisible et prolongée. HA gère très bien une baisse sur un capteur total_increasing (interprétée comme reset du compteur, sans double comptage) : le verrou high-water échange un reset propre et visible contre un gel silencieux.

Recommandation

Trancher explicitement avant v1.0 :

soit publier live_total_wh brut et laisser HA gérer le reset (le filtre de tolérance ±5 Wh couvre déjà le bruit),
soit conserver le high-water — mais alors corriger la docstring et documenter le gel.

En l'état, le code ne fait ni l'un ni l'autre de façon cohérente.

Constaté lors de la review de code pré-v1.0 (v0.8.1).

## Problème La docstring de `_fetch_device_metrics` (`coordinator.py:767-773`) affirme : « Larger backward corrections are still applied as a snap ». Elles le sont en interne : le snap arrière est bien appliqué à `live_total_wh` (`coordinator.py:819-830`)… mais `_publish_device_energy` (`coordinator.py:672-680`) **refuse de publier une valeur inférieure au max déjà publié**. Le capteur (TOTAL_INCREASING, alimenté par `data["devices"][id]["energy"]` = published) reste donc sur l'ancienne valeur haute : toute l'énergie réelle entre le total corrigé et l'ancien max est invisible jusqu'à ce que `live_total_wh` re-franchisse le max — potentiellement des heures/jours. La divergence est persistée (le save re-publie live, published reste le max), donc durable à travers les redémarrages. ## Risque Sous-comptabilisation invisible et prolongée. HA gère très bien une baisse sur un capteur `total_increasing` (interprétée comme reset du compteur, sans double comptage) : le verrou high-water échange un reset propre et visible contre un gel silencieux. ## Recommandation Trancher explicitement avant v1.0 : - soit publier `live_total_wh` brut et laisser HA gérer le reset (le filtre de tolérance ±5 Wh couvre déjà le bruit), - soit conserver le high-water — mais alors corriger la docstring et documenter le gel. En l'état, le code ne fait ni l'un ni l'autre de façon cohérente. --- Constaté lors de la review de code pré-v1.0 (v0.8.1).

mat added the

v1.0 · majeur

label

2026-08-26 05:32:40 +00:00