Schlage BE469 Zwave-JS Manual Lock/Unlock not reflected in UI

omriasta commented 3 years ago

The problem

After migrating to Zwave-JS, my Schlage BE469 door lock is not displaying status correctly in the UI. The UI shows the status and updates correctly when operating the lock from homeassistant but if I lock /unlock using a code or the manual knob the status does not update in the UI. The entity created for "current status of the door" is always set to open no matter what. I believe this is related to: https://github.com/zwave-js/node-zwave-js/issues/1602

What is version of Home Assistant Core has the issue?

2021.2.1

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Z-Wave JS

Link to integration documentation on our website

https://www.home-assistant.io/integrations/zwave_js/

Example YAML snippet

# Put your YAML below this line

Anything in the logs that might be useful for us?

# Put your logs below this line

This issue presents in the official Zwave-JS addon as well as using the community zwavejs2mqtt. I noticed that the manual lock/unlock operations show up in the community addon logs like this:

2021-02-04 07:44:13.814 INFO ZWAVE: Node 2: notification: Manual unlock operation
2021-02-04 07:44:14.850 INFO ZWAVE: Node 2: notification: Manual lock operation
2021-02-04 07:44:15.883 INFO ZWAVE: Node 2: notification: Manual unlock operation

However this does not show at all in the Official Addon. As mentioned in the other bug report referenced above, this is not an issue with polling but rather with handling the events that the lock sends out during manual operations. Looks like this issue was also addressed in the old open zwave integration.

probot-home-assistant[bot] commented 3 years ago

Hey there @home-assistant/z-wave, mind taking a look at this issue as its been labeled with an integration (zwave_js) you are listed as a codeowner for? Thanks! _{^{(message by CodeOwnersMention)}}

Ikcelaks commented 3 years ago

There's an open issue in the zwave-js repository discussing this issue. That's definitely the problem: the lock sends DoorLockCC reports when it's operated via z-wave and NotificationCC events when operated manually or by the touchpad. The two need to be aggerated like in the legacy zwave implementation. Other door locks are also affected in similar ways.

Edit: just saw that you included that already.

omriasta commented 3 years ago

I know everyone has complained that these locks were not compliant with z wave standard for a long time. Wondering if anyone knows of a zwave lock that is compliant and doesn't have all these issues. Does anyone know if this issue is also present on the BE469ZP (the zwave plus version)?

marcelveldt commented 3 years ago

The entity is not updated because the lock operations are sent as notifications. You can see these notifications in Home Assistant by subscribing to the zwave_js_event btw.

For now not much we can do. Maybe you can do something with the events for now. Let's hope/wait if the issue can be fixed upstream in Z-Wave JS or there can be a workaround provided.

omriasta commented 3 years ago

Yes, I was able to setup an automation that calls the lock/unlock service based on the event that is fired. That being said I also noticed that an event is not fired when a code is used to lock/unlock. The addon logs:

2021-02-05 18:38:51.379 INFO ZWAVE: Node 7: notification: Keypad lock operation with [object Object]
2021-02-05 18:39:26.363 INFO ZWAVE: Node 7: notification: Keypad unlock operation with [object Object]

but no event is fired under zwave_js_event.

Also, if anyone is interested, this is the automation:

alias: Manual Unlock
description: ''
trigger:
  - platform: event
    event_type: zwave_js_event
    event_data:
      label: Manual unlock operation
condition: []
action:
  - service: lock.unlock
    data: {}
    entity_id: lock.touchscreen_deadbolt_current_lock_mode
mode: single

AZDane commented 3 years ago

I know everyone has complained that these locks were not compliant with z wave standard for a long time. Wondering if anyone knows of a zwave lock that is compliant and doesn't have all these issues. Does anyone know if this issue is also present on the BE469ZP (the zwave plus version)?

I have the BE469ZP.

The Lock entity updates correctly as far as I have noticed.
The current status of the door shows always open
I am missing Alarm Level and Alarm Type entities that I had in the deprecated ZWave.

Ikcelaks commented 3 years ago

I have the BE469ZP.

The Lock entity updates correctly as far as I have noticed.

The current status of the door shows always open

I am missing Alarm Level and Alarm Type entities that I had in the deprecated ZWave.

I believe that the door status entity is supposed to represent if the door is open or closed, which these devices don't actually monitor. I just disabled the entity.

Hopefully one of the PRs related to notification sensors resolves the broken alarm_type and alarm_level sensors.

AZDane commented 3 years ago

I have the BE469ZP.

The Lock entity updates correctly as far as I have noticed.

The current status of the door shows always open

I am missing Alarm Level and Alarm Type entities that I had in the deprecated ZWave.

I believe that the door status entity is supposed to represent if the door is open or closed, which these devices don't actually monitor. I just disabled the entity.

Hopefully one of the PRs related to notification sensors resolves the broken alarm_type and alarm_level sensors.

Yes, you are probably correct. The lock has no clue whether the door is open or not.

xntricweb commented 3 years ago

I have the same issue with Kwikset 888 locks.

Here is a temporary fix in node red. The flow connects to the zwave-js-server via websocket and polls the lock state when the notification event is received. I'm sure it could be tweaked to work on other locks.

I tried using an automation in home assistant, but it didn't work very well for me. It takes a good amount of time for my lock state to update which left time for it to get out of sync and would actually result in my lock locking or unlocking after I had changed it manually.

You will have to enable the websocket interface on the ZWave JS addon by setting the host port in the network section of the addon configuration. The flow currently expects it to be running at port 3000.

[{"id":"69700476.97d29c","type":"tab","label":"ZWave JS Listener","disabled":false,"info":""},{"id":"ca3b2a8d.694358","type":"websocket in","z":"69700476.97d29c","name":"zwave-js-server reciever","server":"","client":"165b200f.2b9c9","x":130,"y":80,"wires":[["fba431c9.d3fce"]]},{"id":"43d2b884.a79b58","type":"websocket out","z":"69700476.97d29c","name":"zwave-js-server responder","server":"","client":"165b200f.2b9c9","x":920,"y":260,"wires":[]},{"id":"5b38cc1f.dd5f74","type":"inject","z":"69700476.97d29c","name":"Start Listening Command","props":[{"p":"payload"}],"repeat":"","crontab":"","once":true,"onceDelay":0.1,"topic":"","payload":"{\"messageId\":\"start-listening-result\",\"command\":\"start_listening\"}","payloadType":"str","x":750,"y":120,"wires":[["43d2b884.a79b58"]]},{"id":"b3d48d3b.16db","type":"switch","z":"69700476.97d29c","name":"Message Type Router","property":"payload.type","propertyType":"msg","rules":[{"t":"eq","v":"result","vt":"str"},{"t":"eq","v":"event","vt":"str"}],"checkall":"true","repair":false,"outputs":2,"x":140,"y":140,"wires":[["4340a491.114b3c"],["d32d77ad.dd3cd8"]],"outputLabels":["","event handler"]},{"id":"d32d77ad.dd3cd8","type":"switch","z":"69700476.97d29c","name":"Event Message Router","property":"payload.event.event","propertyType":"msg","rules":[{"t":"eq","v":"notification","vt":"str"}],"checkall":"true","repair":false,"outputs":1,"x":260,"y":200,"wires":[["100372e9.debf0d"]]},{"id":"100372e9.debf0d","type":"switch","z":"69700476.97d29c","name":"Notification Event Router","property":"payload.event.notificationLabel","propertyType":"msg","rules":[{"t":"regex","v":"(Manual|Keypad) (un)?lock operation","vt":"str","case":false}],"checkall":"true","repair":false,"outputs":1,"x":370,"y":260,"wires":[["71e5f463.86256c"]],"outputLabels":["Lock status changed notification"]},{"id":"71e5f463.86256c","type":"change","z":"69700476.97d29c","name":"","rules":[{"t":"move","p":"payload","pt":"msg","to":"incoming","tot":"msg"},{"t":"set","p":"payload","pt":"msg","to":"{\"messageId\":\"get_value\",\"command\":\"node.poll_value\",\"valueId\":{\"commandClassName\":\"Door Lock\",\"commandClass\":98,\"endpoint\":0,\"property\":\"boltStatus\",\"propertyName\":\"boltStatus\"}}","tot":"json"},{"t":"set","p":"payload.nodeId","pt":"msg","to":"incoming.event.nodeId","tot":"msg"},{"t":"delete","p":"_session","pt":"msg"},{"t":"delete","p":"_msgid","pt":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":640,"y":260,"wires":[["43d2b884.a79b58"]]},{"id":"fba431c9.d3fce","type":"json","z":"69700476.97d29c","name":"","property":"payload","action":"","pretty":false,"x":310,"y":80,"wires":[["b3d48d3b.16db"]]},{"id":"4340a491.114b3c","type":"debug","z":"69700476.97d29c","name":"Debug Resutls","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":420,"y":140,"wires":[]},{"id":"6cb620e3.fe00d","type":"inject","z":"69700476.97d29c","name":"Test - Request node 55 value ids","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"{\"messageId\":\"get_value_ids\",\"nodeId\":55,\"command\":\"node.get_defined_value_ids\"}","payloadType":"json","x":750,"y":380,"wires":[["43d2b884.a79b58"]]},{"id":"fb7aafa2.a1fb7","type":"inject","z":"69700476.97d29c","name":"Test - Poll node 55 bolt status","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"{\"messageId\":\"get_value\",\"nodeId\":55,\"command\":\"node.poll_value\",\"valueId\":{\"commandClassName\":\"Door Lock\",\"commandClass\":98,\"endpoint\":0,\"property\":\"boltStatus\",\"propertyName\":\"boltStatus\"}}","payloadType":"json","x":740,"y":420,"wires":[["43d2b884.a79b58"]]},{"id":"165b200f.2b9c9","type":"websocket-client","path":"ws://localhost:3000","tls":"","wholemsg":"false"}]

omriasta commented 3 years ago

I have the same issue with Kwikset 888 locks.

Here is a temporary fix in node red. The flow connects to the zwave-js-server via websocket and polls the lock state when the notification event is received. I'm sure it could be tweaked to work on other locks.

I tried using an automation in home assistant, but it didn't work very well for me. It takes a good amount of time for my lock state to update which left time for it to get out of sync and would actually result in my lock locking or unlocking after I had changed it manually.

You will have to enable the websocket interface on the ZWave JS addon by setting the host port in the network section of the addon configuration. The flow currently expects it to be running at port 3000.

[{"id":"69700476.97d29c","type":"tab","label":"ZWave JS Listener","disabled":false,"info":""},{"id":"ca3b2a8d.694358","type":"websocket in","z":"69700476.97d29c","name":"zwave-js-server reciever","server":"","client":"165b200f.2b9c9","x":130,"y":80,"wires":[["fba431c9.d3fce"]]},{"id":"43d2b884.a79b58","type":"websocket out","z":"69700476.97d29c","name":"zwave-js-server responder","server":"","client":"165b200f.2b9c9","x":920,"y":260,"wires":[]},{"id":"5b38cc1f.dd5f74","type":"inject","z":"69700476.97d29c","name":"Start Listening Command","props":[{"p":"payload"}],"repeat":"","crontab":"","once":true,"onceDelay":0.1,"topic":"","payload":"{\"messageId\":\"start-listening-result\",\"command\":\"start_listening\"}","payloadType":"str","x":750,"y":120,"wires":[["43d2b884.a79b58"]]},{"id":"b3d48d3b.16db","type":"switch","z":"69700476.97d29c","name":"Message Type Router","property":"payload.type","propertyType":"msg","rules":[{"t":"eq","v":"result","vt":"str"},{"t":"eq","v":"event","vt":"str"}],"checkall":"true","repair":false,"outputs":2,"x":140,"y":140,"wires":[["4340a491.114b3c"],["d32d77ad.dd3cd8"]],"outputLabels":["","event handler"]},{"id":"d32d77ad.dd3cd8","type":"switch","z":"69700476.97d29c","name":"Event Message Router","property":"payload.event.event","propertyType":"msg","rules":[{"t":"eq","v":"notification","vt":"str"}],"checkall":"true","repair":false,"outputs":1,"x":260,"y":200,"wires":[["100372e9.debf0d"]]},{"id":"100372e9.debf0d","type":"switch","z":"69700476.97d29c","name":"Notification Event Router","property":"payload.event.notificationLabel","propertyType":"msg","rules":[{"t":"regex","v":"(Manual|Keypad) (un)?lock operation","vt":"str","case":false}],"checkall":"true","repair":false,"outputs":1,"x":370,"y":260,"wires":[["71e5f463.86256c"]],"outputLabels":["Lock status changed notification"]},{"id":"71e5f463.86256c","type":"change","z":"69700476.97d29c","name":"","rules":[{"t":"move","p":"payload","pt":"msg","to":"incoming","tot":"msg"},{"t":"set","p":"payload","pt":"msg","to":"{\"messageId\":\"get_value\",\"command\":\"node.poll_value\",\"valueId\":{\"commandClassName\":\"Door Lock\",\"commandClass\":98,\"endpoint\":0,\"property\":\"boltStatus\",\"propertyName\":\"boltStatus\"}}","tot":"json"},{"t":"set","p":"payload.nodeId","pt":"msg","to":"incoming.event.nodeId","tot":"msg"},{"t":"delete","p":"_session","pt":"msg"},{"t":"delete","p":"_msgid","pt":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":640,"y":260,"wires":[["43d2b884.a79b58"]]},{"id":"fba431c9.d3fce","type":"json","z":"69700476.97d29c","name":"","property":"payload","action":"","pretty":false,"x":310,"y":80,"wires":[["b3d48d3b.16db"]]},{"id":"4340a491.114b3c","type":"debug","z":"69700476.97d29c","name":"Debug Resutls","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":420,"y":140,"wires":[]},{"id":"6cb620e3.fe00d","type":"inject","z":"69700476.97d29c","name":"Test - Request node 55 value ids","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"{\"messageId\":\"get_value_ids\",\"nodeId\":55,\"command\":\"node.get_defined_value_ids\"}","payloadType":"json","x":750,"y":380,"wires":[["43d2b884.a79b58"]]},{"id":"fb7aafa2.a1fb7","type":"inject","z":"69700476.97d29c","name":"Test - Poll node 55 bolt status","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"{\"messageId\":\"get_value\",\"nodeId\":55,\"command\":\"node.poll_value\",\"valueId\":{\"commandClassName\":\"Door Lock\",\"commandClass\":98,\"endpoint\":0,\"property\":\"boltStatus\",\"propertyName\":\"boltStatus\"}}","payloadType":"json","x":740,"y":420,"wires":[["43d2b884.a79b58"]]},{"id":"165b200f.2b9c9","type":"websocket-client","path":"ws://localhost:3000","tls":"","wholemsg":"false"}]

I was noticing a delay myself. Just copied your flow and adjusted the node and ws server address. I'll test it out later to see if anything else needs to be adjusted...pretty sure the regex is correct.

Ikcelaks commented 3 years ago

PR #1641 of zwave-js/node-zwave-js should properly fix this issue for the BE469 and other locks that issue Notification reports according to the standard (notification type 0x06 and values 0x01 (manual lock), 0x02 (manual unlock), 0x05 (keypad lock), and 0x06 (keypad unlock)).

Older devices that use the old Alarm CC will not be fixed by that PR. Hopefully we'll soon get a way to issue a polling request from HA, so that we can make these automations more robust.

bachya commented 3 years ago

Looks like zwave-js merged a PR that should help: https://github.com/zwave-js/node-zwave-js/pull/1641

divinehawk commented 3 years ago

I got bit by this. I have an automatic door lock automation that stopped working when I switched from Openzwave(beta) to zwavejs. Had to revert to my openzwave snapshot but will be happy to test.

enriqg9 commented 3 years ago

I have the same issue with a Yale YRD256, the mentioned PR has been merged upstream in zwave-js 6.2.0, I updated the Zwave-js supervisor component and now run the V6.2.0 but my Zwave-js server still runs the driver in V6.1.3 so my lock still doesn't update the manual lock/unlock statuses.

omriasta commented 3 years ago

I updated the add-on and now my be469 is fine. Lock state updates perfectly and fast!

no-bull commented 3 years ago

I believe the lock/unlock status is not the only issue. Several entities didn't show up when I upgraded. Here is a list of entities that I receive with openZwave: `3:

Schlage Connect Smart Deadbolt: Access Control: Manual Lock Operation binary_sensor.be469zp_connect_smart_deadbolt_access_control_manual_lock_operation
Schlage Connect Smart Deadbolt: Access Control: Manual Unlock Operation binary_sensor.be469zp_connect_smart_deadbolt_access_control_manual_unlock_operation
Schlage Connect Smart Deadbolt: Home Security: Intrusion binary_sensor.be469zp_connect_smart_deadbolt_home_security_intrusion
Schlage Connect Smart Deadbolt: Power Management: Replace Battery Now binary_sensor.be469zp_connect_smart_deadbolt_power_management_replace_battery_now
Schlage Connect Smart Deadbolt: Power Management: Replace Battery Soon binary_sensor.be469zp_connect_smart_deadbolt_power_management_replace_battery_soon
Schlage Connect Smart Deadbolt: System: Hardware Failure binary_sensor.be469zp_connect_smart_deadbolt_system_hardware_failure
Schlage Connect Smart Deadbolt: Locked lock.be469zp_connect_smart_deadbolt_locked
Schlage Connect Smart Deadbolt: Access Control sensor.be469zp_connect_smart_deadbolt_access_control
Schlage Connect Smart Deadbolt: Battery Level sensor.be469zp_connect_smart_deadbolt_battery_level
Schlage Connect Smart Deadbolt: Home Security sensor.be469zp_connect_smart_deadbolt_home_security
Schlage Connect Smart Deadbolt: Power Management sensor.be469zp_connect_smart_deadbolt_power_management
Schlage Connect Smart Deadbolt: Previous Event Cleared sensor.be469zp_connect_smart_deadbolt_previous_event_cleared
Schlage Connect Smart Deadbolt: System sensor.be469zp_connect_smart_deadbolt_system
Schlage Connect Smart Deadbolt: User Code sensor.be469zp_connect_smart_deadbolt_user_code`

dshokouhi commented 3 years ago

I believe the lock/unlock status is not the only issue. Several entities didn't show up when I upgraded. Here is a list of entities that I receive with openZwave:

Lets not add more to what this issue is about, missing entities is not the same as the lock status. Please open a new issue for this. Always keep each issue separate from one another otherwise you risk getting things fixed properly.

omriasta commented 3 years ago

Yes, I am closing as this was fixed in the update to zwave js.

no-bull commented 3 years ago

I believe the lock/unlock status is not the only issue. Several entities didn't show up when I upgraded. Here is a list of entities that I receive with openZwave:

Lets not add more to what this issue is about, missing entities is not the same as the lock status. Please open a new issue for this. Always keep each issue separate from one another otherwise you risk getting things fixed properly.

My apologies. New issue #46594

willheineman commented 3 years ago

I know this issue is closed, but I am seeing the same thing with my Yale YRD210 locks.

In the Zwave-JS control panel, I can see the manual lock/unlock activity within the debug logs. But it only shows a change to the alarmType entity. Within HA, the lock status remains unchanged.

2021-02-28 15:20:51.056 INFO ZWAVE: Node 46: value updated: 113-0-alarmType 25 => 22

I did create an automation to monitor for alarmType 22 (manual unlock) and 21 (manual lock); and then call the appropriate lock service. But this doesn't seem like it should be required.

Should I open a new issue, or am I just doing something wrong in my environment?

Ikcelaks commented 3 years ago

I know this issue is closed, but I am seeing the same thing with my Yale YRD210 locks.

In the Zwave-JS control panel, I can see the manual lock/unlock activity within the debug logs. But it only shows a change to the alarmType entity. Within HA, the lock status remains unchanged.

2021-02-28 15:20:51.056 INFO ZWAVE: Node 46: value updated: 113-0-alarmType 25 => 22

I did create an automation to monitor for alarmType 22 (manual unlock) and 21 (manual lock); and then call the appropriate lock service. But this doesn't seem like it should be required.

Should I open a new issue, or am I just doing something wrong in my environment?

The YRD210, and the many other locks that use the outdated AlarmType/AlarmLevel notifications are not yet fixed in the node-zwave-js library. They are working on it, and there is an active open issue. https://github.com/zwave-js/node-zwave-js/issues/1713

home-assistant / core

Schlage BE469 Zwave-JS Manual Lock/Unlock not reflected in UI #46066