datalist reste local, mais data <adresse> history <n> est adressable
et rend l'enregistrement complet, quinze cellules comprises. Les trois
modules de la chaine ancienne sont donc extraits d'un seul
branchement, tous corriges du meme decalage lu au chronometre : 369
minutes. Les jeux sont enfin comparables entre eux, ce que les
decalages deduits - divergents de deux heures et demie - ne
permettaient pas.
Le module d'adresse 2 donne le temoin qui manquait : meme chaine,
memes courants, memes journees, et ses quinze cellules tiennent dans
onze millivolts d'amplitude les unes des autres, ecart median 6 mV.
Ce qui a tue les autres ne vient donc ni du regime de charge, ni du
pilotage, ni de l'installation.
Sur cette base commune la cellule 14 du module ...0322 passe a 273 mV
et rejoint les atteintes : dix cellules, pas neuf.
L'horloge se propage bien du maitre a sa chaine - j'avais conclu
l'inverse en verifiant une seconde apres l'ecriture, il en faut vingt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
K220803C30160323 complete l'inventaire : les huit modules sont nommes.
La carte adresse -> code-barres ne vaut que pour la chaine du pack
ancien, le pack recent renumerotant lui aussi de 1 a 4 ; l'appliquer
a l'autre chaine attribuerait ses relevés aux mauvais modules.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le module ecrit une heure de mur LOCALE. Je l'interpretais comme de
l'UTC, ce qui ajoutait exactement le decalage de Paris a chaque
decalage deduit : d'ou les +7 h 27 et +9 h 59 qui semblaient absurdes
et qui, corriges, tombent sur les valeurs mesurees au chronometre.
La deduction redevient donc fiable, et chaque export voit desormais
son dernier enregistrement atterrir sur l'heure de l'export lui-meme.
Les valeurs mesurees restent en commentaire pour controler la
deduction, pas pour la remplacer.
--remplacer efface les lignes du module avant de reinserer : corriger
un decalage AJOUTAIT sinon une seconde copie decalee, la cle primaire
portant l'instant.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Nouvelle table cellule, indexee par CODE-BARRES et non par adresse :
chaque chaine renumerote ses modules a partir de 1, il existe donc
deux « module 1 » dans ce parc.
L'importeur lit les exports d'historique et les CSV de suivi. Deux
pieges corriges en le construisant : le tampon du BMS est circulaire,
donc le plus grand index n'est pas le plus recent - trier par index
donnait un decalage deduit de -865 h ; et les fichiers d'evenements
portent les memes colonnes sans decrire un echantillonnage regulier,
ils sont ecartes.
La deduction du decalage d'horloge reste approximative : sur BAT3 elle
donne huit heures la ou le chronometre en donne six. La console
inscrit desormais le decalage en tete de chaque export, mesure a la
seconde ou il commence ; l'importeur le prefere toujours a sa propre
deduction.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
