Glad you got it working, Sorry about not keeping the one lock and two lock packages up to date, its just a bit of a pain and since I have three locks that’s what I keep updated. Glad you were able to figure out how to make it work with two fe599s that was my intent with the comments throughout.
Yes the zwave options do not work with the fe599. To be honest I really never did extensive testing with the zwave options. In theory they should work, but it’s possible that there is a typo or that some of the config options may require a little massaging.
Thanks … that’s OK, I have plenty of features to do what I was looking for anyway. Again many thanks for your contribution. Just hope that you don’t update it too often this was a bunch of work, but the comments were great and helped a lot.
I will say that for the most part I’m done. The one thing left I want to do at some point in the future is reoccuring codes based on days and times. Like M-F 8-5, or disable a code if we’re home. I remember those from rboy. Would not be hard, just adds a lot more inputs, etc.
@Jay_Heavner this solution persists on container restart. The only time you need to “redo” everything is after any updates. I listed all the commands above and put it into a bash script that I execute after every update. the script takes a minute or so to run and when it finishes you just restart the container and all is good…
For some reason it’s not adding or deleting new codes, or anything now. Do you have any advice on how to do a “fresh start”, I’ve tried doing a factory reset of the lock and removing/adding the package, but to no avail.
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.
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.
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 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.
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?
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
this was a bunch of work, but the comments were great and helped a lot.
