there is a quirk in development that works, however you have to customize the quirk per installation as the locks send data specific to each lock. Until there is a calibration step native in HA, the quirk will need to manually edited before it will work.
2 Likes
How’s your experience of ZHA and wyze lock so far? I’m looking for smart locks that integrate with HA.
I honestly do not have it in use. I’ve tested the quirk that I linked above and it works but has to be manually updated. I run HA Supervised so I have to had that quirk back every update which I have not done. The lock does stay online in my zigbee mesh, and I can trigger a lock/unlock without the quirk and it works consistently, it just does not report the the states.
1 Like
Thanks for the response. How do I manually install/update those ZHA quirks? I’m running HA container, didn’t find the instruction from the github page.
you have to get a command line inside the docker container. With HA Supervised, I use portainer, and am able to use that to get a command line. I put the quirk files in a directory in my config directory, then copy them over to the quirks folder.
in the HA docker container they are here: /usr/local/lib/python3.7/site-packages/zhaquirks/
For this quirk you have to turn on debug logging and and watch the logs then edit the quirk to match the responses your lock gives. It is far from straight forward, it has been a while since I worked with the dev and he helped me get it working.
2 Likes
Does this work for your purposes yall? it’s functional for me!
1 Like
I believe I understand what needs to be done to modify the quirk to get it working properly. What i’m confused about is how do you obtain the data that’s needed? Could you please shed some light on this for me? I’m guessing you need to use a sniffer or a logger of some sort but i have no clue how that works.
It’s been a long time since I did this, but you’ll want to install the quirk as is, then turn on debug logging for zigpy.
Trigger all the different states (manual lock/unlock, app lock/unlock, open/closed)
Do them all a few time the lock will send some long codes for each which should be in the logs. I believe the quirk will spit out some useful logging to help guide you to the values needed. I’ll try and double check later tonight.
Thanks, this was helpful but I must still be doing something wrong. Do i need to use zigbee2mqtt or something? Currently using ZHA and my logs are not spitting out anything that resembles the data above.
this is all ZHA.
After you install the quirk and turn on zigpy debug logging, you should see a message like this for each action:
2020-09-30 20:49:01 INFO (MainThread) [zigpy.zcl] [0xd946:1:0xfc00] Interesting attributes - 52: 236, 41: 142, 56: 119, 57: 170
these are the values that will go into the quirk - for my lock they match the Manually locked action:
(edited to make sure screenshot had the line numbers)
there is a section of the readme for zha_device_handlers that describes how to install the quirk that is not in the official release:
So i installed the quirk a while back using Portainer but i’m not getting the same kind of output in my logs when i use the lock. Not sure where I went wrong, here is what i’m seeing in my logs:
2020-09-30 21:08:14 DEBUG (MainThread) [zigpy.zcl] [0xec7e:1:0x0101] ZCL request 0x000a: [[Attribute(attrid=0, value=<TypeValue type=enum8, value=enum8.undefined_0x02>)]]
2020-09-30 21:08:14 DEBUG (MainThread) [zigpy.zcl] [0xec7e:1:0x0101] Attribute report received: lock_state=2
2020-09-30 21:08:14 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xEC7E:1:0x0101]: Attribute report 'Door Lock'[lock_state] = LockState.Unlocked
2020-09-30 21:08:14 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=lock.yunding_ford_075bb4fe_door_lock, old_state=<state lock.yunding_ford_075bb4fe_door_lock=locked; friendly_name=Yunding Ford 075bb4fe door_lock @ 2020-09-30T21:03:52.114109-04:00>, new_state=<state lock.yunding_ford_075bb4fe_door_lock=unlocked; friendly_name=Yunding Ford 075bb4fe door_lock @ 2020-09-30T21:08:14.102747-04:00>>
2020-09-30 21:08:14 DEBUG (MainThread) [zigpy_cc.zigbee.application] request (0xEC7E, 260, 257, 1, 1, 124, b'\x18|\x0b\n\x00', False, False)
2020-09-30 21:08:14 DEBUG (MainThread) [zigpy_cc.api] --> SREQ AF dataRequest tsn: 124 {'dstaddr': 60542, 'destendpoint': 1, 'srcendpoint': 1, 'clusterid': 257, 'transid': 124, 'options': 0, 'radius': 30, 'len': 5, 'data': b'\x18|\x0b\n\x00'}
2020-09-30 21:08:14 DEBUG (MainThread) [zigpy_cc.uart] Send: b'\xfe\x0f$\x01~\xec\x01\x01\x01\x01|\x00\x1e\x05\x18|\x0b\n\x00\xba'
have you updated HA since installing the quirk? you will need to reinstall it after each update.
I have an EmberZNet based stick, so I don’ t know if the zigpy_cc lib is acting a bit different. you may want to try switching to the zigpy_znp lib which is now working with all the TI controllers I think, it was in the 0.115 release. I haven’t followed too much about how to do that switch but the zigbee channel on discord is very helpful, and the main dev of zigpy_znp (puddy) is helpful there.
the actual message may be in the lines above that log as well.
instructions to switch to zigpy-znp: https://github.com/zha-ng/zigpy-znp/#home-assistant
1 Like
Argh! I totally forgot that I updated to 0.115.5! Now my log resembles yours so i’ll see if can figure out which attributes are needed for the quirk
1 Like
Thank you so much for taking the time to help me with this! I got the correct attributes identified and everything works properly now. It’s nice to have the lock automatically show it’s correct state for a change
Awesome! Glad I could help. @dmulcahey did the hard work of deciphering the mess that the lock sends and writing this quirk. It sucks wyze won’t share any info.
Hopefully one day the variables for the quirk can be read from a config file or be set up in the zha config panel.
2 Likes
So just when i thought everything was working perfectly now, my lock has been randomly changing it’s state from locked to unlocked. It’s not actually unlocking itself, just seems to be setting the state incorrectly. No idea why, i thought i identified all the correct attributes for the states as they all do report correctly (locked/unlocked, closed/open). Have you had any similar experiences?
I don’t have the lock in production and haven’t noticed that
I had the same issue. Some messages from the lock are being incorrectly identified as lock state changes. I fixed it by looking at an additional value which was changed in the messages.
This is what I changed:
self.info(
"Interesting attributes - 0: %s, 52: %s, 41: %s, 56: %s, 57: %s",
args[0],
args[52],
args[41],
args[56],
args[57],
)
if args[52] == 221 and args[41] == 155 and args[0] == 79:
self.warning("the lock is unlocked via the app")
self.endpoint.device.lock_bus.listener_event("lock_event", 2)
elif args[52] == 221 and args[41] == 156 and args[0] == 79:
self.warning("the lock is locked via the app")
self.endpoint.device.lock_bus.listener_event("lock_event", 1)
elif args[52] == 217 and args[41] == 155 and args[0] == 79:
self.warning("the lock is unlocked manually")
self.endpoint.device.lock_bus.listener_event("lock_event", 2)
elif args[52] == 217 and args[41] == 156 and args[0] == 79:
self.warning("the lock is locked manually")
self.endpoint.device.lock_bus.listener_event("lock_event", 1)
elif args[52] == 212 and args[41] == 156 and args[0] == 79:
self.warning("the lock is locked via auto lock")
self.endpoint.device.lock_bus.listener_event("lock_event", 1)
I’m currently using a ConBee2 as my zigbee stick and can’t seem to see the “Interesting attributes” you mentioned anywhere in my logs? Any idea how to see that info?