From a08820d827ba329cd8dd29b49ffccd807523049b Mon Sep 17 00:00:00 2001 From: Tallagrand Thierry Date: Thu, 24 Sep 2026 14:51:02 +0200 Subject: [PATCH] =?UTF-8?q?HANDOFF=20=C2=A775=20:=20migration=20du=20relev?= =?UTF-8?q?e=20des=20cellules=20vers=20le=20Synology=20.17?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj --- HANDOFF.md | 85 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 85 insertions(+) diff --git a/HANDOFF.md b/HANDOFF.md index 398c060..54926e4 100644 --- a/HANDOFF.md +++ b/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 `** (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*