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?
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?
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.
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.
So 95% of the time when lovelace says “Entity ID missing” it’s because the entity is missing.
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?
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:
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
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
I realize that my lovelace looked to be out of date. I updated the lovelace to what I am using now. It does include the atomic calendar plugin, but if you dont care to load it or see the calendar, you can just remove that from the lovelace.
