Sensors unavailable after time

[BuurmanG]

Checklist

• [x] I have tried the latest version of BMS_BLE-HA.
• [x] I have enabled debug logging for my installation.
• [x] This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
• [x] This issue is not a duplicate issue of any previous issue.
• [x] I have filled out the issue template to the best of my ability.

Provide the type of BMS you used:

PowerQueen (Redodo)

Describe the issue

De integration stops updating. Sensors become unavailable. Reloading the integration does not work. After restarting home assistant the integration works fine.

Reproduction steps

1.
2.
3.
...

Debug logs

Do not have logs

[patman15]

Without a debug log I cannot solve this issue. Please follow these steps and wait till the problem occurs. In case it is already there, just skip the restart of HA and create a log of ~2 minutes.

[BuurmanG]

Meanwhile I have improved the bluetooth signalstrength, downloaded the latest release 1.18.0-beta 1, started debug logging. Now awaiting for results...

[sircambridge]

I have actually noticed something similar. after about a day, all my battery info becomes unavailable, and re-initializing the device or integration does not help, I have to do a restart of home assistant and it will come back. my RSSI is -52, but sometimes fluctuates to -80.

the last thing I saw in my logs is

2025-05-29 07:18:22.904 DEBUG (MainThread) [custom_components.bms_ble.jbd_bms::ECO-LFP48100-3U-8EC7:8EC7)] disconnected from BMS
2025-05-29 07:18:25.588 DEBUG (MainThread) [custom_components.bms_ble.jbd_bms::ECO-LFP48100-3U-8EC7:8EC7)] disconnected from BMS
2025-05-29 07:18:25.589 DEBUG (MainThread) [bleak_retry_connector.bluez] ECO-LFP48100-3U-8EC7 - AA:C2:37:01:8E:C7: Waited 4.8249028623104095e-05 seconds to disconnect
2025-05-29 07:18:25.691 DEBUG (MainThread) [custom_components.bms_ble] ECO-LFP48100-3U-8EC7: BMS communication failed, check signal strength (-82 dBm): AA:C2:37:01:8E:C7 - AA:C2:37:01:8E:C7: Failed to connect after 4 attempt(s): failed to discover services, device disconnected (BleakConnectionError)
2025-05-29 07:18:25.691 DEBUG (MainThread) [custom_components.bms_ble] Shutting down BMS (ECO-LFP48100-3U-8EC7)

what is strange is that once the RSSI recovers to around -52, it does not try to reconnect or re-establish connection, until I do a full restart of homeassistant. then it will run fine for another day or so.

this has so far happened only twice, I am trying to gather logs again and will report back if i find it again. sorry I dont have better debug logs, as it is very hard to reproduce.

Once it does happen, even waiting an entire day does not re-connect. I am also not completely sure why my RSSI dips so low momentarily, as the battery is only a few meters from the Bluetooth antenna, maybe it is some sort of interference. I guess this is a separate issue I need to solve.

[patman15]

@sircambridge do you use a Raspberry Pi and/or a Realtek Bluetooth adapter? Can you give me more details about your BT setup? The integration is built to retry everything every 30s. So almost no permanent data is retained. Thus, it's highly unlikely that something would get stuck that hard. Anyways, there is nothing certain, so I need more data please.

[sircambridge]

I am using a UGREEN USB bluetooth dongle, and i am running home assistant in a docker container on my synology NAS DS220+ (intel celeron). its shared with the container with dbus. i am not sure which bluetooth chip UGREEN uses, perhaps it is realtek.

maybe the issue is with the blueZ running on my synology, however all my other bluetooth devices are working fine with HA.

even after the disconnect, I can see the BMS show up in the bluetooth advertisements in the bluetooth integration has having a good signal RSSI -52.

when it gets into this stuck state, what can I do to help get more diagnostic information? should I look in the bluetoothd logs - i need to figure out where they are stored on my synology.

EDIT: I have enabled debug logging on the bluetooth integration in HA, maybe I can capture what is happening upon the disconnect and what is happening in the 30 second retry, there must be some state retained upstream that is stuck. hopefully I will be able to reproduce it in the next 24 hours and will report back.

[sircambridge]

could this be relevant?

2025-05-29 22:41:04.560 DEBUG (MainThread) [custom_components.bms_ble] ECO-LFP48100-3U-8EC7: BMS data update
2025-05-29 22:41:04.560 DEBUG (MainThread) [custom_components.bms_ble.jbd_bms::ECO-LFP48100-3U-8EC7:8EC7)] connecting BMS
2025-05-29 22:41:06.272 DEBUG (MainThread) [custom_components.bms_ble.jbd_bms::ECO-LFP48100-3U-8EC7:8EC7)] RX BLE data (start): bytearray(b'\x01Q\x00\x00\xff\xff\x00.\x14\xc3\xff\xd1\x00P\x00d\x0b\xdf\x0c\xfc')
2025-05-29 22:41:06.272 DEBUG (MainThread) [custom_components.bms_ble.jbd_bms::ECO-LFP48100-3U-8EC7:8EC7)] incorrect frame end (length: 20).
2025-05-29 22:41:06.272 DEBUG (MainThread) [custom_components.bms_ble.jbd_bms::ECO-LFP48100-3U-8EC7:8EC7)] RX BLE data (cnt.): bytearray(b'\x0c\xf9\x0b\xe1\x0b\xd0\x00\x03\x03\x18\x03\xe8\x00\x01\x00\x01\x00\x17\x00\x00')
2025-05-29 22:41:06.272 DEBUG (MainThread) [custom_components.bms_ble.jbd_bms::ECO-LFP48100-3U-8EC7:8EC7)] incorrect frame end (length: 40).
2025-05-29 22:41:06.273 DEBUG (MainThread) [custom_components.bms_ble.jbd_bms::ECO-LFP48100-3U-8EC7:8EC7)] RX BLE data (cnt.): bytearray(b'\x00\x00\x01\x10\x01\x06\x01\x03\x01\x02\x00\x00\x00\x004\x9d')
2025-05-29 22:41:06.274 DEBUG (MainThread) [custom_components.bms_ble.jbd_bms::ECO-LFP48100-3U-8EC7:8EC7)] incorrect frame end (length: 56).
2025-05-29 22:41:06.722 DEBUG (MainThread) [custom_components.bms_ble.jbd_bms::ECO-LFP48100-3U-8EC7:8EC7)] disconnected from BMS
2025-05-29 22:41:06.722 INFO (MainThread) [custom_components.bms_ble.jbd_bms::ECO-LFP48100-3U-8EC7:8EC7)] failed to initialize BMS connection (BleakDBusError)
2025-05-29 22:41:06.723 DEBUG (MainThread) [custom_components.bms_ble] ECO-LFP48100-3U-8EC7: BMS communication failed, check signal strength (-79 dBm): [org.bluez.Error.Failed] Operation failed with ATT error: 0x0e (Unlikely Error) (BleakDBusError)
2025-05-29 22:41:06.723 DEBUG (MainThread) [custom_components.bms_ble] Finished fetching ECO-LFP48100-3U-8EC7 data in 2.163 seconds (success: False)
2025-05-29 22:41:36.560 DEBUG (MainThread) [custom_components.bms_ble] ECO-LFP48100-3U-8EC7: BMS data update

[patman15]

[org.bluez.Error.Failed] Operation failed with ATT error: 0x0e (Unlikely Error) (BleakDBusError)

This is definitely not a good sign and hints to an issue with the underlying Bluetooth system. You could probably try another Bluetooth dongle?

What I would need is a log showing the minute before the first time Finished fetching ECO-LFP48100-3U-8EC7 data in x seconds (success: False) (with success: false) appears and the minute thereafter. If you have logging constantly on, you should be able to find it. Also, I recommend enabling the RSSI and link_quality sensor. A 24h diagram could give hints as well.

EDIT: please also check that you are running the 1.18.0-beta.1 release. It has some recovery mechanism for stuck BMSs.

[BuurmanG]

Update on Bluetooth Signal Quality and Battery Level Impact

I’ve observed a significant degradation in Bluetooth signal quality when the battery level drops below 10%. Specifically, the signal strength can fall to approximately -90 dBm, which is considered too low for stable communication and can result in intermittent connectivity or complete disconnection.

After recharging the battery and reloading both the Bluetooth and BMS integrations, the signal stabilizes and returns to acceptable levels. This behavior suggests a correlation between low battery voltage and reduced Bluetooth module performance, possibly due to power-saving mechanisms or insufficient voltage supply to the communication module.

[patman15]

For both of you, in case you need my help still (for the moment it does not sound like a bug in the integration),

• use version 1.18.0-beta.1 (or higher in future)
• enable RSSI and link_quality sensor to get an overview of 24hrs
• provide any observation together with a log showing the minute before the first time Finished fetching <BMS> data in x seconds (success: False) (with success: false) appears and the minute thereafter.
• provide diagnosis data from the integration so that I have an overview of your BT setup

The integration should automatically recover from any situation where

• the Bluetooth module of HA is not stuck or degraded, e.g. Raspberry PI, Realtek chipsets, bad connection to proxy
• the BMS is not in a rogue state

i.e. reloading the integration should never make a difference (given that you wait for the recovery to kick in, worst case ~1h).

[BuurmanG]

See result of switching battery off at 10% capacity: the link quality remains intact, and so does the interface with the integration, without interruptions.

[mareklab]

I've noticed the same with 100 Balance BMS by Dale. After a few hours, sensors become unavailable, and it starts working again after a full restart of HA. Batteries loaded to 100%.