WYZE LOCK - Zigbee - Home Assistant - HassIO - HassOS - ZHA integration - Working as expected - remove cloud control

BrianHenryIE · January 14, 2024, 7:00am

I used a hacksaw to cut a notch in the plastic and then used a flat-head screwdriver to pry it open by slowly working my way around.

I’m hoping to use them as Bluetooth proxies with esphome.io. Has anyone done this yet?

And unrelated: has anyone figured how to enable/disable auto-lock without using the Wyze app?

BrianHenryIE · January 27, 2024, 6:22am

The ESP32 will enter the serial bootloader when GPIO0 is held low on reset.

https://docs.espressif.com/projects/esptool/en/latest/esp32/advanced-topics/boot-mode-selection.html#select-bootloader-mode

I haven’t got that to work yet. I’ll update when I do.

Serial output at 115200 baud for an already configured unit:

gist.github.com

https://gist.github.com/BrianHenryIE/f3152b4d3ba4da062bc0c9c0361c9c70

gistfile1.txt

21:55:07.525 -> ets Jun  8 2016 00:22:57
21:55:07.525 -> 
21:55:07.525 -> rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
21:55:07.525 -> flash read err, 1000
21:55:07.525 -> ets_main.c 371 
21:55:07.877 -> ets Jun  8 2016 00:22:57
21:55:07.877 -> 
21:55:07.877 -> rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
21:55:07.877 -> configsip: 0, SPIWP:0xee
21:55:07.877 -> clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00

This file has been truncated. show original

oxnor · March 1, 2024, 9:33pm

I added two locks to Home Assistant from the method at the top, everything added and am able to control just fine.

The issue I’m seeing is the status is not being reflected in any updates. If I manually unlock that status does not get translated back to Home Assistant.

Has anyone else seen this and know how to fix?

toxicfirefly · March 2, 2024, 11:44pm

I was using the Wzye Lock with the custom quirk a year or so ago and I was able to see the Interesting Attributes debug log. But now with the latest Home Assistant I don’t see status updates or any Interesting Attributes debug logs when manually unlocking/locking the lock.

What changed?

@oxnor I have the same problem, not getting status updates. Seems like an on-going problem

EDIT: I removed the Wyse Lock and replaced it with a Kwikset 914. I wanted something better but not going to spend another $100 or so right now on another gadget haha! It was only $30 on eBay. I get updates and appears a correct battery level with the Kwikset. I still have to configure everything in HA but so far so good!

jeffmunk · August 29, 2024, 11:05pm

Seems like there may have been a breaking change that F’d custom quirks. I am not sure how to fix it, but if I figure it out I will post the results here.

github.com/zigpy/zha-device-handlers

[BUG] Custom quirks not working in HA 2023.03

opened 07:01PM - 03 Mar 23 UTC

closed 12:29PM - 10 Jul 23 UTC

javicalle

Recently in HA v2023.03, the ZHA integration has stopped working due to issues w…ith some user-installed custom quirks. The issue is caused by some changes made to Tuya's MCU device implementations. These changes (necessary and brilliantly implemented) could have been deployed in a different way to avoid the impact **on integration** and the noise generated. This could be fixed with PR #2242, but it only mitigates the effect of possible changes. It should be said that the use of custom quirks implies (or should imply) some technical knowledge about what is being done and about the analysis of the incidents that can be generated. On many occasions the problem has been detected and corrected by the users, but not all users are the same. My intention is to collect here the problem that occurred, the possible solutions and lessons learned. The first thing is to identify the origin (or origins) of the problem. I have detected mainly 2: * PR #2043 that removes the `dp_type` from the `DPToAttributeMapping` class * PR #2017 that implements the autodetection of the Tuya data type from the value type Nothing to reproach the changes. I gave them my approval myself. But it is clear that we underestimate the impact of change. Although all the code implemented in the library was modified according to the new implementation, the custom quirks hosted in the user installations have not, and these have affected the integration. In order to mitigate this type of problem, it would have been convenient to grant a deprecation time to the implemented changes. It will not always be achievable, but at least we should considerate it. Let it be clear that this issue is only addressed to myself and that he only seeks to collect my comments on it.

I am getting this in logs:

DEBUG (SyncWorker_8) [zhaquirks] Loading custom quirk module 'wyzelock'

2024-08-29 16:57:53.913 ERROR (SyncWorker_8) [zhaquirks] Unexpected exception importing custom quirk 'wyzelock'

Traceback (most recent call last):

File "/usr/local/lib/python3.12/site-packages/zhaquirks/__init__.py", line 459, in setup

spec.loader.exec_module(module)

File "<frozen importlib._bootstrap_external>", line 995, in exec_module

File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed

File "/config/zigbee/quirks/wyzelock.py", line 21, in <module>

from . import YUNDING

ImportError: attempted relative import with no known parent package

mariusmuja · February 7, 2025, 3:29am

Hi all,

I was having the same issue that many others have reported on this thread (no arguments were passed to the incoming message), so I did a bit of digging and managed to fix it. The updated code is here (I also added a comment with installation instructions): wyze.py · GitHub

It would be good if people would post the messages they see in the logs for various operations (manual lock/manual unlock/app lock/app unlock/open door/close door/auto-lock), the messages looking like this:

2025-02-06 18:04:15.203 WARNING (MainThread) [zigpy.zcl] [0x2F7D:1:0xfc00] [Wyze Lock] Received command: [49, 171, 64, 0, 39, 143, 92, 128, 50, 0, 3, 6, 96, 172, 36, 229, 187, 91, 157, 138, 98, 247, 245, 49, 26, 215, 232, 187, 80, 178, 101, 149, 17, 94, 213, 83, 91, 110, 186, 14, 162, 0, 186, 182, 166, 47, 92, 225, 186, 89]

Maybe if we can see enough messages we can make more progress in reverse engineering the message format. Also post the battery % you see in the app at the time when the messages are sent.

lygris · November 4, 2025, 9:49pm

Can anyone help me figure out which pins connect the zigbee chip to the esp32? I tried probing with my multimeter but there isnt continuity between any of the esp32 pins and the test pads on the board near the zigbee chip besides 3.3v, gnd, and gnd1. I did color code the solder pads to the test pins though.

junalmeida · November 21, 2025, 6:27pm

I like your version better because it provides a way to have different values when you have multiple locks. However it seems to me that my lock is different from yours because:

Value at index args[52] is not consistent on subsequent operations of lock/unlock, so I tried to rely only on args[41].
It seems that messages of lock/unlock of either manually or via app are the same (on regards to args[41]. Given 52 is not consistent I can’t tell if on my case it would be at another index.
Opening and closing the door produces no log at all. Not sure what I am missing, or if it is really different to the point of not reporting the status at all on zigbee - maybe this is something pooled? idk.

I’m yet to find out how it behaves on auto-lock and door jam.
I’d also like to learn how to report on battery level.

Here is the log of what I’ve tested so far

2025-11-21 12:15:44.409 WARNING (MainThread) [zigpy.zcl] [0x6BD7:1:0xfc00] [Wyze Lock] Received command: [75, 171, 64, 0, 65, 219, 228, 128, 97, 0, 1, 6, 96, 237, 23, 50, 66, 192, 136, 27, 24, 194, 89, 30, 183, 148, 70, 224, 167, 86, 119, 248, 16, 123, 90, 176, 137, 13, 221, 109, 187, 165, 200, 93, 145, 6, 55, 154, 13, 180, 8, 88, 112, 180, 93, 117, 151, 56, 199, 140, 166, 85, 36, 127, 107, 251, 65, 206, 224, 53, 4, 34, 205, 163, 73, 92]
2025-11-21 12:15:44.410 WARNING (MainThread) [zigpy.zcl] [0x6BD7:1:0xfc00] [Wyze Lock] Door action: Action.APP_LOCK
2025-11-21 12:18:44.887 WARNING (MainThread) [zigpy.zcl] [0x6BD7:1:0xfc00] [Wyze Lock] Received command: [45, 171, 64, 0, 35, 172, 112, 128, 99, 0, 1, 6, 96, 237, 23, 50, 66, 192, 136, 29, 24, 194, 89, 30, 183, 149, 12, 224, 167, 86, 16, 120, 121, 123, 74, 74, 137, 17, 193, 77, 23, 160, 63, 93, 148, 110]
2025-11-21 12:18:44.887 WARNING (MainThread) [zigpy.zcl] [0x6BD7:1:0xfc00] [Wyze Lock] Ignoring mesage of unknown type: (45, 171, 64), len: 46
2025-11-21 12:31:44.584 WARNING (MainThread) [zigpy.zcl] [0x6BD7:1:0xfc00] [Wyze Lock] Received command: [75, 171, 64, 0, 65, 165, 109, 128, 102, 0, 1, 6, 96, 237, 23, 50, 66, 192, 136, 28, 24, 194, 89, 30, 183, 136, 0, 224, 167, 86, 69, 113, 16, 123, 90, 176, 137, 13, 221, 109, 187, 162, 200, 93, 145, 6, 55, 134, 77, 180, 8, 88, 116, 180, 93, 117, 148, 213, 199, 140, 166, 85, 36, 127, 107, 251, 65, 206, 224, 53, 24, 98, 205, 163, 73, 95]
2025-11-21 12:31:44.585 WARNING (MainThread) [zigpy.zcl] [0x6BD7:1:0xfc00] [Wyze Lock] Door action: Action.APP_UNLOCK

During these tests, I had the “Door Position” setting off.
I just recalibrated and enabled door position, and now I can’t even figure out the lock status anymore. The number of arguments is less then 52, often 20 or 40, and the messages are not consistent with the real actions I see in the app - like, opening the door shows in the app a log of the door open, but this doesn’t show up in zha logs with an approximate time stamp. Most of time the number of logs is smaller than the number of items in the Wyze App.

So I ended up with having Door Position = Disabled, and I adapted the quirks to be like this:

gist.github.com

https://gist.github.com/junalmeida/9ad7655951bb0fba24b307987bdb111a

wyzelock.py

"""Support for the Wyze lock."""
# ## Enable Quirks in configuration.yaml
#
# zha:
#   enable_quirks: true
#   custom_quirks_path: /config/zigbee/quirks
#
#
# put this file in the path specified
#

This file has been truncated. show original