Zwave Lock Manager

Are you able to lock and unlock the deadbolt, via Home Assistant? Do you have many zwave devices?

did you securely add the lock? Do you have your network key configured

Yes it locks via HA.
I have 8 zwave devices
I think its added securely
Yes the key is configured

Is there a way to ensure its added as a secure node without removing it and adding it again?

Ok so now one of the two locks allows me to add codes. However, it does not delete codes and does not send notifications.

here is my yaml file https://gist.github.com/cjackson234/9879ca00e621e3803b35079f335180c4

Note: my lock is called lock.front_door_lock

What did I do wrong?

Change to this (around line 140)

      - service: lock.set_usercode
        data_template:
          usercode: >-
            {{ range(1000, 9999) | random }}
# 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
          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 }}

          code_slot: >-
            {% set object_id = trigger.to_state.object_id %}
            {% set code_slot = "_".join(object_id.split("_")[2:-2]) %}
            {{ code_slot }}
#      - service: lock.clear_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_name ~ '_door_lock' %}
#            {{ states['lock'][lock_id].attributes.node_id }}
#          code_slot: >-
#            {% set object_id = trigger.to_state.object_id %}
#            {% set code_slot = "_".join(object_id.split("_")[2:-2]) %}
#            {{ code_slot }}

If i’m reading this right, its creating a random active code, right?

Yes. Clear code does not currently work in HA for most zwave locks.

1 Like

depending on the lock, another option could be to set a specific code. One that you know. Schlage (I believe) will actually let you assign the same user code to multiple slots. So if the idea of random codes is concerning, then you could do that.

I have two Schlage locks and its still acting odd.

2019-09-11 10:36:00.404 Info, Node008, Response RTT 1567 Average Response RTT 2416
2019-09-11 10:36:00.404 Info, Node008, Received DoorLock report: DoorLock is Secured
2019-09-11 10:36:00.404 Detail, Node008, Refreshed Value: old value=false, new value=true, type=bool
2019-09-11 10:36:00.404 Detail, Node008, Changes to this value are not verified
2019-09-11 10:36:00.404 Detail, Node008, Expected reply and command class was received
2019-09-11 10:36:00.404 Detail, Node008, Message transaction complete
2019-09-11 10:36:00.404 Detail,
2019-09-11 10:36:00.404 Detail, Node008, Removing current message
2019-09-11 10:36:00.405 Detail, Node008, Notification: ValueChanged

I see this in the logs when I enable to disable a code using the toggle in the UI. But no matter what, that code is always enabled once its set.

I’ve made some significant changes to my lock package. Mostly just a streamlining of yaml. I broke the package up into 4 yaml files. One for each lock and a common yaml package. It will also probably be easier to update the yaml if you want to name your locks differently than I have. I’ll post more soon, just need to do a bit more testing to make sure nothing is broken. I think those with one lock will be very happy, but even those with three locks (or more) will probably find this easy to work with as well.

2 Likes

Just about to give your package a spin, when do you anticipate to upload the latest version?

Thank you for all your work!

Probably tomorrow. How many locks do you have?

1 Like

I’ll try to provide more details tomorrow but the code is posted to my github page

Bottom line, use the door lock yaml files (front, back and/or garage), and the common code. Read the comments, the common has two automations, and scripts that need to have items removed depedning on your locks.

Also the garage yaml is for a fe599 which is a weird lock. The other two (front and back) should be pretty universal.

Two currently, one to be added in a month.

All locks are Schlage BE469ZP

Will you make a post here when the latest code is on GitHub ?

The code is there (see post above)
I’m going to write something more formal in Post #1, but here are the basics
If you look in my packages folder in my github, you’ll see several packages.
Three lock packages. front, back and garage - door_lock.yaml.
One common package - common_lock_config.yaml
and a lovelace guide - lovelace_lock.txt. The lovelace is just a simple page, of course you can do what you’d like, but this is a good starter to fully understand and use the lock packages.

For the be 469 locks, use front and back, and the common packages. Follow the comments, and name your entities accordingly.

if you name your entities to match the packages, you should only need to do minor editing on the common file. The details are in the comments.

I dont know your level of expertise with HA, but if it’s decent, you should find this fairly easy to follow.

You should end up with 3 yaml files in the packages folder.

Now if your locks are not front and back, you can probably figure out how to make the changes to the files to make it work for you.

I just finished setting up my second Schlege BE469 lock, and I switched all the yaml scripts over to the new format - works great!

One thing to mention is the new lock BE469ZP has different nomenclature for the option commands - many of them now default to just enabled, disabled (for instant auto lock) . This took a bit to figure out.

Here is an excerpt for the changes I had to make (backdoor)

input_select:
  lock_zwave_option_3_back:
      name: Enable or disable the beeper.
      options:
          - Enable
          - Disable
  lock_zwave_option_4_back:
      name: Prevents all user codes from unlocking the deadbolt
      options:
          - Disable
          - Enable
  lock_zwave_option_5_back:
      name: Press the Outside Schlage Button to lock the deadbolt
      options:
          - Enable
          - Disable
  lock_zwave_option_7_back:
      name: Alarm sounds based on door activity
      options:
          - Alarm Off
          - Alert
          - Tamper
          - Forced Entry
  lock_zwave_option_15_back:
      name: Auto lock
      options:
          - Disable
          - Enable
2 Likes

I’m working on replacing the input date times with a google calendar system instead. I was just wondering how the community as whole would like that. On one hand, the google calendar integration will allow setting reoccurring lock schedules very easily. On the other hand it does require setting up another component. I find that trying to maintain multiple packages for people who want different things ends up leaving one group of people with outdated packages. So I thought I’d ask before moving too far ahead

I think you would be better off with a start/end date or a start date/number of days. The extra component isn’t going to add a lot for the hassle.

I’m going back and forth. I have it set up and working using a google calendar, and although it does add an extra (external) component, I sure do like the flexibility. Want Mon-Friday 8-5 only, easy. Want the 1st wed of each month, easy. Just want the 2nd full week in July, also easy. I think it comes down to what people like to schedule. For me to be honest, I’ve never scheduled lock codes much. The current config that I have is not bad, but if you actually want to do any advanced scheduling it’s kind of a pain.

I believe the most common scenarios would be

  • Code that only works during Specific times. Like M-F 8 until 5
  • Code that works just one specific day of the week, maybe also for specific times
  • if you had an air BnB, the current set up works good. Just one specific date range

Anyway, I keep going back and forth. I could not think of an easy way to create some of those without creating input booleans for each day of the week, and then for each lock code. 10 used codes = 70 input booleans?

@FutureTense, still feel the same? Probably, haha. thanks for the feedback so far, looking forward to more

Code that only works during Specific times. Like M-F 8 until 5 would be handy but I agree that I don’t use scheduling much so far. In my case, I may in the future put a lock on the pantry that would be scheduled to turn off during the night… keep the teenagers in the house from late night beer fridge raids!

1 Like

Which is why I split my package up into “slots”, with a slot per file. It has all of those options as well. Plus you can add your own with a simple binary sensor.

1 Like