I’m still seeing it relentlessly update my lock. I have to set “allow automation execution” to off to stop this. Any advice?
Make sure you update the lovelace, then post a pic of your keypad slots. e.g.
Do any of your slots show PIN synchronized with lock set to off?
Just to explain what’s going on here, Paul has a PIN of 1987. However, the slot shows that it is in a “Disconnected” state. This is because the slot has been disabled by the input boolean.
A key concept to comprehend about lock-manager is that every slot has a schedule for its PIN
Even if you just added one code for yourself and never touched the advanced settings, then your schedule is “always on”. Whenever the current conditions match a PIN’s schedule, that lock recognizes this and uses the frontdoor_code_slot_X and PIN synchronized with lock controls to either add or remove the PIN from the lock.
For example, you can modify Advanced settings by sliding the input boolean for Sunday, Tuesday, Thursday, Saturday to off, which will effectively create a “schedule” that the PIN 1987 will only work on Monday, Wednesday, Friday.
So if it is currently Friday night at 23:59 the PIN status control would show “Connected” because current conditions “pass” the PIN’s schedule. When midnight strikes, this control will change to “Disconnected”. In the debug section, frontdoor_code_slot_3 shows the PIN value that is being reported by the lock for this slot #. This value takes a while to update, depending upon your lock model and if you’re using zwave or ozw. Be patient. If you’re using ozw, a cleared lock may show a blank string, 0000, or ******. The status control PIN synchronized with lock should be “on” if the state of the slot is “Connected* AND if the PIN value being reported by the lock slot matches the value in the PIN field. If the state of the slot is “Disconnected*, then this value will be “on” only if the lock is reporting the code slot does not have a PIN. Remember, a disconnected PIN means the PIN’s schedule does not match current conditions. In other words, the PIN shouldn’t work and be deleted from the lock if it already exists
Are any of the backdoor code slot X sensors returning values? I believe you have the lock which is returning **** for user codes in ozw?
I suggest you only use 2 slots for now, just to make debugging easier. Are you running ozw in docker? if so, restart ozw and watch the values for codeslotX. They should ignore the stars and only report actual codes. The fact they ARE returning stars is something @firstof9 needs to look at. Try changing the PIN to something else and see if that updates the sensor.
You might want to jump on discord
I’m running Home Assistant OS on a RPi4, Version 5.4 and OZW is running on this device.
Each time the script goes through “Value Refreshed” to set the code I temporarily see in OZW ********, then I see the set numeric value for each slot.
I also see some Notification_Code_MsgTimeout intermixed between “Value Change” messages
Per your screenshot are some of the slot showing the code or are they just blank?
IE code_slot_1
What’s the full entity_id of your lock? e.g.
lock.be469zp_connect_smart_deadbolt_locked
Is that specified for the first row in your lock-manager options (config | integrations | lock-manager | options)?
All the codes are showing in LoveLace & all the codes are showing in OZW, they just don’t stop sending value refreshed commands.
lock.backdoor_locked
Why did you delete that post of your UI? That has useful information for us to help you. Maybe you should ignore lovelace for now and just use the dev states screen and enterbackdoor_code_slot so you can see all of those sensors. If those aren’t retrieving the actual codes from the lock, then nothing will work properly.
IIRC people have said that when adding a new code to the lock, ozwadmin shows that code appearing for about 15 secs, then it gets replaced with ****. Can you manually use ozw.set_usercode and set one of the slots to 1234 and report back what shows up in ozwadmin?
Check your entities and filter on lock.
I suspect you have other entities as well. We want the entity associated with the integration: OpenZWave Beta
I am in the process of moving my configuration over from SmartThings and have been struggling mightily to get this to work but haven’t been able to get it functional. I also have some questions that I am hoping will clear things up.
-
Does the contents of this thread or the README in the repository have the most up to date information? I ask because there are some differences. In particular, the open_zwave_network_up script is a condition clause on the Github page, which isn’t mentioned here. I am not sure it matters, but it is there.
-
I finally figured out that I need to put the packages line in the configuration.yaml. I was relying solely on the README initially, and this isn’t mentioned anywhere that I could see.
-
For whatever reason, when my locks were added to OZW, many sensors are added as disabled, including the User Code and Access Control ones. I had to enable these sensors to get the integration to be added through the GUI. This is probably also worth mentioning in the README. Are there any other sensors that should be enabled for the lock?
-
My lock has two sensors that are labeled User Code. I have been using the first one based on what I’ve read, but it’s not clear to me if that is correct.
-
My system ready, and automation flags are not turning on correctly. In the logbook, I see that all the steps appear to be running correctly, but they get turned back off after system_cleanup stops. Is this supposed to happen?
-
Everything appears on the Lovelace information correctly, but my codes are never getting set, and I see the following message in the logs every 30 seconds.
ERROR (MainThread) [homeassistant.helpers.entity] Update for sensor.frontinner_code_slot_1 fails
I am not sure where to look at this point. Everything seems to be as requested. Can someone help point me in the right direction?
I’ve attempted to hit almost all your points in the new Wiki pages.
This should cover most of your questions along with some troubleshooting tips.
If something doesn’t seem covered do let me know.
No. I’m really bad about updating that. The “startup” automations in the 1st post need to be added in order to make things work. They basically set the “allow automations” boolean to true after basic network stuff completes.
I recommend people factory reset their lock, then add it to their zwave network before installing lock-manger via HACS. Then add the startup automations. Then add the generated lovelace code to the end of your “raw” lovelace. Add a couple of PIN entries to your UI. Like one for you and one for your wife. Since you will likely want these PINs to be “always on”, don’t touch any of the advanced settings. Use the input boolean slider to “enable” your PIN. If you are using ozw, you can watch your PIN get added to the lock. It can take a few seconds for this to happen, and can take even longer for lock-manager to “confirm” the slot is synchronized with the lock. That means either the PIN is “in” the lock if the slot status is “Connected”, or if the status is “Disconnected” the PIN is not in the lock (the PIN has been removed from the lock).
Each slot has a debugging section. The first item is a PIN sensor reporting what the code is that appears in the corresponding user code. The second item is a “PIN synchronized with lock sensor” which returns TRUE if the status is “connected” and the UI PIN value matches the PIN sensor value. If the status is “disconnected”, the sensor returns true only if the corresponding value is blank.
I need to work on the terminology a bit, and then update the README.
Looking at the new wiki pages under Additional Setup. We create an input boolean for system ready but then the “home assistant start-up” automation and the “system_startup_cleanup” script are not included on that page. I assume these are still needed for should be included in automations.yaml and scripts.yaml respectively? (As opposed to the new file mentioned in Easy Mode) Or is the system ready input not needed anymore?
You only need to create the allow automation boolean. System ready isn’t used by lock manager
2 Likes
Anything I posted into the Wiki is the only bits you’ll need to get the setup working 
I removed everything related to the integration and am now stepping through the Wiki so that I can provide some feedback. I will provide the first batch here, but if you would prefer it somewhere else I am happy to do that. Since there is a number of parts, I am breaking it up to make sure it is working before proceeding.
On Additional Steps (although as I am doing these, I would say initial steps as you can get this part working before anything else), there are some issues in Easy Mode.
- I was getting an invalid slug error when using the suggest lock-manager-additional.yaml file name. I changed it to lock_manager_additional.yaml
- The yaml itself has the following issues:
- Line 1:
input_booleans:should beinput_boolean: - Line 22 and 23 are not properly indented, both need to be moved to the right
- Line 25:
automations:should beautomation:
- I am using OZW which is what was used to test this, but it appears the same issues exist in yaml for the built-in Zwave.
Less critical suggestions:
- There is an assumption that the appropriate packages entry has been placed in the configuration.yaml. This is one of the things that got me initially as I didn’t have the entry in place so it may be useful to state that the packages directory needs to be created and the appropriate entry placed into the configuration.yaml.
- Also, as part of this step, I also created a lock-manager directory (knowing it will be created once the integration is installed) and placed the lock_manager_additional.yaml in that directory so everything is self contained. Any thoughts on having the appropriate yaml file created by the integration based on whether OZW is checked or not.
- Testing the setup: At this point, I just have the created file and place it appropriately. Check configuration, restart the server and then checked logbook to look for the ozw_network_up message along with the allow_automation binary being set. It may be helpful to add steps along the way to make sure things are being set up correctly.
This is addressed in https://github.com/FutureTense/lock-manager/wiki/Pre-Installation-Steps-(IMPORTANT)
This idea is being tossed around now.
As for the yaml formatting, I did throw them together in about 10mins before be, there were bound to be formatting/spelling issues 
we’ll get them adjusted.
