2 Commits

Author SHA1 Message Date
Tallagrand Thierry
7d76319509 Releve cellules : le pack 2 compte CINQ modules, pas quatre
MODULES=1,2,3,4,5. Le cinquieme etait vivant et ignore depuis la mise en service
du releve : constate le 16/09, la chaine enumerait un module 5 a 50,7 V / 14,6 A
/ 80 % que personne ne lisait. Son code-barres est K220803C30160323 — le seul
module sain de l'ANCIEN parc (zero cellule marquee, zero compteur, cf. §51), que
le proprietaire a garde. Ecart de cellules 6 mV contre 2 a 4 pour les quatre
Y230202C de 2023 : acceptable.

⚠️ Il faut relancer le SUPERVISEUR et pas seulement son fils : lancer.sh lit
MODULES a son demarrage, donc tuer le processus node laisse le superviseur
relancer avec l'ancienne liste.

⚠️ TROU DE 44 H dans la table cellule, du 14/09 17:01 au 16/09 13:02, explique :
le cable console etait sur le PACK 1 pendant cette periode, et les US5000
n'emettent pas le meme tableau console que les US2000C — colonnes Tlow.Id,
Thigh.Id, Vlow.Id, Vhigh.Id presentes chez les uns, absentes chez les autres.
Le parseur du releve ne sait lire que le format US2000C : sur le pack 1 il
journalise « module N : illisible » et n'ecrit rien. Rien d'autre ne le signale.
A traiter si le releve doit un jour couvrir le pack 1.

⚠️ Et mes propres commandes console s'entrelacent avec le releveur sur le meme
port serie : la garde anti-doublon de lancer.sh ne filtre que son propre motif.
Les « illisible » de 12:42 et 12:52 sont de mon fait. Arreter le releveur avant
toute lecture manuelle.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
2026-09-16 13:08:06 +02:00
Tallagrand Thierry
a9047d1391 Le releve part d'une entree crontab, pas d'un service utilisateur
Le linger systemd aurait fait demarrer une douzaine de services
graphiques sans session ouverte - gnome-remote-desktop et le trousseau
compris. Le proprietaire a tranche pour une entree @reboot qui ne
relance que ce releve.

Consequence technique : on ne peut pas passer par systemctl --user,
qui echouerait faute de gestionnaire de services au demarrage. Le
script fait donc lui-meme le travail d'un superviseur : garde
anti-doublon - deux processus sur le meme port entrelacent leurs
lectures et produisent des relevés faux sans que rien ne le signale -
attente si le port n'est pas encore la, redemarrage apres echec, et
journal tronque au-dela de cinq megaoctets.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
2026-09-05 20:40:40 +02:00