Closed Holric closed 3 years ago
sorry that was a (actually 2) bugs on my part this part is undergoing a lot of rework at the moment so may break if you keep updating if fixed to 2 bugs above, but also made more changes, so worth staying on .7.8 if it works for you if the protocol gave the right voltages, then it is correct - i havent determine which systems use which yet what does getInfo give for your hardware?
ive just got my JKBMS v3.0 working (this uses JK04 though) and managed to test the code - should be working in 0.7.14 or later
The actual code is working now after installing (.7.14). For my JK-B2A24S15P (combined BMS / active Balancer) the JK02 protocol is working on "getCellData". Using "getInfo" the unit is responding on JK02 and JK04. The mpp-solar-service refuses to start now, while in .7.8 it worked. But at first I have to improve the weak Bluetooth connection, then I will try to get logging to work. I will post the "getInfo" response when my BT connection is stable again.
Here are the responses on "getCellData" and "getInfo" :
mpp-solar -p 3C:A5:4A:DE:F6:52 -P JK02 -c getInfo Got 1 records Command: getInfo - BLE Device Information inquiry
Parameter Value Unit Header 55aaeb90 Record Type 03 Record Counter 48 Device Model JK-B2A24S1 Hardware Version 5P3.0 Software Version 4.2.1 Device Name JK-B2A24S15P Device Passcode XXXX Unknown1 200909 Unknown2 2008102328 User Data Input Userdata Settings Passcode? XXXXXX
mpp-solar -p 3C:A5:4A:DE:F6:52 -P JK02 Got 1 records Command: getCellData - BLE Cell Data inquiry
Parameter Value Unit Header 55aaeb90 Record Type 02 Record Counter 55 Voltage Cell01 3.1590 V Voltage Cell02 3.1590 V Voltage Cell03 3.1540 V Voltage Cell04 3.1590 V Voltage Cell05 3.1540 V Voltage Cell06 3.1590 V Voltage Cell07 3.1590 V Voltage Cell08 3.1590 V Voltage Cell09 3.1530 V Voltage Cell10 3.1540 V Voltage Cell11 3.1530 V Voltage Cell12 3.1530 V Voltage Cell13 3.1590 V Voltage Cell14 3.1530 V Voltage Cell15 3.1570 V Voltage Cell16 3.1590 V Voltage Cell17 0.0000 V Voltage Cell18 0.0000 V Voltage Cell19 0.0000 V Voltage Cell20 0.0000 V Voltage Cell21 0.0000 V Voltage Cell22 0.0000 V Voltage Cell23 0.0000 V Voltage Cell24 0.0000 V discard1 ffff0000 Average Cell Voltage 3.1560 V Delta Cell Voltage 0.0060 V Unknown1 2.0480 00 08 Resistance Cell01 0.0530 Ohm Resistance Cell02 0.0520 Ohm Resistance Cell03 0.0530 Ohm Resistance Cell04 0.0520 Ohm Resistance Cell05 0.0510 Ohm Resistance Cell06 0.0500 Ohm Resistance Cell07 0.0520 Ohm Resistance Cell08 0.0520 Ohm Resistance Cell09 0.0520 Ohm Resistance Cell10 0.0510 Ohm Resistance Cell11 0.0510 Ohm Resistance Cell12 0.0510 Ohm Resistance Cell13 0.0520 Ohm Resistance Cell14 0.0520 Ohm Resistance Cell15 0.0610 Ohm Resistance Cell16 0.0520 Ohm Resistance Cell17 0.0000 Ohm Resistance Cell18 0.0000 Ohm Resistance Cell19 0.0000 Ohm Resistance Cell20 0.0000 Ohm Resistance Cell21 0.0000 Ohm Resistance Cell22 0.0000 Ohm Resistance Cell23 0.0000 Ohm Resistance Cell24 0.0000 Ohm Resistance Cell25 0.0000 Ohm discard2 00000000 Battery Voltage 50.4990 V discard3 000020a4000090fdffff Battery T1 14.6 °C Battery T2 16.4 °C MOS Temp 17.1 °C discard4 00000000 Unknown5 0.0000 00 00 Unknown6 0.0000 00 00 Unknown7 0.0000 00 00 Unknown8 24.4640 90 5f Unknown9 0.0010 01 00 discard5 02000000 Unknown10 44.4800 c0 ad Unknown11 0.0030 03 00 Unknown12 0.1000 64 00 Unknown13 0.0000 00 00 Time 8D1H46M58S Unknown15 0.2560 00 01 Unknown16 48.6410 01 be Unknown17 0.0090 09 00 discard6 000000000000000000000007 Unknown18 0.2570 01 01 Unknown19 0.0000 00 00 Unknown20 4.3520 00 11 Unknown21 0.0040 04 00 Unknown22 0.7680 00 03 Unknown23 36.8640 00 90 Unknown24 16.3910 07 40 Unknown25 0.0640 40 00 Unknown26 0.0000 00 00 Unknown27 51.7120 00 ca Unknown28 65.5290 f9 ff Unknown29 0.2550 ff 00 remainder bytearray(b'\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xed') len remainder 93
can you post the status of the service after you have tried starting it (and the relevant logs)
ie the output of $ systemctl --user status mpp-solar.service
and journalctl -r -n 40
remember to update to the latest
systemctl --user start mpp-solar Job for mpp-solar.service failed because the control process exited with error code. See "systemctl --user status mpp-solar.service" and "journalctl --user -xe" for details.
systemctl --user status mpp-solar.service ● mpp-solar.service - MPP Solar Service Loaded: loaded (/etc/systemd/user/mpp-solar.service; disabled; vendor preset: enabled) Active: failed (Result: exit-code) since Tue 2021-01-12 22:27:42 CET; 46s ago Process: 2972 ExecStart=/usr/bin/python3 /usr/local/bin/mpp-solar -C /etc/mpp-solar/mpp-solar.conf (code=exited, status=1/FAILURE) Main PID: 2972 (code=exited, status=1/FAILURE)
Jan 12 22:27:42 smartpi systemd[672]: mpp-solar.service: Service RestartSec=100ms expired, scheduling restart. Jan 12 22:27:42 smartpi systemd[672]: mpp-solar.service: Scheduled restart job, restart counter is at 5. Jan 12 22:27:42 smartpi systemd[672]: Stopped MPP Solar Service. Jan 12 22:27:42 smartpi systemd[672]: mpp-solar.service: Start request repeated too quickly. Jan 12 22:27:42 smartpi systemd[672]: mpp-solar.service: Failed with result 'exit-code'. Jan 12 22:27:42 smartpi systemd[672]: Failed to start MPP Solar Service.
-- Logs begin at Thu 2019-02-14 11:11:59 CET, end at Tue 2021-01-12 22:29:29 CET. --
Jan 12 22:27:41 smartpi python3[2971]: record_type = command_defn["record_type"]
Jan 12 22:27:41 smartpi python3[2971]: File "/usr/local/lib/python3.7/dist-packages/mppsolar/io/jkbleio.py", line 26, in send_and_receive
Jan 12 22:27:41 smartpi python3[2971]: raw_response = self._port.send_and_receive(command, self._protocol)
Jan 12 22:27:41 smartpi python3[2971]: File "/usr/local/lib/python3.7/dist-packages/mppsolar/devices/mppsolar.py", line 55, in run_command
Jan 12 22:27:41 smartpi python3[2971]: results = _device.run_command(command=_command, show_raw=False)
Jan 12 22:27:41 smartpi python3[2971]: File "/usr/local/lib/python3.7/dist-packages/mppsolar/init.py", line 292, in main
Jan 12 22:27:41 smartpi python3[2971]: sys.exit(main())
Jan 12 22:27:41 smartpi python3[2971]: File "/usr/local/bin/mpp-solar", line 10, in
It seems, I have an error in the .conf, I will check it tomorrow.
looks like jkbms stuff causing the problem - this has been moved around a bit, actually i'll make some updates to have a jkbms daemon
make sure to update, and post your conf
running /usr/local/bin/mpp-solar -C /etc/mpp-solar/mpp-solar.conf -D
on the command line will help see the problem too
ok its now changed
use the /etc/jkbms/jkbms.conf.example file as a basis and create a jkbms.conf in the same location
the test with jkbms -C /etc/jkbms/jkbms.conf
or jkbms -C /etc/jkbms/jkbms.conf -D
if there are problems
should be able to create a jkbms service in the same way as the mpp-solar one
Thank you, the new version is working. The new separate jkbms.service is active now after some struggling with the previously installed older jkbms package. There is a strange behaviour in the Bluetooth connection of my Raspberry Pi 3 with the JK-BMS. After some time working and getting responses of the BMS, the connection brakes: jkbms -p 3C:A5:4A:DE:F6:52 -P JK02 WARNING:MPP-Solar:Cannot connect to mac 3C:A5:4A:DE:F6:52 - exceeded 3 attempts Failed to connect to 3C:A5:4A:DE:F6:52 Parameter Value Unit ERROR No response
Using bluetoothctl, everything seems ok: bluetoothctl Agent registered [3C-A5-4A-DE-F6-52]# info Device 3C:A5:4A:DE:F6:52 (public) Alias: 3C-A5-4A-DE-F6-52 Paired: no Trusted: yes Blocked: no Connected: yes LegacyPairing: no
I found out solving the problem temporary by "power off" and "power on" in bluetoothctl: bluetoothctl Agent registered [3C-A5-4A-DE-F6-52]# power off [CHG] Device 3C:A5:4A:DE:F6:52 Connected: no Changing power off succeeded [CHG] Controller B8:27:EB:A0:1E:E8 Powered: no [CHG] Controller B8:27:EB:A0:1E:E8 Discovering: no [CHG] Controller B8:27:EB:A0:1E:E8 Class: 0x00000000 [bluetooth]# power on [CHG] Controller B8:27:EB:A0:1E:E8 Class: 0x00480000 Changing power on succeeded [CHG] Controller B8:27:EB:A0:1E:E8 Powered: yes [bluetooth]# exit
It works for some time and then refuses connection again. Did you have similar problems before?
How far away is Pi from JKBMS? I had same issue with Pi4 every now and then. I switched to Ubuntu machine and found optimal distance with simple USB BT device on 2 meter long cable. Closer is not always better.
The Pi is about 4-5 meters away from the BMS around the corner and with some stuff in between. I did fix external antennas to the units, it does improve to get connection on the first try but doesn't make it long term stable.
There is no way to get valid data via Telegraf into Influxdb and Grafana after countless trying. I tried mqtt, influxdb_mqtt influxdb2_mqtt via MQTT. In this case, telegraf does throw errors on data parsing. MQTT is working generally. Another try was using json as output in jkbms.conf and using inputs.exec in telegraf for polling data:
[[inputs.exec]]
commands = [
"jkbms -C /etc/jkbms/jkbms.conf"
]
timeout = "30s"
name_suffix = ""
#name_override = "jkbms"
data_format = "json"
json_strict = false
fielddrop = ["_command","_command_description","Header","Record Type","Record Counter","discard1","discard2","discard3","discard4","discard5","len remainder","remainder"]
This works also partially, the JSON output is:
{'_command': 'getCellData', '_command_description': 'BLE Cell Data inquiry', 'Header': '55aaeb90', 'Record Type': '02', 'Record Counter': 70, 'Voltage Cell01': '3.2010', 'Voltage Cell02': '3.1980', 'Voltage Cell03': '3.1980', 'Voltage Cell04': '3.2000', 'Voltage Cell05': '3.1970', 'Voltage Cell06': '3.2000', 'Voltage Cell07': '3.2000', 'Voltage Cell08': '3.2000', 'Voltage Cell09': '3.2040', 'Voltage Cell10': '3.2030', 'Voltage Cell11': '3.2030', 'Voltage Cell12': '3.2010', 'Voltage Cell13': '3.2030', 'Voltage Cell14': '3.2030', 'Voltage Cell15': '3.2030', 'Voltage Cell16': '3.2010', 'Voltage Cell17': '0.0000', 'Voltage Cell18': '0.0000', 'Voltage Cell19': '0.0000', 'Voltage Cell20': '0.0000', 'Voltage Cell21': '0.0000', 'Voltage Cell22': '0.0000', 'Voltage Cell23': '0.0000', 'Voltage Cell24': '0.0000', 'discard1': 'ffff0000', 'Average Cell Voltage': '3.2010', 'Delta Cell Voltage': '0.0070', 'Unknown1': '1.0320', 'Resistance Cell01': '0.0530', 'Resistance Cell02': '0.0520', 'Resistance Cell03': '0.0530', 'Resistance Cell04': '0.0520', 'Resistance Cell05': '0.0510', 'Resistance Cell06': '0.0500', 'Resistance Cell07': '0.0520', 'Resistance Cell08': '0.0520', 'Resistance Cell09': '0.0520', 'Resistance Cell10': '0.0510', 'Resistance Cell11': '0.0510', 'Resistance Cell12': '0.0510', 'Resistance Cell13': '0.0520', 'Resistance Cell14': '0.0520', 'Resistance Cell15': '0.0610', 'Resistance Cell16': '0.0520', 'Resistance Cell17': '0.0000', 'Resistance Cell18': '0.0000', 'Resistance Cell19': '0.0000', 'Resistance Cell20': '0.0000', 'Resistance Cell21': '0.0000', 'Resistance Cell22': '0.0000', 'Resistance Cell23': '0.0000', 'Resistance Cell24': '0.0000', 'Resistance Cell25': '0.0000', 'discard2': '00000000', 'Battery Voltage': '51.2110', 'discard3': '0000134d0100aff8ffff', 'Battery T1': '14.1', 'Battery T2': '16.3', 'MOS Temp': '17.0', 'discard4': '00000000', 'Unknown5': '0.2560', 'Unknown6': '1.5120', 'Unknown7': '0.0000', 'Unknown8': '24.4640', 'Unknown9': '0.0010', 'discard5': '02000000', 'Unknown10': '64.4230', 'Unknown11': '0.0030', 'Unknown12': '0.1000', 'Unknown13': '0.0000', 'Time': '9D21H42M45S', 'Unknown15': '0.2560', 'Unknown16': '47.6170', 'Unknown17': '0.0090', 'discard6': '000000000000000000000007', 'Unknown18': '0.2570', 'Unknown19': '0.0000', 'Unknown20': '4.3520', 'Unknown21': '0.0040', 'Unknown22': '2.3040', 'Unknown23': '36.8640', 'Unknown24': '16.3910', 'Unknown25': '0.0640', 'Unknown26': '0.0000', 'Unknown27': '51.7120', 'Unknown28': '65.5290', 'Unknown29': '0.2550', 'remainder': "bytearray(b'\\x00\\x00\\x01\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\xc5')", 'len remainder': 93}
This hands over data but leads also to parsing errors in telegraf.
I! Starting Telegraf 1.17.0
I! Loaded inputs: cpu disk diskio exec kernel mem processes swap system
I! Loaded aggregators:
I! Loaded processors:
I! Loaded outputs: influxdb
I! Tags enabled: host=smartpi
I! [agent] Config: Interval:30s, Quiet:false, Hostname:"smartpi", Flush Interval:10m0s
E! [inputs.exec] Error in plugin: invalid character 'G' looking for beginning of value
E! [inputs.exec] Error in plugin: invalid character 'F' looking for beginning of value
E! [inputs.exec] Error in plugin: invalid character 'G' looking for beginning of value
Could the single quotes in the JSON output causing the error? Shouldn't it look like { ... , "Voltage Cell08": 3.2000, ...} ? I'm more a hardware guy and doing some µC coding and Python stuff in Addition, but I'm not so familiar with MQTT, databases and so on. I'm sorry for causing circumstances while tinkering around with your package. Thank you and best regards
Yeah that looks likely, I'll do an update to the json output to fix that
try 0.7.19 or later for fixed version of the json output module
I tested the last version - same error in telegraf. In the past three days I did modify json.py mqtt.py jk02.py jkbleio.py I did remove the spaces in the field names like "Battery_Cell_Voltage" etc in JK02.py . In json.py and mqtt.py I added a filter list to select the wanted output values to get rid of the "unknown" etc. In mqtt.py I did a type conversion for the numerical values (not very elegant, but works). With these modifications I was able to get values logged via mqtt via telegraf into influxdb (setting data_format=value in mqtt-input.conf for telegraf). In json.py I did a type conversion for the numerical values, in 7.18 it didn't work, but adding it to 7.19 was successfull. Now logging with json works too. Please check the attached archive.
I still have problems with the connection and will try it with an external BT-adapter when I have one.
Best regards
Logging using json-output does work better than using mqtt. There are some droputs, but no more permanent freezes.
I assume it has to do something with the combined Bluetooth / WLAN unit on the Pi.
Telegraf doesn't reply errors since I commented out the line
print("Got {} records".format(recordsToGrab))
in jkbleio.py
Grafana view:
thanks the extra prints (and unknowns) have been removed in 7.21 the json output should not need the extra casts to ints etc, that was an error in the jk decode - should be fixed in 7.21
Thank you for working so quickly and precisely, I will test it soon. I made the list to filter the "wanted to log" values to get rid of the unknowns temporary. May be it could be an idea to implement the possibility to configure the items to log using a configuration file. So it would be possible to customize the logging values and adapt it to the number of used cells in the battery pack and to reduce the data volume in the database. When the logging is stable, I would like to investigate, what the unknown values represent. As there are some more useful values in the app, e.g. current, capacity, remaining capacity, battery in %, balance current etc., it would be desirable to implement it in the protocol in the future. If I can support you in any way, please tell me.
That makes sense, I never really intended for the unknown ones to stick around but an option isn't a bad idea
The json output is working now. Telegraf is parsing and transfering data without error messages. To have an output matching with my current data fields in influxdb, I had to remove the lowercase conversion (maybe also an option for a configuration file).
There is a strange behaviour in the Bluetooth connection of my Raspberry Pi 3 with the JK-BMS. After some time working and getting responses of the BMS, the connection brakes:
I found out solving the problem temporary by "power off" and "power on" in bluetoothctl: It works for some time and then refuses connection again. Did you have similar problems before?
I'm getting a similar result on the Pi, I can 'solve' it with a restart of the bluetooth service (which probably does much the same as the power on/off of bluetoothctl
I wonder if it is the repeated connect and disconnect of the code - will try to think of a way to maintain the connection option and just 'send' another command. It will be quite a big change I think
The json output is working now. Telegraf is parsing and transfering data without error messages. To have an output matching with my current data fields in influxdb, I had to remove the lowercase conversion (maybe also an option for a configuration file).
Good to hear it is working - are you still getting broken connections to bluetooth? I guess I could add another config item - getting to be a few too many though
Using json, there are no permanent losses of connection anymore. But there are frequent dropouts / errors in data, as could be seen in the uploaded Grafana screenshot. I'm waiting for my USB-Bluetooth device to compare the results. But I'm glad have been getting so far, thanks to your support.
For what is worth here is my input. I have been running jkbms since June.2020. After finding optimal distance between BT dongle and all 3 devices I did not have any service interruptions. I have 6 months worth of data from my modules. However this is on PC running Ubuntu 20.04.
Yes it connects and disconnects every time it pulls data. I think John designed it this way because of me. I have 3 jkbms devices.
Hi, for the decode4ByteHex(hexToDecode) function, it's looklike a IEEE-754 Floating Point but with reversed bytes : e.g. 5b566240 = 3.5365V if you reverse bytes like 4062565b you get 3.5365207195281982421875E0 https://www.binaryconvert.com/result_float.html?hexadecimal=4062565B
Hi, for the decode4ByteHex(hexToDecode) function, it's looklike a IEEE-754 Floating Point but with reversed bytes : e.g. 5b566240 = 3.5365V if you reverse bytes like 4062565b you get 3.5365207195281982421875E0 https://www.binaryconvert.com/result_float.html?hexadecimal=4062565B
Awesome thanks - that makes it a lot simpler!!
Hello, thank you for providing this powerful package and the JK-BMS integration. While trying to log my JK-B2A24S15P data I found the discussion in the jblance/jkbms repository. I installed the mpp-solar (7.8) including all requirements on my raspi3 and had the following error:
_mpp-solar -p 3C:A5:4A:DE:F6:52 -P JK02 -c getCellData Traceback (most recent call last): File "/usr/local/bin/mpp-solar", line 10, in
sys.exit(main())
File "/usr/local/lib/python3.7/dist-packages/mppsolar/init.py", line 343, in main
device = device_class(name=args.name, port=args.port, protocol=args.protocol, baud=args.baud)
File "/usr/local/lib/python3.7/dist-packages/mppsolar/devices/mppsolar.py", line 11, in init
self.set_port(port=kwargs["port"], baud=kwargs["baud"])
File "/usr/local/lib/python3.7/dist-packages/mppsolar/devices/device.py", line 117, in setport
from mppsolar.io.jkbleio import JkBleIO
File "/usr/local/lib/python3.7/dist-packages/mppsolar/io/jkbleio.py", line 6, in
from .jkbledelegate import jkBleDelegate
File "/usr/local/lib/python3.7/dist-packages/mppsolar/io/jkbledelegate.py", line 40, in
self.notificationData = bytearray()
NameError: name 'self' is not defined
Installing mpp-solar 7.10 is resulting in the same error.
After (quick&dirty) commenting out the line "self.notificationData = bytearray()" at the bottom of jkbledelegate.py file, mpp-solar -p 3C:A5:4A:DE:F6:52 -P JK02 -c getCellData is working in 7.8, replying the correct cell voltages etc.
In the actual 7.10, after commenting out the line "self.notificationData = bytearray()", there are following more errors:
_mpp-solar -p 3C:A5:4A:DE:F6:52 -P JK02 -c getCellData Traceback (most recent call last): File "/usr/local/bin/mpp-solar", line 10, in
sys.exit(main())
File "/usr/local/lib/python3.7/dist-packages/mppsolar/init.py", line 358, in main
results = device.run_command(command=args.command, show_raw=args.showraw)
File "/usr/local/lib/python3.7/dist-packages/mppsolar/devices/mppsolar.py", line 45, in run_command
response = self._port.send_and_receive(command, show_raw, self._protocol)
File "/usr/local/lib/python3.7/dist-packages/mppsolar/io/jkbleio.py", line 35, in send_and_receive
if self.ble_connect(self._device_path, protocol):
File "/usr/local/lib/python3.7/dist-packages/mppsolar/io/jkbleio.py", line 59, in ble_connect
self._device.withDelegate(jkBleDelegate(self, protocol, record_type))
NameError: name 'recordtype' is not defined
_mpp-solar -p 3C:A5:4A:DE:F6:52 -P JK485 -c getBalancerData Traceback (most recent call last): File "/usr/local/bin/mpp-solar", line 10, in
sys.exit(main())
File "/usr/local/lib/python3.7/dist-packages/mppsolar/init.py", line 361, in main
results = device.run_default_command(show_raw=args.showraw)
File "/usr/local/lib/python3.7/dist-packages/mppsolar/devices/device.py", line 151, in run_default_command
return self.run_command(command=self._protocol.DEFAULT_COMMAND, show_raw=show_raw)
File "/usr/local/lib/python3.7/dist-packages/mppsolar/devices/mppsolar.py", line 45, in run_command
response = self._port.send_and_receive(command, show_raw, self._protocol)
File "/usr/local/lib/python3.7/dist-packages/mppsolar/io/jkbleio.py", line 28, in send_and_receive
record_type = command_defn["record_type"]
KeyError: 'recordtype'
Is there anything I'm doing wrong? As you recently added support for the combined JK BMS/Balancer, what protocol is the right one to use for the BMS type JK-B2A24S15P?
Thank you and best regards