ca90ce1e28
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
3.2 KiB
Releve continu des cellules Pylontech
Lit le cable console Pylontech (adaptateur FTDI USB-serie) et depose un CSV par
tour dans docs/mesures/batteries/. Le service d'historisation sur le .22
ingere ces CSV (ingererCellules, tools/historise-evcs.mjs) et remplit la
table cellule, que Grafana lit. Le lecteur serie ne touche jamais la base.
Deux hotes possibles
| hote | supervision | fichier |
|---|---|---|
| Synology .17 (recommande, toujours allume) | restart: unless-stopped du conteneur |
compose.yaml |
| PC portable | boucle while |
lancer.sh (@reboot crontab) |
Le portable a montre sa limite le 20/09 : ferme, il ne releve plus, et son
@reboot a refuse de relancer sur un faux positif du garde anti-doublon — 4
jours de trou. Le NAS supprime ce mode de panne.
Dans les deux cas, un garde anti-blocage integre a pylontech-console.mjs
(--suivi) force la sortie du processus si le CSV cesse de grossir pendant plus
de 3x le pas (mini 180 s) : le port serie peut se figer en renvoyant du vide
sans jamais lever d'erreur, et sans ce garde le releve reste muet sans crasher.
La sortie fait rouvrir le port par le superviseur.
Deploiement sur le Synology .17
1. Pilote USB-serie (root, une fois + a chaque reboot)
DSM embarque usbserial.ko et ftdi_sio.ko mais ne les charge pas d'office.
charger-pilotes.sh les charge et ouvre les droits de /dev/ttyUSB0.
Automatiser via Planificateur de taches DSM -> tache declenchee « Au demarrage », utilisateur root, commande :
/volume1/homes/TMZF5455/projects/EVCS/EVCS/deploy/releve-cellules/charger-pilotes.sh
A relancer aussi manuellement (meme chemin, en root) apres avoir rebranche le cable, sinon le device n'existe pas.
2. Le conteneur (TMZF5455, membre du groupe docker -> sans sudo)
cd /volume1/homes/TMZF5455/projects/EVCS/EVCS/deploy/releve-cellules
/usr/local/bin/docker compose up -d
/usr/local/bin/docker compose logs -f
Le conteneur tourne en uid 1026:gid 100 (ni root, a cause du root_squash NFS,
ni un compte sans droit d'ecriture sur le depot). Il redemarre seul apres un
crash, un reboot du NAS, ou une sortie du garde anti-blocage.
3. Basculer depuis le portable
Sur le portable, arreter la boucle et desactiver le @reboot pour eviter deux
lecteurs sur deux cables (ou un cable deplace) :
pkill -f 'pylontech-console.mjs --port'
crontab -e # commenter la ligne @reboot .../lancer.sh
Ne JAMAIS avoir deux relevés actifs sur la meme chaine : leurs lectures s'entrelacent et produisent des valeurs fausses sans que rien ne le signale.
Verifier que ca tourne
# cote NAS
/usr/local/bin/docker logs --tail 20 evcs-releve-cellules
# cote base (.22)
ssh tmzf5455@10.10.10.22 "sudo /usr/local/bin/docker exec -i evcs-postgres \
psql -U evcs -d evcs -c \"SELECT module, max(ts) FROM cellule GROUP BY module ORDER BY 2 DESC LIMIT 6;\""
Le panneau Grafana « Sante des modules » ne montre que les modules vus dans les 2 dernieres heures : s'il est vide, le releve est arrete.
Limite connue
Le cable est sur le pack 2 (5x US2000C). Le pack 1 (4x US5000) reste hors surveillance cellule jusqu'a un 2e cable. La courbe de capacite et le SOC, eux, couvrent tout le parc (agregat du Cerbo).