Switchbot WoHand not working after renaming and reloacting device

[cmerkle]

The problem

I previously had a Switchbot WoHand device located in my garage and all was working fine both with HA switchbot integration (bluetooth) and the switchbot app. I deicide to move that device to another area and another appliance in my house, so I renamed the device and changed the room in the Swithbot app as well as in HA. Now the device can no longer be controlled via HA, however it is recognized in HA and still works fine with the Switchbot app.

I tried removing and readding the device to HA and to the swithbot app, and also factory resetting the device and removing and replacing the battery. I also even re-pulled and re-built the HA container, all to no avail.

The HA log files are showing the following error:

"characteristic missing, clearing cache: cba20003-224d-11e6-9fb8-0002a5d5c51b; RSSI: -67"

Please see log below for more detail.

What version of Home Assistant Core has the issue?

2023.8.3

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant Container

Integration causing the issue

Switchbot

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

2023-08-23 09:58:08.867 DEBUG (MainThread) [homeassistant.components.switchbot.entity] Turn Switchbot device on FB:B6:13:A7:54:CC
2023-08-23 09:58:08.867 DEBUG (MainThread) [switchbot.devices.device] FB-B6-13-A7-54-CC (FB:B6:13:A7:54:CC): Scheduling command 570101
2023-08-23 09:58:08.868 DEBUG (MainThread) [switchbot.devices.device] FB-B6-13-A7-54-CC (FB:B6:13:A7:54:CC): Connecting; RSSI: -67
2023-08-23 09:58:14.269 DEBUG (MainThread) [switchbot.devices.device] FB-B6-13-A7-54-CC (FB:B6:13:A7:54:CC): Connected; RSSI: -67
2023-08-23 09:58:14.270 DEBUG (MainThread) [switchbot.devices.device] FB-B6-13-A7-54-CC (FB:B6:13:A7:54:CC): characteristic missing, clearing cache: cba20003-224d-11e6-9fb8-0002a5d5c51b; RSSI: -67
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/switchbot/devices/device.py", line 286, in _ensure_connected
    self._resolve_characteristics(client.services)
  File "/usr/local/lib/python3.11/site-packages/switchbot/devices/device.py", line 312, in _resolve_characteristics
    raise CharacteristicMissingError(READ_CHAR_UUID)
switchbot.devices.device.CharacteristicMissingError: cba20003-224d-11e6-9fb8-0002a5d5c51b

Additional information

No response

[bdraco]

Its likely the device is too far away from HA now to correctly resolve the chars

[bdraco]

Install a proxy near the device https://esphome.github.io/bluetooth-proxies/

[cmerkle]

I thought that may be the case, so I tired holding the bot in my hand right next to my orangepi5b which runs HA and it still did not work. The bot currently has an RSSI of -64dBm which should be acceptable. I also have one of my switchbot meter pluses in the room right next to it and that works fine.

[bdraco]

I'd still try the proxy as the local adapter can't resolve the services for some reason which likely isn't fixable in Home Assistant and has to addressed at the operating system level.

[bdraco]

You could also try a CSR based adapter as they tend to be the most reliable https://www.home-assistant.io/integrations/bluetooth/#cambridge-silicon-radio-csr-based-adapters

But the proxy is still a better bet most of the time

https://www.home-assistant.io/integrations/bluetooth/#improving-connection-times

[cmerkle]

It can't be a signal strength issue since I currently have it sitting right next to my orangepi and it sill doesn't work. It worked just fine yesterday, the issue seems to have started when I moved and renamed it. Is it possible that there is a registry somewhere that isn't getting removed when I remove the device and is conflicting with something?

[bdraco]

You could hard reboot the orangepi and remove all the cache in /var/lib/bluetooth

[cmerkle]

I tried that. Still no success. Really lost here

[bdraco]

Most of these type of issues end the same way since resolving operating system level issues is difficult: either goes stale or getting the esphome proxy.

[cmerkle]

So I tried running sudo systemctl status blueooth and I see the following errors:

Aug 23 22:59:35 orangepi5 bluetoothd[4758]: src/device.c:load_gatt_db() No cache for FB:B6:13:A7:54:CC
Aug 23 22:59:39 orangepi5 bluetoothd[4758]: src/device.c:load_gatt_db() Unable to load key file from /var/lib/bluetooth/B8:2D:28:42:2D:B1/cache/FB:B6>
Aug 23 22:59:39 orangepi5 bluetoothd[4758]: src/device.c:load_gatt_db() No cache for FB:B6:13:A7:54:CC
Aug 23 22:59:48 orangepi5 bluetoothd[4758]: src/device.c:load_gatt_db() Unable to load key file from /var/lib/bluetooth/B8:2D:28:42:2D:B1/cache/FB:B6>
Aug 23 22:59:48 orangepi5 bluetoothd[4758]: src/device.c:load_gatt_db() No cache for FB:B6:13:A7:54:CC
Aug 24 05:57:15 orangepi5 bluetoothd[4758]: src/device.c:load_gatt_db() No cache for DE:99:8E:67:D6:BC
Aug 24 06:28:13 orangepi5 bluetoothd[4758]: src/device.c:load_gatt_db() Unable to load key file from /var/lib/bluetooth/B8:2D:28:42:2D:B1/cache/FB:B6>
Aug 24 06:28:13 orangepi5 bluetoothd[4758]: src/device.c:load_gatt_db() No cache for FB:B6:13:A7:54:CC
Aug 24 06:28:22 orangepi5 bluetoothd[4758]: src/device.c:load_gatt_db() Unable to load key file from /var/lib/bluetooth/B8:2D:28:42:2D:B1/cache/FB:B6>
Aug 24 06:28:22 orangepi5 bluetoothd[4758]: src/device.c:load_gatt_db() No cache for FB:B6:13:A7:54:CC

The output from sudo dmesg | grep -i blue is

[    2.325480] Bluetooth: Core ver 2.22
[    2.325495] Bluetooth: HCI device and connection manager initialized
[    2.325499] Bluetooth: HCI socket layer initialized
[    2.325502] Bluetooth: L2CAP socket layer initialized
[    2.325508] Bluetooth: SCO socket layer initialized
[    4.048888] [BT_RFKILL]: bluetooth_platdata_parse_dt: get property: uart_rts_gpios = 122.
[    4.048906] [BT_RFKILL]: bluetooth_platdata_parse_dt: get property: BT,reset_gpio = 102.
[    4.048917] [BT_RFKILL]: bluetooth_platdata_parse_dt: get property: BT,wake_gpio = 22.
[   19.234527] Bluetooth: HCI UART driver ver 2.3
[   19.234535] Bluetooth: HCI UART protocol H4 registered
[   19.234538] Bluetooth: HCI UART protocol BCSP registered
[   19.234541] Bluetooth: HCI UART protocol ATH3K registered
[   19.234899] Bluetooth: HCI UART protocol Intel registered
[   19.234904] Bluetooth: HCI UART protocol AG6XX registered
[   19.468312] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   19.468315] Bluetooth: BNEP filters: protocol multicast
[   19.468328] Bluetooth: BNEP socket layer initialized

One odd thing that I notice is if I look in /var/lib/bluetooth/DEVICE:MAC:ADDRESS/cache, I do not see a cache file for my switchbot which has mac FB:B6:13:A7:54:CC, but I DO see a cache file for FB:B6:13:A7:54:CD, which is only one character off. The contents of that file are:

[General] Name=WoHand_D

Which shows that it's the correct device. So it's almost like it's getting cached with the wrong MAC address?

[home-assistant[bot]]

Hey there @danielhiversen, @renierm26, @murtas, @eloston, @dsypniewski, mind taking a look at this issue as it has been labeled with an integration (switchbot) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `switchbot` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign switchbot` Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

---

switchbot documentation switchbot source _{^{(message by IssueLinks)}}

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.