HANDOFF §75 : migration du releve des cellules vers le Synology .17

Le releve serie tournait sur le portable et est mort 4 jours au reboot du 20/09.
Migre sur le .17 (conteneur node + tache de boot root/sh chargeant les pilotes).
Survie prouvee de bout en bout sur reboot + saut majeur DSM 7.3.2 -> 7.4.1, qui a
revele et fait corriger deux pieges (NFS noexec, sudo passwordless efface par
l'update). @reboot du portable retire.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj

HANDOFF.md

@@ -7351,3 +7351,88 @@ les jours ou la batterie s'est remplie tot.)
 
 ---
 *Document mis a jour le : 20/09/2026 — nuit LVHUB (trames etendues mortes cote Venus), P11-bis + bouton reset + alerte, courbe batterie remesuree (plate 0,30, ~23 kWh utiles), top-off 52,8 V*
+
+## 75. Session du 24/09/2026 — Le releve des cellules migre du portable vers le Synology .17
+
+### Le declencheur
+Le releve serie des cellules Pylontech tournait sur le PC PORTABLE (boucle
+`deploy/releve-cellules/lancer.sh`, @reboot crontab). Il est mort le **20/09 a
+17:29** : le portable a redemarre a 18:13, son garde anti-doublon a vu un
+`pgrep` transitoire et a refuse de relancer -> **4 jours de trou** dans la table
+`cellule`, Grafana « No data » (§74 finissait juste avant ce constat). Le
+portable n'a pas vocation a rester allume ; le proprietaire a propose d'utiliser
+le **.17** (ARCHIVE3, DS920+), toujours allume, avec le cable FTDI sur un port
+USB du NAS.
+
+### Ce qui a rendu la migration possible (verifie, pas suppose)
+- DSM embarque les pilotes `usbserial.ko` + `ftdi_sio.ko` (presents dans
+  `/lib/modules/`), simplement pas charges d'office. **Verrou decisif leve.**
+- Le .17 monte deja le depot en NFS : `10.10.10.22:/volume2/projects` ->
+  `/volume1/homes/TMZF5455/projects`. Le conteneur ecrit donc les CSV dans le
+  meme `docs/mesures/batteries/` que lit le service d'historisation du **.22**.
+  **Un seul maillon bouge : le lecteur serie.** Toute la chaine aval est
+  inchangee.
+- ⚠️ Le montage NFS est **`noexec`** : node LIT le .mjs (OK), mais un script ne
+  peut pas etre EXECUTE directement depuis ce montage.
+
+### Ce qui a ete construit (`deploy/releve-cellules/`)
+- **`compose.yaml`** : conteneur `node:20-bookworm-slim`, `restart:
+  unless-stopped`, device `/dev/ttyUSB0` mappe, depot monte en `/depot`. Tourne
+  en **`user: 1026:100`** (PAS root : le NFS peut ecraser root via root_squash ;
+  le dossier CSV est g+w pour `users`). TMZF5455 est dans le groupe `docker` ->
+  compose sans sudo. Remplace la boucle `lancer.sh`.
+- **`charger-pilotes.sh`** : charge les modules (verifie via `lsmod`, ne fait PAS
+  confiance au code retour de `modprobe`) et `chmod 666 /dev/ttyUSB0` (le
+  conteneur n'est pas root). A lancer au boot en **root**.
+- **`README.md`** : deploiement, bascule depuis le portable, verification.
+
+### Garde anti-blocage ajoute a `pylontech-console.mjs` (--suivi)
+Cause racine de la panne du 20/09 identifiee : **`lireJusqua` resout au timeout
+au lieu de rejeter**, donc un port fige renvoie du vide en boucle sans jamais
+crasher — `restart: unless-stopped` ne l'aurait pas rattrape. 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. Protege les deux hotes.
+
+### L'EPREUVE DU FEU : reboot + saut majeur DSM 7.3.2 -> 7.4.1 le meme coup
+Le proprietaire a tout tente d'un coup. **Le premier boot a echoue**, revelant
+deux pieges que l'update majeur cree — desormais corriges et **documentes dans
+le README** :
+
+1. **`noexec`** : la tache DSM appelait le CHEMIN NU du script -> « Permission
+   denied ». Corrige : commande **`sh <chemin>`** (lit au lieu d'executer).
+2. **L'update majeur EFFACE le sudo passwordless** : DSM 7.4.1 a supprime le
+   NOPASSWD de TMZF5455, donc l'auto-elevation `sudo -n` du script est morte.
+   Parade durable : la **tache de boot tourne en root** (aucun sudo requis). Un
+   update majeur peut aussi DESACTIVER les taches declenchees — a reverifier.
+
+Autres faits etablis : le noyau est **inchange** (4.4.302+ en 7.4.1, donc pas de
+souci de vermagic) ; les `.ko` existent toujours ; le cable FTDI est bien
+enumere (`0403:6001 FT232R USB UART`). `insmod` en root fonctionne sans erreur.
+
+### Preuve du dernier maillon (reboot propre, ZERO intervention)
+Second reboot, sans rien charger a la main :
+```
+uptime 14 min  ·  /dev/ttyUSB0 cree a 14:14:11 en crw-rw-rw- (666)
+conteneur Up  ·  base .22 ingere les 5 modules (dernier point 14:24)
+```
+Le **666** est la preuve decisive : seul `charger-pilotes.sh` fait ce chmod, et
+il n'a pas ete lance a la main -> la tache de boot (root, `sh`) s'est executee
+seule. Chaine complete automatique validee.
+
+### Config finale de la tache DSM (a ne pas casser)
+Planificateur de taches DSM, tache declenchee **« Au demarrage »**,
+**utilisateur = root**, commande :
+```
+sh /volume1/homes/TMZF5455/projects/EVCS/EVCS/deploy/releve-cellules/charger-pilotes.sh
+```
+Le `@reboot lancer.sh` du portable est **retire** de son crontab (remplace par
+une note) : ne jamais le reactiver, il ferait un second lecteur sur la meme
+chaine (relevés faux, silencieux).
+
+### Limite inchangee
+Le cable est sur le **pack 2** (5x US2000C) ; le **pack 1** (US5000) reste hors
+surveillance cellule jusqu'au 2e cable en commande. La courbe de capacite et le
+SOC couvrent tout le parc (agregat Cerbo).
+
+---
+*Document mis a jour le : 24/09/2026 — releve migre sur le Synology .17 (conteneur + tache boot root/sh), survie prouvee sur reboot + update DSM 7.4.1*