That is amazing. That has always been one of my biggest fears or concerns. Setting a lock code for someone when you’re away and for whatever reason it did not load correctly. Great work!!!
Make sure you have in your configuration.yaml:
homeassistant:
packages: !include_dir_named packages/
1 Like
Problem solved, I’m now up and working. It required:
- Removing spacing in the name of my lock
- Following all the install steps in the README.md found in github
- Adding the line about packages to my configuration.yaml (which showed errors originally before I removed the spacing from my lock name.
1 Like
If a user code/slot is “Active” in the UI, that means the slot has been enabled (by using the input_boolean slider) and all of the conditions in “Advanced” section are currently satisfied. Another way of saying this is if a user code/slot shows it is active, the PIN for this slot should be in the lock.
However, adding/deleting a PIN to the lock is not foolproof. For whatever reason the commands to add/remove a PIN from a slot sometimes fails. And since even successful commands takes time to be reflected in the lock, the only way to have absolute confidence in a command is to manually test the PIN. Since this is impossible in cases where you have setup a schedule for the PIN, it is a great cause for concern as @ptdalen mentioned.
But your fears have been addressed! Thanks to @firstof9, each lock slot now has an associated sensor reporting the “almost” current value of the slot’s PIN. I say “almost” current because it takes up to 10 seconds for a change to the lock to be reflected in the sensor. You can see this sensor in action by examining it using the developer tools. sensor.frontdoor_code_slot_1 shows the PIN (if any) for Code #1. Note, a code of 0000 simply reflects a deleted slot. That value won’t do anything when entered on the keypad. Using this, we were able to create a related binary sensor which shows on/off if the value in the lock’s slot matches what is displayed in the UI. Using Code #1 as an example, if binary_sensor.pin_synched_frontdoor_1 shows on, and the UI code/slot shows “active” then that means the PIN in the UI matches the value in the lock which is displayed in sensor.frontdoor_code_slot_1. If the slot isn’t “active”, then this means there should be no PIN at that slot. If this binary sensor shows off, then we have a mismatch. Either the PIN shown in the UI does not match what is shown in the lock, or a PIN exists when it shouldn’t. An automation catches when this sensor’s state changes to off and attempts to correct it. This can take a couple of minutes, but it should eventually sort itself out.
2 Likes
The status showed disconnected until I “reset code slot” and “enabled”. The status now says connected but the lock code isn’t working. Is there a “save” button I should press after entering the code?
(The code displayed is not really my code)
What else should I do to troubleshoot why it might not be communicating with my lock?
If you’re using zwave you should be able to see what’s going on in the OZW_Log.txt file in your configuration directory.
If you’re using ozw you can see what’s going on directly via your MQTT broker.
Quick question/thought. If the slot and the input text match and all is good. Does it still “scan” every 30 seconds? Was thinking about battery life. Also another weird scenario. Maybe only have it retry a specific number of times, and then notify on failure? Was wondering how it would handle me setting trying to set an incompatible code. Like a 10 digit # for example. Would it keep trying every 30 seconds until the battery eventually died? Just throwing out random scenarios/thoughts.
my code_slot_# all have ********** and not a pin number. Looking at the User Values in OZW it shows the same. I tried setting a new code, but it just came out as ********** as well.
So this seems to be constantly pegging the lock to set the code as it doesn’t see it as it should be. I turned off the input_boolean.allow_execution to stop the battery from getting drained.
When pairing with the new OZW I used secure mode if that matters.
What type of lock do you have?
Schlage Century BE469 (not the ZP version), it shows the numbers for a second, then puts it in ********** in OZW. The sensor.mudroom_code_slot_# show the same stars that it’s getting from OZW
Never ran into a lock like that. I haven’t heard of any locks doing this other than now.
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.
For ozw the data’s pulled via mqtt, for zwave it’s pulled from the python objects directly since that’s how the old integration works.
Nope this doesn’t shorten battery life. The codes get updated when they’re updated, we’re not polling anything.
That’s correct.
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?
also, is there a way to speed up the UI?
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
Changing the “automatically clear events” did not seem to make a difference. Here is the chain of events that I noticed
- Changed code in HA
- Saw new code in vnc ozw.
- About 10 seconds later code in UI changed to ****
- Code works in door of course.
Here is what it looks like in the UI
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.