0fe24ff950
Valide par le proprietaire le 16/09. Le service publie desormais sensor.evcs_historisation_heartbeat a chaque cycle : etat = horodatage ISO 8601 UTC, attributs statut (ok|degrade), base_joignable, cycles_en_echec, dernier_echec. Forme figee avec la session OpenClaw pour que les deux battements du systeme soient identiques. POURQUOI UN CAPTEUR DEDIE. Mesure du 16/09 : Home Assistant ne materialise pas une ecriture identique, et last_reported — le champ introduit en 2024 pour marquer chaque remontee d'etat — est rigoureusement EGAL a last_changed. Aucun champ de l'API ne distingue donc un ecrivain mort d'un ecrivain qui republie la meme valeur. Sur une installation saine, trois entites sur cinq paraissaient figees. La vivacite se lit donc sur ce capteur seul, dont l'etat est un horodatage : il change forcement a chaque ecriture. L'appel est HORS du try/catch du cycle, dans les deux branches. C'est tout le correctif : base morte, le battement part quand meme en portant degrade et la cause. Avant, un cycle en echec n'ecrivait que sur console.error, et l'incident n'etait journalise qu'au RETOUR a la normale — dans PostgreSQL, donc jamais quand c'est PostgreSQL qui est tombe. ⚠️ CE QUE LE TEST A TROUVE, ET QUI RENDAIT LE BATTEMENT INUTILE. Eprouve sur une base JETABLE derriere un relais TCP coupable a volonte (pas sur la production : deux instances sur la meme base double-compteraient l'energie des sessions, le UPDATE energie_kwh = energie_kwh + ... n'est pas idempotent). Premier essai : le service a CRASHE a la coupure. Le client pg emet un evenement 'error' sur le socket ; sans ecouteur, c'est une exception non capturee qui ne passe PAS par le try/catch du cycle — il n'attend qu'une promesse — et qui tue le processus. Le service mourait donc exactement dans la panne que le battement existe pour signaler. Trois correctifs qui en decoulent : un ecouteur 'error' qui marque la connexion morte au lieu de faire tomber le processus ; une reconnexion, un client pg n'etant pas reutilisable apres erreur (sans elle le service resterait vivant mais definitivement muet) ; et une connexion initiale non fatale, pour qu'une base absente au demarrage ne tue pas le service — un service mort ne signale rien. Sequence complete verifiee : base vivante -> ok ; coupure -> service VIVANT, degrade, base_joignable false, cycles_en_echec 2, cause « connect ECONNREFUSED » ; retour -> reconnexion automatique, ok, et l'episode journalise avec sa duree. Le message de reprise disait « Home Assistant injoignable » quelle que soit la cause ; il nomme desormais ce qui a reellement echoue. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
EVCS
@ 5e6798b702