search

jdeath / rd200v2

RadonEye RD200 Version 2 Integration for Home Assistant
MIT License
78 stars 17 forks source link

RD200 sensors work for an hour, then stop until BLE proxies or HA are rebooted #30

Closed dimatx closed 11 months ago

dimatx commented 11 months ago

It's unlikely this is an issue with this integration, but wanted to see if others may have found a workaround.

The RD200 goes 'Unavailable' until BLE proxies or HA are rebooted. Other BLE sensors that are near and far continue to work though without requiring reboot.

I have a couple ESP32-based Bluetooth proxies. One is in close proximity next to the RD200.

The error I get in HA is: Error fetching rd200_ble data: Unable to fetch data: 94:E6:86:88:70:9A - 94:E6:86:88:70:9A: Failed to connect after 10 attempt(s): No backend with an available connection slot that can reach address 94:E6:86:88:70:9A was found: The proxy/adapter is out of connection slots or the device is no longer reachable; Add additional proxies (https://esphome.github.io/bluetooth-proxies/) near this device

BigThunderSR commented 11 months ago

I have the same issue, but everything tends to reconnect after a short while if you wait. On rare occasions, I do end up having to power cycle the Radon detector because even the RadonEye app is unable to detect the unit.

jdeath commented 11 months ago

Yes, this is just how it works. Mine will usually just working again after a couple missed updates. Make sure you are running the latest ESPHome. Mine has been up for 76 days, but usually miss a reading a few times a day. The radon eye using a longer-than-standard notification data length, which I think causes issues.

FYI. The people on discord gave some advice on a possible fix to retry when the characteristic is missing, but I do not quite understand. I am a little out of my league. From Discord:

There is a cache clear function that is bound to bleak retry connector that will delete the bluez/esphome caches when this happens if you catch the problem, disconnect, call the function, and try again
https://github.com/Jc2k/aiohomekit/blob/89b33a304391b1743b0f8b58da8da96eedf14afc/aiohomekit/controller/ble/client.py#L72

https://github.com/Jc2k/aiohomekit/blob/89b33a304391b1743b0f8b58da8da96eedf14afc/aiohomekit/controller/ble/client.py#L84
you can rip that wrapper as a decorator for all your gatt calls

Is it "weird" that the charactersitic isn't there, or is this a case where its legitimately not there? 
HomeKit has similar problems with what might be a bluez bug. Something (bluez?) fails to enumerate a device properly on connection, so then you can't use a characteristic because its just not there.
We ended up with a wrapper that force closes the connection when it happens, and another wrapper that retries
https://github.com/Jc2k/aiohomekit/pull/240
those exceptions are specific to us though

edit: Actually, I have never seen the missing slot issue. Do you have any non-Proxy adapters? That could be causing the missing slot issue. If you use BT on a Raspberry Pi, it could have issues as described in the readme.

dimatx commented 11 months ago

Yeah, my issue is that it wasn't coming back for hours/days. I am not sure if I've fixed it, but by disabling sensors in HA that I didn't need (like the pulse ones), it seems to be working now without going unavailable. Possibly a coincidence? Not sure. (Also, just as a data point, this wasn't an issue for me until I upgraded to the latest ESPHome earlier this month.)

All of my BLE adapters are proxies.