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.