Zwave Lock Manager

I use HACS, but not sure how to make it a HACS integration. Overall this integration is really just a collection of YAML, automations, scripts, input_texts, sensors, etc. It’s put together in a package to make it easier to manage. There is nothing else to it. When I first moved over to HA, I wanted something to manage my codes because I had something similar with SmartThings, and found a bunch of different automation, scripts, etc from various people over the years. For the most part I just pulled those all together into a single package and have slowly tweaked a bit over the last year, but it really has not changed much.

Anyway, I have been trying the best way to put together some good ideas for automations, and sensors, etc that can be used with locks. because different people want different things.

The three main things I seem to see that People want

  1. Just a simple place to go to set and clear codes on a lock. No scheduling needed.
  2. Simple code manager with some basic scheduling
  3. Lock/code manager with lots of cool options, one time use, X time use, alerts, advanced scheduling, Zwave lock options, etc.

Also, one lock, two locks, or more, means slightly different code, some can be used for multiple locks, some cannot.

I think that one of the “issues” with this lock manager, is that it seems to be a common thing for newer users to be drawn to. People like me last year, and they are looking for a plug and play solution like smartthings. As you get smarter with YAML, it’s easy to break this down and see how it works, and make it work how you want it.

I guess I’m just rambling, but what is the best way to share the knowledge without having to maintain multiple packages for various user bases.

1 Like

This makes sense. I’m not that familiar with HA integrations to understand how/if this would work. I was impressed with the recent Entity Controller integration, as this replaced a bunch of automations and boolean_inputs I had created to replicate the same result.

I was wondering if something like this could be done for the Lock integration.

1 Like

Just trying to cleanup my log and was wondering if anyone has seen this:

Value cannot be processed as a number: <state zwave.lock_side_door_deadbolt=initializing; node_id=24, node_name=Schlage (Allegion) BE469ZP Connect Smart Deadbolt, manufacturer_name=Schlage (Allegion), product_name=BE469ZP Connect Smart Deadbolt, query_stage=CacheLoad, is_awake=True, is_ready=False, is_failed=False, is_info_received=True, max_baud_rate=40000, is_zwave_plus=True, capabilities={'frequent', 'zwave_plus', 'routing', 'beaming'}, sentCnt=0, sentFailed=0, retries=0, receivedCnt=0, receivedDups=0, receivedUnsolicited=0, sentTS=2019-11-16 20:27:50:816 , receivedTS=2019-11-16 20:27:50:816 , lastRequestRTT=0, averageRequestRTT=0, lastResponseRTT=0, averageResponseRTT=0, friendly_name=Side Door Lock @ 2019-11-16T20:27:55.669585-05:00> (Offending entity: None)

I know this is a Z-Wave Plus model and some other differences were already noticed in the naming of certain options etc… but Im having trouble figuring out why this is coming up on every restart of HA… the Front door lock which is the same lock just the standard Z-wave version never gives this error.

I had been holding off on pushing a new update to git, but my personal files were getting a bit out of date and I really wanted to get them backed up. I will provide details soon, but the current files on my repository are using a google calendar integration for scheduling.

Here is an snip of my google calendar entry

- cal_id: [email protected]
  entities:
  - device_id: door_lock_schedule
    ignore_availability: true
    name: Door Lock Schedule
    track: true
  - device_id: lock_code_1_schedule
    ignore_availability: true
    name: Door Code 1 Schedule
    track: true
    search: "#Door Code 1"
  - device_id: lock_code_2_schedule
    ignore_availability: true
    name: Door Code 2 Schedule
    track: true
    search: "#Door Code 2"
  - device_id: lock_code_3_schedule
    ignore_availability: true
    name: Door Code 3 Schedule
    track: true
    search: "#Door Code 3"
  - device_id: lock_code_4_schedule
    ignore_availability: true
    name: Door Code 4 Schedule
    track: true
    search: "#Door Code 4"
  - device_id: lock_code_5_schedule
    ignore_availability: true
    name: Door Code 5 Schedule
    track: true
    search: "#Door Code 5"
  - device_id: lock_code_6_schedule
    ignore_availability: true
    name: Door Code 6 Schedule
    track: true
    search: "#Door Code 6"
  - device_id: lock_code_7_schedule
    ignore_availability: true
    name: Door Code 7 Schedule

The in my google calendar I just set a schedule for with a title of
Door Code X as the entry.

It has worked quite well for me. Sorry I dont have more time for documentation at the moment, but overall I think it’s not super hard to follow if you look at the yaml.

If you want the previous version with the input date/times, just pull that from github previos commit

Edit here is also an example of the lovelace I’m using for my codes

cards:
  - cards: null
    color: 'rgb(0, 0, 0)'
    color_type: label-card
    name: Entry Code 1
    styles:
      card:
        - height: 20px
      name:
        - justify-self: center
        - padding-left: 10px
        - font-size: 16px
    type: 'custom:button-card'
  - cards: null
    entities:
      - entity: input_text.door_keypad_1_name
      - entity: input_text.door_keypad_1_code
    type: entities
  - card:
      entities:
        - entity: input_boolean.code_1_notify
        - entity: input_select.door_keypad_1_access_schedule
      type: entities
    cards: null
    conditions:
      - entity: input_text.door_keypad_1_code
        state_not: Code Here
    type: conditional
  - card:
      color: 'rgb(44, 109, 214)'
      color_type: label-card
      name: Lock Schedule (Only Shows when on)
      styles:
        card:
          - height: 20px
        name:
          - justify-self: center
          - padding-left: 10px
          - font-size: 16px
      type: 'custom:button-card'
    cards: null
    conditions:
      - entity: input_select.door_keypad_1_access_schedule
        state_not: Always
    type: conditional
  - card:
      columns: 3
      entities:
        - entity: calendar.lock_code_1_schedule
          name: Start Time
          secondary_info: '[[ {entity}.attributes.start_time ]]'
          type: 'custom:secondaryinfo-entity-row'
        - entity: calendar.lock_code_1_schedule
          name: End Time
          secondary_info: '[[ {entity}.attributes.end_time ]]'
          type: 'custom:secondaryinfo-entity-row'
      show_icon: false
      show_state: true
      state_filter:
        - 'on'
      type: entity-filter
    cards: null
    conditions:
      - entity: input_select.door_keypad_1_access_schedule
        state_not: Always
    type: conditional
  - card:
      entities:
        - entity: input_boolean.door_keypad_1_front_switch
        - entity: input_boolean.door_keypad_1_back_switch
        - entity: input_boolean.door_keypad_1_garage_switch
        - entity: script.door_keypad_1_delete
      type: entities
    cards: null
    conditions:
      - entity: input_text.door_keypad_1_code
        state_not: Code Here
    type: conditional
type: vertical-stack

You’ll need the appropriate custom cards in your lovelace, but I like that is only shows enties as they are needed or valid

Hi,

First at all, thank you for your excellent work. I have a question: in the path https://github.com/ptdalen/home-assistant/tree/master/packages you have several files but I don’t know what are the ones that I have to use for one door lock (BE469ZP). Please, can you guide me?
Thanks

Hello anyone who has used or is thinking about using this package. I’ve made some updates to the Yaml and my lock and sensor names. based on feedback, my entities has names that were a bit long. I did not have the time to update my automations to use shorter names, but finally did. If you are using my previous package files, and they are working, I would ignore this post. No real changes other than the entity names.

So if you have a look at the latest github

Some people have asked which files to use, and I get it there are a lot of unneeded files, that I kept in the packages folder to try to account for various configurations. At this point I recommend using these

common_lock_config.yaml - Needed regardless of how many locks you have
and then
back_door_lock.yaml and/or front_door_lock.yaml depending on how many locks you have

if you have an FE599, use the garage door lock.yaml file and edit if needed.

Bottom line if you take the front, back, garage yaml files and put them in your packages folder, and rename your entities accordingly (the names are in shown in the comment of each yaml, but basically lock.front_door, lock.back.door, etc) Overall you need to rename three entities for each lock. One for the lock, and two sensors (alarm type and alarm level). No other editing should need to be done to the lock.yaml files. For the common lock config, the only real editing needed is to remove the unused entities if needed. For example if you only have one lock, remove the few places where there other locks are referenced. It’s pretty minimal editing.

One change I made that works well for me is that I decided to move to a google calendar for lock scheduling. It allows you to be as detailed for a schedule as needed.

Here is my google_calendar.yamls

- cal_id: [email protected]
  entities:
  - device_id: door_lock_schedule
    ignore_availability: true
    name: Door Lock Schedule
    track: true
  - device_id: lock_code_1_schedule
    ignore_availability: true
    name: Door Code 1 Schedule
    track: true
    search: "#Door Code 1"
  - device_id: lock_code_2_schedule
    ignore_availability: true
    name: Door Code 2 Schedule
    track: true
    search: "#Door Code 2"
  - device_id: lock_code_3_schedule
    ignore_availability: true
    name: Door Code 3 Schedule
    track: true
    search: "#Door Code 3"
  - device_id: lock_code_4_schedule
    ignore_availability: true
    name: Door Code 4 Schedule
    track: true
    search: "#Door Code 4"
  - device_id: lock_code_5_schedule
    ignore_availability: true
    name: Door Code 5 Schedule
    track: true
    search: "#Door Code 5"
  - device_id: lock_code_6_schedule
    ignore_availability: true
    name: Door Code 6 Schedule
    track: true
    search: "#Door Code 6"
  - device_id: lock_code_7_schedule
    ignore_availability: true
    name: Door Code 7 Schedule
    track: true
    search: "#Door Code 7"
  - device_id: lock_code_8_schedule
    ignore_availability: true
    name: Door Code 8 Schedule
    track: true
    search: "#Door Code 8"
  - device_id: lock_code_9_schedule
    ignore_availability: true
    name: Door Code 9 Schedule
    track: true
    search: "#Door Code 9"
  - device_id: lock_code_10_schedule
    ignore_availability: true
    name: Door Code 10 Schedule
    track: true
    search: "#Door Code 10"
  - device_id: lock_code_11_schedule
    ignore_availability: true
    name: Door Code 11 Schedule
    track: true
    search: "#Door Code 11"
  - device_id: lock_code_12_schedule
    ignore_availability: true
    name: Door Code 12 Schedule
    track: true
    search: "#Door Code 12"
  - device_id: lock_code_13_schedule
    ignore_availability: true
    name: Door Code 13 Schedule
    track: true
    search: "#Door Code 13"
  - device_id: lock_code_14_schedule
    ignore_availability: true
    name: Door Code 14 Schedule
    track: true
    search: "#Door Code 14"
  - device_id: lock_code_15_schedule
    ignore_availability: true
    name: Door Code 15 Schedule
    track: true
    search: "#Door Code 15"

I’m not going to go into details on how to set up the integration, but the way this works is to set up your schedule however you want and have The code slot as the name of the event, for example “Door Code 5”, in google calendar as the event name, will enable and disable the code slot based on whatever schedule you set. Could be one time, every M-F 8-5, every other Sunday, whatever you’d like.

I’ve also set up my lovelace panel to include some conditional settings to that it does not show things that are unneeded. For example if a slot is unused, no need to show all the switches, etc. I am also using the atomic calendar addon (added via HACS) to show the current lock/slot calendar schedules.

The lovelace is in github too. and named packages/lock_lovelace.txt

I just started using this, and I’m really liking it so far. I have a couple of questions though.

I have the google calendar integration setup and I can’t seem to get the lock codes to enable/disable with the schedule.

I assume its something I’m doing wrong, for instance, I’m currently using code 15 to test the manager and have it set with a code of 2020 and I have the Access Schedule set to Temporary. It’s allowed to access the one door that I’m using for testing. Even when the schedule is “off” the code still works on the lock. Should I not be manually selecting a lock, if so how do I tell the manager which doors the code has access to? Is the code just not properly being removed after the schedule? What am I missing?

Thanks for all of your hard work and for sharing it!

Below is a picture showing how Entry Code 15 looks during an “On” schedule.

Is there a way to tell which code unlocked it and use that result to disarm a security system? I would like to have the doorlock be able to disarm the security system only on code usage. Preventing the manual unlock knob on the inside from disarming it.

Just wanted to ask a couple questions to be sure I have all the info.

Did you load the code using this or was it previously loaded?
When the time started did you get a notification? When the time ended did you get a notification?

So, when the time ended, the code still worked?

Short answer is yes. You could also do the same thing without this though. One of the attributes of a lock (lock status) is how it was opened and which slot was used if it was opened with a code

image

You could also make some changes to the yaml in this package to include a disarm action for a slot. I’d probably use the notify on unlock code and make some changes there

I know little to nothing about yaml programming so you’re speaking over my head at the moment. What event/tag/datapoint am I looking to use when the door is unlocked by code? lock status doesn’t help me much when I don’t know its data source or even how to track it down yet. Learning is part of the fun of this but without a reference point its hard.

Yale 256 lock.

I loaded the code into the door using this code manager, I had never used it before.

I’m getting no notifications, even with “Notify when Used” is checked. (Tried with pushover, and html5 notifications). I have been assuming this was a separate issue and since I know little about notifications, aside from the bit I’ve used before, I’ve been trying to troubleshoot.

I also was not aware that I should be getting notifications when the codes were removed/added. Where in the common/door yaml files is this setup? I must have missed it.

Yes, when the time ended and before the time began, the code still worked.

I just started the same type of test with a different code. The schedule came and went, the new code “2021” was never added to the system. I tried the code when the entry looked like the below picture.

Edit:

I just ran a couple more tests, it appears as though any code I now add as “Temporary” is never being added to the locks, even during their schedule. Also, I’ve tried two separate One time use codes, after being used, the codes are not removed from the locks.

Any code that I add via this manager with the default “Always” schedule work 100% of the time. (I mean they are always added to the locks, at this point I was checking to see if for whatever reason the system was failing to add codes in general) Any lock that I run the Delete Door Code on is removed successfully 100% of the time so far.

I have no idea whats going on. For some more background, if it helps, two of my locks are Schlage BE469NX and the 3rd lock is a Schlage BE468.

Thanks again for your help.

Yes when the temp codes are used you should get a notification when they are set and when they are cleared.

I would start by checking
sensor.keypad_1_temp_lock_turn_on, or whatever number you are testing with

Here is the Yaml for one of the sensors

      keypad_1_temp_lock_turn_on:
        friendly_name: Turn keypad 1 on
        entity_id: sensor.date_time
        value_template: >-
          {{ ((states['input_select']['door_keypad_1_access_schedule'].state in ['Temporary', 'Recurring']) and states('calendar.lock_code_1_schedule') == 'on') }}

Basically if the door slot is set to temp or recurring AND the calendar even becomes true (check calendar.lock_code_1_schedule too) the sensor turns on. The sensor is the trigger to load the code into the slot.

There is also a sensor.keypad_1_temp_lock_turn_off which is the opposite, it is “on” when the calendar event is “off” it is the trigger to remove the code.

for the one time use, check sensor.front_door_deadbolt_alarm_level the value of that is the code slot used. It should be 15, 16, thru 19. And also check the report sensor (sensor.front_door_report) it needs to start with “keypad unlock”. The alarm level changing is the trigger and the front door report is a condition.

I suspect that your one or more of your sensors are not named correctly. Sounds like you;ve already mostly gotten it, hope this helps get you the rest of the way

Yeah, I think this is exactly the issue I’m running into. Sometimes I think I’m too smart for my own good, so instead of changing my device names to match the provided code, I changed the names the code was looking for.

In my hubris, I didn’t modify the common lock file. /facepalm

1 Like

I hear you. I had never heard of YAML when I started messing with HA last year.

Bottom line, the YAML provided does not do what you asked, but it would not take much work to get what you want. If your goal is just to turn off a security system though, then this is probably overkill. The foundations for what you want are in there though.

Basically you need a trigger. A trigger is what starts the automation

So in this case

  trigger:
  - platform: state
    entity_id: lock.front_door
    from: 'locked'
    to: 'unlocked'

then you need a condition and that condition is your code slot
Not tested but something like this should work

  condition:
  - condition: template
    value_template: "{{ 'user 1' in states.lock.front_door.attributes.lock_status | lower }}"

then your action will be whatever you want to happen, in your case disarm your system. I’ll say if you search the forums you’ll find many examples of doing similiar things that you’ll be able to adjust to fit your needs. Good luck

Been there done that. Many, many times. haha

Thanks again for the help.

I did have to correct 3 lines in the common lock yaml to match my lock names. My primary issue was that I had configured my uptime sensor incorrectly, and I was completely missing a time_date sensor.

The one time use code uses the uptime sensor as a condition and the google calendar code uses the time_date sensor.

Figured it out and I’m working great now. Thanks again for your hard work and for your help.

Edit: The only odd thing I’ve noticed, is that if I schedule a code for say 4 PM, it doesn’t activate until about 4:04 - 4:08. Are you seeing this type of behavior also, or am I having a possible timing issue?

Thanks.

I have seen issues with google calendar. I believe it only updates once every 5 min. But I’ve personally not had issues when the calendar event was in a 5 min increment. Such as 5:05am vs 5:04am.

Glad you got it “mostly” working. I did use input date times on my initial implementation and they worked on a per minute basis. But was not nearly as flexible as the calendar.

Its giving no reaction, and it may be due to the way its being created via the automations interface in HA. this is the resultant yaml, minus the action section. I feel like its borking the code somehow.

- id: '#############'
  alias: Disarm Security System on Coded Door Unlock
  description: ''
  trigger:
  - entity_id: lock.front_door_lock_locked
    from: locked
    platform: state
    to: unlocked
  condition:
  - condition: template
    value_template: '{{ ''user 1'' in states.lock.front_door.attributes.lock_status
      | lower }}'