Commit Graph

4 Commits

Author SHA1 Message Date
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
8112701122 charger-pilotes.sh : recherche dynamique des modules (mise a jour DSM 7.4)
Le .17 passe en DSM 7.4.1 (saut majeur, noyau potentiellement different). Les .ko
etaient charges par chemin fixe /lib/modules/ ; si 7.4.1 les deplace, insmod
echouait. Desormais : modprobe si dispo (gere les dependances), sinon find du .ko
dans /lib/modules et /usr/lib/modules. usbserial reste charge avant ftdi_sio.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
2026-09-24 13:07:21 +02:00
Tallagrand Thierry
16516e3973 charger-pilotes.sh : auto-elevation root (tache DSM en utilisateur simple)
La tache DSM « Au demarrage » CHARGE_PILOTES a ete creee en owner 1026 (TMZF5455),
pas root (verifie en base esynoscheduler). insmod aurait echoue en silence au
boot -> pas de /dev/ttyUSB0 -> conteneur bloque. Le script se re-exec via sudo -n
(passwordless pour cet utilisateur sur le .17) quand il n'est pas root. Teste en
lançant le script sans prefixe sudo : il s'eleve et charge les pilotes.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
2026-09-24 12:55:57 +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