EVCS/deploy/releve-cellules/README.md

# 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** (onglet General, PAS un compte simple),
commande :

    sh /volume1/homes/TMZF5455/projects/EVCS/EVCS/deploy/releve-cellules/charger-pilotes.sh

⚠️ **Invoquer via `sh`, PAS le chemin nu.** Le depot est monte en NFS `noexec` :
executer le script directement donne « Permission denied » (constate le 24/09,
la tache ne chargeait rien). `sh <chemin>` lit le script au lieu de l'executer.

⚠️ **La tache DOIT tourner en root.** `insmod` exige root, et une mise a jour
DSM MAJEURE efface le sudo passwordless : constate le 24/09, DSM 7.3.2 -> 7.4.1 a
supprime NOPASSWD pour TMZF5455, et une tache en compte simple n'a alors plus
aucun moyen de s'elever. Le script tente bien `sudo -n` en secours, mais ce
secours disparait au premier update majeur. Une tache root, elle, ne depend de
rien et survit aux updates.

Apres un update DSM majeur, verifier aussi que la tache n'a pas ete DESACTIVEE
(les updates majeurs desactivent souvent les taches declenchees).

A relancer manuellement apres avoir rebranche le cable : DSM -> selectionner la
tache -> « Executer » (elle tourne en root), ou en terminal `sudo charger-pilotes.sh`
avec le mot de passe.

### 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).

## Garde contre les debranchements (25/09/2026)

Debrancher puis rebrancher le cable recree `/dev/ttyUSB0` accessible a root
seul : le conteneur (uid 1026) meurt (« EIO: i/o error ») et ne repart pas.
Et le NUMERO du port change : rebranche pendant que le conteneur tenait
`ttyUSB0` ouvert, le cable est revenu en `ttyUSB1` (25/09). `surveiller-port.sh`
corrige les deux toutes les 5 minutes, en root : pilotes recharges si absents,
lien stable **`/dev/pylontech-pack2`** cree d'apres le NUMERO DE SERIE du cable
(`A78KC4LE`, jamais l'ordre d'enumeration), droits rouverts, conteneur RECREE
si le port a change de numero (Docker resout le lien a la creation), relance
s'il est simplement arrete. `compose.yaml` mappe `/dev/pylontech-pack2` sur
`/dev/ttyUSB0` dans le conteneur. Un 2e cable FTDI s'ajoutera a la liste
`CABLES` du script, avec son propre service. Il ne fait rien si le cable est debranche, et ne journalise (tag
`evcs-releve`, `journalctl -t evcs-releve`) que lorsqu'il agit.

Pose en timer systemd (le Planificateur DSM n'a pas d'ajout en ligne de
commande ; meme choix que `openclaw-session-rotate.timer`) :

    /etc/systemd/system/evcs-releve-port.service   # ExecStart=/bin/sh <depot>/deploy/releve-cellules/surveiller-port.sh
    /etc/systemd/system/evcs-releve-port.timer     # OnBootSec=3min, OnUnitActiveSec=5min

⚠️ Pour ARRETER volontairement le releve, arreter d'abord le timer, sinon il
relance le conteneur dans les 5 minutes :

    sudo systemctl stop evcs-releve-port.timer && sudo systemctl disable evcs-releve-port.timer

⚠️ Une mise a jour majeure de DSM peut effacer ces fichiers (elle a deja
efface le sudo NOPASSWD, voir plus haut) : reverifier
`systemctl list-timers | grep evcs` apres chaque MAJ.

⚠️ Seuls les cables a puce **FTDI** fonctionnent sur ce NAS : DSM (noyau 4.4)
n'embarque pas de pilote Prolific PL2303, et le modele `067b:23a3` n'est de
toute facon reconnu que par des noyaux recents (verifie sur la Spark et le PC
maison, noyaux 7.0). Essai du 25/09 : cable PL2303 illisible, retire.