The thing that makes the syncing possible is the code slot sensors e.g. sensor.frontdoor_code_slot_1. There is a sensor for every slot, so the Schlage 469 locks have 30 of these. I’m not positive how they work, but I think they pull information from the hass object every 10 seconds.
@firstof9, can you please explain how this works? And specifically does this sensor cause the lock to wake and shorten battery life? My impression was that when the sensors load, they are getting information from ozw which in turn is using the MQTT retained messages. And when something on the lock changes, like a new code being added, that causes a new MQTT message which is caught and stored by ozw. This new message might sit around for up to 10 seconds before the sensor code detects the change and updates itself.
I’ve never seen the star issues before. I’d factory reset the lock and try adding it again, both in secure and insecure mode. I don’t know what you can change with ozwadmin, but it’s possible you have some setting on there which is hiding the codes.
for the life of me, i can’t get this to work. i have everything showing up in the UI, but none of the codes are ever actually added to the door. in addition, the UI is painfully slow. it takes several seconds for the door panel to load and then several seconds to switch back to any other panel…i have no idea where to even start looking at what i’m doing wrong.
edit: all of my input booleans are “off.” both system_ready and allow_automations. neither one of them ever turns on.
edit 2: if i manually turn allow_automations and system_ready on, then it seems to work for adding codes. any idea why the default readme setup doesn’t work?
I have two older BE469s (not zwave plus, etc). They do the same thing. in the OZW control panel, you see ******* for the codes. There is also a setting to automatically clear events that defaults to 5000ms. I am able to set it to 0 which keeps it from clearing events, but i never looked at codes. I’ll do some testing to see if that keeps the valuses from changing to **** in the control panel
Even with schlage, I think that if you monitored for the code in the ozw, even if its only visible for 10 seconds or so, you could be confident that it was loaded if it appeared at all. The issue with failed loads usually is because there is something wrong in HA, or the node is dead, etc.
As a test I tried to set a code that was not valid for my lock (8 digits). It still showed in the ozw contol panel, even though it did not load in the lock, then reverted to ****. I also did a quick count. The timing is about 15 seconds, from the time it appears to the time it changes to ****.
For the new OZW, I had to setup the binary_sensor here so that it saw that ozw was ready and turned on those input_booleans. Seems like a step that should be added to the documents.
Perhaps having the code clear the slot, verify it’s blank, then write the code and verify there’s some string in there would help universalize the procedure. I had issues yesterday writing to one slot and had to choose another. It would have ********** for a second, then go back to blank.
I checked the code_slot_# and it never shows the pin number even though as mention it momentarily shows up in vnc ozw.
So you see the code in ozw before it changes to stars? If so, we can probably tweak the sensor to ignore stars and keep showing the existing code. Can you restart ozw and see if the codes show up before reverting to stars?
@firstof9 if the sensor is detecting the correct code before the stars, then it probably makes sense to change the sensor to use listeners to update on state changes to catch the correct values being reported, and of course ignore the stars overwriting the actual code. I can see why they would add the stars, but I wonder why they didn’t continue this in the later locks.
how do i know if i’m using ozw or zwave? i got the script and startup stuff working by changing to the zwave.network_ready and zwave.network_stop events, but in the zwave config it’s letting me open the ozw log…
when i load the ozw log via the integration page, the first line is this:
2020-10-18 23:46:10.817 Always, OpenZwave Version 1.4.3469 Starting Up
I just did a restart of OZW and watched the OZW control panel through the whole startup process. The *****'s never showed the code. Only time I have seen a code is when setting a code,where as mentioned above, shows for 10-15 seconds and then is replaced with *****'s. A cleared code does show blank though. So at least I know that **** means something is in the slot.
is there a way to not make the UI freeze other than separating each lock code into a separate panel? i have 10 codes set up but when i have them all on the same panel, the entire UI pretty much crashes any time i try to look at that panel…if i separate them all out into individual panels, then it works (there’s a bit of a pause on load for each one, but it doesn’t crash the entire UI)…
I used this post with the help of button-card custom card and browser_mod integration for popups to create one panel page with pop-up options for each code. It seems to load significantly quicker and hasn’t ever crashed for me.
I’m not a Lovelace guru, so I’m not sure what you mean when you say panels. When you configure lock-manager and specify the settings, including the number of codes it sets up Lovelace code to create a view, which is one of the tabs that goes along the top of the screen. The view is built using two files under custom-components\lock-manager\ named lovelace.head and lovelace.code. You can modify these files to make any changes you want to the view. N.B. If you update to a new version or reinstall lock-manager these files will get overwritten, so make sure you back them up somewhere.
Open both of these files and peek inside. Note the naming convention. Anything in ALL CAPS represents one of the fields in the integration options. If you named your lock frontdoor, when you save your options, the integration will create a file below your packages folder called frontdoor_lovelace and replace every instance of LOCKNAME with frontdoor.
lovelace.head
This file is rather simple. It defines a new view to accept multiple cards, and defines the badges you want displayed across the top of the view.
lovelace.code
This is a little bit trickier. This file represents a single “slot”. If you specified you want 6 code slots, it will add this to your lovelace file 6 times. Note the TEMPLATENUM text. When creating the lovelace, this value is changed to 1,2,3,4,5,6 each time it is added to your lovelace output.
The easiest way to modify your lovelace is to make the changes to your “live” lovelace, and then compare that back to the lovelace.code file. Save the options on the integration again to regenerate the code, or from developer tools run the lock-manager.generate_package service to rebuild your lovelace code. Since it’s an entire view, I suggest deleting the current keypad view with the UI, then opening the raw configuration and pasting the code at the end.
doesn’t that make it horribly insecure on the old version? i mean you’re ending up with random codes that someone could theoretically (however unlikely) guess to unlock the door…
