Felicity ESS battery looses connection

[SirkoVZ]

Checklist

• [x] I need support with using the integration.
• [x] My issue is not a feature request
• [x] I have thought about providing a debug log and/or diagnostic data.

Describe the issue

Hi,

there are issues with the connection to my FelicityESS LUX-Y-48300LG01 15kWh battery. The symptoms are:

• The battery is found, but it is hard to connect. The integration tries over and over again and fails with "Failed setup, will retry: device communication timed out"
• It seems to help when I open the FSolar app (used for managing the battery) at the mobile and connect. Then the integration is often also able to connect, even when both are connected to the battery.
• When it is finally connected then it looses connection after some time, hours. Either the integration still shows the battery and the entities have "unknown" state. Or, the integration tries to connect as described above.

Observations: The bluetooth device of my HA (hardware: Intel NUC) shows the battery in "Connection slot allocations monitor" only for a few seconds, then it disappears and appears a few seconds later again. When the connection is stable then it is shown all the time. It doesn't matter whether I use active or passive scanning. A second battery (JK BMS) is rock solid showing values.

I attached a debug log file. Please let me know when you need something else. I'm root at the HAOS, so I can provide more details, if necessary.

Best Regards Sirko

debug.log

[patman15]

Hi! Looks like the BMS simply does not answer. Could be an issue with BT or a power save mode that is not handled in my protocol implementation. Did you enable RSSI and link_quality sensor and monitor it for at least 24hrs? Power saving could be seen e.g. that connection is lost when no current is flowing. It could also be an interference issue. The graphs might give hints and correlations.

[SirkoVZ]

Ok, thanks. I enabled both and enabled history graphs for all related entities. After that I restarted HA and connection was fine. (Former HA restarts didn't necessarily let the battery successfully reconnect.) Let's see what the graphs say.

[SirkoVZ]

After some days we have the following:

• RSSI is fine all the time (between -50 and -60 dBm)
• all other entities are "not available" after some time, but the connection is still fine, means, 1 device and 13 entities are still shown in the integration (but the entities show "not available")
• when I reload the device then it is tried to initialize it, but fails
• when I then try to access using the app at the mobile phone then it is able to initialize the device, sometimes several attempts are necessary
• a restart of Homeassistant doesn't fix the issue
• a reboot of HAOS often works, the device is back and showing the entities' values
• interestingly, the time when it stops reporting the values is about 4:05 am, every day! I don't have a clue why is it at the same time every day...

Hope that helps, somehow...

[patman15]

• a restart of Homeassistant doesn't fix the issue
• a reboot of HAOS often works, the device is back and showing the entities' values

Do you maybe have a Realtek adapter for BT? Both observations hint towards a hardware and/or Bluetooth issue.

[SirkoVZ]

According to the "device Info" and to the MAC it is Intel

[patman15]

Hi @SirkoVZ, maybe you could also try to increase the timeout for your battery as mentioned in this https://github.com/patman15/BMS_BLE-HA/issues/273#issuecomment-2817278959

[SirkoVZ]

Hi,

I increased the timeout to 20 seconds, but still not possible to get an answer. I added another log with two connection attempts, first one faild and second one succeeded. The only difference is that I connected using the FSolar app in background before the second attempt.

debug2.log

[patman15]

Hmm, this sounds like the battery expects some additional commands that I haven't implemented. Could you try to capture the Bluetooth traffic on Android or iOS while using the vendor app with the battery. I would need a few minutes, say 3-5 just to be sure to capture all communication with the battery. Did you see the integration ever connecting without the help of the app?

EDIT: Just saw that there are two more commands I'm not using that might be expected by the battery. I can implement them later on an see if that helps. Still a recording would be cool if possible.

[patman15]

Hi @SirkoVZ, can you try the linked branch? I added two more queries, maybe those wake the BMS. Let me know if it helps!

[SirkoVZ]

Hi,

thanks, I added the code, let's see tomorrow the results...

[SirkoVZ]

Hi,

adding the code didn't make any difference. Still not awaking. But I attached the btsnoop_hci.log from the Android Device when I used the FSolar app that shows the values. Maybe it helps.

Maybe it is helpful to filter for BouffaloLab in src or dst in WireShark.

btsnoop_hci.log

[patman15]

Hi, I had a first look but couldn't spot something obvious. Did you do the recording from a situation, where the integration failed shortly before? (Just to make sure that the "unlock command" has to be in the recording). I have another idea that I could try, will let you know, when I have test code.

[SirkoVZ]

Hi, yes, the integration failed before, while I opened the FSolar app on the mobile. The app was able to show results. Thanks for your effort

[patman15]

So, I updated again with two possible solutions, let's see if something helps. Otherwise I fear I'm running out of ideas, but let's see. A debug log would be cool! Thanks!

[SirkoVZ]

Hi,

there are still issues. I attached a log. It shows as it is working until 4:07 am and fails afterwards. It also shows how it is starting again when I opened the app at about 15:44:15. Hope that helps

felicity.log

[patman15]

Hi! There is unfortunately nothing in the log the would give a hint. It just stops. I did another small change that might help, just update the code on the branch. There is one last thing another user found with the JBD BMS, which we then can try last. Sorry for the tedious process, but without having the battery, it is really just trial and error. 😔

[SirkoVZ]

Hi, no need to excuse :-) I know that it is hard when it is not possible to have access to the device.

The connection is still lost short after 4:00 am. Interestingly it is 0:00 am Chinese time. (the Felicity battery is a Chinese product) Maybe some kind of reset at 0:00 am is done.

As the Bluetooth connection to Homeassistant is restored when I open the FSolar app at the mobile phone, I will try to get another Bluetooth traffic capture of the mobile in such case. Additionally, I will contact the vendor, probably the behavior is different/better when I can convince them to update the BMS/firmware. Thanks so far. Sirko

[patman15]

The timing is interesting, indeed. Is it that you need to recover it every day? Like you run HA, 4am, App, HA continues, 4am, App, HA continues, ... or does the sequence only happen once? I'm working in the background on a mechanism that would try to recover such a situation. It cannot be perfect but would result in limited loss of data and automatic recovery. Do you want to test that? Of course it does not fix the issue itself.

[SirkoVZ]

Sometimes after a restart of HA it is working for a while, but at most to 4 am. THen I need to use the App, or maybe another restart helps (but not always). Sometimes I see even that it recovered over the day. I have another HA system with the same battery. Here is it somehow different: it works for one or two updates, then it timing out for a few requests and then it is working for one or two requests a.s.o. Yes, I can do tests (but after next week)

[patman15]

I have another HA system with the same battery.

@SirkoVZ Not sure I read this correctly, but you cannot have the same battery in two systems. The integration requests exclusive access, so only one reader can exist at a time.

[SirkoVZ]

It's a different system, completely independent. Another address, another HA.

[github-actions[bot]]

This issue is stale because it has been open 32 days with no activity. Remove stale label or comment or this will be closed in 8 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 8 days with no activity.