From ee1ca8aef77dfa641107331eb2991c60a41144b6 Mon Sep 17 00:00:00 2001 From: Tallagrand Thierry Date: Wed, 16 Sep 2026 08:20:22 +0200 Subject: [PATCH] last_reported ne sauve pas last_changed : la vivacite appartient au battement de coeur seul MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit En outillant la session OpenClaw, recherche du champ qui distinguerait « pas ecrit » de « ecrit a l identique ». Home Assistant expose last_reported depuis 2024, cense marquer chaque remontee d etat meme sans changement de valeur. Il ne sert a rien ici : mesure sur cinq entites, il est rigoureusement EGAL a last_changed, alors que le controleur reecrit source_mode et night_target_soc a chaque cycle de 30 s. Consequence generale : aucun champ de l API ne distingue un ecrivain mort d un ecrivain qui republie la meme valeur. L anciennete d une entite metier n est donc jamais une preuve de panne. Releve sur une installation saine : vehicle_connected inchange depuis 752 min, night_target_soc 194, source_mode 139 — trois faux positifs sur cinq entites. Regle adoptee avec OpenClaw : la vivacite se lit sur un battement de coeur dedie dont l etat est un horodatage, seule entite dont l immobilite soit interpretable. Les entites metier se lisent pour leur VALEUR, jamais pour leur fraicheur. « inchange depuis X » est un fait, « fige » est un verdict. Co-Authored-By: Claude Fable 5.1 Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj --- HANDOFF.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/HANDOFF.md b/HANDOFF.md index 4e6b85b..110a9e2 100644 --- a/HANDOFF.md +++ b/HANDOFF.md @@ -2202,6 +2202,33 @@ contrôleur tournait normalement (`charging_hold_grid` stable depuis 02:12, et l raison tronquée à 255 caractères perdait justement les champs variables). Un helper HA est un mauvais battement de cœur. +⚠️ **COMPLÉTÉ LE 16/09/2026 — et c'est pire que « un mauvais battement de +cœur ».** En outillant la session OpenClaw j'ai cherché le champ qui +distinguerait « pas écrit » de « écrit à l'identique ». Home Assistant expose +`last_reported` depuis 2024, précisément censé marquer chaque remontée d'état +même sans changement de valeur. **Il ne sert à rien ici** : mesuré sur cinq +entités, il est rigoureusement ÉGAL à `last_changed`. Or le contrôleur réécrit +`source_mode` et `night_target_soc` à chaque cycle de 30 s (`execute: true`, +inconditionnel) — Home Assistant ne matérialise tout simplement pas une écriture +identique, sur aucun des deux horodatages. + +**Conséquence générale : aucun champ de l'API ne permet de distinguer un +écrivain mort d'un écrivain qui republie la même valeur.** L'ancienneté d'une +entité métier n'est donc JAMAIS une preuve de panne, et un système stable +produit des entités immobiles par construction. Relevé à 08:15 sur une +installation parfaitement saine : `vehicle_connected` inchangé depuis 752 min +(la voiture est branchée depuis la veille 19:43), `night_target_soc` depuis +194 min (hors session de nuit, la cible n'a plus de raison de bouger), +`source_mode` depuis 139 min (la voiture est pleine, le système reste en +« Bloqué »). Trois faux positifs sur cinq entités. + +**Règle qui en découle, adoptée avec la session OpenClaw : la vivacité se lit +sur un battement de cœur DÉDIÉ dont l'état est un horodatage — la seule entité +dont l'immobilité soit interprétable, parce que sa valeur change forcément à +chaque écriture. Les entités métier se lisent pour leur VALEUR, jamais pour leur +fraîcheur.** Et en vocabulaire : « inchangé depuis X » est un fait, « figé » est +un verdict ; ne pas transformer le premier en second. + 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 »