Releve des cellules sur le Synology .17 + garde anti-blocage

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

deploy/releve-cellules/README.md

@@ -0,0 +1,76 @@
+# 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).