JK-BMS LiFePo4 active balancer BMS - in grafana

[paulca]

The BMS:
Its meant to be the "mutts nuts" in DIY "smart" BMSes.  I'll not rattle the specs as it depends on the model, but it's got:

* FET-Bridge partially independent charge/discharge control (body diode drop in asymetric state)
* 3*Rating breaking current (ill trust that at arms reach and fuse at half it)
* Over/Under voltage/current protection, voltage per cell, current per pack.
* Active cell balancing (not sure of the mechanism, but by saying active it's not just a resistor, seems to be a "charge from high", "discharge to low" style flying capacitor setup. 

The smarts are the controls, settings, data and monitoring abilities it presents, including UART, RS485, CAN and BLE.  The settings come down to fine enough grain that you can individually set the resistance on the cell voltage taps/balance leads.  If you don't it will make some attempt to guess them.  Voltage and current are calibratable to.

The data monitoring aspects are what triggered my data hording side and I had to "hack" it. 

Starting with the RS485 I was hoping to find a nice ModBus style interface and dozens of projects already hacking it out on github.  After a few hours bouncing around different git hub repos and forum posts and a few hours with Python code trying to use the same github projects BLE implmentation, which included an hour wasted trying to get a bluetooth dongle to work on my linux server as I sure as hell wasn't installing python windows for anything other than pycharm, where I'd already wasted 20 minutes trying to import the project AND it's "Poetry" environment and getting no where.  Turns out it's not a Modbus standard, it's more a custom UART protocol which unsurprisingly more closely matches their bluetooth protocol.  Also, there have been about 3 maybe 4 incompatible versions of the protocol.

I ended up with clunky partial data from one instance of the BMS (the larger 100A 24S one) and garbage and errors from the smaller one.

Metaphorically wiping the desk clear with a sweep of the arms, I went back to google and widened my search beyond the RS485.  Finding the BLE far more popular to hack, I groaned, having already wasted an evening prior trying to use an Andoid emulator to view the dashboard on the PC rather than the mobile screen.

How things change in a moment.  While still grumbling about having to use Bluetooth I found an ESPHome project for the ESP32 to do the BLE interfacing with the BMS and...  publish all the data via MQTT.  As this ESP32 project required no additional connections other than power to the ESP32 I had it running in 5 minutes.  Not only did it connect and produce sane data first time, but it also produced sane data from both models.

Having the data in the "public" MQTT broker broke the back on the project.  It was all just "work" from there.  Proxying the MQTT topics into the internal MQTT bus, normalising their topics and message format into json and timestamping everything.  Then adding the topic and 10 lines of python code to republish the data to influx along with the rest of the juicier message bus contents.

Of course once it's in Influx, these become about an hours work.
[ Specified attachment is not available ]

Or you can have a play with this interactive snapshot.  There have been a few data outages (as with any fresh into production software).  The first was forgetting it wasn't actually IN production and only finding out when the SSH session on the VM aborted connection and killed the docker running the modified dev code.  Cowboy!  The second was going for a nap and switching off all non-essential DC loads before so.  Unfortunately the USB hub powering said ESP32 found itself included.  Doh!

https://snapshots.raintank.io/dashboard/snapshot/YOLjvioCCaAgwmRWlQxr6n6rF4ecWk14

If anyone is interested I can share some more particulars on the various steps, although all you really need is the ESPHome JKBMS install with a config, and an MQTT to Influx bridge.