Just wanted to thank you for your work… this worked great and I’m now completely off my Wink Hub 2… thanks! 
1 Like
No matter what I do, I’m unable to set/clear codes from my lock. Does anyone know how to manually call the set lock service for a code?
Kwikset locks you cannot clear codes, only overwrite.
What brand and type of lock do you have?
While this is a nice package, it’s a little too complicated for my tastes. For example, I’m not interested in sharing the same codes across locks, considering I only have one. I did a preliminary build of a similar setup. This concept relies heavily on the status sensor. Best of all, it’s one sensor controlling the automation to add/delete a code. If it’s not “connected”, the code won’t open the lock. You can connect/disconnect the user by using the Enabled boolean. However if you activate the date range boolean, it will also make sure the current date/time falls in between the specified range. It should be easy to add a bunch of other options, such as boolean and start/finish times for the days of the week. Additionally you can add a counter that will decrement for each lock access. That way if you want to allow only one “open” command you can set the value to 1. I plan on adding these later, but wanted to share where I’m going with this in case anyone has any suggestions.
4 Likes
This is exactly what I’m looking for FutureTense. Do you have a github repo we can follow for this package?
1 Like
I’m looking to improve some of your code, and had a question about your sensor report. Specfically, what is the purpose of comparing the last_changed timestamp to the system time? I know you want to check if the status changed in the last 15 seconds, but why do you even care about the time period? If the status changes, it changes.
{% set alarm_type_value = '24' if (as_timestamp(now())-as_timestamp(states.lock.front_door_lock.last_changed)) < 15 and (as_timestamp(now())-as_timestamp(states.sensor.lock_front_door_deadbolt_alarm_type.last_changed)) > 15 and (states.lock.front_door_lock.state) == 'locked' else alarm_type_value %}
{% set alarm_type_value = '25' if (as_timestamp(now())-as_timestamp(states.lock.front_door_lock.last_changed)) < 15 and (as_timestamp(now())-as_timestamp(states.sensor.lock_front_door_deadbolt_alarm_type.last_changed)) > 15 and (states.lock.front_door_lock.state) == 'unlocked' else alarm_type_value %}Hmm, it’s been a while, haha. I think that I had issues where when I unlocked and locked the door a bit too fast (usually just during testing), that I would end up getting out of sync. But honestly, It has been a while.
I’ll say one thing. The “report section” really could use a bit of updating. One of the main reasons for the reporting section was that when I first started using HA, the locks did not properly report all lock status in the lock entity itself. Specifically it did not report when it was locked with HA.
But now it does, if you pulled the attribute from the lock, you would not really even need to use the report anymore. I had not done that because It was tied into other automations and did not have the time to get them updated and tested.
Lock status is the section I’m talking about. It should report “locked by RF” when it’s locked by HA, unlocked by RF, locked by keypad, manual lock, unlock, etc.
Fair 'nuff. I don’t remember half of what I do unless I leave comments.
I’m doing a significant rebuild of my code, based on yours. You should take a look sometime, and maybe it might be easy to add some of the functionality I ignored from yours into mine. I think you will find it easy to work with. Not that I’m crapping on your code, but refactoring is always a good idea.
1 Like
I did look, and it looks great. I really like the ideas and way you have implemented the # of codes into separate files. Dont feel like your crapping on the code at all. Even when I look at it I have to step back. it’s more of a franken package. When I first started there were 4 or 5 people who had created various things I wanted but all in different places, so I added them to mine, tweaked to make them work together, and then updated and modified a bit over time.
I have partially converted @FutureTense into a multi-lock friendly format by some global replaces, and changed the lovelace around a little bit to save some screen real estate using fold-entity-row. One drawback is that amount of objects/js being run starts to lag the browser a little bit, especially on mobile.
I think it is still broken, all the entities dissapear after I load in multiple folders,but you can see my progress here.
1 Like
I too was fiddling around with folding row, but didn’t want to require it for anyone just yet. I’ll probably get back to that soon. I’ve been cleaning a few things up. Mainly how one goes from adding a new zwave device to renaming it to work with the default package. I just made a push a while ago. JavaScript is the bane of my existence for these type of “single” pages, yes it gets large fast. It would be nice if the Devs could give us the option to add multiple Lovelace pages. Since the lock settings are rarely used, I would bundle the entire thing away on its own page if I had my druthers.
I like the lock options you added. Maybe we could collaborate on the same github instead of just copying code back and forth. I think we’ve covered all the options one could want for lock access.
The more I look at this, I don’t think @ptdalen didn’t realize the genius of his sensor report. He gave me way too much credit for splitting the “codes” up into separate files. It is pretty much the only way you can reuse code in a such a development platform. If there’s one thing I’ve learned from this side project, it’s that binary sensors are powerful tools.
1 Like
So I just had to replace a lock that kept having connectivity issues… everything is renamed to exactly what old one was… is there a way to get it to “resend” the codes to the lock without a removal of each code then re-adding… the codes and slots already match up with my front door lock and automations so I was trying to see if there was an easy way to “resend” them to the new lock… I did already manually change the code length… will it send them and I’m just being impatient?
Turn the code “off” and then back “on”. You will still have to update thebYAML with the new zwave node id though.
I did miss changing the node_id, but even afterwards I am still having trouble, just won’t seem to set it and not seeing any errors in the log either… I’m going to try manually now but back in here looking for the correct json
Ok… refreshed/healed/tested again and now it seems to be updating… it’s like z-wave stopped doing anything… I’m very slowly enabling them while watching the log. Thanks… awesome work!
On a side note… has anyone done anything with an automation to make the alarm mode to change to tamper at night only? We like to have activity alert on normally as we have small kids, so it’s nice to hear if anyone is opening the door, but I was thinking it may be nice to have it go to the tamper mode with the alarm for nighttime (like a home ARMED mode) when we are asleep. Anyone else do that? and does it consistently work? I would never hear the end of it if the 90db alarm went off unexpectedly while I was at work from her opening the door.
I have not done a ton of testing lately, but the tests I did a while back worked for the settings I tried.
So I have an input selects for the various schlage zwave options
They’ll be named like this - lock_zwave_option_7_back (this is the one for what you asked about)
If you created an automation to change the value of that input select to what you wanted it would trigger the automation that is already set up in the package.
So something like this
Trigger - Whatever you use to determine it’s night (sun compoment, time componet, alarm modes, etr)
condition - Whatever you may want to set
Action -
- service: input_select.select_option
entity_id: input_select.lock_zwave_option_7_back
data:
option: 'Tamper'
the options are Alarm Off, Activity, Tamper or Forced Entry
I did change this manually a few times back and it worked, but I never went much further with it. If you do get it working, would you mind posting your success or failures for others
Been reading through trying to understand how this works. Am I correct in saying that I just replace any reference to the following:
Names in needed in entity registry:
zwave.lock_front_door_deadbolt
lock.lock_front_door_lock
sensor.lock_front_door_deadbolt_alarm_type,
sensor.lock_front_door_deadbolt_alarm_level
with these 4 in my configuration?
zwave.schlage_allegion_be469_touchscreen_deadbolt
lock.schlage_allegion_be469_touchscreen_deadbolt_locked
sensor.schlage_allegion_be469_touchscreen_deadbolt_alarm_type
sensor.schlage_allegion_be469_touchscreen_deadbolt_alarm_level
Those are the 4 that most closely match to what you say to replace. If I just replace all in that order it should work right? Or are there other things I need to change? I only have on lock on my back door.
That should do it, nothing else needs to be done but renaming those.
Just to clarify, the easiest way to get this to work is to rename your entities to match the names in the package.
So rename
zwave.schlage_allegion_be469_touchscreen_deadbolt
to
zwave.lock_front_door_deadbolt
Only posting this because I was not positive from your comment.
Now in your case, you can change the yaml or entities for back door. Just look at the comments in the lock package, It should point out where you should change _front to_back,