v2.0.20250729: No response from battery with JK_B2A20S20P

[SenH]

Describe the bug

I tried to upgrade today from v1.6.20250131 to v2.0.20250729.
Version 2.0 is able to connect to the BMS but does not seem to able to communicate?
There is also Python non-blocking exception logged. I downgraded to v1.6.20250131 and all is fine again.

Although I have BLOCK_ON_DISCONNECT = True in my config.ini the v2 driver kept charging/discharging without communication. Is this correct behaviour? According to the documentation in config.ini it should only do that with BLOCK_ON_DISCONNECT = False

log v2.0.20250729

2025-08-31 14:36:54.955457500 INFO:SerialBattery:Starting dbus-serialbattery
2025-08-31 14:36:54.959189500 INFO:SerialBattery:Venus OS v3.54 (normal) running on Cerbo-S GX
2025-08-31 14:36:54.959870500 INFO:SerialBattery:dbus-serialbattery v2.0.20250729
2025-08-31 14:37:10.969321500 INFO:SerialBattery:-- Testing BMS: 1 of 3 rounds
2025-08-31 14:37:10.970088500 INFO:SerialBattery:  Testing Jkbms with 115200 baud
2025-08-31 14:37:11.046581500 INFO:SerialBattery:-- Connection established to Jkbms
2025-08-31 14:37:11.858741500 INFO:SerialBattery:Reconnected to previously identified battery with DeviceInstance: 1
2025-08-31 14:37:11.924739500 ERROR:root:Failed to add setting /Settings/Devices/serialbattery_JK_B2A20S20P/SocCalc, error -5
2025-08-31 14:37:11.926139500 INFO:SerialBattery:Use DeviceInstance: 1
2025-08-31 14:37:11.928160500 INFO:SerialBattery:Use dbus ServiceName: com.victronenergy.battery.ttyUSB0
2025-08-31 14:37:11.990810500 INFO:SerialBattery:Polling interval: 1.000 s
2025-08-31 14:37:11.993775500 INFO:SerialBattery:Battery JKBMS connected to dbus from /dev/ttyUSB0
2025-08-31 14:37:11.995256500 INFO:SerialBattery:========== Settings ==========
2025-08-31 14:37:11.995260500 INFO:SerialBattery:> Connection voltage: 53.22 V | Current: 4.93 A | SoC: 58% | SoC calc: 42%
2025-08-31 14:37:11.995717500 INFO:SerialBattery:> Cell count: 16 | Cells populated: 16
2025-08-31 14:37:11.996512500 INFO:SerialBattery:> CHARGE MODE: Linear
2025-08-31 14:37:12.029417500 INFO:SerialBattery:> MIN CELL VOLTAGE: 2.900 V | MAX CELL VOLTAGE: 3.450 V| FLOAT CELL VOLTAGE: 3.375 V
2025-08-31 14:37:12.032793500 INFO:SerialBattery:> MAX BATTERY CHARGE CURRENT: 70.0 A | MAX BATTERY DISCHARGE CURRENT: 70.0 A
2025-08-31 14:37:12.032803500 INFO:SerialBattery:> MAX BATTERY CHARGE CURRENT: 120.0 A | MAX BATTERY DISCHARGE CURRENT: 120.0 A (read from BMS)
2025-08-31 14:37:12.032809500 INFO:SerialBattery:> CVCM:       True
2025-08-31 14:37:12.033695500 INFO:SerialBattery:> CCCM CV:    True  | DCCM CV:       True
2025-08-31 14:37:12.035618500 INFO:SerialBattery:> CCCM T:     True  | DCCM T:        True
2025-08-31 14:37:12.035870500 INFO:SerialBattery:> CCCM T MOS: True  | DCCM T MOS:    True
2025-08-31 14:37:12.051676500 INFO:SerialBattery:> CCCM SOC:   False | DCCM SOC:      False
2025-08-31 14:37:12.054061500 INFO:SerialBattery:> CHARGE FET: True  | DISCHARGE FET: True | BALANCE FET: True
2025-08-31 14:37:12.056357500 INFO:SerialBattery:Serial Number/Unique Identifier: JK_B2A20S20P
2025-08-31 14:37:13.017058500 ERROR:SerialBattery:CRC checksum mismatch: Expected 0x0cfe, Got 0x0749
2025-08-31 14:37:13.322564500 ERROR:SerialBattery:Non blocking exception occurred: TypeError("unsupported operand type(s) for -: 'NoneType' and 'NoneType'") of type <class 'TypeError'> in /data/apps/dbus-serialbattery/dbushelper.py line #1082
2025-08-31 14:37:38.982516500 ERROR:SerialBattery:>>> No response from battery. Connection lost or battery not recognized. Check cabeling! [len:274/781]
2025-08-31 14:37:38.983793500 ERROR:SerialBattery:>>> ERROR: Battery does not respond, init/reset values <<<
2025-08-31 14:37:38.986578500 ERROR:SerialBattery:    |- Cell voltages are in a safe threshold to proceed with charging/discharging without communication to the battery.
2025-08-31 14:37:38.986589500 ERROR:SerialBattery:    |- Min cell voltage: 3.324 > Min Threshold: 3.250 --> OK
2025-08-31 14:37:38.987091500 ERROR:SerialBattery:    |- Max cell voltage: 3.329 < Max threshold: 3.350 --> OK
2025-08-31 14:37:38.987828500 ERROR:SerialBattery:    |- Trying further for 1200 s, then restart the driver
2025-08-31 14:37:56.046093500 ERROR:SerialBattery:>>> No response from battery. Connection lost or battery not recognized. Check cabeling! [len:32/14915]
2025-08-31 14:37:56.050104500 ERROR:SerialBattery:>>> ERROR: Battery does not respond, init/reset values <<<
2025-08-31 14:37:56.051198500 ERROR:SerialBattery:    |- Cell voltages are in a safe threshold to proceed with charging/discharging without communication to the battery.
2025-08-31 14:37:56.052223500 ERROR:SerialBattery:    |- Min cell voltage: 3.325 > Min Threshold: 3.250 --> OK
2025-08-31 14:37:56.053176500 ERROR:SerialBattery:    |- Max cell voltage: 3.330 < Max threshold: 3.350 --> OK
2025-08-31 14:37:56.053835500 ERROR:SerialBattery:    |- Trying further for 1200 s, then restart the driver

log v1.6.20250123 (after downgrade)

2025-08-31 15:15:29.355206500 INFO:SerialBattery:
2025-08-31 15:15:29.355849500 INFO:SerialBattery:Starting dbus-serialbattery
2025-08-31 15:15:29.358610500 INFO:SerialBattery:Venus OS v3.54 running on Cerbo-S GX
2025-08-31 15:15:29.359512500 INFO:SerialBattery:dbus-serialbattery v1.6.20250131
2025-08-31 15:15:45.374759500 INFO:SerialBattery:-- Testing BMS: 1 of 3 rounds
2025-08-31 15:15:45.375460500 INFO:SerialBattery:Testing Jkbms
2025-08-31 15:15:45.449407500 INFO:SerialBattery:-- Connection established to Jkbms
2025-08-31 15:15:46.140509500 INFO:SerialBattery:Reconnected to previously identified battery with DeviceInstance: 1
2025-08-31 15:15:46.444469500 INFO:SerialBattery:Use DeviceInstance: 1
2025-08-31 15:15:46.446227500 INFO:SerialBattery:Use dbus ServiceName: com.victronenergy.battery.ttyUSB0
2025-08-31 15:15:46.484449500 INFO:SerialBattery:Polling interval: 1.000 s
2025-08-31 15:15:46.486778500 INFO:SerialBattery:Battery JKBMS connected to dbus from /dev/ttyUSB0
2025-08-31 15:15:46.486787500 INFO:SerialBattery:========== Settings ==========
2025-08-31 15:15:46.487930500 INFO:SerialBattery:> Connection voltage: 53.12 V | Current: -0.0 A | SoC: 60% | SoC calc: 44%
2025-08-31 15:15:46.493104500 INFO:SerialBattery:> Cell count: 16 | Cells populated: 16
2025-08-31 15:15:46.493268500 INFO:SerialBattery:> LINEAR LIMITATION ENABLE: True
2025-08-31 15:15:46.494434500 INFO:SerialBattery:> MIN CELL VOLTAGE: 2.900 V | MAX CELL VOLTAGE: 3.450 V| FLOAT CELL VOLTAGE: 3.375 V
2025-08-31 15:15:46.505915500 INFO:SerialBattery:> MAX BATTERY CHARGE CURRENT: 70.0 A | MAX BATTERY DISCHARGE CURRENT: 70.0 A
2025-08-31 15:15:46.505924500 INFO:SerialBattery:> MAX BATTERY CHARGE CURRENT: 120.0 A | MAX BATTERY DISCHARGE CURRENT: 120.0 A (read from BMS)
2025-08-31 15:15:46.506897500 INFO:SerialBattery:> CVCM:     True
2025-08-31 15:15:46.508194500 INFO:SerialBattery:> CCCM CV:  True  | DCCM CV:  True
2025-08-31 15:15:46.508666500 INFO:SerialBattery:> CCCM T:   True  | DCCM T:   True
2025-08-31 15:15:46.509499500 INFO:SerialBattery:> CCCM SOC: False | DCCM SOC: False
2025-08-31 15:15:46.510362500 INFO:SerialBattery:> CHARGE FET: True | DISCHARGE FET: True | BALANCE FET: True
2025-08-31 15:15:46.530298500 INFO:SerialBattery:Serial Number/Unique Identifier: JK_B2A20S20P

How to reproduce

See above

Expected behavior

v2.0.20250729 should succeed in communicating.

Installation method

⚠️ Choose your option ⚠️

Driver version of the currently installed driver

v2.0.20250729

Driver version of the last known working driver

v1.6.20250131

Venus OS device type

Cerbo GX

Venus OS version

v3.54

Venus OS image type

Normal

BMS type

JKBMS (Heltec BMS)

Cell count

16

Battery count

1

Connection type

Serial USB adapter to TTL

USB hub

No, the Serial USB adapter is connected directly to the Venus OS device

Config file

[DEFAULT]

; Set charge/discharge current to 70A (*51,2V = 3584W) = 0,3C @ LF230
MAX_BATTERY_CHARGE_CURRENT    = 70.0
MAX_BATTERY_DISCHARGE_CURRENT = 70.0

CVL_CONTROLLER_MODE = 2

; Copy value from "Balance Trig. Volt" in JK BMS app
SWITCH_TO_FLOAT_CELL_VOLTAGE_DIFF = 0.010
; Extend absorption phase for balancing cells
SWITCH_TO_FLOAT_WAIT_FOR_SEC = 1800

; JK BMS shunt can not measure baseline load (Cerbo = 0.1A)
SOC_CALCULATION = True
CURRENT_REPORTED_BY_BMS  = -300, -0.1,    0, 0.1, 300
CURRENT_MEASURED_BY_USER = -300, -0.1, -0.1, 0.1, 300

; Keep charge Current fraction at 1.00 @ 15°C
TEMPERATURES_WHILE_CHARGING      =    0,    2,    5,   10,   15,   20,   35,   40,   55
MAX_CHARGE_CURRENT_T_FRACTION    = 0.00, 0.10, 0.20, 0.40, 1.00, 1.00, 1.00, 0.40, 0.00

TEMPERATURE_1_NAME = T1 C5
TEMPERATURE_2_NAME = T2 C13

BMS_TYPE = Jkbms
BLOCK_ON_DISCONNECT = True

Relevant log output

See above

Any other information that may be helpful

No response

Please confirm that you have completed the following steps before submitting your support request

• I have carefully read all the instructions above including the descriptions.
• I have tried the nightly build first, if I was not already using it. This means the logs I provide are from the nightly build.
• I have rebooted at least once after I saw the issue.
• I have read the complete changelog.
• I have provided the logfiles in the correct format with a HUMAN READABLE timestamp by piping it through tai64nlocal.
• I have clicked all checkboxes because I did not read the instructions.

[Smarty73]

Is there a solution yet? I just bought the same BMS and want to use it.

Many greetings,
Smarty

[Smarty73]

Did you try to download the files again? (See the CRC checksum error)

[SenH]

The CRC checksum is calculated on the received serial data.
It has nothing to do with the Python scripts.

I'm still on v1.6.20250131 which is working fine with Venus v3.66.

[mr-manuel]

Very likely this errors are due to not proper cabeling. Check the FAQ for this.

[Smarty73]

Hello.

@mr-manuel
I think this is a bug and not related to the cable. I got exactly the same issue. All the informations are shown in the Venus page from the MultiPlus, but still there is an error, showing that communication to BMS is lost. Therefore no charging or discharging, even I can see all the informations provided by the JK BMS.

But I found a workaround:
After setting the serialbattery as the BMS in the Multiplus (settings-system setup-battery management) you will get the error. Now switch the Multiplus off with its MainSwitch (reset is not enough), wait 20sec and switch it on again. Now the BMS communication works.

@SenH you might try this and report

Best regards,
Smarty

[mr-manuel]

Inproper cabeling cannot be a bug. If it would be a bug also a lot of other people would have this issue. What @Smarty73 is doing, is the same procedure for resetting the VE.Bus and therefore also removing the BMS controlling from the MultiPlus, if the BMS is not found after. Not sure how exactly you verify that it‘s working properly. Did you check the logs or it‘s working because there is no error in the GUI? 😅

I checked the issue with the block on disconnect and was not able to reproduce it.

The logging in v2 was improved, therefore it‘s easily possible that the issue exists in v1.6.x but is not shown.

That issue should be more spread, if it‘s really a driver issue.

[Smarty73]

Of course improper cabeling is not a bug :-) But I thought that this might not have been the reason for this behaving. Maybe at some installations the update will not create a proper "first setup" to the MultiPlus or something like that? In my case everything seemed to work, I got all the informations available by the JKBMS in the Venus surface as well as in the MultiPlus page (e.g. single cells voltages, temperatures and so on.) Nothing was missing. Nevertheless the MultiPlus had a (non resettable) error "BMS communication lost" and therefor there was no charge or discharge done.
This issue can be easily recognized even without logging, as the battery simply doesn't charge or discharge.
But unfortunatelly I didn't create any logfiles when the problem occured, sorry for that.

[mr-manuel]

The question is, if you now have a clean logfile?

[SenH]

Not sure why marked as off-topic and not sure why @Smarty73 is polluting the the issue.

I can only conclude that in v1.6.20250131 I don't have any errors what so ever.

• If there are cabling errors why don't they show up as CRC errors in v1.6.20250131.
• I don't see missing values in VRM statistics.
• Data on dbus is coming in every second.

Since the system is my "production" system at home, I don't like to fiddle with it and no issue whatsoever to stay onv1.6.20250131

Also the spelling in the source code is wrong: cabeling --> cabling

[Smarty73]

not sure why @Smarty73 is polluting the the issue.
Sorry, I just wanted to help to solve your problem, as I had the same issue. No reason to get unfriendly...

The question is, if you now have a clean logfile?
If this question was for me: Well, kind of. Somehow both logfiles have a time stamp from yesterday. Maybe because the logging is set to INFO. Content is the same:

2025-09-27 10:12:46.756721500 INFO:SerialBattery:
2025-09-27 10:12:46.757803500 INFO:SerialBattery:Starting dbus-serialbattery
2025-09-27 10:12:46.763424500 INFO:SerialBattery:Venus OS v3.66 (large) running on MultiPlus-II
2025-09-27 10:12:46.763934500 INFO:SerialBattery:dbus-serialbattery v2.0.20250729
2025-09-27 10:13:02.765425500 INFO:SerialBattery:-- Testing BMS: 1 of 3 rounds
2025-09-27 10:13:02.765874500 INFO:SerialBattery: Testing Jkbms with 115200 baud
2025-09-27 10:13:02.914839500 INFO:SerialBattery:-- Connection established to Jkbms
2025-09-27 10:13:03.288323500 INFO:SerialBattery:Reconnected to previously identified battery with DeviceInstance: 1
2025-09-27 10:13:03.366978500 INFO:SerialBattery:Use DeviceInstance: 1
2025-09-27 10:13:03.368635500 INFO:SerialBattery:Use dbus ServiceName: com.victronenergy.battery.ttyUSB0
2025-09-27 10:13:03.458715500 INFO:SerialBattery:Polling interval: 1.000 s
2025-09-27 10:13:03.480285500 INFO:SerialBattery:Battery JKBMS connected to dbus from /dev/ttyUSB0
2025-09-27 10:13:03.480292500 INFO:SerialBattery:========== Settings ==========
2025-09-27 10:13:03.480295500 INFO:SerialBattery:> Connection voltage: 48.93 V | Current: -0.62 A | SoC: 43%
2025-09-27 10:13:03.480297500 INFO:SerialBattery:> Cell count: 16 | Cells populated: 16
2025-09-27 10:13:03.480300500 INFO:SerialBattery:> CHARGE MODE: Linear
2025-09-27 10:13:03.480302500 INFO:SerialBattery:> MIN CELL VOLTAGE: 2.900 V | MAX CELL VOLTAGE: 3.500 V| FLOAT CELL VOLTAGE: 3.375 V
2025-09-27 10:13:03.480373500 INFO:SerialBattery:> MAX BATTERY CHARGE CURRENT: 40.0 A | MAX BATTERY DISCHARGE CURRENT: 60.0 A
2025-09-27 10:13:03.480377500 INFO:SerialBattery:> MAX BATTERY CHARGE CURRENT: 45.0 A | MAX BATTERY DISCHARGE CURRENT: 65.0 A (read from BMS)
2025-09-27 10:13:03.480381500 INFO:SerialBattery:> CVCM: True
2025-09-27 10:13:03.480383500 INFO:SerialBattery:> CCCM CV: True | DCCM CV: True
2025-09-27 10:13:03.480409500 INFO:SerialBattery:> CCCM T: True | DCCM T: True
2025-09-27 10:13:03.480411500 INFO:SerialBattery:> CCCM T MOS: True | DCCM T MOS: True
2025-09-27 10:13:03.480414500 INFO:SerialBattery:> CCCM SOC: False | DCCM SOC: False
2025-09-27 10:13:03.480417500 INFO:SerialBattery:> CHARGE FET: True | DISCHARGE FET: True | BALANCE FET: True
2025-09-27 10:13:03.492449500 INFO:SerialBattery:Serial Number/Unique Identifier: 407272D1125

[marcelrv]

adding my 2ct as well.
I also experience disconnects with the JKBMS, about once 1/2 weeks.
In my case, restarting the serialbattery driver always resolves the matter.

Though I am not 100% sure why it happens, based on the behaviour I get the sense that either the driver gets stuck in some sort of loop (after some wrong input) or the serial ports somehow gets blocked and does not release & restart itself.

I strongly doubt it is the cabling that is the issue, much more suspect the BMS giving some odd responses.

[ayasystems]

I have also disconnects with the new version after update. I've removed the driver