Le service publie le facteur nuit prevue / nuit moyenne (sensor.evcs_nuit_maison_prevue_kwh),
le bilan l'applique a son profil de 21:30 a 09:00. Diagnostics 81/81, bilan 68/68.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
Le cable du pack 1 est a puce Prolific, sans pilote sur DSM : lu par un
portable a noyau recent. --suffixe pack1 separe les CSV des deux lecteurs ;
evcs_cellules regarde 15 min (deux lecteurs non synchronises) et publie
modules_lus (9 attendus).
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
Rebranche pendant que le conteneur tenait ttyUSB0, le cable est revenu en
ttyUSB1 : la garde cree un lien d'apres le numero de serie et recree le
conteneur quand le port change de numero.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
Deux defauts vus au retour de l'update 7.4.1 :
- le montage NFS du depot est noexec, donc la tache DSM qui appelait le chemin nu
du script donnait « Permission denied » et ne chargeait rien. Commande corrigee
en `sh <chemin>` (lit le script au lieu de l'executer).
- la boucle faisait confiance au code retour de modprobe (0 sans charger sur DSM).
Elle verifie maintenant l'etat reel via lsmod apres chaque tentative.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Constate au reboot + update DSM 7.3.2 -> 7.4.1 : le sudo passwordless de TMZF5455
a ete supprime, donc l'auto-elevation du script ne marche plus et la tache de
boot (owner 1026) n'a pas charge les pilotes -> device absent, conteneur Exited.
Les .ko existent toujours en 7.4.1. Le fix durable est une tache Planificateur
en utilisateur root, qui ne depend d'aucun sudo. Note aussi que les updates
majeurs peuvent desactiver les taches declenchees.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le .17 passe en DSM 7.4.1 (saut majeur, noyau potentiellement different). Les .ko
etaient charges par chemin fixe /lib/modules/ ; si 7.4.1 les deplace, insmod
echouait. Desormais : modprobe si dispo (gere les dependances), sinon find du .ko
dans /lib/modules et /usr/lib/modules. usbserial reste charge avant ftdi_sio.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
La tache DSM « Au demarrage » CHARGE_PILOTES a ete creee en owner 1026 (TMZF5455),
pas root (verifie en base esynoscheduler). insmod aurait echoue en silence au
boot -> pas de /dev/ttyUSB0 -> conteneur bloque. Le script se re-exec via sudo -n
(passwordless pour cet utilisateur sur le .17) quand il n'est pas root. Teste en
lançant le script sans prefixe sudo : il s'eleve et charge les pilotes.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le releve tournait sur le PC portable (deploy/releve-cellules/lancer.sh) : ferme,
il ne releve plus, et le 20/09 son @reboot a refuse de relancer sur un faux
positif du garde anti-doublon -> 4 jours de trou dans la table cellule, Grafana
"No data". Le portable n'a pas vocation a rester allume.
Deplacement vers le Synology .17 (ARCHIVE3, DS920+), toujours allume :
- compose.yaml : conteneur node:20 en uid 1026:100 (le montage NFS peut ecraser
root ; le dossier CSV est g+w pour users), device /dev/ttyUSB0 mappe, depot
monte en /depot. Ecrit les CSV comme avant ; le service d'historisation du .22
les ingere sans changement. restart:unless-stopped remplace la boucle lancer.sh.
- charger-pilotes.sh : DSM embarque usbserial.ko + ftdi_sio.ko mais ne les charge
pas d'office. Script root (Planificateur DSM au boot) qui insmod les deux et
ouvre les droits de /dev/ttyUSB0.
- README.md : deploiement, bascule depuis le portable, verification.
Garde anti-blocage dans pylontech-console.mjs (--suivi) : lireJusqua resout au
timeout au lieu de rejeter, donc un port fige renvoie du vide en boucle sans
jamais crasher -- exactement le hang du 20/09. Un controle du mtime du CSV force
process.exit(1) apres 3x le pas sans ecriture, pour que le superviseur (conteneur
ou lancer.sh) rouvre le port.
Menage : modified/*.bak-* (rollbacks locaux) ignores comme prepush-* ; ajout des
relevés de mesure batterie des sessions 16-20/09.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le proprietaire demandait si le rang dans le pack etait accessible ou si seul
le code-barres l'etait. Il l'etait depuis le debut : l'outil de releve resout
adresse <-> code-barres au demarrage mais ne l'ecrivait pas. Desormais :
- pylontech-console.mjs --suivi ecrit une colonne 'adresse' (vide en mono-module,
jamais devinee) ;
- historise-evcs.mjs l'ingere par son NOM dans cellule.rang, enregistre PAR
RELEVE et non dans une table figee — un recablage du LVHUB renumerote, et
l'historique de chaque ligne doit garder le rang vrai a son instant ;
- Grafana : colonne 'Rang' dans le tableau de sante, et la liste deroulante
des modules affiche 'rang - code-barres' quand le rang est connu.
75/75 requetes valides.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le proprietaire veut « dans Grafana le detail de chaque cellule pendant la
charge ». Le detail existait deja ; ce qui manquait etait le « pendant la
charge » — rien ne disait QUAND le module chargeait, et un ecart entre cellules
ne veut rien dire hors de son courant : le 05/09 la cellule meneuse etait a
3555 mV sous 50 A et a 3496 mV sous 30 A, meme module, meme tension de parc.
Le releve console porte le courant depuis le 17/09, mais l ingestion ecrivait
`null` : elle ne lisait que les quinze tensions. Elle repere maintenant la
colonne `courant_mA` PAR SON NOM — les US5000 et les US2000C n emettent pas les
memes colonnes, et une position ferait lire la mauvaise grandeur des qu on
deplace le cable d un pack a l autre. Absente des anciens fichiers, donc les
lignes deja versees gardent leur courant inconnu.
Deux panneaux au tableau « Les batteries ».
« Sante des modules — tous, d un coup d oeil » : le resume qu on lit en premier,
tous modules ensemble, la ou les autres panneaux demandent de choisir un module
d avance. Ecart maintenant, ecart maximum sur la periode, cellule la plus haute
et la plus basse, courant au moment du releve, date du dernier releve. Releve au
deploiement : cinq modules vivants, ecarts de 1 a 3 mV — le parc restant est
sain, les trois modules atteints sont sortis le 12/09.
« Le module chargeait-il ? » : le courant du MODULE, lu dans la table des
cellules et non dans celle du parc, ce qui permet de voir qu un module se
charge moins que ses voisins.
Verifie contre la base et pas seulement execute : 75/75 requetes valides ne
prouve que l execution, donc les deux nouvelles ont ete rejouees avec la vraie
fenetre et rendent bien les grandeurs voulues.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Suite du correctif de l onglet Home Assistant. « La journee » avait le meme
angle mort : cadre sur le jour civil, il s arretait a l heure en cours.
Fenetre portee a la journee ENTIERE (dashboard() gagne un parametre `jusqu`),
serie « Encore attendu » en gris translucide a la suite des barres mesurees,
et colonne « Reste attendu » dans le bandeau du haut, a cote de « Solaire
produit ».
Sur le telephone, aucun panneau ajoute — un panneau de plus y est un ecran de
plus a faire defiler. « Soleil restant » rejoint le bandeau Maintenant, a cote
de Excedent ; « Soleil demain » rejoint La nuit qui vient, puisque c est lui
qui decide jusqu ou la batterie peut descendre.
Trois pieges, tous dans la meme direction. La mesure ne doit pas suivre la
fenetre dans le futur : ENERGIE_SQL construisait son axe entre les deux macros
puis reportait la derniere valeur connue, ce qui aurait rempli les heures a
venir avec la puissance de l instant et gonfle l energie du jour — sa borne
haute est desormais least($__timeTo(), now()). FULL OUTER JOIN et non LEFT :
une periode a venir n a aucune ligne de mesure. Et borne haute stricte, sans
quoi une barre « 18/09 00 h » apparaissait dans La journee.
L heure EN COURS n a volontairement pas de barre de prevision : elle est deja
mesuree pour ses minutes ecoulees.
73/73 requetes valides — mais ce controle prouve l execution, pas la grandeur.
Les deux requetes de La journee ont donc ete rejouees a la main avec la vraie
fenetre : 24 lignes, mesures jusqu a 02 h, prevision de 03 h a 23 h, somme des
barres 36,95 kWh contre 37,0 annonces par le bandeau. C est ce recoupement qui
a fait apparaitre le troisieme piege.
Corrige au passage la note du 08/09 sur l acces a l API Grafana : les
apostrophes du .env sont SIMPLES et non doubles, verifie a l octet.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
MODULES=1,2,3,4,5. Le cinquieme etait vivant et ignore depuis la mise en service
du releve : constate le 16/09, la chaine enumerait un module 5 a 50,7 V / 14,6 A
/ 80 % que personne ne lisait. Son code-barres est K220803C30160323 — le seul
module sain de l'ANCIEN parc (zero cellule marquee, zero compteur, cf. §51), que
le proprietaire a garde. Ecart de cellules 6 mV contre 2 a 4 pour les quatre
Y230202C de 2023 : acceptable.
⚠️ Il faut relancer le SUPERVISEUR et pas seulement son fils : lancer.sh lit
MODULES a son demarrage, donc tuer le processus node laisse le superviseur
relancer avec l'ancienne liste.
⚠️ TROU DE 44 H dans la table cellule, du 14/09 17:01 au 16/09 13:02, explique :
le cable console etait sur le PACK 1 pendant cette periode, et les US5000
n'emettent pas le meme tableau console que les US2000C — colonnes Tlow.Id,
Thigh.Id, Vlow.Id, Vhigh.Id presentes chez les uns, absentes chez les autres.
Le parseur du releve ne sait lire que le format US2000C : sur le pack 1 il
journalise « module N : illisible » et n'ecrit rien. Rien d'autre ne le signale.
A traiter si le releve doit un jour couvrir le pack 1.
⚠️ Et mes propres commandes console s'entrelacent avec le releveur sur le meme
port serie : la garde anti-doublon de lancer.sh ne filtre que son propre motif.
Les « illisible » de 12:42 et 12:52 sont de mon fait. Arreter le releveur avant
toute lecture manuelle.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Les trois pieces soudees, parce qu aucune ne tient seule. Le defaut de la
colonne passe a faux ; plus rien dans le chemin d ecriture ordinaire ne peut le
mettre a vrai ; le libelle Grafana « selecteur change » devient « a confirmer »,
et le compteur « Etiquette douteuse » devient « A confirmer ».
L ancienne semantique — « le selecteur n a pas bouge pendant la session » — ne
prouvait rien : le selecteur est reste sur VW du 07/09 au 13/09 et les onze
sessions fausses portaient toutes true. La mesure d hier a acheve de la
disqualifier : sur douze branchements, le selecteur n a ete regle au bon moment
qu une seule fois.
Rattrapage des lignes anterieures a faux, sauf les six que le proprietaire a
arbitrees lui-meme le 13/09 — une vraie confirmation humaine, seulement donnee
de vive voix, qu il serait absurde de jeter. Une ligne de journal l explique.
Rien n est deploye : le service tourne encore l ancien code.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Verification des droits reels : SELECT sur toutes les tables, plus INSERT
sur `evenement` — un octroi deliberé et documente plus haut dans ce meme
README (les annotations qu aucun service ne peut deviner s ecrivent a la
main), mais que deux autres passages decrivaient comme « lecture seule ».
Je l ai moi-meme affirme a un pair qui prepare un acces pour un agent
externe. La consequence est concrete : confier ce role a un tiers lui
donnerait l ecriture sur le journal qui alimente les annotations Grafana,
le rapport de nuit et l attribution des transitions — et ses lignes y
seraient indiscernables des notres.
Pour un tiers : un role dedie, SELECT sur les seules tables necessaires.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le format « une ligne par grandeur » etait illisible, et la hauteur du panneau
n'en montrait que trois sur sept. Le tableau rend desormais une ligne
d'en-tetes et une ligne de valeurs, ce qui est la forme attendue pour un
resume.
C'est toujours un panneau `table` et pas un `stat` : ce dernier, sur exactement
cette requete, affichait sept « — » alors que l'API montrait qu'il recevait
sept champs de type number avec leurs valeurs. Une note le rappelle dans le
generateur pour ne pas y revenir.
Les unites reviennent en overrides puisque les libelles n'ont plus a les
porter, avec deux colorations utiles : le reseau importe passe a l'ambre au-dela
de 3 kWh et a l'orange au-dela de 8, l'autonomie a un fond vert au-dessus de
85 %.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Quatre tentatives sur le panneau stat : selecteur de champs, unites, bornes de
l'axe, GROUP BY, retrait de la colonne texte et de son override. A chaque fois
sept « — » a l'ecran.
L'acces a l'API Grafana, obtenu entre-temps, a tranche : /api/ds/query montre
que le serveur renvoyait bien sept champs de type number avec leurs valeurs, y
compris sur la fenetre exacte de la derniere capture. Ce n'etait donc ni la
requete, ni le cache du navigateur, ni le provisioning — md5 du fichier servi
et version en base verifies. Le panneau recevait les donnees et ne les rendait
pas.
Le bilan sort desormais en LIGNES, une par grandeur, dans un panneau table :
celui-ci affiche toujours ce qu'il recoit, et le format se lit tres bien pour un
bilan. L'unite est portee par le libelle, ce qui permet de melanger kWh et
pourcentage dans la meme colonne.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
L'API Grafana, enfin accessible, a montre que le serveur renvoyait bien une
ligne de valeurs au panneau : le defaut etait donc dans le rendu, pas dans la
donnee. Restaient deux elements que le panneau « Sur la periode » des vehicules,
lui fonctionnel, n'a pas : une colonne de texte dans le resultat, et un override
`custom.hidden` pose pour la masquer — propriete qui n'existe pas sur un
panneau stat.
Les deux disparaissent. Le GROUP BY, lui, reste necessaire et s'ecrit desormais
sur une expression constante, `GROUP BY (1 = 1)`, qui ne demande aucune colonne
dans le SELECT. PostgreSQL refuse `GROUP BY true` (non-integer constant) mais
accepte cette forme.
Verifie par l'API sur la fenetre « Last 24 hours » : sept champs, tous de type
number, valeurs presentes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le panneau rendait sept « — » malgre trois tentatives : correction du selecteur
de champs, ajout des unites, bornes de l'axe tirees des donnees au lieu des
macros de temps. Verifie entre-temps que ce n'etait ni le cache du navigateur
ni le rechargement — le md5 du fichier servi par Grafana est identique a celui
du depot — et que le serveur ne journalisait aucune erreur de requete.
Il ne restait qu'une difference structurelle avec l'histogramme du meme
tableau, qui partage exactement les memes CTE et s'affiche sans probleme :
celui-ci groupe par heure, le bilan agregeait globalement. Le bilan groupe
desormais sur une colonne constante, masquee a l'affichage.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le panneau rendait sept « — » alors que sa requete donnait les bons totaux en
psql, avec la substitution exacte que Grafana applique, et que le serveur ne
journalisait aucune erreur : une ligne de NULL, donc un axe de minutes vide
cote Grafana.
Les bornes de generate_series venaient de $__timeFrom() et $__timeTo(). Elles
viennent desormais du min et du max de la table sur la fenetre, et la seule
macro restante est $__timeFilter(ts) — exactement la forme du panneau « Sur la
periode » des vehicules, qui lui a toujours fonctionne.
C'est aussi plus juste physiquement : on n'extrapole plus au-dela de la
derniere mesure observee.
Note d'exploitation : le GRAFANA_ADMIN_PASSWORD du .env n'est pas celui en
service. Grafana n'applique cette variable qu'a la creation initiale de
l'admin, jamais a un compte deja existant — l'API refuse donc ce mot de passe.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le bilan rendait sept tirets et l'histogramme « No numeric fields found », alors
que verifier-dashboards donnait les deux requetes vertes : il prouve qu'une
requete s'execute, pas qu'elle s'affiche.
FILTRE_VUE ne se recopie pas d'un tableau a l'autre : cette transformation ne
garde que les colonnes nommees par la variable $vue, propre a « Le systeme ».
Sur un tableau qui n'a pas cette variable, elle filtre tout. Retiree.
champs="/.*/" est reserve aux etats d'alarme, qui sont du texte ; sur des
colonnes numeriques il empeche le rendu. Remis a "" comme le panneau « Sur la
periode » des vehicules, et les unites kWh et % ajoutees en overrides — sans
elles les chiffres etaient nus.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Il manquait le bilan qu'on cherche en premier : ce qui a ete produit, consomme,
achete, et ou c'est alle. « La journee » (evcs-journee) le donne sur la fenetre
now/d — le jour civil, pas les 24 dernieres heures, sinon deux journees se
melangent et le total de production n'est plus comparable d'un jour a l'autre.
En controlant ses chiffres, un defaut bien plus large est apparu : la voiture
annoncait 6,9 kWh la ou le compteur cumulatif de la borne et la table des
sessions donnent tous deux 3,6.
Le report de la derniere valeur connue propageait la MOYENNE de la minute au
lieu de sa DERNIERE valeur. Le 07/09 a 14:28 la borne passe de 1577 a 0 W dans
la meme minute : cette minute vaut 788 W en moyenne, et le report la maintenait
pendant les heures sans ecriture qui suivaient — 0,79 kWh fabriques sur la
seule heure de 15 h, exactement 788 x 60 / 1000.
Le defaut ne se voyait ni sur le solaire ni sur la maison, ecrits en continu.
Il frappe les grandeurs intermittentes, au premier rang la borne qui passe
l'essentiel de la journee a zero. Les colonnes « Voiture » de « Le systeme » et
« Les vehicules » etaient donc fausses depuis leur creation, en surestimation.
Corrige dans les trois constructeurs de requetes : la minute observee garde sa
moyenne, juste pour l'energie consommee dans cette minute, mais le report
propage la derniere valeur reellement lue. Aucun seuil, aucune peremption
arbitraire. Apres correction la voiture tombe a 3,6 kWh, egal au centieme a la
somme des sessions.
verifier-dashboards annoncait 73/73 avec le chiffre faux : il prouve qu'une
requete s'execute, pas qu'elle rend la bonne grandeur. Deuxieme fois en trois
jours qu'une source independante est le seul controle qui attrape le defaut.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Trois choses vues en regardant deux captures.
La tache Hyper Backup « Synology NAS 1 » echoue en zero seconde : sa
destination, le dossier partage ARCHIVEFAMILLE sur 10.10.10.22, n existe pas —
ni en clair, ni chiffre, ni dans la configuration Samba. Sa jumelle, qui vise
le dossier video du meme hote, reussit. Dix notifications d echec retrouvees,
zero reussite, la plus ancienne du 6 juin : les photos 2008-2015 n ont aucune
sauvegarde depuis trois mois. Non corrige, la machine source n accepte pas ma
cle et le choix de destination appartient au proprietaire.
Les annotations Grafana deviennent opt-in, et le genre bilan en est ecarte : a
lui seul un quart des lignes, presque toutes des bascules d un drapeau qui
change plusieurs fois par heure. Un trait vertical marque ce qui arrive, pas ce
qui clignote. Au passage les deux panneaux de comparaison affichaient huit
courbes dont quatre mortes ; ils ne montrent plus que les modules ayant emis
dans les deux dernieres heures — un critere d activite, pas un prefixe de
code-barres.
Et la marge de 50 % de la nuit est verifiee : il fallait couvrir 2,22 kWh
jusqu au croisement solaire, le bilan en avait reserve 2,65. Dix-neuf pour cent
d assurance sur un parc de quatre modules.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Valeurs negatives au point de raccordement, contacteur ferme. La mesure separe
deux phenomenes que rien ne reliait.
Le premier est bien la plaque qui cycle : sur la fenetre de midi, 9 % des
echantillons negatifs, minimum -477 W, mediane -146. Le regulateur ne rattrape
pas un delestage brutal d un kilowatt avec une consigne de repos a 200 W. Elle
passe a 700 : la courbe monte de 500 W et le minimum devient +23 W. Le surcout
va dans le bon sens, cette consigne ne s appliquant que contacteur ferme sans
session reseau — c est-a-dire apres une coupure sur SOC bas ou une fermeture
par la regle de protection, deux cas ou l on veut justement que le reseau
contribue davantage.
Le second, -2819 W pendant deux minutes, n a rien a voir : le debranchement du
vehicule a supprime 2,2 kW d un coup alors que la batterie a 93 % n absorbait
rien et que le MPPT produisait 4 kW. Aucune consigne n absorbe cela. Ce qui l
evite est le correctif du matin sur la regle de protection : la demande sur le
parc valait 741 W, le contacteur n aurait pas ete ferme, et sans reseau il n y
a rien ou injecter.
Golden 80/80, trois attendus mis a jour avec la mesure en commentaire.
Et docker n est pas dans le PATH d une session SSH sur DSM : les commandes de
deploiement appellent desormais /usr/local/bin/docker.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le linger systemd aurait fait demarrer une douzaine de services
graphiques sans session ouverte - gnome-remote-desktop et le trousseau
compris. Le proprietaire a tranche pour une entree @reboot qui ne
relance que ce releve.
Consequence technique : on ne peut pas passer par systemctl --user,
qui echouerait faute de gestionnaire de services au demarrage. Le
script fait donc lui-meme le travail d'un superviseur : garde
anti-doublon - deux processus sur le meme port entrelacent leurs
lectures et produisent des relevés faux sans que rien ne le signale -
attente si le port n'est pas encore la, redemarrage apres echec, et
journal tronque au-dela de cinq megaoctets.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le suivi n'ecrivait que l'adresse du module, traduite a l'import par
une table figee sur le pack ancien. Le cable ayant change de pack,
tout releve fait maintenant aurait ete attribue aux mauvais modules.
Le code-barres est desormais resolu au demarrage et ecrit dans le CSV ;
la table ne sert plus qu'aux anciens fichiers.
Le releve tourne sur le poste qui porte le cable serie - le port USB
est la, pas sur le Synology - et n'ecrit qu'un CSV dans le depot
partage. C'est le service d'historisation, cote Synology, qui le verse
en base : le poste n'a donc aucun mot de passe a connaitre.
Archive pour le constructeur : un dossier par code-barres, plus un
manifeste en francais, anglais et chinois qui dit ou regarder en
premier et signale que les CSV sont deja corriges de la derive
d'horloge des BMS.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le GX n'expose que l'agregat du parc : les quinze tensions d'un module
ne sortent que par la console de son BMS. Le tableau les trace, avec
les paliers d'alarme du materiel lui-meme - 3480, 3520, 3550, 3600 mV
- et met la cellule meneuse en regard du plafond de charge.
Le plafond impose par le BMS, grandeur centrale de tout ce diagnostic,
n'etait pas historise : il l'est desormais, comme l'alarme de tension
de cellule. Ils manquaient tous les deux a la memoire.
Les quatre requetes cellule echouent tant que la table n'existe pas ;
elles passeront apres redemarrage du service et import.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Quatrieme valeur : « Session », le compteur de la BORNE, celui qui vaut les
8 kWh de VRM et compte depuis le vrai debut de la charge.
Il vient de PostgreSQL et non d'InfluxDB : `sensor.evcs_hq2239dnt7p_*` n'est
pas dans les globs d'entites envoyees a InfluxDB. Plutot que de redemarrer Home
Assistant pour l'y ajouter — en pleine charge, a 4 h du matin — la valeur est
reprise de la table `session_charge`, ou elle est deja enregistree. Le panneau
passe donc en source « Mixed », chaque requete portant la sienne.
La session n'est affichee que si elle date de moins de deux heures : au-dela,
la case reste vide plutot que d'exhiber le reliquat d'une charge terminee la
veille — meme principe que la fenetre de lecture des autres panneaux.
La premiere rangee passe a sept unites de hauteur et la Batterie a neuf
colonnes : quatre et cinq valeurs cote a cote redevenaient illisibles a cinq
unites, c'est le defaut deja corrige une fois sur ce meme panneau.
54/54 requetes verifiees. Valeur attendue a l'ecran : 8,30 kWh.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le tableau annoncait 750 Wh la ou VRM affichait 8 kWh. Ce n'etait pas une
erreur de mesure mais une erreur de SOURCE : j'integrais la puissance depuis le
moment ou mon detecteur avait commence a fonctionner — 03:16 — pour une session
ouverte a 01:25.
Or la borne tient son propre compteur de session,
`sensor.evcs_hq2239dnt7p_last_session_energy`, qui vaut exactement les 8,0 kWh
de VRM et compte depuis le vrai debut. Nouvelle colonne
`energie_station_kwh` : c'est elle qui alimente desormais les totaux et le
graphique.
Mon integration est conservee en colonne « kWh integres » : l'ecart entre les
deux signale un demarrage ou un redemarrage du service en cours de session, ce
qui est une information en soi. Et elle sert de secours si la borne ne publie
rien.
Cherche au passage, sans succes : VRM affiche « Vehicule : Guest EV » mais
AUCUNE entite ne porte ce champ cote Home Assistant. « Guest EV » signifie
d'ailleurs vehicule NON identifie — Victron ne sait pas non plus qui est
branche.
50/53 : les trois requetes en echec portent sur la nouvelle colonne, que la
migration creera au prochain demarrage du service.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
« No data » sur le panneau Chargeur PV a 03:20 : la production avait ete ecrite
pour la derniere fois au coucher du soleil, 370 minutes plus tot, et ma fenetre
etait de 6 h. La valeur zero etait pourtant exacte et connue.
C'est la seconde erreur sur ce meme reglage, en sens inverse de la premiere :
- trop LARGE partout (7 jours), le panneau Reseau affichait un courant vieux de
quatorze heures, parce que ces capteurs passent en `unavailable` quand AC-IN
s'ouvre au lieu de tomber a zero ;
- trop ETROITE partout (6 heures), les entites qui publient un vrai zero au
repos disparaissent de l'ecran alors que leur derniere valeur reste juste.
Il n'y a donc pas de bonne valeur unique. Regle inscrite dans le generateur :
fenetre LARGE (24 h) pour ce qui publie un vrai zero — production PV, borne a
l'arret, trackers ; fenetre COURTE (6 h) pour ce qui disparait, c'est-a-dire
les seules grandeurs du reseau.
Consigne au passage dans le manuel : le proprietaire possede une troisieme
monture, une moto electrique Zero Motorcycles SR/F, a ajouter au selecteur fin
septembre. Avec la remarque qui compte : sa batterie et son chargeur embarque
etant bien plus petits, elle sera peut-etre le premier vehicule du foyer
electriquement distinguable des deux autres.
53/53 requetes verifiees.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le service ne journalise que lorsqu'il a ecrit quelque chose. `--tail=5`
affiche donc les cinq dernieres lignes quelles qu'elles soient, y compris des
erreurs anterieures au redemarrage : le proprietaire a relance la commande
quatre fois devant un ecran fige montrant des erreurs deja corrigees, alors que
le service tournait normalement.
`--since 2m` borne le temps et non le nombre de lignes. Ajout aussi de la
verification qui ne ment pas, parce qu'elle regarde le resultat et non le
journal : la fraicheur et l'energie accumulee de la derniere session.
Etat verifie a l'instant : derniere mise a jour il y a 19 s, 0,345 kWh
accumules sur la session JEEP en cours, 18 mesures sur les trois dernieres
minutes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
`operator is not unique: unknown * unknown`. node-postgres envoie ses
parametres SANS type ; multiplier deux d'entre eux ne permet pas a PostgreSQL
de choisir un operateur.
Et contrairement a ce que j'ai d'abord annonce, ce n'est pas l'ajout de la part
reseau qui a casse la ligne : les DEUX lignes en souffraient. La premiere
version du detecteur de session n'a jamais reussi un seul UPDATE — la session
enregistree a 02:56 affichait 0,000 kWh avec fin = debut, seul l'INSERT avait
abouti. Verifie en rejouant les trois formes contre la vraie base : l'ancienne
echoue, la nouvelle passe.
Lecon consignee dans le README : l'essai a blanc remplace l'envoi a la base par
un compteur, donc il valide la logique et JAMAIS le SQL. Une erreur de typage y
est invisible par construction. D'ou la regle — tout parametre entrant dans un
calcul porte son ::float8 — et l'obligation de lire le journal du conteneur
apres chaque deploiement du service.
Tableaux : 53/53 depuis que la colonne existe.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Demande du proprietaire : voir ce que la JEEP ou la VW encaisse dans une
session, et evaluer sur une periode (jour, semaine, mois), en assumant
l'imprecision liee a l'impossibilite d'identifier le vehicule au branchement.
Trois panneaux : les totaux par vehicule sur la periode, l'energie par periode
et par vehicule avec le meme pas adaptatif que les autres tableaux (heure /
jour / mois), et la liste des sessions.
L'incertitude est AFFICHEE plutot que masquee :
- un compteur « Etiquette douteuse » — sessions ou le selecteur a change en
cours de route, ou n'etait pas renseigne ;
- une colonne « Doute » dans le tableau ;
- une serie « Non etiquete » dans le graphique ;
- l'heure de debranchement, qui confirme apres coup puisque les deux vehicules
partent a des heures differentes.
Le commentaire du generateur consigne pourquoi aucune verification n'est
possible : electriquement les deux voitures sont indiscernables (3 680 contre
3 655 W a consigne identique de 20 A), et horairement la routine s'inverse le
week-end, donc une regle horaire serait fausse un week-end sur deux.
Ajout a la table : `energie_reseau_kwh`, la part venue du reseau, fondee sur le
`source_mode` du controleur — son intention — et non sur la puissance reseau
instantanee, laquelle peut alimenter la maison pendant que le soleil alimente
la voiture.
52/53 requetes verifiees. La seule en echec porte sur cette nouvelle colonne,
que la migration creera au prochain demarrage du service.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
L'etiquette du vehicule n'existe QUE pendant la session.
`input_select.victron_evcs_vehicle` est un reglage manuel, il change, et rien
ne conservait sa valeur au moment ou la charge avait lieu — une session d'il y
a trois semaines etait anonyme pour toujours, et toute analyse d'usage
impossible.
Nouvelle table `session_charge` : debut, fin, vehicule tel que le selecteur
l'indiquait PENDANT la session, un drapeau disant s'il a change en cours de
route, energie accumulee, puissance et courant maximum, mode source, et
l'heure de debranchement — qui confirme apres coup, les deux vehicules partant
a des heures differentes.
Le service applique lui-meme la migration au demarrage : `schema.sql` n'est
joue qu'a la creation de la base, une table ajoutee plus tard n'y arriverait
jamais. `CREATE TABLE IF NOT EXISTS` rend l'operation rejouable.
On ne DEVINE rien, et le commentaire du schema dit pourquoi :
- electriquement, la VW accepte 3 680 W et la JEEP 3 655 W a consigne
identique de 20 A — 0,1 A d'ecart, indiscernables ;
- horairement, la routine s'inverse le week-end (la femme du proprietaire
travaille samedi et dimanche matin), donc « midi = JEEP, nuit = VW » serait
faux un week-end sur deux.
Essai a blanc : la session en cours serait correctement inscrite (JEEP,
3396 W, Reseau force, profil night_hc).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Effet de bord du correctif precedent : pour montrer les alarmes, qui sont du
texte, j'avais mis « fields: /.*/ » — ce qui fait aussi remonter la colonne
_time des requetes Flux, affichee en gros au-dessus de chaque valeur.
Un panneau stat n'a besoin d'aucun champ temporel. Les requetes ne renvoient
plus que la valeur. Applique a tous les panneaux stat, pas seulement au BMS :
_time n'y servait a rien et restait un piege latent, invisible tant que le
reglage « champs numeriques seulement » le masquait.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le filtre de vue fonctionne sur le graphique en barres — la capture du
proprietaire montrait bien « Solaire, Voiture » seuls — et echouait sur « Les
flux » avec « Data is missing a time field ». La seule difference entre les
deux etait le format de sortie : `table` d'un cote, `time_series` de l'autre.
Un panneau time series accepte parfaitement une trame de type table des lors
qu'elle porte une colonne temporelle, et le rendu est identique. On aligne donc
« Les flux » sur le format dont on a la PREUVE qu'il se laisse filtrer, plutot
que de continuer a deviner comment `time_series` nomme son champ temporel.
Changement circonscrit a ce seul panneau : les trois autres tableaux utilisent
le meme generateur de requete, n'ont pas de filtre de vue, et restent en
time_series.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
