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
77 lines
3.2 KiB
Markdown
77 lines
3.2 KiB
Markdown
# 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).
|