Hi,
during a scanning - firmware update via VRM, I always get an error during Status: Scanning VE.Direct devices.
And the battery is then disconnected -> have to make a restart to connect to it again.

To Reproduce
Steps to reproduce the behavior:

1. Go to Vrm
2. Click on the firmware update
3. See an error

Expected behavior
The driver should be able to handle that situation to reconnect again. And there has to be an answer to be able to update another device.

VenusOS (please complete the following information):

• Device type: Cerbo
• Firmware Version 2.80

Battery/BMS (please complete the following information):

• BMS/Battery type: ANT
• Cells: 16
• Interface: USB-RS232

Describe the bug
Minimum cell voltage on D-Bus has value False; instead of a numeric value. Seen on the system of de Longis which ahs a Daly 4S BMS, running the sinoweath protocol (?).

This causes issues in Venus OS and also in the VRM data ingestion system.

Please don't only fix that path, but make sure that also other paths cannot do this.

Its seen only sometimes, so maybe this is during startup, or some other exceptional situation.

The data as sent to VRM is:

    ["mcV"]=>
    array(1) {
      [1]=>
      string(5) "False"
    }

And the error in our VRM ingestion system is is:

InfluxException: HTTP code: 500. {"error":"write failed: partial write: field type conflict: input field \"value\" on measurement \"173\" is type boolean, already exists as type float dropped=1"}

To Reproduce
I don't know

Expected behavior
Either publish a valid numeric value, typically a float. Or a dbus-invalid value, (let me know if you don't know what that is), or don't publish the path at all.

Screenshots

VenusOS (please complete the following information):

• RaspberryPi, Venus OS v2.66.

Battery/BMS (please complete the following information):

• BMS/Battery type: Daly 4S
• Cells: 4
• Interface: I don't know, its not my system.

Additional context
I'll ask the user of the system to add more information to this issue if necessary. I'm from Victron, and just posting this to reduce the amount or errors and warnings seen in our monitoring system.

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Install successful, and device found, and logs data for around an hour or so.

This is error is found logs:

@40000000608770e81d459954 *** CCGX booted (0) ***
@400000006087711627f5a31c INFO:main:dbus-serialbattery
@40000000608771170076dbbc INFO:main:JBD-SP04S020-L4S-100A-B-U
@4000000060877117189ce164 INFO:main:Battery connected to dbus from /dev/ttyUSB1

@400000006087868c15d7b29c ERROR:main:>>> ERROR: No reply - returning
@400000006087868c352bc73c ERROR:main:>>> ERROR: No reply - returning
@400000006087868d342933ec ERROR:main:>>> ERROR: No reply - returning
@400000006087868e356015dc ERROR:main:>>> ERROR: No reply - returning
@400000006087868e3587d98c Traceback (most recent call last):
@400000006087868e35ca783c File "/opt/victronenergy/dbus-serialbattery/dbus-serialbattery.py", line 414, in publish_battery
@400000006087868e35ea21b4 self.publish_battery_dbus()
@400000006087868e35ed80fc File "/opt/victronenergy/dbus-serialbattery/dbus-serialbattery.py", line 234, in publish_battery_dbus
@400000006087868e35f2053c self._dbusservice['/System/MaxVoltageCellId'] = 'C' + str(max_cell + 1)
@400000006087868e35f4fb0c TypeError: coercing to Unicode: need string or buffer, int found

Expected behavior
To keep running and logging data. It is very possible I have an issue with my setup or an error in my install.

Screenshots
If applicable, add screenshots to help explain your problem.

VenusOS (please complete the following information):

• Device type: [e.g. VenusGX, Cerbo, Raspberry Pi]
• Firmware Version [e.g. 262]

***Raspberry PI 3B+, VenusOS 2.66

Battery/BMS (please complete the following information):

• BMS/Battery type: [e.g. LTT, Daly] JBD-SP04S020-L4S-100A-B-U
• Cells: [e.g. 16] 4
• Interface: [e.g. USB-RS485, USB-RS232, Ve.Direct] USB-RS232 box that came with Overkill Solar BMS. I do have and tried a VEDirect USB cable but it did not try to run the driver for it.

Additional context
Add any other context about the problem here.

The Daly BMS protection notifications have not been implemented in the current release

Hey there,

I am using a JBP-SP04S010 via UART.
In a former release I could manage to make it work, I had to change the parsing of the BMS status message.
As far as i could follow the answer contains the count of temp sensors and depending on that count the length of the answer differs.
Since my BMS has only one temp sense and the code expects at leased two it crashes when reading the RAW data and reports an array length missmatch.

In the most recent version many things changed and were definetly improoved, but my old trick does not work out any more. (simply removed any occurence of temp sense two in code or gave a static value)

Any chance to get a single temp sensor running?
I can provide any data that could be usefull to solve the issue!

best regards

Iolinar

Add the ANT-BMS communication to the driver.

• SOC
• Battery voltage
• Charge/discharge current
• Temprature
• Min/max cell voltages
• protection notifications

Add the Chargery BMS basic communication to the driver.

• SOC
• Battery voltage
• Charge/discharge current
• Temprature
• Min/max cell voltages
• protection notifications

Add the Renogy BMS basic communication to the driver.

• SOC
• Battery voltage
• Charge/discharge current
• Temprature
• Min/max cell voltages
• protection notifications

ROVER MODBUS.pdf

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Go to Cell Number
2. See error All Cell Numbers are one to hi real Cellnumber is 2 and Venus show Cellnumber 3

Screenshots

VenusOS (please complete the following information):

• Device type: Raspberry Pi]
• Firmware Version 266

Battery/BMS (please complete the following information):

• BMS/Battery Daly 100A
  
  

• Cells: 16

• Interface: USB-RS232

Additional context
Add any other context about the problem here.

The values on a Raspberry Pi v2.73 with (since?) v0.8beta1 are not the same like the PC Windows App with the same USB-UART cable. (with v0.8 the BMS is not running)

Between the two screenshots are only some seconds apart.

Min/max difference is according v0.8beta1 since days about 0.008V - and according PC-App/Android App 0.003 V.
The min Volt seems to be too low.

The 123electric 123SmartBMS has a similar DBUS serial integration in early stages of development which I am currently trying to test:

https://github.com/123electric/smartbms-venus

But currently it appears unclear how the charge and discharge enable is controlled. Could somebody here please help by confirming what the "System status" screen should look like with your DBUS integration for other BMS systems. As displayed below the solar and BMS control state/ability appear to be disabled:

Can your solution/other BMS show all as "On" or is this normal and the charge/discharge is controlled via some other API, or only ever by physical cables?

It would be great to have a single update mechanism for all custom packages installed on Venus OS.

Since I already use SetupHelper project for their GUI changes , I would like to incorporate the setup and upgrade with their project. (console based update button)

It is cumbersome to ssh to the remote box once disconnected from home network and check for new version of the project.

SetupHelper project is written in SHELL and will require a standard version file indicating the installed and new version (hope to have this automatically updated during build / publish). There are additional requirements during the installation. The Feature request on kwindrem repository is included.

kwindrem/SetupHelper#3

Hi there, as I can see the Victron SmartShunt is quite expensive, it might be interesting or benefit to buy a SmartShunt like this one (or amazon link) then use the Raspberry-Pi + Venus OS + this very nice plug-in to monitoring the simple battery data via Victron VRM web site.

This could be especially useful in case someone's BMS doesn't have a RS485 output then a simple shunt like this might be used.

I also noticed on Youtube someone used this device to read voltage and current info from the RS485 output.

So perhaps it is possible? If so, I might want to order a part like this to try it out. And if you also want to play it out, I can also a similar part from aliexpress and deliver it to you directly :)

I have very limited USB/485 knowledge, but if this can be not difficult I then would like to learn more about it :)

Thank you.

AllowToCharge is depending on battery.charge_fet AND control_allow_charge. This sound strange becauls the fet is The parameter enabaling charging.
Becauls my AllowToCharge gives on an off at (seems) random moment i change the code a little:

self._dbusservice['/History/TotalAhDrawn'] = self.battery.total_ah_drawn
_self.dbusservice['/Io/AllowToCharge'] = 1 if self.battery.charge_fet else 0
self._dbusservice['/Io/AllowToDischarge'] = 1 if self.battery.discharge_fet else 0

Show when bank in online/offline.
If connection is lost this bank online/offline count can be used to indicate this.
Also make sure all value updates can handle handle it if no value is retrieved.

I would like to ask, if you could support for switching on / off the FETs from Daly Smart BMS?

With the original bluetooth dongle, i can turn them on or off with the app.

Id like to disconnect the whole battery on low SoC for example to save energy in critical situations.

Check compatibility with VenusOS 2.80

In Venus 2.80, the rootfs is now read-only. To install the service, you need to remount it rw (which you can do with the script /opt/victronenergy/swupdate-scripts/remount-rw.sh), and then the service needs to be installed in /opt/victronenergy/service instead (which is overlayed onto /service at bootup, but reset to original at each boot).

3S And 4S BMS have different communications.
My contact at Daly says this should be the document that describes the communication between 3 and 4S BMS and PC.

Daly RS485+UART protocol.pdf

Manual install instructions are not clear as to where the package must be copied to.
[ ] look at manual install command or script to extract the package to the correct location

I think there is some confusion in the instructions, as there is no

/data/etc/dbus-serialbattery/dbus-serialbattery.py
/data/etc/dbus-serialbattery/service/log/run
/data/etc/dbus-serialbattery/service/run
unless I copy them too. Or, there is an "etc" missing somewhere.
I assumed you want us to copy what is inside "etc" to the main "etc" on Pi

Add the Coslight BMS basic communication to the driver.

• SOC
• Battery voltage
• Charge/discharge current
• Temprature
• Min/max cell voltages
• protection notifications

414669189-Coslight-48VBMS-MODBUS-Communication-Protocol-Simplified-Version.pdf

https://github.com/stuartpittaway/diyBMSv4

This BMS would be fine to be integrated

Add paths with values for:

/Dc/0/MidVoltage <- V DC Mid voltage (BMV-702 configured to read midpoint voltage only)
/Dc/0/MidVoltageDeviation <- Percentage deviation

Compare the summed voltage of the first half set of cells to the sum of the last half set.
If an uneven cell count is used ignore the last cell (15 cell battery will only be cells 1-7 vs 8-14)

Integrate the Tian Power BMS via RS485 to Victron Venus OS-equipped devices.

• SOC
• Battery voltage
• Charge/discharge current
• Temprature
• Min/max cell voltages
• protection notifications

It uses CRC-16-ANSI function

def calc_crc(data):
    crc = 0xFFFF
    for pos in data:
        crc ^= pos 
        for i in range(8):
            if ((crc & 1) != 0):
                crc >>= 1
                crc ^= 0xA001
            else:
                crc >>= 1
    return crc

Hey, Luis,
I've been looking for a good, working, isolated UART converter for a long time, but I haven't found one. Finally I had to make it myself and already my LLT/JBD BMS is communicating. Do you recommend the original Victron ve-direct cable, the one that is isolated and at TTL level for use with the UART on the BMS?
The second question is towards the SOC/current to battery (CCCM) setup. Where can these values be changed and how to enable this feature?

Thank you for the answer DJ.

Daly Smart BMS 150A 16S has a firmware problem that reports inverted sign for Amps. This results in BMS reporting charging when inverter is running , and BMS discharing when the charger is running.

I would like to have a variable / switch that would cause the values to invert when such a problem is detected by the user. This should be manual configuration , not an automatic switch.

I am considering replacing the BMS.

BMS is connected using UART to USB connection which works perfectly. Above scenario is also observed using Bluetooth IOS app and PC app

.

Add the REC BMS basic communication to the driver.

• SOC
• Battery voltage
• Charge/discharge current
• Temprature
• Min/max cell voltages
• protection notifications

Uploading UserManual_REC_Victron_BMS.pdf…

https://github.com/Louisvdw/dbus-serialbattery/wiki/How-to-install

Number 7 refers to constants in etc/dbus-serialbattery/utils.py but it should be etc/dbus-serialbattery/battery.py since v0.5 I think.

• SOC
• Battery voltage
• Charge/discharge current
• Temprature
• Min/max cell voltages
• protection notifications

When a JBD BMS connected via USB UART is disconnected physically (Turned off or UART plug pulled), it still shows as connected in Venus OS and battery values still persist.

Steps to reproduce the behavior:

1. Connect JBD BMS via USB UART
2. Unplug UART cable
3. BMS still shows as connected in Venus

Expected behavior
Battery to show as disconnected and values to no longer be displayed (e.g current, SOC, cell voltage etc)

• Device type: Cerbo GX

• Firmware Version: v2.80~21-large-23

• BMS/Battery type: JBD

• Cells: 8

• Interface: JBD tools USB - UART (connected to serial port that was previously used for bluetooth)

Hi,
German company ECS has some nice BMS called LiPro, with very high balancing current and high measurement accuracy. The have active BMS too, because it is cell bases it supports more then 200 cells.
They use modbus RTU with 19200 baud and even parity. Register Description is at the end of user manuals.
https://ecs-online.org/BMS:::2.html

It would be great to implement this Lipro BMS.
If there is any question you can contact support at [email protected]

BD_LiPro1_x_active_de.pdf

• SOC
• Battery voltage
• Charge/discharge current
• Temprature
• Min/max cell voltages
• protection notifications

Hello,
On the Daly bms, when the battery is charging, the BMS displays discharging, and when the battery is discharging it displays charging. On venusOS and VRM the direction of the current is therefore reversed, the reading of information is therefore mistaken. Is there a way to reverse the direction in order to interpret the values as they are displayed on the BMV, so that the current direction is correct?
Thanks in advance,

1. Allow unloading ON/OFF MosFet as a function from victronOS - as a function Controllable e.B of ModBus address 280.
   
   See #26

2. Get installed and available capacity from the daly
   

3. Read alarms
   
   
   See #90

thx for your Work on this Driver

Is your feature request related to a problem? Please describe.

As you might know it or not, I had bought 2 Ant BMS and they both didn't start on my LTO nor LFP bettery packs.
Then I tried a Daly 300A LTO BMS on my LTO battery site with your plug in it works nicely with Venus OS but the Daly BMS I got having two problems: 1. There is no amp reading when current is less than 2A, which makes the SOC easily go off after a few days for my application. 2. The SOC often (like yesterday) caps and stucks at a value (33.3% last time) - which seems a firmwire bug to me.

Then I finally got my 2 QUCC BMS arrived yesterday and they work very nicely, build quality is great and nice service as well. And their SOC estimation seems much better than the Daly ones. The package came with an usb storage key which contians phone app, pc software, detailed doc and serial communication protocols. I think some of their products have the same protocal as the Jaibaida one. But other products from them, like the one I got, have a different protocal (also a different phone app). I think it is a really good product from a good company. The only down side I can think of right now is they don't have a good marketing outside China and their App's English UI needs more polishing for sure.

I will attach their protocal doc here as well.
QUCC BMS-ModbusRTU Communication ProtocolV1.6-User Edition.pdf
(Above one is for 485 I suppose, but I also put CAN doc here just in case)
Qucc CAN communication datasheet-V2.0.pdf

Describe the solution you'd like

Support our plugin (just for monitoring or reading parameters, for my use case I don't need to nor want to do any settings on the BMS via our plugin) with the QUCC BMS protocal

Describe alternatives you've considered

Not sure what alternatives there could be...

Additional context

I natually assume you would be busy to support all different BMSs but if there could be some guide or help, I could perhaps give it a try and see if I could come up with some simple status readings from the QUCC BMS using python. I think the most important values for me to know is SOC, current, voltage, min/max cell voltage (and temperature perhaps). So to achieve this minimum requirement it shouldn't be too hard as we already have a protocol doc?

I also have the usb to 485 adaptor bought together with this bms and it has that ch340 chip on it and can work with their PC softwares. So I am able to test any python or raspberry pi code to read BMS status.

Or if you do have time and want to have a QUCC BMS on your side to test, perhaps I could let the seller know about it and we can ship you one with a low cost (I will cover the cost for you). If that is the case, please let me know what your application requirement is, how many series and what is the max current limit you need.

Thank you :)

Describe the bug

To Reproduce
Steps to reproduce the behavior:
Connect the MGod BMS via RS485 to USB cable to Raspberry Pi.
Logs would be like:

root@raspberrypi2:~# tail -f /data/log/dbus-serialbattery.ttyUSB1/current 
...
@40000000611ea5c536bf82b4 INFO:__main__:dbus-serialbattery v0.5
@40000000611ea5c536d05364 INFO:__main__:Testing Daly
@40000000611ea5c53947fe6c INFO:utils:DalyBMS 10 cells
@40000000611ea5c6017fcfdc INFO:__main__:Battery connected to dbus from /dev/ttyUSB1
@40000000611ea5d014d71734 ERROR:utils:>>> ERROR: No reply - returning
@40000000611ea5d6185c9474 ERROR:utils:>>> ERROR: No reply - returning
@40000000611ea61219cdbc5c ERROR:utils:>>> ERROR: No reply - returning
@40000000611ea62818ad583c ERROR:utils:>>> ERROR: No reply - returning
@40000000611ea64c23e6161c ERROR:utils:>>> ERROR: No reply - returning
@40000000611ea67a24c2e18c ERROR:utils:>>> ERROR: No reply - returning
...

Then when discharging the battery (by wiring it on to a step up converter to charge another battery), I saw this on the VRM website:

Which shows charging state.

Also from the control UI seeing the amp and power is not negative perhaps that means charging as well?

One more thing I should mention is perhaps the Amp reading, which in this 2.4 to 2.6A, but with my other physical meters it reads around 2.1A. Not sure why there is some difference and what could be causing it.

Another thing is what I am not sure about those ERROR:utils:>>> ERROR: No reply - returning output means. Perhaps that means something is not working correctly?

Expected behavior
It should show power usage stage as discharge when the current is going out?

VenusOS (please complete the following information):

• Device type: Raspberry Pi
• Firmware Version v2.72

Battery/BMS (please complete the following information):

• BMS/Battery type: [Daly branded with MGod, LTO version]
• Cells: [10]
• Interface: [USB-RS485]

Additional context
I have asked the seller why MGod BMS looks very similar with Daly BMS, he told me they are corporative companies. I suppose the Daly driver can work out of the box but perhaps there is a few things I need to tweak for the MGod BMS to work?

As I can see the driver is already output some of the key values such as voltage and max,min cells, SOC, so I guess now it should be simple to fix it?

Thank you very much

• SOC
• Battery voltage
• Charge/discharge current
• Temprature
• Min/max cell voltages
• protection notifications

Handle multiple battery modules

Add JKBMS Venus OS integration to the driver:

• SOC
• Battery voltage
• Charge/discharge current
• Temprature
• Min/max cell voltages
• protection notifications
  BMS 485 instruction.pdf
  BMS CAN instruction.pdf
  BMS-CAN2-english.pdf

Read charge/discharge limits from the BMS settings instead of using a hard coded value.
This command is not in the LTT protocol document, but the app does set these so it should be possible to read.

• ANT BMS
• Daly --> Not available. See #550 (comment)
• ECS
• HLPdataBMS4S --> Not applicable. See #505 (comment)
• Jkbms
• Jkbms BLE
• Life/Tian Power
• LLT/JBD
• MNB
• Renogy
• Seplos --> Not available. See #530 (comment)
• Sinowealth

Add the Daly BMS basic communication to the driver.

• SOC
• Battery voltage
• Charge/discharge current
• Temprature
• Min/max cell voltages
• protection notifications

Part 4_ Daly RS485+UART Protocol.pdf

Daly bms connects en disconnects every 5 to 10 seconds.

tail -f /data/log/serial-starter/current also shows the start of the dbus-serialbattery at the same time.

I use Venus Version 2.66 on my Raspberry Pi
Daly 3Cell for testing, interface USB-RS485 and the USB-RS232 from daly or the FTDI: all the same problem...

My current BMS can either be connected to BT or Serial connection to VenusOS. I get to see all cell voltages in BMS , but would like to have the BMS sending the low and high cell to the VenusOS to control charge / discharge of the battery.

I would like to display all 16 cells in the detail, and have this accessible using the Console.

I have decided to return my current BMS and replace with one that supports dual connection. This functionality would still be very useful for single connection devices.

Add units to

• min/max cell voltage (v)
• capacity (Ah)
• battery voltage (V)
• battery current (A)
• battery power (W)

Describe the bug
I installed the package manually on a dev build of VenusOS (2.70~17), ran basic ethernet configuration and enabled SSH to install this package.

I have two USB TTL adaptors installed, neither or them are Victron units - one is connected to a VE.Direct for my SolarCharger (which is still working great) and the other is connected to the JBD Modbus/USB adapter.

The Log contains this information:

root@raspberrypi2:~# cat /data/log/dbus-serialbattery.ttyUSB0/current
@4000000060c29d5336ae8af4 INFO:__main__:dbus-serialbattery
@4000000060c29d540f24462c INFO:__main__:JBD-SP10S009-L8S-100A-B-K
@4000000060c29d542329b38c Traceback (most recent call last):
@4000000060c29d54232b807c   File "/opt/victronenergy/dbus-serialbattery/dbus-serialbattery.py", line 534, in <module>
@4000000060c29d54233505fc     main()
@4000000060c29d542335adf4   File "/opt/victronenergy/dbus-serialbattery/dbus-serialbattery.py", line 521, in main
@4000000060c29d54233ef8dc     battery.read_gen_data()
@4000000060c29d54233f951c   File "/opt/victronenergy/dbus-serialbattery/dbus-serialbattery.py", line 376, in read_gen_data
@4000000060c29d5423465f64     = unpack_from('>HhHHHHhHHBBBBBHH', gen_data)
@4000000060c29d542347651c struct.error: unpack_from requires a buffer of at least 27 bytes

I can confirm this by running it manually as well via /data/etc/dbus-serialbattery/dbus-serialbattery.py /dev/ttyUSB0

root@raspberrypi2:~# /data/etc/dbus-serialbattery/dbus-serialbattery.py /dev/ttyUSB0
INFO:__main__:dbus-serialbattery
ERROR:__main__:>>> ERROR: Incorrect Reply
INFO:__main__:JBD-SP10S009-L8S-100A-B-BK
Traceback (most recent call last):
  File "/data/etc/dbus-serialbattery/dbus-serialbattery.py", line 534, in <module>
    main()
  File "/data/etc/dbus-serialbattery/dbus-serialbattery.py", line 521, in main
    battery.read_gen_data()
  File "/data/etc/dbus-serialbattery/dbus-serialbattery.py", line 376, in read_gen_data
    = unpack_from('>HhHHHHhHHBBBBBHH', gen_data)
struct.error: unpack_from requires a buffer of at least 27 bytes

VenusOS (please complete the following information):

• Device type: Raspberry Pi
• Firmware Version: 2.70~17

Battery/BMS (please complete the following information):

• BMS/Battery type: JBD (https://overkillsolar.com/product/bms-100a-8s-lifepo4/ - re-soldered to be 7s)
• Cells: 7
• Interface: USB-RS485 + USB-RS232 w/Ve.Direct

Additional context
Add any other context about the problem here.

Refactor battery() object to handle different BMS types

Hi Louis,

I have downloaded the driver to USB and for the life of me can’t get it to load to the Cerbo GX.. Any pointers you can give??

Thanks in advance..

Shaun

I love your project! Could you please add support for TinyBMS: https://www.energusps.com/shop/product/tiny-bms-s516-150a-750a-36?category=4

There's a communication protocol PDF here too: https://www.energusps.com/web/binary/saveas?filename_field=datas_fname&field=datas&model=ir.attachment&id=21208

Many thanks!! :)

Describe the bug
I sometimes get wrong readings from the jkbms code. I already added code to test the checksum and the various framing bits (command type, etc), but e.g. the SoC (offset 0x85) sometimes goes to 133%, while battery voltage stays in the correct range (offset 0x83).

The captured status_data in this case is
Invalid soc: [bytearray(b"\x01y0\x01\r\'\x02\r,\x03\r+\x04\r\'\x05\r-\x06\r(\x07\r,\x08\r+\t\r2\n\r\'\x0b\r-\x0c\r(\r\r+\x0e\r-\x0f\r\'\x10\r,\x80\x00\x1d\x81\x00\x18\x82\x00\x18\x83\x15\x10\x84\x85\xc3\x85M\x86\x02\x87\x00\x03\x89\x00\x00\x03\x00\x8a\x00\x10\x8b\x00\x00\x8c\x00\x07\x8e\x16\x80\x8f\x10@\x90\x0e\x10\x91\rH\x92\x00\x05\x93\n(\x94\x0b\xb8\x95\x00\x05\x96\x01,\x97\x00d\x98\x01,\x99\x002\x9a\x00\x1e\x9b\x05\xdc\x9c\x00\x03\x9d\x01\x9e\x00Z\x9f\x00F\xa0\x00d\xa1\x00d\xa2\x00\x14\xa3\x00F\xa4\x00F\xa5\xff\xec\xa6\xff\xf6\xa7\xff\xec\xa8\xff\xf6\xa9\x10\xaa\x00\x00\x01\x18\xab\x01\xac\x01\xad\x04\x0f\xae\x01\xaf\x01\xb0\x00\n\xb1\x14\xb2123456\x00\x00\x00\x00\xb3\x00\xb4Input Us\xb52101\xb6\x00\x00\xd6\x00\xb7H6.X__S6.1.0S__\xb8\x00\xb9\x00\x00\x01\x00\xbaBT307202012000")]

A correct case right next to the wrong frame is like this:
[bytearray(b"\x01y0\x01\r\'\x02\r,\x03\r+\x04\r\'\x05\r-\x06\r(\x07\r,\x08\r+\t\r8\n\r,\x0b\r+\x0c\r(\r\r-\x0e\r\'\x0f\r,\x10\r+\x80\x00\x1d\x81\x00\x18\x82\x00\x18\x83\x15\x11\x84\x86\x01\x85M\x86\x02\x87\x00\x03\x89\x00\x00\x03\x00\x8a\x00\x10\x8b\x00\x00\x8c\x00\x07\x8e\x16\x80\x8f\x10@\x90\x0e\x10\x91\rH\x92\x00\x05\x93\n(\x94\x0b\xb8\x95\x00\x05\x96\x01,\x97\x00d\x98\x01,\x99\x002\x9a\x00\x1e\x9b\x05\xdc\x9c\x00\x03\x9d\x01\x9e\x00Z\x9f\x00F\xa0\x00d\xa1\x00d\xa2\x00\x14\xa3\x00F\xa4\x00F\xa5\xff\xec\xa6\xff\xf6\xa7\xff\xec\xa8\xff\xf6\xa9\x10\xaa\x00\x00\x01\x18\xab\x01\xac\x01\xad\x04\x0f\xae\x01\xaf\x01\xb0\x00\n\xb1\x14\xb2123456\x00\x00\x00\x00\xb3\x00\xb4Input Us\xb52101\xb6\x00\x00\xd6\x00\xb7H6.X__S6.1.0S__\xb8\x00\xb9\x00\x00\x01\x00\xbaBT307202012000")]

In this particular case (it's unfortunately not the only ones), the following bytes are flipped (some might be due to different values):

Offset 0x1d Wrong 0x32 OK 0x38
Offset 0x20 Wrong 0x27 OK 0x2c
Offset 0x23 Wrong 0x2d OK 0x2b
Offset 0x29 Wrong 0x2b OK 0x2d
Offset 0x2c Wrong 0x2d OK 0x27
Offset 0x2f Wrong 0x27 OK 0x2c
Offset 0x32 Wrong 0x2c OK 0x2b
Offset 0x3e Wrong 0x10 OK 0x11
Offset 0x40 Wrong 0x85 OK 0x86
Offset 0x41 Wrong 0xc3 OK 0x01

What I believe is that the find() function in get_data is brittle as it doesn't differentiate between value and idcodes. I think it would be better to parse the bytes continuously, ie. first read the ID, then read the number of bytes associated to it, then continue, etc. I'm happy to write up a patch if you agree with the approach.

ps:
Modified code to test for checksum and print framing bits (in read_serial_data_jkbms):

`
start, length = unpack_from('>HH', data)
terminal = unpack_from('>L', data[4:])[0]
cmd, src, tt = unpack_from('>bbb', data[8:])
frame = unpack_from('>H', data[-9:])[0]
end, crc_hi, crc_lo = unpack_from('>BHH', data[-5:])

    s = sum(data[0:-4])
    logger.info('S%d C%d C%d' % (s, crc_lo, crc_hi))
    logger.info('T%d C%d S%d F%d TT%d' % (terminal, cmd, src, frame, tt))

    if s != crc_lo:
        logger.error('CRC checksum mismatch: Expected 0x%04x, Got 0x%04x' % (crc_lo, s))

`

update formatting

HI.

I am always logging BMS data of the different BMS's I am using.
The single cell voltages are also logged, so I can see in a graph over time if one cell is faster dropping/rising.

Is there a way to get the (even the raw hex values) out of your wonderful piece of code into a /var/log/serial-starter/debug.txt ?

Thank you for your work.

It would be good to have the driver use bluetooth to connect from the VenusOS device to the BMS
The latest rPi images has bluetooth enabled. A GX device will need a USB bluetooth dongle.

It will need to

• Pair the device and the BMS
• Send commands to connected bluetooth
• Read values from connected bluetooth

I would like to ask, if you could support for switching on / off the FETs from ANT BMS?

With the bluetooth , i can turn them on or off with the app.

Id like to disconnect the whole battery on low SoC for example to save energy in critical situations.