I recently just added a Secure Door Lock into my home setup. And I can control the lock with HASS. But it appears the lock status is not updating correctly.
If I lock/unlock the door manually, I am not seeing any change in the status in the web UI. I do have the polling_interval set for 60000 (~ 1 minute) as well.
Shouldn’t the status be updating either if the lock is turned manually or not?
Not sure of the brand of lock you are using, but I have 2 Kwikset locks, and they do not update the state when you lock and unlock them manually, however, my locks have the following sensors that are updated on all changes:
Front Door Lock (sensor.kwikset_touchpad_electronic_deadbolt_alarm_type_44)
Back Door Lock (sensor.kwikset_touchpad_electronic_deadbolt_alarm_type_45)
If the lock is locked by pressing the button on the keypad, the state of the sensor is ‘18’, if it is unlocked by the keypad, the state is ‘19’, if it is manually locked by turning the latch, the state of is ‘21’, and if it is unlocked manually by the latch, the state is ‘22’, and finally, if it is locked by Zwave, the state is ‘24’ and unlocked by Zwave the state is ‘25’
So, home assistant only gets notified of changes when it is locked and unlocked by Z-Wave, so that only covers alarm_type ‘24’ and ‘25’.
So I had to create an automation that monitors the alarm_type sensor on each of the locks, and if the alarm type changes to ‘18’ or ‘21’, I issue the lock.lock service call, even though the lock is already locked, it will change the alarm_type sensor to ‘24’ and thus home assistant will see it as locked.
And just the same, if it changes to ‘19’ or ‘22’ I call the lock.unlock service, so the sensor will change to ‘25’ and Home Assistant will see it as unlocked.
It seems like a lot of work, but really it can all be done in one automation and you never have to worry about it again.
Again, I am not sure what locks you are using, but I am sure other brands have a similar sensor. But if you are using the Kwikset locks, just use the following alarm_type states to know the status.
‘18’, ‘21’ and ‘24’ all mean Locked
‘19’, ‘22’ and ‘25’ all mean Unlocked
I do not believe this is the fault of Home Assistant, but rather I think it could be an Openzwave problem, perhaps with an incomplete profile for the locks, or perhaps it is a manufacturer issue where kwikset is not sending the status value but only updating the alarm_type sensor, but either way, the State value is not being sent to Home Assistant unless it is locked and unlocked by Z-wave.
Thanks for the reply, and yes I also have a Kwikset Lock also. I have the Kwikset 916 deadbolt, although it gets picked up as the TRL914 model.
Like you said, this is likely an issue with OpenZwave, and not Hass directly. And I did have the lock paired with a Wink Hub previously. And under Wink, if you did lock/unlock the door manually, the status did update within the Wink App, so pretty sure its not the lock itself.
I’m still pretty new though with Home Assistant. Can you share your rule and I can try and implement and see if I an get it working here?
So, I’m not at home yet to test and add try out, and in trying to create my first rule/automation is the below something on the correct path?
And I’m assuming where you reference alarm_type_44 and alarm_type_45 that is perhaps your node number?
automation:
- alias: Sync Lock State
hide_entity: False
trigger:
platform: event
event_type: zwave.node_event
object_id: kwikset_touchpad_electronic_deadbolt_alarm_type_4
condition:
condition: or
conditions:
- condition: template
value_template: '{{ sensor.kwikset_touchpad_electronic_deadbolt_alarm_type_4 = 18 }}'
- condition: template
value_template: '{{ sensor.kwikset_touchpad_electronic_deadbolt_alarm_type_4 = 21 }}'
- condition: template
value_template: '{{ sensor.kwikset_touchpad_electronic_deadbolt_alarm_type_4 = 24 }}'
action:
service: lock.lock
- alias: Sync UnLock State
hide_entity: False
trigger:
platform: event
event_type: zwave.node_event
object_id: kwikset_touchpad_electronic_deadbolt_alarm_type_4
condition:
condition: or
conditions:
- condition: template
value_template: '{{ sensor.kwikset_touchpad_electronic_deadbolt_alarm_type_4 = 19 }}'
- condition: template
value_template: '{{ sensor.kwikset_touchpad_electronic_deadbolt_alarm_type_4 = 22 }}'
- condition: template
value_template: '{{ sensor.kwikset_touchpad_electronic_deadbolt_alarm_type_4 = 25 }}'
action:
service: lock.unlockYes, 44 and 45 are the node ids of my front and back door locks.
Your automations would not work because you are not referencing an entity_id to perform the action on, which, in your case, I believe would be lock.kwikset_touchpad_electronic_deadbolt_locked_4
Try this automation instead:
automation:
- alias: 'Sync Lock/Unlock State'
trigger:
platform: state
entity_id: sensor.kwikset_touchpad_electronic_deadbolt_alarm_type_4
action:
service_template: >
{%- if ( (trigger.to_state.state == "19") or
(trigger.to_state.state == "22") or
(trigger.to_state.state == "25") )
-%}
lock.unlock
{%- else -%}
lock.lock
{% endif %}
entity_id: lock.kwikset_touchpad_electronic_deadbolt_locked_4
I have not tested this code myself, since I have moved all of my internal automations over to AppDaemon and Node-Red, so mine are all written in python and javascript now, but this should work. If you have any problems, let me know any errors or anything and I’ll see if I can figure out what is wrong.
The code is shorter by allowing the locking to occur simply if it does not match the unlock codes, but also, I am sure there are other codes sent by the lock for different scenarios that I am unaware of, such as if someone attempted to force the lock open, so to be on the safe side, you want to explicitly reference the unlock codes and not the lock codes, that way you ensure your door will ONLY ever unlock with those 3 codes.
As for this lock working correctly with Wink, keep in mind that Wink, SmartThings and all of the other commercially available Hubs have very detailed internal profiles for know devices, such as those by large companies like Kwikset, so a lot of the backend stuff is hidden from you, so to the end user, it just appears to work, but in reality, Wink has a lot of code specific to certain devices to ensure statuses are updated, such as monitoring the internal alarm sensors as we are doing manually here.
Home Assistant, on the other hand, being very DIY, does not do all of the work for you, so we end up having to do it ourselves through code, while Wink is most likely doing this behind the curtain so that everything just works like plug and play to the end user.
Tested that and it worked perfectly.
But seems better to start shifting to AppDaemon as well now? From my limited reading, it seems it provides a more powerful level of rules and automation.
I have a sensor on the door as well, and I may look to get that working that when the sensor says the door is closed, to then go and ahead and auto lock the door. Or combination of door is closed, its 8pm or later, so lock it, etc.
Still getting familar with Home Assistant, and have never used python before. So its all one big learning curve.
Yeah, I would definitely recommend looking into external automation systems. I am using both AppDaemon and Node-Red. All of my automations are in AppDaemon, but I have about 1/4 of them paused in AppDaemon as I have re-created them in Node-Red with the http-sse package, which allows Node-Red to receive a constant stream of all changes to Home Assistant on the fly, so that it works exactly like AppDaemon, only instead of direct coding, you can drag and drop nodes and string them together and visually build your automations like objects. Some of those automations also require a little javascript code, but mostly like 1 or 2 lines in a function node, but with the node-library giving you access to a ton of 3rd party nodes, a lot of the functionality is already in place, and if you know javascript, you can even customize some of the 3rd party nodes to add features, but thats a little more advanced.
Yeah, one of the codes I moved over to Node-Red is my auto locking the door when it is shut while the alarm is armed and it is after sunset. This works great because Node-Red auto arms my alarm and locks the locks (if the doors are closed) 15 minutes after sunset, but sometimes my front door is still open when the alarm arms, so after it warns me that the Alarm has been armed but the front door was left open, then it will auto lock after I shut it.
I’m also having this same issue. Can you help me? I’m unsure where to put this script at. When I call services to unlock my Kwikset 910 it works to lock and unlock but when I use the toggle switch then it only unlocks and never locks also it doesn’t display the correct status.
Thank you!
Also, 27 is Auto Relock, if you have that feature and it’s enabled.
And the alarm level is set to which user code unlocked the door for 19 (e.g., 1, 2).
Is there a way you could just set the state of the lock entity vs sending an actual lock/unlock command?
Hey guys my lock show strange behaviour. While it is physically unlocked the front end show state locked but notification manually unlocked 
Any hints on this?
Thanks this worked well. I did find one flaw. If you unlock and relock the door in just a few seconds the delay in the data being sent back to HA causes it to get behind enough that it is one step behind the true state which causes it to cycle back and forth indefinitely. I added a delay to the sequence which resolved the issue. See below.
- alias: 'Sync Lock/Unlock State'
trigger:
platform: state
entity_id: sensor.kwikset_touchpad_electronic_deadbolt_alarm_type_39_0
action:
- delay:
seconds: 30
- service_template: >
{%- if ( (trigger.to_state.state == "19") or
(trigger.to_state.state == "22") or
(trigger.to_state.state == "25") )
-%}
lock.unlock
{%- else -%}
lock.lock
{% endif %}
entity_id: lock.kwikset_touchpad_electronic_deadbolt_locked_39_0friendly_name": “Main Door”,
“value_instance”: 1,
“old_entity_id”: “lock.lock_main_door_locked_7_0”,
“value_id”: “72057594161168384”,
“notification”: “Manual Lock”,
“value_index”: 0,
“new_entity_id”: “lock.lock_main_door_locked”,
“node_id”: 7
This is my entity and lock works good sobfar but opens in the middle of the night. Sensors are never updated. It’s a Dana lock
You would be better served if you started your own post and fully explain your issue.
u r right… was in the rush… just to mention and re warm the thread
Thanks for sharing guys, Did use your work to make mine’s work. I just move the automation from configuration.yaml to automation.yaml. I gave it a unique id, the service_template is depreciated and we now call for service only. So this is a working code in date of 20 feb 2021 :
- id: 'f386a8d402c84d73bd38a6e477225895'
alias: "Synchronisation état de serrure entrée garage"
trigger:
platform: state
entity_id: sensor.smart_code_with_home_connect_technology_alarmtype
action:
- delay:
seconds: 30
- service: >
{%- if ( (trigger.to_state.state == "19") or
(trigger.to_state.state == "22") or
(trigger.to_state.state == "25") )
-%}
lock.unlock
{%- else -%}
lock.lock
{% endif %}
entity_id: lock.smart_code_with_home_connect_technology_current_lock_mode
Thanks again for your work guys!
This is my first automation and I’m having trouble with it. I’m getting the following error message “Error rendering service name template: UndefinedError: ‘dict object’ has no attribute ‘to_state’”. Two things I don’t understand about the automation: 1) I type > after service, but it keeps changing to | and I don’t know why, 2) what should the entity_id: reference? I don’t have a similar entity id (similar to lock.kwikset_locked), so I’m not sure what to do with this. All I have is lock.door_lock which is the name of my node.
I also see that sensor.door_lock_alarmtype is unknown. I’m thinking I need to use the template that Fox350 posted to define the values. For what its worth, here’s my configuration. Again, still not sure whats causing the update from > to |, or what to do with the entity_id reference. Not sure if I’m smart enough to learn this…
id: ‘1631302576844’
alias: Update door lock status
description: Updates status for manual lock/unlock
trigger:
Hello,
I have two of these Weiser locks. One is the older model and the other is the SmartCode10. After migrating to ZWaveJS, the Alarmlevel is no longer being reported (it always shows Unknown). The other lock is still working. I’ve tried unpairing/repairing to no effect.
Is anyone else having this issue?
I don’t have this exact lock (I have kwikset zwave locks), but it sounds like it’s not exchanging security keys properly. I would remove the lock from the door and try pairing it right next to you zwave zstick. Also make sure you have security keys defined in zwavejs.
It’s also possible the alarm code translation for this lock isn’t loaded in the zwavejs config files. What’s the model number of the one not working?