[Bug] Wyze deadbolt not working after latest ha-wyzeapi update

[ljhardy]

Describe the bug After installing the last update and restarting HA, all of the wyze deadbolt entities are either "not provided" or "unavailable"

Battery - Not Provided Lock - Unavailable

To Reproduce Steps to reproduce the behavior:

Update the ha-wyzeapi to the latest version, restart ha.

Expected behavior

System configuration System: HASS.IO HA Version: Core 2025.4.1 Supervisor 2025.03.4 Operating System 15.1 Frontend 20250404.0 WyzeApi Version: 0.1.3.3

home-assistant.log

This error originated from a custom integration.

Logger: custom_components.wyzeapi.coordinator Source: helpers/update_coordinator.py:380 integration: Wyze Home Assistant Integration (documentation, issues) First occurred: 10:11:05 AM (1 occurrences) Last logged: 10:11:05 AM

Unexpected error fetching Wyze Lock State Updater data Traceback (most recent call last): File "/usr/local/lib/python3.13/site-packages/bleak/backends/bluezdbus/client.py", line 214, in connect reply = await self._bus.call( ^^^^^^^^^^^^^^^^^^^^^ ...<6 lines>... ) ^ File "/usr/local/lib/python3.13/site-packages/dbus_fast/aio/message_bus.py", line 398, in call await future asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last): File "/usr/local/lib/python3.13/site-packages/bleak_retry_connector/init.py", line 366, in establish_connection await client.connect( ...<3 lines>... ) File "/usr/local/lib/python3.13/site-packages/habluetooth/wrappers.py", line 328, in connect connected = await super().connect(**kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.13/site-packages/bleak/init.py", line 615, in connect return await self._backend.connect(**kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.13/site-packages/bleak/backends/bluezdbus/client.py", line 151, in connect async with async_timeout(timeout): ~~~~~~~~~~~~~^^^^^^^^^ File "/usr/local/lib/python3.13/asyncio/timeouts.py", line 116, in aexit raise TimeoutError from exc_val TimeoutError

The above exception was the direct cause of the following exception:

Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 380, in _async_refresh self.data = await self._async_update_data() ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/config/custom_components/wyzeapi/coordinator.py", line 54, in _async_update_data client = await self._get_ble_client() ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/config/custom_components/wyzeapi/coordinator.py", line 157, in _get_ble_client self._bleak_client = await establish_connection(BleakClient, ble_device, ble_device.address) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.13/site-packages/bleak_retry_connector/init.py", line 390, in establish_connection _raise_if_needed(name, device.address, exc) ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.13/site-packages/bleak_retry_connector/init.py", line 330, in _raise_if_needed raise BleakNotFoundError(msg) from exc bleak_retry_connector.BleakNotFoundError: 70:54:64:FA:D2:65 - 70:54:64:FA:D2:65: Failed to connect after 7 attempt(s): TimeoutError

[ejpenney]

I think this is a problem with the API, I just tried reverting to the old release, deleting and re-adding, my locks are all missing, with the same errors.

I don't know if something changed on the Wyze side or if it's a (temporary) issue but it's totally broken for me!

[ljhardy]

Same. I reverted to the last release and locks are still broken.

[ejpenney]

I just realized I'm getting a different error message than you:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 780, in _async_add_entity
    await entity.async_device_update(warning=False)
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1318, in async_device_update
    await self.async_update()
  File "/config/custom_components/wyzeapi/token_manager.py", line 45, in inner_function
    await func(*args, **kwargs)
  File "/config/custom_components/wyzeapi/lock.py", line 165, in async_update
    lock = await self._lock_service.update(self._lock)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/wyzeapy/services/lock_service.py", line 24, in update
    device_info = await self._get_lock_info(lock)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/wyzeapy/services/base_service.py", line 625, in _get_lock_info
    check_for_errors_lock(self, response_json)
    ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/wyzeapy/utils.py", line 112, in check_for_errors_lock
    raise UnknownApiError(response_json)
wyzeapy.exceptions.UnknownApiError: {'ReqID': '9e5767d0c2', 'ErrNo': '14003', 'ErrMsg': ' Internal Error'}

I also noticed I cannot control the locks via the Wyze app either. They also state "Internal Error" and won't even open the device. I tried restarting the lock and the device bridge, but no changes.

It's distinctly possible this is a different error and my issue appears to be a Wyze issue...

[ljhardy]

My locks work fine from the Wyze app, not there in Homeassistant.

[ljhardy]

I am also getting this error, although my locks are still working with the Wyze app:

wyzeapy.exceptions.UnknownApiError: {'ReqID': '9e5767d0c2', 'ErrNo': '14003', 'ErrMsg': ' Internal Error'}

[ljhardy]

@SecKatie - any ideas here?

[brg468]

@ljhardy if you roll back a version are your locks still broken? If you try that, post any related logs that come up please.

Edit to clarify: roll back a Wyze integration version, shouldn’t matter what HA version you’re on.

[ljhardy]

Yes, they are still broken with the previous version of the integration. Do you want the logs from the current version or from -1?

[brg468]

I guess both if you can. Unless they’re the same.

[ljhardy]

Hmm. It does appear that the locks are back with 0.1.32. Except the entity names have changed a bit. ( I wonder if that was my problem with 0.1.33 too ) I will reinstall that version and report back.

[ljhardy]

Ok, locks work with 0.1.32, but unavailable with 0.1.33. Here are some debug log entries:

2025-04-14 15:58:06.139 DEBUG (MainThread) [custom_components.wyzeapi.light] Creating new WyzeApi light component 2025-04-14 15:58:06.142 DEBUG (MainThread) [custom_components.wyzeapi.switch] Creating new WyzeApi light component 2025-04-14 15:58:06.148 DEBUG (MainThread) [custom_components.wyzeapi.lock] Creating new WyzeApi lock component 2025-04-14 15:58:06.149 ERROR (MainThread) [custom_components.wyzeapi.coordinator] Unexpected error fetching Wyze Lock State Updater data Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 380, in _async_refresh self.data = await self._async_update_data() ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/config/custom_components/wyzeapi/coordinator.py", line 54, in _async_update_data client = await self._get_ble_client() ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/config/custom_components/wyzeapi/coordinator.py", line 157, in _get_ble_client self._bleak_client = await establish_connection(BleakClient, ble_device, ble_device.address) ^^^^^^^^^^^^^^^^^^ AttributeError: 'NoneType' object has no attribute 'address' 2025-04-14 15:58:06.151 DEBUG (MainThread) [custom_components.wyzeapi.coordinator] Finished fetching Wyze Lock State Updater data in 0.002 seconds (success: False)

[brg468]

Can you send me the model id? Its under the specific device page in HA on the top left under Device Info.

[ljhardy]

[brg468]

Thanks. And it's this lock right?

[ljhardy]

No, it's the deadbolt.

[brg468]

Ok. I didn't realize that lock was supported at all prior to 0.1.33. Were you able to lock/unlock it from HA before or just see status? Also do you have Bluetooth setup on your HA installation?

[ljhardy]

Yes. It was fully functional. And yes, Bluetooth is configured on HA.

---

Len Hardy Bartlett, IL USA

---

From: Brian Rogers @.> Sent: Monday, April 14, 2025 4:23:26 PM To: SecKatie/ha-wyzeapi @.> Cc: ljhardy @.>; Mention @.> Subject: Re: [SecKatie/ha-wyzeapi] [Bug] Wyze deadbolt not working after latest ha-wyzeapi update (Issue #690)

Ok. I didn't realize that lock was supported at all prior to 0.1.33. Were you able to lock/unlock it from HA before or just see status? Also do you have Bluetooth setup on your HA installation?

— Reply to this email directly, view it on GitHubhttps://github.com/SecKatie/ha-wyzeapi/issues/690#issuecomment-2803058663, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEARDREGTKYMXBZER4CC5X32ZQRM5AVCNFSM6AAAAAB236GG22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMBTGA2TQNRWGM. You are receiving this because you were mentioned.Message ID: @.***>

[https://avatars.githubusercontent.com/u/19143191?s=20&v=4]brg468 left a comment (SecKatie/ha-wyzeapi#690)https://github.com/SecKatie/ha-wyzeapi/issues/690#issuecomment-2803058663

Ok. I didn't realize that lock was supported at all prior to 0.1.33. Were you able to lock/unlock it from HA before or just see status? Also do you have Bluetooth setup on your HA installation?

— Reply to this email directly, view it on GitHubhttps://github.com/SecKatie/ha-wyzeapi/issues/690#issuecomment-2803058663, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEARDREGTKYMXBZER4CC5X32ZQRM5AVCNFSM6AAAAAB236GG22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMBTGA2TQNRWGM. You are receiving this because you were mentioned.Message ID: @.***>

[brg468]

That's interesting. I was just reading through https://github.com/SecKatie/ha-wyzeapi/issues/394 and it didn't sound like it was controllable prior to it being added in the latest release. Not having this I can't really troubleshoot but maybe @widewing can share some insight since they wrote the latest PR to add Bluetooth functionality.

[ljhardy]

My bad. The lock / unlock doesn't work in 0.1.32, the controls are there, but the lock status doesn't really change:

These are what the entities look like with 0.1.33:

These are what the entities look like with 0.1.32

[widewing]

In previous version the states were fetched from cloud. The states were synced when your phone connected the lock, so you can't get the realtime update or control the lock. The current release connect the lock via bluetooth or bluetooth proxy. But if you do not have bluetooth configured or your device is too far from lock, it will fail. Also it does not support the battery level yet, this requires more reverse engineer effort.

@brg468 I'm wondering if it would make sense to keep both approaches in this integration? To me it seems pointless to get the states from cloud since it's not synced and cannot control. but maybe to some users they still want to see the cloud data?

[ljhardy]

Hmm, so the host that HA is running on has to be close enough to the lock for bluetooth, or there has to be a bluetooth proxy configured in HA that is close enough to the lock?

[brg468]

In previous version the states were fetched from cloud. The states were synced when your phone connected the lock, so you won't get the realtime update or control the lock. The current release connect the lock via bluetooth or bluetooth proxy. But if you do not have bluetooth configured or your device is too far from lock, it will fail. Also it does not support the battery level yet, this requires more reverse engineer effort.

I was literally typing a similar explanation as you posted that 😄.

My 2 cents would be to attempt to determine if the user is able to connect via Bluetooth at all, and if not continue with the old approach, or at least fail gracefully in the short term. Is there an easy way to check if Bluetooth is enabled on a HA install and add the lock or not based on that?

Down the road we could maybe then figure out how to fall back to the old version of polled info if desired, and even consider a hybrid approach where battery status is polled on setups with Bluetooth enabled and get the rest of the info real-time over Bluetooth.

[ljhardy]

I happened to have an Atom Lite laying around, so I configured it with esphome / bluetooth proxy and plugged it in a few feet from the deadbolt. It does work! Would be great to get the battery level in there somehow. Thanks!

[widewing]

In previous version the states were fetched from cloud. The states were synced when your phone connected the lock, so you won't get the realtime update or control the lock. The current release connect the lock via bluetooth or bluetooth proxy. But if you do not have bluetooth configured or your device is too far from lock, it will fail. Also it does not support the battery level yet, this requires more reverse engineer effort.

I was literally typing a similar explanation as you posted that 😄.

My 2 cents would be to attempt to determine if the user is able to connect via Bluetooth at all, and if not continue with the old approach, or at least fail gracefully in the short term. Is there an easy way to check if Bluetooth is enabled on a HA install and add the lock or not based on that?

Down the road we could maybe then figure out how to fall back to the old version of polled info if desired, and even consider a hybrid approach where battery status is polled on setups with Bluetooth enabled and get the rest of the info real-time over Bluetooth.

An underlying issue for hybrid states is the value may be inconsistent: if bluetooth is present but it cannot connect lock consistently, the state will jump between the real time value and cloud value, which could confuse people.

[brg468]

I guess my thought on the hybrid state would be more for things like battery that we just always pull from the server and always pull lock state from the lock if able.

[Mr-Wicket]

So far neither of my Lock Bolt locks have been able to lock/unlock even after the update. I have Bluetooth and Proxies around but honestly my be user error.. not sure if I need to pair it? anyways sharing my experience so far, I just hadn't had time to report.

[widewing]

So far neither of my Lock Bolt locks have been able to lock/unlock even after the update. I have Bluetooth and Proxies around but honestly my be user error.. not sure if I need to pair it? anyways sharing my experience so far, I just hadn't had time to report.

It doesn't require pairing. Do they show lock/unlock states correctly? Can you share the relevant error logs

[github-actions[bot]]

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

[bapesupreme]

I recently picked up the Wyze deadbolt lock and am reading through the previous threads. Prior to 0.1.33 the deadbolt lock was not supported but now it is?

It shows up as keypad_battery but home assistant interprets this as the lock?

It is grayed out for me in HA and I cannot control the lock

This is my first time integrating Wyze with HA

Installed 0.1.32 and lock is not grayed out. I am unable to control the lock.

Failed to perform the action lock/unlock. Wyze returned an error: ({'ReqID': 'defd3f76c0', 'ErrNo': 5038, 'ErrMsg': '无网关类型设备，无法执行该操作'},)

From google translate No gateway type device, unable to perform this operation

HA reports and tracks the state of the lock correctly. I am able to control the lock from the Wyze app.

[Mr-Wicket]

I haven't had time to look into mine.. I have 2 and they show the locked/unlocked state fine but I get failed beeps when I try to do anything. I think mine is a bigger issue though because my VR base stations are also having issues being controlled. Hopefully I can take some time soon to get logs and send them over. Lock State has been a huge improvement alone so I'll take it even if I can never control the damn things in HA.

should we start a new issue for the Deadbolt Lock since this topic was started for the Deadbolt? Thanks Wyze for the fabulous product naming. 😂