search

jdeath / rd200v2

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

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

Closed dimatx closed 9 months ago

dimatx commented 9 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 9 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 9 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 9 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.