a4de466ae1
Le suivi n'ecrivait que l'adresse du module, traduite a l'import par une table figee sur le pack ancien. Le cable ayant change de pack, tout releve fait maintenant aurait ete attribue aux mauvais modules. Le code-barres est desormais resolu au demarrage et ecrit dans le CSV ; la table ne sert plus qu'aux anciens fichiers. Le releve tourne sur le poste qui porte le cable serie - le port USB est la, pas sur le Synology - et n'ecrit qu'un CSV dans le depot partage. C'est le service d'historisation, cote Synology, qui le verse en base : le poste n'a donc aucun mot de passe a connaitre. Archive pour le constructeur : un dossier par code-barres, plus un manifeste en francais, anglais et chinois qui dit ou regarder en premier et signale que les CSV sont deja corriges de la derive d'horloge des BMS. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
947 B
Dépôt des relevés BatteryView / console Pylontech
BatteryView tourne sur la machine Windows 10.10.10.93. Elle n'expose que SMB (445) : il n'y a rien à interroger à distance, BatteryView étant une application graphique qui garde le port COM pour elle seule.
Le chemin de dépôt, vu depuis Windows :
\\10.10.10.22\projects\EVCS\EVCS\docs\mesures\batteries\
C'est le même dossier que celui-ci.
Nommer les fichiers AAAAMMJJ-hhmm-<quoi>.<ext>, par exemple
20260905-1600-history.csv, 20260905-1600-events.csv,
20260905-1600-cellules.png.
Ce qui compte le plus : un relevé pendant le bridage, c'est-à-dire à SOC élevé en pleine charge solaire (le 04/09 l'alarme est tombée à 16:36 et le CCL est passé de 150 à 20 A entre 16:13 et 16:39). Un relevé du matin, batterie à 45 %, ne peut rien montrer : sur du LiFePO4 les cellules lisent la même tension à quelques millivolts près en dessous de ~70 % de SOC.