Als Quelle ist das Device “JK BMS” aufgeführt. Also darf ich doch davon ausgehen, dass der Alarm extern über CAN ins System reinkommt über diese Zustände:
und nicht über Alarmgrenzen im Victron-System, oder?
Zuordnen kann ich die Alarme trotzdem nicht, da die Alarmgrenzen im BMS wesentlich höher parametriert sind und aktuell auch überhaupt nicht angekratzt werden:
Ja, die Quelle „JK BMS“ spricht eher dafür, dass Venus OS einen Alarmzustand vom BMS-/CAN-Dienst übernimmt und nicht selbst aus einer Victron-Temperaturgrenze ableitet.
Ich würde den Logger genau auf diese Trennung ausrichten:
- zeitgleich die echten Werte loggen: Zelltemperaturen, MOS-/BMS-Temperatur, Min/Max-Temp
- zusätzlich die Alarm-Flags loggen, nicht nur die Temperaturwerte. Auf Venus-Seite wären das sinngemäß die D-Bus-Pfade des Batteriedienstes wie `/Alarms/HighTemperature`, ggf. auch die Batterie-Temperaturpfade unter dem jeweiligen `com.victronenergy.battery…`-Service
- wenn du mehrere Packs hast: pro Instanz/Device-Instance loggen, damit nicht Pack 3 den Alarm liefert und du in Pack 1 auf die Werte schaust
- prüfen, ob der JK-Treiber evtl. „Charge high temp“, „Discharge high temp“, MOS-Temp oder Sensorfehler alle auf denselben Victron-Alarm mappt
Ein falscher CAN-Adressbereich wäre möglich, aber ich würde zuerst beweisen, welcher konkrete Batteriedienst im Moment des Alarms welches Alarmbit setzt. Wenn Temperaturwerte unkritisch sind, aber das Alarmbit kurz auf 1 springt, liegt es sehr wahrscheinlich in der JK-/Treiber-Mapping-Schicht oder in einem einzelnen Pack, nicht in der Victron-RemoteKonsole selbst.
Was Du im Screenshot natürlich nicht siehst, dass der Logger bei Triggerung komplett den D-Bus der Batterie loggt. Hier erwarte ich durch den Aufbau keine Eindeutigkeit zu den Batteriepacks. Von der Info über Highest Cell und Low Cell erwarte ich mir aber einen Indikator.
Wo ich dann gf versuche nochmal tiefer einzutauchen. So erstmal den Aufbau nicht verändert.
Danke @busbum, der Logger ist inzwischen scharf. Kurz zu deinen Punkten und zum aktuellen Stand:
Aufbau bestätigt: 3× JK-BMS (FW V19.31, per D-Bus verifiziert: FirmwareVersion 4895 = 0x131F) über BMS-CAN am nativen Treiber can-bus-bms v0.71, DeviceInstance 512.
Zu deinen Prüfpunkten – soweit ohne aktives Ereignis schon beantwortbar:
Mapping: Der Treiber führt HighTemperature, HighChargeTemperature und LowChargeTemperature als getrennte D-Bus-Pfade. Es wird also nicht von vornherein alles auf einen gemeinsamen Alarm gemappt – welches Bit im Ereignisfall real gesetzt wird, muss das nächste echte Event zeigen.
Pro-Pack-Zuordnung: Die Diagnostics/Module0..2/Alarms/*-Pfade sind bei can-bus-bms v0.71 alle leer ([]). Eine eindeutige Pack-Zuordnung über den D-Bus ist damit nicht möglich. Als Indikator bleibt System/MaxTemperatureCellId (Format Pack::Sensor), das ich im Ereignismoment mitlogge.
Werte + Flags: Der Logger schreibt bei jeder Flanke von /Alarms/HighTemperature einen vollständigen Snapshot aller com.victronenergy.battery…-Dienste weg – also Alarm-Bit und alle Temperaturpfade gleichzeitig. Genau die Trennung „Wert unkritisch, Flag trotzdem gesetzt?", die du angesprochen hast, will ich damit sauber belegen.
Status: Seit Mittwoch ist kein Alarm mehr aufgetreten – der Logger wartet noch auf das erste echte Ereignis. Belastbare Aussagen zur Ursache habe ich daher noch nicht.
Eine Frage, die ich trotzdem in den Raum stellen möchte: Die Alarme begannen bei mir schlagartig am Wochenende, ohne Änderung an Batterie, BMS-Firmware oder Anlage – zeitlich zusammenfallend mit dem Update auf Venus OS 3.75. Der offizielle 3.75-Changelog nennt eine CAN-Änderung (Fix der VE.Can-Address-Claim-Prozedur bei BUS-OFF). Das ist VE.Can und nicht zwingend der BMS-CAN-Pfad – aber weiß jemand (gern auch von Victron), ob diese Änderung auch den can-bus-bms-Dienst berühren kann? Gibt es zu 3.75 bekannte CAN-Timing-Auffälligkeiten am BMS-Pfad?
Sobald der Logger ein echtes Event hat, melde ich mich mit den Daten.
Update mit echten Logger-Daten. Der Alarm ist erneut aufgetreten und ich habe im Moment der aktiven Warnung einen D-Bus-Snapshot festgehalten (socketcan_can0, DeviceInstance 512, JK-BMS FW V19.31, Treiber can-bus-bms v0.71):
Heißester Fühler 27 °C, trotzdem HighTemperature = 1. @busbum, zu deinen Punkten: Die Temperatur-Alarme liegen auf getrennten Pfaden – es feuert nur HighTemperature, die Charge-/Low-Temp-Pfade bleiben 0. Pro-Pack-Zuordnung geht nicht, die Diagnostics/Module*/Alarms/* sind leer (). Werte harmlos, Flag trotzdem gesetzt – genau dein Verdacht.
Auffällig: Der Wert ist eine 1 (Warning), obwohl die Enum dieses Pfads nur 0/2 kennt.
