Refresh BLE client before cover commands - #13
Conversation
|
I tested this with my own T50 door, which was having the same issue reported on #13 and it works without issues. |
|
@reydelleon Thank you for this fix, it happened once or twice that the power was lost on the Bluetooth proxy, and when power came back, connection would not work, and I would get the "Characteristic 00000000-8e22-4541-9d4c-21edae82ed19 was not found!" error until I rebooted HA. It was hard to know if I had a reliable connection or not with the door looking at entity/device statuses because everything seemed to be OK. Looking forward to new features for this integration, such as battery %/voltage! 🙏 |
|
Thank you so much! Sorry real job got busy and pays better than chickens. I will get this merged ASAP. |
The door occasionally drops its BLE connection. Until HA was restarted this left it unusable in three ways, because nothing reconnected: - Commands failed with "characteristic ... was not found": the cover's controller kept writing through the client captured at setup while RunChickenDevice had built a replacement. Reconnect and repoint the controller at the live client before each command (the fix from #13). - Push updates (door-state changes the door reports on its own) stopped: GATT notifications only arrive over a live connection, and after a drop nothing re-established it or re-subscribed. Add active reconnection: RunChickenDevice takes a disconnect callback that fires on an unexpected drop; __init__ wires it to a coordinator refresh, which reconnects, re-subscribes notifications, and re-reads state. The notification callback is stored and re-subscribed on every reconnect. Lifecycle: async_disconnect() marks an expected disconnect and tears down the link on unload (suppressing reconnect), and the advertisement callback registration is now released via entry.async_on_unload.
|
Closing because I seriously refactored things while incorporating this, so it doesn't make sense to merge , but thanks for finding the bug and the fix! |
|
No worries @bkanuka. The end goal was to have things working well abd it seems that's the case now. Thanks for including the change. |
3 participants
Issue(s): Closes #3
Context
After a Run-Chicken door disconnects,
RunChickenDevicecan establish a replacementBleakClient, but the cover entity continues using the client captured during entity initialization. Commands sent through that stale client have no current GATT service cache and fail withBleakCharacteristicNotFoundErrorfor the write characteristic.Changes in this PR
Before each open or close command, the cover entity ensures the device has an active connection and updates its controller to use the device's current client. This keeps command writes aligned with the client managed by
RunChickenDeviceafter reconnects.Highlights
custom_components/run_chicken/cover.py: Refresh the BLE connection and controller client before open and close writes.Validation outcomes
git diff --check.