Files
EVCS/deploy/releve-cellules/charger-pilotes.sh
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

38 lines
1.4 KiB
Bash
Executable File

#!/bin/sh
# Charge le pilote USB-serie sur le Synology .17 (ARCHIVE3, DS920+) et rend le
# port accessible au conteneur du releve. A LANCER EN ROOT.
#
# Pourquoi : DSM 7.3.2 embarque les modules (/lib/modules/usbserial.ko et
# ftdi_sio.ko) mais ne les charge pas d'office, et un cable branche ne cree donc
# aucun /dev/ttyUSB*. Ce script charge les deux modules puis ouvre les droits du
# device (le conteneur tourne en uid 1026, pas en root).
#
# QUAND : au demarrage du NAS, ET a chaque fois qu'on rebranche le cable apres
# coup. A automatiser via Planificateur de taches DSM -> tache declenchee
# « Au demarrage », utilisateur root, commande :
# /volume1/homes/TMZF5455/projects/EVCS/EVCS/deploy/releve-cellules/charger-pilotes.sh
#
# Idempotent : relançable sans risque.
for ko in usbserial ftdi_sio; do
if ! /sbin/lsmod | grep -q "^$ko "; then
/sbin/insmod "/lib/modules/$ko.ko" 2>/dev/null \
&& echo "$ko charge" \
|| echo "$ko : insmod en echec (deja charge ? autre pilote ?)"
else
echo "$ko deja charge"
fi
done
# Laisse le temps a udev de creer le device si le cable est deja branche.
sleep 2
if [ -e /dev/ttyUSB0 ]; then
chmod 666 /dev/ttyUSB0
echo "/dev/ttyUSB0 present, droits ouverts :"
ls -l /dev/ttyUSB0
else
echo "/dev/ttyUSB0 absent : cable non branche, ou adaptateur non reconnu."
echo "Rebrancher le cable puis relancer ce script."
fi