5 Commits

Author SHA1 Message Date
Tallagrand Thierry
7f97e8a85d Releve cellules : port stable par numero de serie (/dev/pylontech-pack2)
Rebranche pendant que le conteneur tenait ttyUSB0, le cable est revenu en
ttyUSB1 : la garde cree un lien d'apres le numero de serie et recree le
conteneur quand le port change de numero.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
2026-09-25 16:53:27 +02:00
Tallagrand Thierry
5ba52023fd Releve cellules : garde contre les debranchements (timer 5 min sur le .17)
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
2026-09-25 16:47:23 +02:00
Tallagrand Thierry
983cff3ec5 charger-pilotes : chargement verifie par lsmod + commande via sh (noexec NFS)
Deux defauts vus au retour de l'update 7.4.1 :
- le montage NFS du depot est noexec, donc la tache DSM qui appelait le chemin nu
  du script donnait « Permission denied » et ne chargeait rien. Commande corrigee
  en `sh <chemin>` (lit le script au lieu de l'executer).
- la boucle faisait confiance au code retour de modprobe (0 sans charger sur DSM).
  Elle verifie maintenant l'etat reel via lsmod apres chaque tentative.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
2026-09-24 13:18:17 +02:00
Tallagrand Thierry
ef45ca2fd4 README releve : la tache DSM DOIT tourner en root (update 7.4.1 a efface NOPASSWD)
Constate au reboot + update DSM 7.3.2 -> 7.4.1 : le sudo passwordless de TMZF5455
a ete supprime, donc l'auto-elevation du script ne marche plus et la tache de
boot (owner 1026) n'a pas charge les pilotes -> device absent, conteneur Exited.
Les .ko existent toujours en 7.4.1. Le fix durable est une tache Planificateur
en utilisateur root, qui ne depend d'aucun sudo. Note aussi que les updates
majeurs peuvent desactiver les taches declenchees.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
2026-09-24 13:10:28 +02:00
Tallagrand Thierry
ca90ce1e28 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
2026-09-24 12:24:06 +02:00