[Bloquant v1.0] Énergie device 100 % dépendante du WebSocket : aucun watchdog de vivacité ni repli polling #80

New issue

Open

opened 2026-08-26 05:31:53 +00:00 by mat · 0 comments

mat commented

2026-08-26 05:31:53 +00:00

Owner

Problème

L'énergie par device n'avance que via integrate_live_energy (samples du stream). La réconciliation horaire serveur ne fait que corriger live_by_hour ; or _server_bucket_to_wh (coordinator.py:166) retourne None quand live_wh < 10 → tout bucket d'une heure sans samples stream est sauté.

Le stream peut mourir silencieusement :

stream.py:158-163 : ComwattAuthError → break définitif, aucun redémarrage. Le commentaire « poll will trigger reauth » est trompeur : le poll re-authe le client du coordinator, pas celui du stream (client séparé, stream.py:113).
Le STOMP négocie heart-beat: 10000,10000 côté lib : le serveur peut envoyer des heartbeats sans données → une connexion zombie paraît saine pour toujours, recv() ne time out jamais.
stream.py:139-146 : sites ajoutés au compte après démarrage → jamais de stream avant un reload (snapshot coordinator.sites figé).

Risque

Pour une intégration de monitoring énergétique, l'échec le plus grave (compteurs d'énergie figés) est précisément celui qui n'affiche aucune erreur : le poll continue d'alimenter la puissance, l'intégration semble saine.

Recommandation

Watchdog par site : si aucune Measurement depuis N min (ex. 10 min), fermer/recréer la connexion.
Repli polling : si live_by_hour d'une heure révolue est vide/≈0 mais que le serveur publie un bucket, l'accumuler au lieu de le sauter systématiquement.
Au minimum : redémarrage du stream après auth error (task de relance), ou arrêt propre + ConfigEntryAuthFailed pour déclencher le flow reauth.
Rafraîchir la liste des sites au poll et lancer les streams manquants.

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

## Problème L'énergie par device n'avance que via `integrate_live_energy` (samples du stream). La réconciliation horaire serveur ne fait que *corriger* `live_by_hour` ; or `_server_bucket_to_wh` (`coordinator.py:166`) retourne `None` quand `live_wh < 10` → tout bucket d'une heure sans samples stream est **sauté**. Le stream peut mourir silencieusement : - `stream.py:158-163` : `ComwattAuthError` → `break` définitif, aucun redémarrage. Le commentaire « poll will trigger reauth » est trompeur : le poll re-authe le client du *coordinator*, pas celui du stream (client séparé, `stream.py:113`). - Le STOMP négocie `heart-beat: 10000,10000` côté lib : le serveur peut envoyer des heartbeats sans données → une connexion zombie paraît saine pour toujours, `recv()` ne time out jamais. - `stream.py:139-146` : sites ajoutés au compte après démarrage → jamais de stream avant un reload (snapshot `coordinator.sites` figé). ## Risque Pour une intégration de *monitoring énergétique*, l'échec le plus grave (compteurs d'énergie figés) est précisément celui qui n'affiche **aucune erreur** : le poll continue d'alimenter la puissance, l'intégration semble saine. ## Recommandation 1. Watchdog par site : si aucune `Measurement` depuis N min (ex. 10 min), fermer/recréer la connexion. 2. Repli polling : si `live_by_hour` d'une heure révolue est vide/≈0 mais que le serveur publie un bucket, l'accumuler au lieu de le sauter systématiquement. 3. Au minimum : redémarrage du stream après auth error (task de relance), ou arrêt propre + `ConfigEntryAuthFailed` pour déclencher le flow reauth. 4. Rafraîchir la liste des sites au poll et lancer les streams manquants. --- Constaté lors de la review de code pré-v1.0 (v0.8.1).

mat added the

v1.0 · bloquant

label

2026-08-26 05:31:53 +00:00