Chien de garde EVCS : remise en etat sur quand le controleur se tait

Le controleur pilote depuis cette nuit la consigne de puissance reseau.
S il meurt en pleine session, elle reste haute et le reseau reprend la
place du solaire toute la journee. Ce chien de garde repare ce risque.

Signal de vie : l API d executions n8n, pas un helper HA. Verifie que HA
ne rafraichit pas l horodatage d un input_text reecrit a l identique --
surplus_state paraissait fige depuis 40 min alors que tout tournait.

Il agit en MQTT direct sur le GX Venus, troisieme machine independante
des deux NAS, jamais via HA ni via le cloud Tuya. Il ne decide rien : il
remet la consigne au repos, arrete la borne, et se tait. Une seule
action par panne, verrou jusqu au retour du controleur.

Tests : controleur vivant, panne simulee, et verrou sur 5 cycles.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ

HANDOFF.md

@@ -2183,3 +2183,79 @@ attente depuis le 27/08 est donc caduque.
 Le contrôleur écrit maintenant la consigne réseau (§31). S'il s'arrête en pleine
 session, elle reste haute et la substitution de journée revient. Ce risque
 n'existait pas avant cette nuit : il justifie à lui seul un chien de garde.
+
+## 33. Session du 01/09/2026 (nuit) — Chien de garde EVCS sur le second Synology
+
+### Ce qu'il protège
+Le contrôleur pilote depuis §31 la consigne de puissance réseau de l'ESS. S'il
+s'arrête **en pleine session**, elle reste haute et le réseau se substitue au
+solaire toute la journée suivante. Ce risque est né cette nuit ; le chien de
+garde existe d'abord pour lui. Il couvre au passage l'incident du 09/07
+(NAS éteint la nuit, EDF laissé fermé jusqu'au matin).
+
+### Le signal de vie : surtout PAS un helper Home Assistant
+Piège trouvé en le construisant, et vérifié : **HA ne rafraîchit pas
+l'horodatage d'un `input_text` réécrit à l'identique.** À 02:52,
+`victron_evcs_surplus_state` paraissait figé depuis 2 440 s alors que le
+contrôleur tournait normalement (`charging_hold_grid` stable depuis 02:12, et la
+raison tronquée à 255 caractères perdait justement les champs variables). Un
+helper HA est un mauvais battement de cœur.
+
+Signal retenu : **l'API d'exécutions de n8n**
+(`GET /api/v1/executions?workflowId=...&limit=3`). Elle prouve que la boucle
+s'exécute, et son absence couvre indifféremment « n8n arrêté », « NAS éteint »
+et « réseau coupé ». Zéro modification du contrôleur, zéro helper à créer.
+Cas supplémentaire traité : trois exécutions consécutives en `error` = le
+contrôleur tourne à vide (typiquement HA inaccessible) → considéré mort.
+
+### Ce qu'il fait, et surtout ce qu'il ne fait pas
+- Il ne prend **aucune** décision d'énergie : ni seuil, ni démarrage. Il remet
+  l'état sûr par défaut (consigne → 50 W, borne arrêtée) et se tait.
+- Il ne touche **pas** au contacteur EDF. C'est un Tuya *cloud* (§32), donc un
+  actionneur non fiable en secours ; et ce n'est pas nécessaire : contacteur
+  fermé + consigne au repos = autoconsommation normale, la maison passe sur la
+  batterie jusqu'au SOC minimal puis le réseau reprend seul. État sûr.
+- Il n'utilise **ni HA ni le cloud** pour agir : MQTT direct sur le GX Venus
+  (10.10.10.9, portail `c0619ab34ac5`), troisième machine indépendante des deux
+  NAS. Topics vérifiés en lecture avant tout code :
+  `settings/0/Settings/CGwacs/AcPowerSetPoint`, `evcharger/40/StartStop`,
+  `evcharger/40/Ac/Power`, `battery/512/Soc`, `system/0/Ac/Grid/L1/Power`.
+  Broker sans authentification, keepalive `R/<portail>/keepalive` obligatoire.
+- **Une seule action par panne**, puis verrou jusqu'au retour d'un signe de vie.
+  Sans ce verrou, une coupure réseau entre les deux NAS ferait rejouer l'action
+  à chaque cycle pendant que le contrôleur, vivant, la défait : un oscillateur
+  de plus, dans un projet qui en a déjà corrigé quatre.
+
+### Réglages
+Seuil de silence **600 s** (20 cycles manqués) : assez long pour ignorer un
+hoquet, assez court pour qu'une panne nocturne ne coûte pas une journée de
+production. Période 60 s. Consigne de repos 50 W (défaut Victron).
+
+### Tests passés
+1. Contrôleur vivant → aucune écriture, une ligne de veille par heure.
+2. Panne simulée (`--simulate-dead --dry-run`) → détection, deux écritures
+   annoncées et supprimées, message d'alerte complet avec l'état du GX.
+3. Verrou : 5 cycles de panne consécutifs → **1 alerte, 2 écritures**, puis
+   silence.
+
+### Déploiement (action utilisateur)
+`deploy/watchdog/compose.yaml`, à lancer **sur 10.10.10.22 uniquement** :
+```
+cd /volume2/projects/EVCS/EVCS/deploy/watchdog
+cp watchdog.env.exemple watchdog.env     # y coller la clé API n8n
+docker compose up -d && docker compose logs -f
+```
+Le dépôt est monté en **lecture seule** ; seul le journal est écrit, hors dépôt.
+`node_modules` (14 Mo, `mqtt` 5.15.2) est **sans dépendance native** — le
+répertoire installé depuis le poste fonctionne tel quel dans le conteneur
+alpine, et il vit déjà physiquement sur 10.10.10.22 (`/mnt/projects` = export
+`10.10.10.22:/volume2/projects`).
+
+⚠️ **Ne jamais le lancer sur 10.10.10.17** : un chien de garde hébergé par la
+machine qu'il surveille meurt avec elle.
+
+### Ce qu'il ne couvre pas encore
+Le contacteur EDF reste incommandable si internet tombe (Tuya cloud). Un
+contacteur local — ou un `localtuya` — est le prochain vrai gain de résilience.
+La sauvegarde (6 Mo d'identité vers Gitea, 6,1 Go d'historique en hebdomadaire
+avec `sqlite3 .backup`) et le secours froid n8n restent à faire.