Schlage Connect Locks - HA Integration Needs Attention

Configuration Z-Wave
#125

The alarm level is also changed when the user code is first set, with alarm type 112 (0x70), confirming the code has been set on the lock. Page 4 of the Yale Developer’s Guide gives a description:

This is what I was observing. I would enable a one-time-use code and it would immediately delete. I checked the OpenZWave logs and noticed alarm type 112 being raised with the alarm level of the one-time-use code I had just created. This triggered the automation and immediately deleted the new code.

Adding the condition to watch for an explicit unlock event fixed things. I’m using Yale YRD110 (B1L) locks.

1 Like
#126

Thanks. That’s good info. Schlage must be slightly different but adding the condition won’t hurt schlage users and will make this more comparable with Yale (and maybe others). Good find.

#127

I’ve updated my package and pushed to my git repository thanks for the details

#128

@nalipaz @ptdalen Great work guys. I just imported your package and modified to work with my set up. Everything looks as expected but when I try to set code looks like it’s not working. Am I missing anything obvious?

FYI

  • Lock - Schlage Connect BE469
  • Z wave - entity name correct
  • I Can lock/unlock via HA

Do I need to turn on all the automation? Tried already, did not work.
Do I need to set an end date for always access? Tried already, did not work.

Must be something stupid that I am missing.

Is sensor.date__time a custom sensor?

#129

Sorry for the delay. Couple of things come to mind to check.

So, the locking and unlocking really has nothing to do with the package, but it does at least mean that your locks are paired. Do you have all the sensors (7 I think)? Paired securely, etc.

So you put in a name and a code, then turn on the switch for the lock(s) you want the code to be set for.

Your lock is named - lock.lock_front_door_lock, (not locked, right?)

Did you name it in the entiry registry file?

Most often naming is the issue.

Can you set codes manually via the zwave panel?

#130

I’m about to switch my Schlage lock over from Wink, but I was wondering if these instructions are still the best way to add the lock?
For example, the first step to generate a network key. I wasn’t sure if that was still necessary given the instructions are over 6 months old (that’s like 5 years in HASS years).
I’m running Hass.io and there is a pair secure zwave option in the zwave control panel.

#133

check this post I made SOLVED Schlage Deadbolt Z-Wave Connect Added to HA a while back on this topic. I thought that was the post you were referring to.

#134

I see @ZStanard has provided the details, but shorter answer is that you definitely need a network key for ANY device that gets added securely. Typically devices that require secure would be locks, covers (garage door/windows, etc), but other devices may also require secure pairing.

#135

Yes, thank you. That was the post I had linked to.
I just wanted to make sure it was still the best method since it was from Dec 2017.

#136

Yes, I have all 7 entities as below.

Back Door Deadbolt Entities

sensor.back_door_deadbolt_power_management:
sensor.back_door_deadbolt_access_control:
sensor.back_door_deadbolt_sourcenodeid:
sensor.back_door_deadbolt_alarm_level:
sensor.back_door_deadbolt_alarm_type:
sensor.back_door_deadbolt_burglar:
sensor.back_door_deadbolt_system:
lock.back_door_deadbolt_locked:
zwave.back_door_deadbolt:

I modified all the package to accomodate above names. I did change entry register file to get the name I wanted.

I am not able to set code via service pannel. I used below service and service data

Service

lock.set_usercode

Service Data

{
“node_id”:20,
“code_slot”:3,
“user_code”:“2030”
}

I also tried from Z wave panel it did not work either I have attached 2 screenshots to show what exactly I did.

Before calling set code

11%20PM
11%20PM1326×674 23.5 KB

after set code call

32%20PM
32%20PM1324×680 31.4 KB

#137

Couple of things.

1 - The package file itself would have no effect of setting the codes via zwave control panel or with a service call. If those are not working, try 1st just unplugging the batteries, wait a few seconds and then plug back in. This fixed weird issues like you are experiencing most of the time. if that does not work, unfortunately the next step it to remove and add secure node again. Get the codes set working before spending time on the package.

  1. As far as your door lock names did you also modify the code, switches, etc for your new door names
          - input_boolean.door_keypad_17_garage_switch
          - input_boolean.door_keypad_18_garage_switch

    condition:
    action:
# if your lock does not end in "door_lock" ie. often its "door_locked" change line 3 below to match
# no other things should need to be changed
      - service: lock.set_usercode
        data_template:
          node_id: >-
            {% set object_id = trigger.to_state.object_id %}
            {% set lock_name = "_".join(object_id.split("_")[3:-1]) %}
            {% set lock_id = 'lock_' ~ lock_name ~ '_door_lock' %}
            {{ states['lock'][lock_id].attributes.node_id }}

I just cut out a small section to explain better how it sends the lock code to the right lock.

This

            {% set lock_name = "_".join(object_id.split("_")[3:-1]) %}

parses the name of the input boolean and pulls the name “Garage” (or front or back) from the name of the entity

            {% set lock_id = 'lock_' ~ lock_name ~ '_door_lock' %}

This combines the name “garage”, etc to end up with lock_id being = to lock_garage_door_lock

lastly
this

            {{ states['lock'][lock_id].attributes.node_id }}

ends up with lock.lock_garage_door_lock, which is used for the automation. If your lock is named differntly, that is fine, just make sure you change the code throughout the package in all of the logic.

With all that said, your issue at this time is not with the script,. After you are able to add codes via the control panel then come back to the package

#138

Thank you for a prompt reply. I will get back with my findings later on.

#139

H there, thanks for all the hard work getting this working. I’ve adapted the code to my house, basically removing the 2nd and 3rd locks, and adapting the names.

The one problem I am running into is that the codes and names frequently get cleared (I’m only using codes 1 and 2 right now). Which means I end up getting notifications like “Front door unlocked by Unknown”.

Has anyone else experienced anything like this?

#140

The name gets cleared when the door is locked or unlocked manually, which is what most people do after they come into the house. Do you ever get the correct name? name would be getting pulled from here

frontdoor_code:
        friendly_name: 'Front Door Code'
        value_template: >
          {% if is_state('sensor.lock_front_door_deadbolt_alarm_type', '19') or is_state('sensor.lock_front_door_deadbolt_alarm_type', '18') %}
            {% if is_state('sensor.lock_front_door_deadbolt_alarm_level', '1') %}
              {{ states.input_text.door_keypad_1_name.state }}

So lock the door, check the sensor, unlock the door check the sensor, keypad, manual, etc. Is it changing?

Might be a typo somewhere causing the value not to be getting set

#141

I realize the name for Front Door Code gets cleared, I mean the actual name and code for Code 1, or Code 2 (the only codes we use) are now “unknown”.

I think it might be related to the issues I was having with ZHA. About 1/3-1/2 the time when I restart HA, it failed during the initialization of ZHA. Last night I got sick and tired of dealing with that issue so I removed any zigbee items from my setup.

I will keep an eye on this and see if the names disappear again.

#142

Make sure you have the history sensor added. (I think). It will keep any input texts, booleans, etc after a restart.

#143

Recorder component.

I have this happen when a startup doesn’t complete fully (usually because of a config error) and HA for some reason will write bogus states to the database. :frowning: Likely a bug that needs fixing.

#144

Yes. Recorder component thanks for the correction. I feel like that component should be mandatory. Really saves a lot of mishaps.

#145

I was able to get it working when I renamed everything to what you have in the package. I guess there was some typo / naming mismatch somewhere. Few things I have noticied so far in my week usage.

  1. Temprorary Code only gets activated if you set it for future time.
  2. iOS Push notification does not seem to work all the time.
  3. battery_level attribute is no longer present is Shclage lock I guess. Are we suppoed to replace it power management?
#146

Good deal. I have answers/questions to your questions. :slight_smile:

  1. I think that is true, I’ll double check the code, The automation that sets the code only runs when the start time is equal to the current time.
  2. Is there a specific notification that never works, or do some notifications work intermittently. If that the case, its more likely not an issue with the package, but with the notifier. Just let me know which ones you seem to be having the most trouble with and I’ll look closer at the yaml
  3. Battery level should be working, I’m on the latest version and it’s working for me using the battery template included in the package. Maybe there is something new I’m not aware of? So what made you say that it’s not present?

Thanks for your replies