Secure Lock Not Updating Status?

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.unlock

Yes, 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_0

friendly_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:

  • platform: state
    entity_id: sensor.door_lock_alarmtype
    condition: []
    action:
  • 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.not_sure_what_this_should_reference
    mode: single

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?

Thanks for the reply @mwav3 . I’ve been digging a bit in the forums and from what I can gather, ZWaveJS is adhering to a newer(?) set of standards and so differentiates between states and events. I’m not sure that applies to this lock (which is actually a Kwikset lock btw, it just goes by the brand Weiser in Canada). The model is SMARTCODE10.

I’m going to try triggering my automation on the zwave_js_notification event and see if that gets me anywhere.

Wow thank you for this. Post is 7 years old and this just helped me figure out why my Zale assure 2 zwave lock wasn’t auto locking in my automation if it was locked manually vs in HA