Venus OS 3.75 — can-bus-bms driver intermittently sets false Warnings etc

Modifications
1

Hello

(translated with the help of KI because no native English speaker)

Since updating to Venus OS 3.75, the native can-bus-bms driver (v0.71) on my JK-BMS (FW V19.31) intermittently raises /Alarms/HighTemperature = 1 on com.victronenergy.battery/512, while all temperatures are completely normal. Under 3.73 this never happened.

Relevant to the version: The official 3.75 changelog lists exactly one CAN-related change — a fix to the VE.Can address-claim procedure that previously failed to complete under BUS-OFF conditions, causing the GX to stop sending on the network. So CAN handling was demonstrably touched in 3.75. That change is described as VE.Can and may not be the same code path as the BMS-CAN port — but it is the only CAN area modified in this release, and it concerns exactly the address-claim / bus-recovery timing that both symptoms below point to.

This is not a Node-RED issue. The faulty value appears on the stock can-bus-bms D-Bus service. Node-RED is only used here to snapshot that service the moment the alarm flips; the extract below shows exclusively service /512.

Key observations across 4 captured events (full extract attached):

  • HighTemperature = 1 while MaxCellTemperature was 24–27 °C. No temperature-based cause. HighChargeTemperature and LowChargeTemperature stayed 0 throughout.
  • The value set is 1 (Warning), though this path is normally 0/2 only.
  • Each event lasted 6–7 s and cleared itself; within the same second the bit toggled 1↔0 (chatter).
  • One event additionally set ChargeBlocked = 1 AND DischargeBlocked = 1 simultaneously (physically contradictory), with NrOfModulesBlocking 1/1.
  • Alarm bits and current limits are mutually inconsistent: in that event charge+discharge are blocked yet CCL/DCL stay full; in another, no block bit is set yet CCL/DCL are reduced.

This pattern — intermittent, sub-second, multiple bits affected, values incoherent with each other — looks like dropped/delayed CAN frames being reassembled into inconsistent snapshots, rather than a real BMS reading.

Question: Given that the 3.75 changelog explicitly changed VE.Can address-claim/BUS-OFF handling, can that change also affect the can-bus-bms path and briefly set spurious alarm bits? Onset correlates exactly with the 3.75 update; 3.73 was clean. Happy to provide full snapshots, timestamps and the logging flow.

========================================================================
JK-BMS HighTemperature false-alarm events  —  Venus OS 3.75
Source: com.victronenergy.battery/512  (native can-bus-bms driver v0.71)
Only the JK-BMS D-Bus service is shown. Serial number removed.
Each event was additionally logged with the alarm already back at 0
within the SAME second (1<->0 chatter); those duplicate 0-state
snapshots are omitted here.
========================================================================

Constant across all events:
  Manufacturer          : JK-BMS
  FirmwareVersion       : 4895  (= 0x131F = JK V19.31)
  Mgmt/ProcessName      : can-bus-bms
  Mgmt/ProcessVersion   : v0.71
  DeviceInstance        : 512
  NrOfModulesOnline     : 3
  HighChargeTemperature : 0   (never triggered)
  LowChargeTemperature  : 0   (never triggered)
  LowTemperature        : 0   (never triggered)
  HighChargeCurrent / HighDischargeCurrent / CellImbalance /
  HighCellVoltage / LowVoltage / InternalFailure : 0

------------------------------------------------------------------------
EVENT 1   2026-07-18 19:15:22   duration 7 s
------------------------------------------------------------------------
  Alarms/HighTemperature        : 1     <-- warning active
  Alarms/ChargeBlocked          : 0
  Alarms/DischargeBlocked       : 0
  Dc/0/Temperature              : 26.2 C
  System/MaxCellTemperature     : 27.0 C
  System/MinCellTemperature     : 25.0 C
  System/MaxTemperatureCellId   : 02::04
  System/MinTemperatureCellId   : 00::02
  Dc/0/Current                  : -2.3 A
  Info/MaxChargeCurrent (CCL)   : 256 A
  Info/MaxDischargeCurrent (DCL): 344 A
  NrOfModulesBlockingCharge/Discharge : 0 / 0

------------------------------------------------------------------------
EVENT 2   2026-07-18 21:05:46   duration 6 s
------------------------------------------------------------------------
  Alarms/HighTemperature        : 1     <-- warning active
  Alarms/ChargeBlocked          : 0
  Alarms/DischargeBlocked       : 0
  Dc/0/Temperature              : 26.1 C
  System/MaxCellTemperature     : 27.0 C
  System/MinCellTemperature     : 25.0 C
  System/MaxTemperatureCellId   : 02::04
  System/MinTemperatureCellId   : 00::01
  Dc/0/Current                  : -14.0 A
  Info/MaxChargeCurrent (CCL)   : 256 A
  Info/MaxDischargeCurrent (DCL): 238 A
  NrOfModulesBlockingCharge/Discharge : 0 / 0

------------------------------------------------------------------------
EVENT 3   2026-07-19 01:21:20   duration 7 s   *** with block bits ***
------------------------------------------------------------------------
  Alarms/HighTemperature        : 1     <-- warning active
  Alarms/ChargeBlocked          : 1     <-- simultaneously set
  Alarms/DischargeBlocked       : 1     <-- simultaneously set
  Dc/0/Temperature              : 25.9 C
  System/MaxCellTemperature     : 27.0 C
  System/MinCellTemperature     : 25.0 C
  System/MaxTemperatureCellId   : 02::04
  System/MinTemperatureCellId   : 00::01
  Dc/0/Current                  : -6.7 A
  Info/MaxChargeCurrent (CCL)   : 256 A       (still full, despite ChargeBlocked=1)
  Info/MaxDischargeCurrent (DCL): 344 A       (still full, despite DischargeBlocked=1)
  NrOfModulesBlockingCharge/Discharge : 1 / 1

------------------------------------------------------------------------
EVENT 4   2026-07-19 02:08:04   duration 7 s
------------------------------------------------------------------------
  Alarms/HighTemperature        : 1     <-- warning active
  Alarms/ChargeBlocked          : 0
  Alarms/DischargeBlocked       : 0
  Dc/0/Temperature              : 25.9 C
  System/MaxCellTemperature     : 26.0 C
  System/MinCellTemperature     : 24.0 C
  System/MaxTemperatureCellId   : 02::04
  System/MinTemperatureCellId   : 00::02
  Dc/0/Current                  : -8.2 A
  Info/MaxChargeCurrent (CCL)   : 176 A       (reduced, no block bit set)
  Info/MaxDischargeCurrent (DCL): 238 A       (reduced, no block bit set)
  NrOfModulesBlockingCharge/Discharge : 0 / 0

========================================================================
Summary
------------------------------------------------------------------------
- 4 events, all HighTemperature = 1 while the hottest cell sensor was
  24-27 C. No temperature-based cause.
- Each event lasted 6-7 s and cleared itself. Within the same second the
  bit toggled 1<->0 (chatter).
- Event 3 additionally set ChargeBlocked = 1 AND DischargeBlocked = 1
  (physically contradictory) plus NrOfModulesBlocking 1/1.
- Alarm bits and current limits are mutually inconsistent:
  Event 3 blocks charge+discharge yet CCL/DCL stay full;
  Event 4 sets no block bit yet CCL/DCL are reduced.
- MinTemperatureCellId flips (00::01 <-> 00::02) at unchanged
  temperatures.
- Onset coincided with the update to Venus OS 3.75; 3.73 was clean.
========================================================================

Thanks

2

To evaluate situation I downgraded to v3.73 and now also received same temperature high warnings without any real critical temperatures in the whole system.

Can you recommend how to locate the problem?

3

The system will just be reporting what is sent by the BMS, so the issue would appear to be with what the BMS is sending, or is BMS specific. As an unsupported/DIY BMS, you will need to address this with the BMS manufacturer.

4

Thanks I´ll do.

May I ask if understanding is correct, that “Alarms/HighTemperature” = 1 is unsupported and should be 0 or 2 for Victron?

This would help to specify by more detail to the BMS manufacturer.

5

Victron don’t officially publish their BMS spec and won’t comment on it here, manufacturers have to request it via the in-country victron manager. Presuming JK have done this, they should have the full spec.
I don’t have access to it beyond the varying amount of information posted to the internet so can’t comment.
This isn’t something that typically changes often so Venus updates shouldn’t break comms with any battery.

6

Thanks, it seems to be a major topic for the customer - but that’s the reality of DIY life.

I’ll try to get an answer from JK. In the meantime, I’ll take some practical steps, such as downgrading the BMS firmware from version 19.31 to 19.27, as I am not aware of any similar issues occurring while the system was running on those earlier versions.

7

Did you tried to use candump on the CAN port on which the battery is connected?
To see the content of the CAN frames and their IDs?

Then you can use these two specs below to get an image about what’s happening.
Content from the web, publicly available.

8

Wow, great, thanks!

Not tested yet, let me check how to handle it.

Edit: Done. I’ve set up a logger that records address 0x35A, so I’ll see what happens.

9

Thanks @alexpescaru - your input pointed me in the right direction.

Using candump I was able to narrow it down: the JK BMS sets/changes something on CAN ID 0x35A, byte 4. Victron picks this up and turns it into warnings. I couldn’t fully work out the why and how, but the warning values it produces don’t look sensible to me.

What I can say for certain: on firmware 19.24 I had none of these warnings. The 19.27 changelog mentions “Optimisation of CAN protocol”, and now on 19.31 the warnings are there. I’ve reported this to JK - feedback still pending.

As a workaround I switched the JK BMS CAN protocol from Victron to Pylontech. That runs cleanly, no warnings, and so far all the data I need is coming through. Fingers crossed nothing important is being dropped on the Victron side.