Le paquet propose par la session Airtria portait trois entites — interrupteur
d alertes, RAM disponible, libelle d etat. Il lui manquait celle sans laquelle
les trois autres mentent : un horodatage ecrit a chaque passage.
Sans lui, un moniteur mort est indiscernable d un systeme sain. Les trois
entites gardent leur derniere valeur, qui dit « tout va bien », indefiniment.
C est exactement l incident du 08/09 sur la prevision solaire, ou 4 h 45 de
panne n ont laisse aucune trace. Et on ne peut PAS deduire la fraicheur du
last_updated des autres entites : Home Assistant ne rafraichit pas l horodatage
d un helper reecrit a l identique — une RAM stable une heure produirait la meme
illusion.
Ajoutes : l horodatage, le modele charge, un capteur d age, et deux alarmes —
moniteur muet, RAM sous le seuil ou earlyoom tue le plus gourmand.
Defaut trouve et corrige apres creation : l alarme RAM se declenchait avant que
le moniteur ait tourne une seule fois, une valeur jamais ecrite valant zero.
Une mesure qu on n a pas recue n est pas une mesure basse. Elle est desormais
conditionnee a la fraicheur.
Tableau separe des tableaux energie : ce qu il montre n a aucun rapport avec le
photovoltaique.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Treize paquets et dix-sept cartes n existaient qu en un seul exemplaire vivant
sur le partage de 10.10.10.17. La sauvegarde quotidienne les couvre contre la
perte, mais elle ne donne ni diff ni historique : le retrait des initial: du
06/09, les helpers de la reserve d orage, la politique batterie dynamique, la
carte du conseiller reecrite hier n avaient aucune trace de leur evolution.
⚠️ Ce sont des COPIES. La source de verite reste le partage — c est l inverse
de src/nodes/, et le LISEZMOI le dit en tete pour qu une prochaine session
n edite pas la copie en croyant changer l installation.
Verifie avant de verser : aucun identifiant en clair. Le paquet du bilan ne
porte que la DECLARATION de la cle Forecast.Solar, en mode password ; sa valeur
vit dans .storage, qui n entre pas ici.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le proprietaire demande comment suivre l'effet du relevement du plafond.
Verification faite : la DVCC n'apparait que dans deux tableaux de debug, et
l'ecart entre cellules comme le mode des chargeurs solaires n'apparaissent
NULLE PART — alors que ce sont exactement les trois grandeurs a regarder.
Deux capteurs modeles crees (`batterie_qui_limite.yaml`), parce que le
systeme publiait les ingredients sans jamais la grandeur :
- **Ecart entre cellules** : le BMS donne la plus haute et la plus basse,
mais c'est leur difference qui dit si le parc est sain. 2 mV aujourd'hui,
contre 168 mV sur l'ancien module 3 juste avant qu'il fasse effondrer le
courant de tout le monde. C'est le garde-fou d'un relevement de plafond.
- **Chargeurs qui se retiennent** : six entites publient leur regime et
aucune n'etait affichee, alors que c'est le seul signal DIRECT de
ressource refusee — la puissance mesuree etant censuree par construction
sur une installation sans injection. `off` ne compte pas : la nuit tout
est `off` sans que rien ne soit refuse.
Carte « Charge de la batterie — qui limite ? » sur le tableau Bilan : le
courant pris face au plafond que NOUS imposons et a celui que le BMS
autorise, idem pour la tension, puis l'ecart entre cellules et les
chargeurs brides. Avec le mode d'emploi de lecture, parce qu'une carte qui
ne dit pas comment l'interpreter se lit de travers.
Nombre de modules et capacite installee du BMS volontairement absents : ils
ne comptent que le groupe maitre (4 modules, 400 Ah pour un parc de neuf).
Le paquet du concierge vehicule entre aussi dans le depot.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
