To my knowledge they are reported as integer by the BMS. If you have other data, please raise an issue on Github and it can probably be improved.
Feature request - would be epic if this could control the batteries as well… you could create a wireless battery balancing method - for example 4 batteries in series making a 48V bank could be wirelessly balanced … at least theoretically
I am running into a snag. It has been working great for months, then after last update, i got this.
Setup failed for custom integration ‘bms_ble’: Requirements for bms_ble not found: [‘aiobmsble==0.17.0’].
I tried redownloading.
This is usually a (temporary) DNS issue. Probably pypi.org is not reachable for your installation.
Ahh. Ok. What you did here is awesome. So awesome. I have HA in my RV and my friends are very jealous.
I did not ask. Is there something I can do to resolve this? Tried the obvious reboot etc.
@pancakesandwich sorry, but this is really hard to say from remote. Maybe you have the chance to try a fresh HAOS installation in parallel? Otherwise it is debugging network issues. I would assume that other integrations are affected as well. Did you check the log?
Hi @patman! Big thanks for your work on the BLE BMS integration.
Inspired by your logic, I’ve created a standalone ESPHome version specifically tailored for Redodo (JBD) batteries, supporting both 12V and 24V configurations. I’ve migrated the code to the modern external_components format and added a local web server for direct monitoring.
If anyone is looking for an ESP32-based hardware monitor for these batteries, feel free to check it out: GitHub - va13ak/esp_redodo_bms: ESPHome monitor for Redodo LiFePO4 Batteries via BLE
Keep up the great work!
Hi @Patman thanks for your work! I have 12 eco worthy 48v batteries and I can poll them all via Bluetooth command line, and I can get 4-6 to work in HA consistently. After that I get another 4-5 to load in your integration but all values say “unknown”. When I look at diagnostic data however all the values are there in the json file. Is there a limit to how many simultaneous connections? I’m using a USB Bluetooth adapter, not the one built in to raspberry pi
This is a limitation by the adapter(s) you have. You can go to Settings > Bluetooth there you will find how many connections slots are used/available:
To solve, add more adapters or ESPhome BT proxies.
@patman I have some questions for you on your ME app or aiobmsble app and what we are trying to do with a LifePo4 battery BMS and are having difficulties. Is there an email I could use to contact you? or discord server where I can reach you? Many thanks Patrick. Rgds Carlos
You can write me a DM here, open an issue on GitHub, or write me on the HA Discord server. Details are in my GitHub profile.
Ok @Patman I have sent a discord connection req as dm was rejected. I will try to highlight the issue and context here.
Thanks for making time → really appreciate it.
Important context first: we’re working blind. We don’t have the battery or a bench setup. We’re a software studio building an Android app for a client (a battery engineer), and all our testing happens through him → he installs the APK, runs it against his physical battery, and sends us the logs. Each test cycle takes days. So every APK has to count.
Here’s the setup:
The battery has a BMS we’ve identified as TDT (Shenzhen Tuodatong Electronics) or a close derivative → we’ve been using the TDT plugin in aiobmsble as our primary protocol reference. The BLE interface is via a HLK-B40 (BLE-to-UART transparent bridge), UART at RS-232, 9600 baud, 8N1.
BLE UUIDs:
• Service: FFF0
• Write (TX): FFF2 → writeWithoutResponse
• Notify (RX): FFF1
• Handshake channel: FFFA
Protocol sequence based on the TDT integration:
- HiLink handshake on FFFA
- Command 0x8C on FFF2
- Command 0x8D on FFF2
Frames use protocol version byte 0x00 after 0x7E.
Current status:
• BLE connects cleanly 
• Handshake completes
• Commands 0x8C and 0x8D write successfully
• Zero RX observed on FFF1 across multiple test runs and two physical batteries 
We’re waiting on results from our latest build right now.
Our questions:
- Is zero RX on FFF1 a known pattern with the TDT BMS → could the device respond on a different channel, or is there an unlock sequence required before it will reply?
- Any known gotchas with the HLK-B40 bridge specifically that could cause silence on the notify channel even when writes appear to succeed?
Happy to share full frame sequences, diagnostic logs, or anything else that helps.
Thanks Patrick 
your work has been a key reference throughout this project.
Carlos
Quick update → we may have had a breakthrough since my last message.
Following the TDT flow more closely, we tried flipping the CRC to high byte first and we’re seeing a real response for the first time. Still awaiting confirmation on a second battery before we call it, but it’s looking promising.
Will update you once we have a confirmed result.
Carlos
Hi Patrick,
Thank you for your work on this great integration!
It took me a little while to get this working, but, my problems were all self-induced.
Once I figured out that the 6-digit Bluetooth password needed to be removed, things worked great. I think the password is using LiTime’s new “Bluetooth encryption” feature. When enabled, I can’t connect to the battery from the integration or when using bluetoothctl. I found a LiTime press release that states that they are using “SHA-256 encryption”. Of course, sha256 isn’t an encryption algorithm, so who knows what they are really doing. Perhaps they are referring to the bluetooth authentication.
Thanks again for your great work!
You’re welcome!
If you can support me in figuring out how it works, I’m happy to implement this feature so you can use it together with the integration. I guess it could get quite difficult …