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
`bucketHourly` garde la derniere valeur de chaque heure : le delta entre H-1
et H est l'energie depensee PENDANT H. `deltaSeries` le rangeait sous H-1.
Discret sur un compteur dense, catastrophique sur un compteur epars — et les
compteurs de cette installation le sont : `ac_in_1_to_ac_out` ne peuple que 57
heures sur 267, `evcs_total` 57 sur 264, parce qu'ils n'emettent que lorsqu'ils
avancent. Une heure vide vaut « zero energie », donc toute l'energie d'un
intervalle a trou a ete consommee pendant l'heure FINALE. Rangee sous l'heure
initiale, l'import reseau de la nuit suivante atterrissait sur la derniere
heure de la nuit precedente.
Mesure du 25/08 : consumption_p50[8] = 2,90 kWh/h pour 0,80 reellement — six
echantillons sur douze portaient un delta etale sur 17 heures. Le bilan
reclamait environ deux fois trop d'energie le matin (3,37 kWh annonces a 06 h
contre 1,35 mesures), et donc un SOC requis de 44,5 % la ou 31 % suffisait.
L'enveloppe de production etait decalee de la meme heure, ce qui a contribue a
surestimer la part matinale de la production dans le journal de chantier.
Ajoute aussi un statut `degrade` : le bilan publie ses chiffres quand aucun
croisement n'apparait sur l'horizon ou quand les heures de deficit reposent sur
une forme minoree, mais il ne les presente plus comme fiables. La nuit du 25/08,
avant la mise en service de la courbe horaire, il a publie un SOC requis de
100 % avec un statut `ok`.
Tests 36 -> 37, dont `compteur-epars-attribution-horaire` (rafale reseau de
1/2/3 kWh a 01/02/03 h : montants distincts pour qu'un decalage d'un cran soit
impossible a confondre). Mutation verifiee : l'ancienne attribution le fait
echouer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Les cartes markdown utilisaient un bloc YAML replie (content: >), qui remplace
les retours a la ligne par des espaces : les tableaux markdown perdaient leur
structure et s'affichaient comme une ligne de texte avec des barres verticales.
Passage en bloc litteral (content: |) sur les six cartes, et le tableau des
profils emet desormais chaque ligne sur la meme ligne que la boucle, sinon
Jinja intercale une ligne vide entre chaque rangee et casse le tableau.
Ajout d'un repli lisible quand les profils ne sont pas encore publies.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Dashboard YAML dedie "bilan-energetique", declare dans configuration.yaml et
copie versionnee dans dashboards/ du depot.
Vue Bilan : la comparaison qui decidera du cablage — seuil calcule, seuil fixe
encore en vigueur, SOC reel — avec un commentaire automatique disant lequel des
deux est trop haut ou trop bas ; la decision immediate ; la prochaine traversee
deficitaire ; une alerte conditionnelle chiffrant la capacite manquante quand
meme une batterie pleine ne passe pas ; l'etat de bridage de la production avec
son motif ; deux graphiques d'historique sur 48 h.
Vue Profils et reglages : tableau horaire des quatre profils avec le taux de
censure par heure, capacite batterie modifiable, kill-switch, statut.
configuration.yaml sauvegarde dans SAVE_CONFIG/ avant modification,
check_config valide, redemarrage HA effectue, journal sans erreur nouvelle.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
