I’m not sure how people prefer to get notices of updates on the forum. Do I put them here at the end, at the beginning, or create a new thread?
Updating with the latest code
It should be fairly simple. Grab the latest files and overwrite them in the packages/lock-manager directory you already have. SSH into your terminal, go to that directory. If your lock is named frontdoor (specified in the ini file) you should already have a frontdoor directory. Make a backup of that directory just to be safe. Next run ./setup.sh and that will update the files in frontdoor. To update your lovelace, copy all the code in frontdoor_lovelace into clipboard. Open up your lovelace GUI and edit the raw code. Go to the very end and paste the contents of the clipboard, save and exit. You should have a new view in your lovelace GUI with the new updates.
I made a couple of commits to the repository. I made a few minor bug fixes, as well as introduced a feature to include/exclude the time zone specified for each day of the week. I found myself having an issue where I wanted the codes to be excluded during a time period. So I added an input_button (God, I want a checkbox or radio button option) so that when the value is true/false the time period is included/excluded accordingly. This is also holds when you have the start/end times the same (both are 0:00), so using “exclude” is essentially the same thing as disabling the day’s time period altogether.
I wonder how RBoy Apps does it in ST? They seemed to have figured out a way when I used to use ST to send the codes to the lock and confirm the lock received them. It was all very slick.
I used ST for quite a while too and also used RBoy lockmanager. It well worth the money. I agree with @FutureTense though. I dont think it confirmed the code itself, I just think SmartThings zwave was more mature and worked better. I will say that there are items in the log that I dont fully understand, that maybe RBoy or ST does. For example at the end of what looks to be a send command this comes back
ZW_SEND_DATA Request with callback ID 0x02 received (expected 0x02)
I dont know, is that saying that the zwave device reporting that it did what is was supposed to do? Not a code itself, but maybe a confirmation of the action being complete.
I do recall RBoy stating that you have to wait a certain amount of time when you send updated PIN’s to the locks. I think what they did was just stage several updates behind each other to ensure they got there. Unless there was some ST API we aren’t aware of. Lastly, does HA have some kind of API where we can poll the pin code in OZW to see the hex values for the lock pin? If there is a way that would be a decent ACK to see that the ASCII conversion matches the intended PIN?
I suspect you are correct. I’ve done a bit of searching, on the web, but have not found a good diagram showing the back and forth communication between a controller and a device. I think an ACK is pretty decent though. It at least confirms the device is not dead, its awake, and it received the command. In my case the few times things have not loaded, even after the zwave “UserCodeCmd_Set” is sent, the logs showed an obvious error. but I dont remember if it also showed a “received” 0x02 line.
I was all about trying to have a bit better confirmation for a while, but with OWZ 1.6 coming soon, I dont know if it will all be a wasted effort
You definitely cannot pull codes from the lock to verify. I believe with a high level of confidence that you never will be able to and that it is not an HA thing, its a zwave things. It would be a bit of a security risk if you could pull codes.
then how come I see the hex values for codes in OZW panel in HA? ugh, never mind, I see what you are saying. OZW may say the pin is set while the lock may not get it… NM
From a security standpoint that function makes no sense. A function that would make sense is confirmCode(x) which is analogous to setting the code. While setCode(x) could return true that indicates x was accepted as a code, a confirmation function would verify the passed in code is in the lock. It’s no more of a security risk than setCode
This function looks like it grabs the codes to me, I could be wrong but that’s what it looks like to me. (As long as the node supports the feature) I’d have to dig thru the zwave specs but I always loose the page I find them at
I’ve only had to make a small tweak to the notify since I use a input_select to allow me to switch from notifications via the Phone App or Google Hangouts. This is because the App has a limit of 150 notifications, so after that I want it to switch to Hangouts (WIP automation).
Great job! Well done. I have two locks and I have been using it. I used to have a Wink and one of the things that I was missing it was the lock management. Now with your package, I got that and extra sensors! Thank you! I I only have one minor request it could be nice to obfuscate the PIN so it does not show on the screen. Thanks again!
@FutureTense Thank you for putting together this great package. When I tried to run ./setup.sh script, I am getting the following error -
./setup.sh: line 32: #the name or location of the lock you are setting up (no spaces): syntax error: operand expected (error token is "#the name or location of the lock you are setting up (no spaces)")
My frontdoor.ini file contents are as bellows:
#See README for more information.
[lockmanager]
#number of PINS to setup in lovelace
numcodes=3
#the name or location of the lock you are setting up (no spaces)
lockname="frontdoor"
#the "lowest common denominator" of the factory lock name.
lockfactoryname="schlage"
#The name of the (optional) door sensor.
sensorname="frontdoor"
#the "lowest common denominator" of the factory door sensor name.
sensorfactoryname="vision_security_zd2105us_5_recessed_door_window_sensor"
#the Home Assistant EntityID of your (optional) garage door
garageentityid="cover.garage_door_opener"
Am I missing someting? I tried renaming file to FrontDoor.ini as well, that did not helped either.
Your lockfactoryname looks wrong. It should look more like lockfactoryname="kwikset_touchpad_electronic_deadbolt" or in your case "schlage_allegion_be469zp_connect_smart_deadbolt" since you have a schlage.
Check the name in Home Assistant’s dev-tools. You’ll want the part between lock. and _locked
