Zwave Lock Manager

Looks like I’m having some trouble with the alarm_type codes reporting correctly in the front_door_report section. Specifically code 23. When HASS locks my Schlage BE469 deadbolt but the door isn’t completely closed the lock jams and I would expect code 23 but instead I get 19. If I manually lock and it jams I correctly get code 9. If I lock with the keypad and it jams I also get code 9. Don’t know if that is correct but at least it’s identified as jammed. Is this an error with the version of Zwave and I need to update the XML? Is it a config setting on the lock itself where it defaults to unlocked if it detects a jam when locked automatically?

sensor:
  - platform: template
    sensors:
      front_door_report:
        friendly_name: 'Front Door'
        value_template: >
          {% set number = states('sensor.front_door_deadbolt_alarm_level') %}
          {% set alarm_type_value = states('sensor.front_door_deadbolt_alarm_type') %}
          {% set entity_id = 'input_text.door_keypad_' + number + '_name' %}
          {% set user = 'Master' if number == '0' else states(entity_id) %}
          {% set alarm_type_value = '24' if (as_timestamp(now())-as_timestamp(states.lock.front_door.last_changed)) < 15 and (as_timestamp(now())-as_timestamp(states.sensor.front_door_deadbolt_alarm_type.last_changed)) > 15  and (states.lock.front_door.state) == 'locked' else alarm_type_value %}
          {% set alarm_type_value = '25' if (as_timestamp(now())-as_timestamp(states.lock.front_door.last_changed)) < 15 and (as_timestamp(now())-as_timestamp(states.sensor.front_door_deadbolt_alarm_type.last_changed)) > 15  and (states.lock.front_door.state) == 'unlocked' else alarm_type_value %}
          {% set alarm_type_general_actions = {
            '0':'No Status Reported',          
            '9':'Lock Jammed',
            '17':'Keypad Lock Jammed',
            '21':'Manual Lock',
            '22':'Manual Unlock',
            '23':'HA Lock Jammed',
            '24':'HA Lock',
            '25':'HA Unlock',
            '26':'Auto Lock Jammed',
            '27':'Auto Lock',
            '32':'All Codes Deleted',
            '161':'Bad Code Entered',
            '167':'Battery Low',
            '168':'Battery Critical',
            '169':'Battery Too Low To Operate Lock' } %}
          {% set alarm_type_lock_actions = {
            '18':'Keypad Lock',
            '19':'Keypad Unlock',
            '162':'Lock Code Attempt Outside of Schedule' } %}
          {% set alarm_type_code_actions = {
            '33':'Code Deleted',
            '112':'Code Changed',
            '113':'Duplicate Code' } %}
          {% if alarm_type_value in alarm_type_code_actions %}
            {{ alarm_type_code_actions[alarm_type_value] }} (Code {{ number}})
          {% elif alarm_type_value in alarm_type_lock_actions and number == '0' %}
            {{ alarm_type_lock_actions[alarm_type_value] }} with Schlage Button
          {% elif alarm_type_value in alarm_type_lock_actions  %}
            {{ alarm_type_lock_actions[alarm_type_value] }} with Code {{ number }} ({{ user }})
          {% elif alarm_type_value in alarm_type_general_actions %}
            {{ alarm_type_general_actions[alarm_type_value] }}
          {% else %}
            Unknown Alarm Type Value {{ states('sensor.front_door_deadbolt_alarm_type') }}
          {% endif %}

1 Like

Actually, I don’t have a quick answer for that. My locks rarely Jam, so I have not spent much time looking at the codes for that. Like you I would expect either a 23 or a 9 if the lock is actually jammed. 19 says HA unlock. So what is physically happening when your lock jams via HA. Does the deadbolt attempt to lock, JAM, and then unlock? I guess my question is after this happens, what is the final state of your lock. Is it actually “jammed”, or is it unlocked?

I do have an automation set up (outside of the lock package), that will unlock the lock if the deadbolt locks and the door is open. I have an open close sensor on my doors. I do that for those very rare times, where the door was physically left open, and the deadbolt gets locked. Keeps it from damaging the lock or the deadbolt.

It’s so weird because I don’t remember having this problem a year ago when I was using an earlier version of your door lock package. I was on a Rpi3 back then and have since moved to a NUC and done a bunch of tinkering (including using your updated lock package). If the door isn’t completely closed which causes the deadbolt to be misaligned with the strike then the lock will try to close twice and then retract the deadbolt and beep a few times. This used to create one of the lock jammed alarm type codes (9, 17, 23 or 26 depending on what tried to lock the deadbolt). I have a binary sensor with a notification which would tell me if the lock jammed.

  sensors:
    front_door_jammed_sensor:
      value_template: "{{ states('sensor.front_door_deadbolt_alarm_type') in ['9', '17', '23', '26'] }}"
      friendly_name: Front door lock jammed sensor
      device_class: problem

I’ll see if I can look more closely at the recorded history of alarm_type and figure out if it ever shows code 23 but then quickly changes back to unlocked. I’ll also do some more testing and try to replicate ALL the different alarm type codes.

1 Like

I will say that this part of my package is pretty much unchanged in the past year.

ok good to know. thanks

[wrap=“justify”]

I hope someone might be able to help me out. I think I am so close to a successful installation of the lock manager. For some reason input_datetime.door_keypad_1_date_start type entities are not loading. The main feature of the manager I wanted was the scheduling of certain codes.

This is what the lovelace swiper cards look like. Any insight is helpful![/wrap]

I recently created and automation to notify us of lock jammed alerts… certain family members were having a problem hitting the Schlage button without actually having the door shut tight so the lock would go to “jammed” and not work until we manually cycled the bolt… after doing this I noticed a couple times where my side door lock (a BE469ZP, the front door Is just a BE469 not z-wave plus) would quickly say jammed (code 9) after just a manual unlock of the lock… it’s only happened a couple times but I’m starting to wonder if it’s something with the cylinder hanging up a little inside or something…

Either way when I am home tomorrow I will try some different ways to jam it and let you know what it reports… do you have the regular z-wave or ZP (z-wave plus) model?

My model number is listed as BE469NX, I don’t think it’s ZwavePlus. Let me know what you discover and I’ll do the same. Thanks.

I have not been very successful in getting the scripts to actually enter a pin on the Schlage locks that i have. Does anyone have insight whether these scripts will have difficulty triggering if the locks are actually connected to a Vera Plus hub (I use the vera: integration configuration.yaml to control my zwave devices that are connected to the hub) versus using HA with say an Aeotec Z-wave USB radio.

In other words, must HA be the direct hub versus accessing through another hub?

Yes, it has to be connected directly to HA for this to work.

Haven’t made much progress, I’m wondering if I need to add some logic to my lock_jammed alert. If anyone could help me figure this out I would really appreciate it. I have a binary sensor called “front_door_jammed_sensor”

- platform: template
  sensors:
    front_door_jammed_sensor:
      value_template: "{{ states('sensor.front_door_deadbolt_alarm_type') in ['9', '17', '23', '26'] }}"
      friendly_name: Front door lock jammed sensor
      device_class: problem

Right now it only looks at the state of the sensor “front_door_deadbolt_alarm_type”

I think if I add a value template to become true if the door lock has been unlocked for more than 5 minutes it will help solve my problem of the binary sensor not catching all the alarm types correctly. I’m stuck with how to use a template to evaluate the amount of time the lock has been unlocked.

The logic I’m trying to create is:

IF the front door deadbolt alarm type is not 9 or 17 or 23 or 26 AND the lock has been unlocked for less than 5 minutes then everything is OK.

explained another way… IF the front door deadbolt alarm type is 9 or 17 or 23 or 26 OR the lock has been unlocked for more than 5 minutes then there is a problem.

  sensors:
    front_door_jammed_sensor:
      value_template: >-
        {{ states('sensor.front_door_deadbolt_alarm_type') in ['9', '17', '23', '26'] 
           and is_state('lock.front_door_lock', 'unlocked) for more than 5 minutes }}
      friendly_name: Front door lock jammed sensor
      device_class: problem

You might want to take a look at Simplified Zwave Lock Manager which is based upon this package. Personally I think it’s a lot easier (hence the name Simplified) to setup, especially if you want to setup one lock at a time. You can install multiple locks by creating multiple package instances and global replaces for entity names and UI elements. Best of all, the recurring schedules is solid. I’ve given out codes to contractors, neighbors, family, etc and after a bit of debugging it’s been extremely reliable.

1 Like

Hi I just bought a Kwikset 910 Z-Wave Plus lock and was just curious if someone could write up a step by step to get this setup? I keep modifying the files in packages and keep getting Entity ID missing on lovelace.

Thank you!

So 95% of the time when lovelace says “Entity ID missing” it’s because the entity is missing. :slight_smile:
seriously, though, that is what it means. What entity does it say is missing? Look at all of your entities in HA. Do you see it? Often it’s a typo, or name changed during your modifying the packages. Do you just have one lock?

Obviously haha!

I currently have one lock but getting another one (identical) in the next few days, so I’m just looking to see what yaml files I need to put into my packages folder. I just nuked it and starting fresh, I currently have:

    common_lock_config.yaml
    front_door.yaml
    lock_package_for_two_deadbolts.yaml
    mancave_door.yaml

I’ve gone through and renamed the locks in the yaml files to match what I have them named as in HA (including all sensors, etc.).

So let’s start with this. You only need
common_lock_config.yaml
front_door.yaml
mancave_door.yaml

the other file is kind of depricated, it was when I had everything in a single package. Some people did not like cleaning out the extra yaml, so I broke it out into common and lock name.yaml

Let’s start with just one lock for the moment since you only have one lock.

Do you have three entities with these names
lock.front_door
sensor.front_door_deadbolt_alarm_type
sensor.front_door_deadbolt_alarm_level

These are the three critical entity names for most of the automations, scripts, inputs, etc

Awesome great,

Yes I have my entities exactly like that.

OK, next. which entities are “missing” according to lovelace?

The lovelace config on your Github gives me the error ‘No card type found’.

On the one you posted on here a while back, I get the following

I understand back switch and garage switch entities are not available, but I’m unable to modify ‘Name’ ‘Code’ or access schedule on any of the user code swipe cards.

Got it, so a while ago, I switched to using google calendar for my scheduled codes. And the old lovelace is for before google calendar. Do you use google calendar? If so, I’ll work with that, if not I’ll get you the version before google calendar and we’ll get it working either way.

Here was the post. I know these things get buried in the long posts

you probably needed to add the atomic calendar lovelace plugin