Hi Guys

Just want to share the video I put together on how I connected my Home Assistant to my BSL Batteries.

Took a while to get it to work but I think I have worked out most of the kinks, let me know what you guys think.

https://youtu.be/HlKNxRJbX3Y

Sample Dashboard

@Sc00bs I don't see hubble Am5 in the list and I've been trying to help my neighbor get his battery info into HA with no luck as hubble is restricting access via the rs232 (methode I use on my personal setup) to pull data. I had a look what options I can see in the hubble BMS tool they gave him when he had to update the firmware and I do see pace as an option:

Just wondering it this is perhaps a rabbit hole I could explore to get his battery info into HA.

Has anyone else had success with this method on Hubble AM5 batteries perhaps? I only see AM2 and AM4 in the untested list though.🤷‍♂️

Edited September 6, 2025Sep 6 by -cK-

Hi @-cK-

You connect using the PACE_Modbus connection, not sure if that is the same protocol.

If you aren't getting any data using the Yaml code then I would try getting a dump of all the Modbus registers using the YAML code at

What RS485 adapter are you using?

I know that some of the PACE BMS firmware's don't seem to have the Pace_Modbus protocol.

Edited September 6, 2025Sep 6 by Sc00bs

According to Gemini:

1. PACE protocol → This is the native protocol Pace uses for its own tools (PBMS Tools, factory diagnostics, and OEM integrations). It’s a proprietary frame structure, not standard Modbus RTU.

2. PACE_MODBUS → This is the Modbus RTU mapping of the same data, designed for third-party systems (inverters, PLCs, Home Assistant, etc.). It translates BMS registers into a Modbus register map.

I would speak to Hubble and see if they have a Firmware version available for the AM5 that supports the PACE_MODBUS protocol.

I don't have any RS485 device connected yet to that port, he is getting another battery next week and said he will have hubble update that battery firmware and he will first ask them about this as well and have them set it if need be.

I do have a RS485 to usb adaptor somewhere and was wondering as a test if that port is set to PACE if I could perhaps see if that might not work with the PACE_BMS addon I'm using to see if we are getting any data at all or not. I'm using one that reads directly from my RS232 ( https://github.com/Tertiush/bmspace/ ) but if it is just porting it to the RS485 I'm hoping it might work otherwise I will need to get a RS485 to TTL module first.

In the addon I use I have both IP or serial connection as an option.

2 minutes ago, Sc00bs said:

According to Gemini:

1. PACE protocol → This is the native protocol Pace uses for its own tools (PBMS Tools, factory diagnostics, and OEM integrations). It’s a proprietary frame structure, not standard Modbus RTU.

2. PACE_MODBUS → This is the Modbus RTU mapping of the same data, designed for third-party systems (inverters, PLCs, Home Assistant, etc.). It translates BMS registers into a Modbus register map.

I would speak to Hubble and see if they have a Firmware version available for the AM5 that supports the PACE_MODBUS protocol.

I'll pass that on to him to ask when he is going to do the firmware update.

Edited September 6, 2025Sep 6 by -cK-

The RS485 breakout boards in my experience were always a bit hit or miss. I think that most of them work on 5V and a lot of the communications is at 3.3V.

There is also the soldering which seems to be problematic.

Better to either order a ESP32 with built in RS485 from Lilygo or get one of the RS485 shields from either Electrodragon or you can get locally from https://smarthomeintegrations.co.za/product/smartdeyedonglev4/

I like the LilyGo board.

3 minutes ago, -cK- said:

I'll pass that on to him to ask when I his going to do the firmware update.

Let us know what they say please, interested to know.

Do you know which model PACE BMS the Hubble uses?

I will let you know as I've been struggling to get a solution for him to get the AM5's info into HA.

That is the thing I'm not sure, I think they have a custom firmware based on the pace bms as they are trying to force their customers to use their cloudlink device but it doesn't give the info needed for proper monitoring either nor can that data be pulled to HA.

When you use their bms tool you get a pop up to select eithr VKPH or VKPG (it think) so it could all together be a different BMS as well but the layout of the ports have me think it is pace bms.

Have you tried connecting using the PBMS Tools?

No. I can ask if he is willing to let me try it.

What we did do in our previous attempt was use the Pace BMS addon with a RS232 converter setup that I use on mine to just broadcast the RS232 over wifi. What we found was that it failed to connect as the script expected a s/n to be broadcast when it runs but we got nothing so it failed to connect. On mine you get the data stream if you log in on the ip address of the esp but not on his (again I'm on different batteries). It was almost as if the RS232 is not broadcasting data unless it is send the correct command to broadcast (making my own assumption here). That is were I parked our attempts last time as I do not want to void a warranty for me tinkering on his batteries.

From Hubble's warranty document.

23. It is forbidden to connect any 3rd party devices to the service ports, which is the RS232 and RS485 ports. These ports are reserved for workshop maintenance only and is for programming the BMS. Connecting any 3rd party devices to the RS232 or RS485 ports will void the warranty.

So he is bit reluctent to just have me try anything and having hubble pull a your warranty is void on him one day but we really want to get the data into HA as I had first hand experience of batteries getting damaged due to them running to low while the inverter thought there was enough left in the tank because the inverter is only getting an avg figure and not individuals data.

Agreed, that doesn't sound great, not worth the risk, you don't want to give them any reason to void his warranty.

Yea so I'll rather have him first talk to the hubble tech next week and see what they have to say about this.

Hello everyone. I have been trying to communicate with my lithium battery that uses PBMStools (though I haven't connected mine to it) but I know some with same brand battery having connected his battery to Pbmstools. From what I have read so far I assume my battery uses pace bms prtocol V25 (as those are the ones that communicate with Pbms and not V20). As my ultimate goal as to integrate my battery in my HA. So I have been probing the battery using laptop-->esp32-->max485ttl--->rj45----> battery Rs485 port (Inv side). When I flashed esp32 with esphome to be able to use esphome's native pace bms, but that ended up in sanity check error. Reason being Esphome pace bms expects 122bytes payload whereas my battery sent out 114bytes payload. dropped that idea flashed the esp32 with arduino then ran a sketch to capture raw frames from the battery. The battery churned out raw frames. now I am faced with a problem that across 4 or 5 AI models where I had them decode the raw data there is a consensus over 7 or 8 parameters but there are some missing links. Taking the rs232 route is simpler but i simply don't want to take it. can someone help me out with my situation?

Thanks

On 2026/06/17 at 9:24 AM, ana said:

Hello everyone. I have been trying to communicate with my lithium battery that uses PBMStools (though I haven't connected mine to it) but I know some with same brand battery having connected his battery to Pbmstools. From what I have read so far I assume my battery uses pace bms prtocol V25 (as those are the ones that communicate with Pbms and not V20). As my ultimate goal as to integrate my battery in my HA. So I have been probing the battery using laptop-->esp32-->max485ttl--->rj45----> battery Rs485 port (Inv side). When I flashed esp32 with esphome to be able to use esphome's native pace bms, but that ended up in sanity check error. Reason being Esphome pace bms expects 122bytes payload whereas my battery sent out 114bytes payload. dropped that idea flashed the esp32 with arduino then ran a sketch to capture raw frames from the battery. The battery churned out raw frames. now I am faced with a problem that across 4 or 5 AI models where I had them decode the raw data there is a consensus over 7 or 8 parameters but there are some missing links. Taking the rs232 route is simpler but i simply don't want to take it. can someone help me out with my situation?

Thanks

What battery do you have? My advice is to connect using PBMS tools to the rs232 port and check you can actually connect. Your batteries may be using a different BMS.

If you can connect you will be able to check, what protocols the CANBUS and RS485 ports are configured for.

I used the https://github.com/syssi/esphome-pace-bms project to speak to my batteries over RS485 but your RS485 protocol needs to be set to PACE_MODBUS protocol . There are other integrations available for other protocols but you will need to look for them.

I made a video on setting it up https://www.youtube.com/watch?v=HlKNxRJbX3Y

Good luck