Schlage Connect ZWave Locks

if you have issues pairing your lock then move your usb stick closer many of us came from ST and had to rearrange some of our zwave stuff so it works. Well worth it to unlocked all features of your lock without having to pay rboy or someone for app access :wink:

You already use a custom smart app so guess what happens during ST cloud outage or your own internet goes out? Your lock functions (any smart app or automation) will cease to work.

Also, anything you can do in ST you can do in Home Assistant and then some.

Source: I have the same stick, same lock and after moving around my controller to a better position all issues went away.

I agree, and have been moving my stuff over in groups. Locks are last because of course they are important. :slight_smile:
I already paid rboy a while ago, and have to say it was worth every penny. This is one area, where I feel like even though I don’t do it often, HA will not be nearly as “capable” as the rboy ST app was. I’d happily pay $25 for a simple lock interface that allowed me to add codes, remove codes, set schedules, and most importantly make it so easy that someone without a high level of computer knowledge can use it. My wife can get in and set a code very easy.

Again, I’ve accepted this, and it’s all good. I would not be able to set a code remotely with HA if the internet became inaccessible either, but HA would be able to run automations to change codes on a schedule if the internet went down, and that’s pretty cool.

You give some/you lose some.

I plan on finishing up the rest of my lights, open close sensor and motion sensors, then will come back to the locks. It will be the “most work” to get back to where I am with ST. Probably the automation I’m looking forward to the least (maybe most, I do like to learn), is to set scheduled codes. And maybe figuring out an easy way to add codes via ui without having to go through config menu. Although I don’t add codes too often so that’s not very high on my list.

Being able to remotely set codes is important, but setting them with the keypad on my lock is very simple as well.

Yes, it is. But I’m just saying it’s easier to open an app, and enter a code. I don’t want to hijack the thread. I’m just trying to say, that there are many benefits of a fully local Home Automation system. MANY!. I really like it a lot. I’m even sure with enough work, I could come up with a simple input template, and create something that would allow adding/removing of codes. But, it will be a step back in some areas. Mostly in the area of convenience and required skill to make changes to the household automations.

Again, not saying it’s not worth it. If it wasn’t, I’d still be using ST, It worked well for me, but what’s the fun in that. To me, the best thing about HA is that it has several compoents that I would likely never get working togerher in ST. I’m using my hikvision camera line crossing as a sensor now. Never had that before. Opens up a lot of new possibilities.

1 Like

What you described about using input templates is actually what other community members are doing today so try to search the forums for examples they may already have the code in place for you to use. You take a service (like the service call to set a lock code), create a script/automation (i.e. the schedule) and add that to the group (UI). You need to get past the initial setup phase and let your house do the work and make it convenient. You need to build your convenience the way you want it. You really need to put in the time to get things working the way you want them to.

2 Likes

Found exactly what I was looking for

Thanks for the recommendation

2 Likes

BTW, I wanted to pass on that after going through the setup for the 4th time, and this time really paying attention to the logs, I found that I was the problem. I never set up a network key. Once I did that, BAM, it’s all working. I did have to add my usb stick to node 2, but otherwise, its great, Was able to add codes via UI as well.

Thanks everyone for the tips

You definitely need the network key for secure nodes :). Glad its working. I really like my lock with HA. Hope yours works out for you too

1 Like

Just wanted to chime in on this thread. I moved to HA from Vera back in 2016. But the one thing that I left attached to Vera was my Schlage lock (BE469) since the process looked daunting.

Well, I moved my lock over to Hassio this morning and it couldn’t have gone smoother. I followed the steps that @mkzimms posted above, but tweaked the steps slightly to work with Hassio. Since Hassio has built-in Zwave control, I added the secure node from there instead of dropping-out to OZWC.

In a nutshell:

  1. Make sure you’ve set a network key for your zwave network. I used the code on that page (in a Hassio SSH session) to generate my key. Restart Hassio after adding a key the first time.
  2. Exclude lock from Vera (long-press zwave button on Vera, key programming code into lock + press zero)
  3. Factory reset lock (disconnect battery, press and hold Schlage button, reconnect battery, release button)
  4. Go to HA zwave panel (under configuration) and click “add note secure”
  5. Within 30 seconds, go to lock, key in programming code + press zero
  6. Optional: rename lock’s zwave node using HA’s zwave panel
  7. Optional: open entity_registry.yaml and rename the lock and the associated sensors (they’ll all be at the end)

I was able to successfully call lock.set_usercode to add back the codes for my family.

2 Likes

Here’s the code I set up to notify me when the door is unlocked. I’m user slot 3, so I exclude myself. Names changed to protect the innocent :slight_smile:

This avoids having to interpret all of the associated sensors that come along with the lock node.
I use Pushover for my notifications. I like the first line to be a quick-read for when it displays on my Pebble.

- alias: Unlock Front Door Notify
  trigger:
    - platform: state
      entity_id: lock.frontdoor
      to: 'unlocked'
      from: 'locked'
  condition:
    condition: and
    conditions:
      - condition: template
        value_template: '{{ states.lock.frontdoor.attributes.notification == "Keypad Unlock"}}'
      - condition: template
        value_template: '{{ states.lock.frontdoor.attributes.lock_status != "Unlocked with Keypad by user 3"}}'
  action:
    - service: notify.scott_notifier
      data_template:
        title: >
          Unlock by {% if states.lock.frontdoor.attributes.lock_status == 'Unlocked with Keypad by user 1' -%}
          Son
          {%- elif states.lock.frontdoor.attributes.lock_status == 'Unlocked with Keypad by user 2' -%}
          Wife
          {%- elif states.lock.frontdoor.attributes.lock_status == 'Unlocked with Keypad by user 4' -%}
          Daughter
          {%- endif -%}
          
        message: >
          {%- if states.lock.frontdoor.attributes.lock_status == 'Unlocked with Keypad by user 1' -%}
          Son
          {%- elif states.lock.frontdoor.attributes.lock_status == 'Unlocked with Keypad by user 2' -%}
          Wife
          {%- elif states.lock.frontdoor.attributes.lock_status == 'Unlocked with Keypad by user 4' -%}
          Daughter
          {%- endif %} unlocked the front door

Very cool. I use very similar. I even have it when we use a specific user code, it automatically disarms the HA Manual Alarm.

It appears that HA can’t see the difference between when the lock is unlocked by the keypad and unlocked by a lock.unlock call from HA. So my above code will trigger if you unlock from HA and give you a wrong notification.

It looks like touchscreen_deadbolt_access_control doesn’t change when altered over zwave and won’t change the values for notification/lock_status.

Actually HA does not send back code ‘24’ and ‘25’ for electronic unlock and lock. Here is the bug:

This is definitely not my code, but I use it on my setup. Works great though.

- platform: template
  sensors:
    garage_door_lock_state:
        #NOTE: To ensure consistent updates, we link to the update of the zwave entity id, and not the lock!
        entity_id:
          - sensor.schlage_be469nxcen_touchscreen_deadbolt_alarm_type_89_0
          #- input_select.lock_hass_status_for_office_back_door_lock
          - zwave.schlage_be469nxcen_touchscreen_deadbolt_89
        value_template: >-
            {% set alarm_type = states('sensor.schlage_be469nxcen_touchscreen_deadbolt_alarm_type_89_0') %}
            {% set alarm_level = states('sensor.schlage_be469nxcen_touchscreen_deadbolt_alarm_level_89_1') %}
            #{% set hass_state = states('input_select.lock_hass_status_for_office_back_door_lock') %}

            {#- Z-Wave/RF Lock: Alarm State 0x01 (???) -#}
            {%- if hass_state == 'locked_by_hass' -%}
                {{ 'locked with Home Assistant' }}

            {#- Z-Wave/RF Unlock: Alarm State 0x01 (???) -#}
            {%- elif hass_state == 'unlocked_by_hass' -%}
                {{ 'unlocked with Home Assistant' }}

            {# Manually Locked: Alarm State 0x15 (21) #}
            {% elif alarm_type == '21' %}
                {{ 'locked manually with key cylinder or inside thumb turn' }}

            {#- Manual Unlock: Alarm State 0x16 (22) -#}
            {%- elif alarm_type == '22' -%}
                {{ 'unlocked manually with key cylinder or inside thumb turn' }}

            {#- Keypad Lock by keypad touch (lock & leave): Alarm State 0x12 (18) -#}
            {%- elif alarm_type ==  '18' -%}
                {{ 'locked with keypad' }}

            {#- Keypad Unlock: Alarm State 0x13 (19) -#}
            {%- elif alarm_type == '19' -%}
                {{ 'unlocked with keypad by user ' ~ alarm_level }}

            {%- else -%}
                {#- The lock status is sometimes unknown when HASS boots and Z-Wave is initialized.  In this case
                    we want to use the last state reported by the lock itself (physically) if possible, otherwise
                    we return 'unknown' -#}
                {# {{ 'unknown' }} #}
                {% set state = states.lock.schlage_be469nxcen_touchscreen_deadbolt_locked_89_0 %}
                {% set status = (state.attributes.lock_status if state else '')|trim() %}
                {% set result = status if status != '' else 'unknown' %}
                {{ result|lower() }}
            {%- endif -%}

I can see things like this in my HA logbook

garage_door_lock_state changed to #unlocked manually with key cylinder or inside thumb turn
garage_door_lock_state changed to #unlocked with keypad by user 3

I have a FE599GR Wireless Door Lock and a couple of BE469’s. So far I’ve only added the FE599. Would this work for the 599 as well. I only have these three devices

sensor.schlage_fe599gr_wireless_door_lock_alarm_level
sensor.schlage_fe599gr_wireless_door_lock_alarm_type
zwave.door_to_the_garage_lock (renamed)

If not no biggie, I’ll defineitly be using this for my other two locks, thanks for sharing

I am not sure if it would or not. Worth a try I guess

Looks like you’re not using hass_state in your code (it’s comment out). Do you have some other code looking for the lock.lock service to be called to value that input_select? Or are you not using it at all?

I didn’t need the input select because I don’t have my lock in the HA gui. I do use service lock.lock though in my scripts files. I use Alexa to lock the doors. (but not unlock). From my script.yaml

time_for_bed:
  sequence:
    - service: homeassistant.turn_off
      data:
        entity_id: group.bedtime

    - service: script.turn_on
      data:
        entity_id: script.timed_orb

    - service: lock.lock

Right - so your code behaves like mine, then. If you were to unlock the door via script (which I don’t actually do in practice), it would trigger notifications like I have above. Since my code is looking for unlocks. I guess that’s not really a big deal, though.

1 Like

Correct. I also have one that notifies me the door didn’t lock as well (like for bedtime)

- alias: Warn if deadbolt not locked at bedtime
  trigger:
    - platform: state
      entity_id: script.time_for_bed
      to: 'on'
  action:
    - delay: 00:01:00
    - condition: state
      entity_id: lock.schlage_be469nxcen_touchscreen_deadbolt_locked_89_0
      state: 'unlocked'
    - service: notify.notify
      data:
        message: "Please check garage door!"

Now if the door is hanging wide open and the deadbolt can still go to the locked position, this won’t notify me, but the door has a reed switch in it that will notify me if the door is left open for more than 3 minutes