Well unfortunately now it looks like after server restart (whole OS restart) I cannot control the lock any more. I’ve moved the stick closer and still no dice. Curious if this has anything to do with the “failed” buzz that happens after pairing.
Edit: Moved a router closer to the lock and now functioning as expected minus manual lock/unlock status updates.
Are you getting locked/unlocked updates in HA when you manually lock or unlock? Other than that, this is working great for me. Thank You.
I’m not getting these updates.
As previously stated in this thread. to reliably get locked/unlocked updates in ha, you will unfortunately need to do some extra steps. Step that I haven’t invested to much time into learning. The quirk for the lock is in development, but it looks like you need to get specific info from each lock to get updates, or so the story goes.
Has there been any progress with this quirk? I installed it and now i get three separate entities, one for the lock, one for battery status and one for the door position. Seems to be working for the lock and battery, but door position never updates and always remains closed. Also if I lock or unlock the door manually it does not push that status back to HA either.
hello friend
do you know how to get wyze lock status updates in HA?
thank you
I literally just linked it in the comment above yours.
Thank you for answer
I am new in this stuff, so it is difficult to understand how to install
I guess if you want Cloud Control you can use Google Home or Alexa via Nabu Casa…
To me, getting it out of the cloud is the whole idea of Home Assistant,
I was waiting to see this sort of integration before deciding on the Wyze Lock. I think it may be a very good option for me now.
Do you know if this will work with deConz, or does it only work with ZHA currently?
Hello
After spending a few days for understanding why there is no door lock state updates(manually lock, manually unlock, door is open, door is closed) for WYZE LOCK, I got the solution
Enable logging by adding this lines in configuration.yaml
logger:
default: info
logs:
asyncio: debug
homeassistant.core: debug
homeassistant.components.zha: debug
zigpy: debug
bellows: debug
zigpy_xbee: debug
zigpy_deconz: debug
zigpy_zigate: debug
By looking for the logs manually lock, unlock, open and close the door. There should be updates in logs like
Interesting attributes - 52: some number, 41: some number, 56: some number 57: some number
We interested in 52 and 41
According door state, “some number” should be different
We need to change those numbers in lock.py file.
Download " zigpy/ zha-device-handlers" from https://github.com/zigpy/zha-device-handlers/tree/dm/wyze-lock/zhaquirks
Connect to HA via portainer and connect to console
Copy wyze folder to /usr/local/lib/python3.8/site-packages/zhaquirks (there should be lock.py file
inside wyze folder)
Edit lock.py file with vi editor
My lock.py file looks like shown below, and it works
"Interesting attributes - 52: %s, 41: %s, 56: %s, 57: %s",
args[52],
args[41],
args[56],
args[57],
)
if args[52] == 65 and args[41] == 187:
self.warning("the lock is unlocked via the app")
self.endpoint.device.lock_bus.listener_event("lock_event", 2)
elif args[52] == 65 and args[41] == 188:
self.warning("the lock is locked via the app")
self.endpoint.device.lock_bus.listener_event("lock_event", 1)
elif args[52] == 69 and args[41] == 187:
self.warning("the lock is unlocked manually")
self.endpoint.device.lock_bus.listener_event("lock_event", 2)
elif args[52] == 69 and args[41] == 188:
self.warning("the lock is locked manually")
self.endpoint.device.lock_bus.listener_event("lock_event", 1)
elif args[52] == 72 and args[41] == 188:
self.warning("the lock is locked via auto lock")
self.endpoint.device.lock_bus.listener_event("lock_event", 1)
if args[52] == 191 and args[41] == 175:
self.warning("the door is open")
self.endpoint.device.motion_bus.listener_event("motion_event", ON)
elif args[52] == 191 and args[41] == 172:
self.warning("the door is closed")
self.endpoint.device.motion_bus.listener_event("motion_event", OFF)So, I’m looking through my logs and I can see some entries for zigbee events, but I’m not finding anything in particular that refers to “Interesting attributes - 52: some number, 41: some number…” etc.
Are you able to share what exactly I should see/be looking for in my logs?
You can see all events when searching zigbee devices
Awesome, as long as nothing crazy changes before when I put in new batteries, and do my update cycle, I’ll give this a go. Thanks @akhlghatyan, good work.
I’ll update my guide as soon as I get a chance.
Great work everyone. Thought I’d add my quirk handler and automation experience to this thread.
I have two locks setup. Both work without issue as long as I checked for their unique values at index 41 and 52. The locks did not share values at either index. I did not have to do anything to identify which lock was being acted upon by the quirk.
There is a random event broadcasting without the lock physically changing. Once every hour, the event would cause HA to become out of sync. I was able to identify them by letting my logs run while I was buying groceries. Looking at index 0 helped me filter them. The value appears to be 117 for both locks. Maybe this is constant for all locks? Perhaps it is some weird check-in? Not sure.
def handle_message(self, hdr, args):
"""Handle a message on this cluster."""
self.debug("ZCL request 0x%04x: %s", hdr.command_id, args)
i = 0
for arg in args:
self.info("index: %s value: %s", i, arg)
i += 1
self.warning("argument: %s", ",".join(map(str, args)))
if len(args) < 70:
return
self.info(
"Interesting attributes - 52: %s, 41: %s, 56: %s, 57: %s, 0: %s",
args[52],
args[41],
args[56],
args[57],
args[0],
)
# Values we care about
manual_unlocked_vals = [9,43]
manual_locked_vals = [14,44]
lock_state_identfiers = [50, 58, 62, 54, 51, 57, 53]
open_state_identfiers = [196, 200]
open_vals = [63, 29]
closed_vals = [60, 30]
# Note sure if these are updates but seem to appear without the lock actually changing
fakes = [117]
if args[0] in fakes:
return
if args[52] == 180 and args[41] == 165:
self.warning("the lock is unlocked via the app")
self.endpoint.device.lock_bus.listener_event("lock_event", 2)
elif args[52] == 180 and args[41] == 162:
self.warning("the lock is locked via the app")
self.endpoint.device.lock_bus.listener_event("lock_event", 1)
elif args[52] in lock_state_identfiers and args[41] in manual_unlocked_vals:
self.warning("the lock is unlocked manually")
self.endpoint.device.lock_bus.listener_event("lock_event", 2)
elif args[52] in lock_state_identfiers and args[41] in manual_locked_vals:
self.warning("the lock is locked manually")
self.endpoint.device.lock_bus.listener_event("lock_event", 1)
elif args[52] == 189 and args[41] == 162:
self.warning("the lock is locked via auto lock")
self.endpoint.device.lock_bus.listener_event("lock_event", 1)
if args[52] in open_state_identfiers and args[41] in open_vals:
self.warning("the door is open")
self.endpoint.device.motion_bus.listener_event("motion_event", ON)
elif args[52] in open_state_identfiers and args[41] in closed_vals:
self.warning("the door is closed")
self.endpoint.device.motion_bus.listener_event("motion_event", OFF)
Sometimes when the lock changes, the event gets broadcasted 2-3 times over 5 seconds. My automation would trigger multiple times as a result. Setting the mode to single and adding a delay of ~5 seconds to ensure the runs don’t overlap worked for me. I assume adding both a from and a to state in my triggers would also resolve this.
Now, if someone could figure out how to get the battery reading to work, I would be forever thankful. I see the battery listed as an entity, but it is always at 100% and never matches what I see within the Wyze app.
I was looking into the battery and it seems the data being returned from the Lock is always ‘200’, which is the ‘xc8’ value in the below DEBUG output
2021-01-12 22:41:53 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=1, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY|APS_OPTION_RETRY: 320>, groupId=0, sequence=175), 255, -57, 0xf60e, 255, 255, b'\x18\x06\x01!\x00\x00 \xc8']
I know I get the Battery Level of the Lock through the Wyze app when I communicate with only Bluetooth. I don’t know if I get the Battery Level when accessing the Lock without Bluetooth as I removed the Gateway today. I wonder if the Wyze app is always using Bluetooth to get the Battery Level and not ZigBee?
99% sure that with the gateway I was able to get the battery. From this thread it looks like the gateways use zigbee
The gateways have WiFi, BT, and zigbee radios built-in
Ah. That sucks if it is BT only. Lucky the locks themselves will show a red light when low.
I’ve scanned the Lock using a BLE app called LightPunch and the Battery Service UUID 0x180F and Battery Level characteristic UUID 0x2A19 returns a long hex value. Maybe after a few times as the battery has different values, I can decode the value?
Wyze App LightPunch
67% 0x573BF3739EE794A341E9D3E0A6DBBCD2
66% 0x6B588FCB494B1C3443B934347F936132
@mzelmanovich That’s good to know the LED turns Red. I didn’t know that!