Looks like due to your lock using the proper notifications and OZW Beta reporting them to Home Assistant, you’ll need a modified version of the lock manager, or template sensors.
@ptdalen might need to know this as well, as I recall he has a Schlage as well.
No, you shouldn’t have too. Mucking around with the generated yaml files isn’t a good idea unless you’re debugging. Once you have your ini files set “just so” it’s only a matter of running the setup.sh script again to get the package working. I know most people who have got their ini files right haven’t had any issues, even updating to a new package version.
The new OZW Beta doesn’t have lock.set_usercode service yet, and some locks like the Schlage send proper Notifications and no longer use alarm_type and alarm_level unless you create template sensors. Unless they tinker with the code (not really likely from what I could tell).
Without setusercode, this project won’t serve much purpose. Do you know how to get in touch with the devs of the beta? Perhaps we should tell them what we’d like to see in future releases?
Speaking of the future, I’m open to adding you to the repo if you’re interested. But I’d like your impressions about what direction you think this project should head. Ideally I’d like to be able to add this via HACS, and then be able to add/delete/update locks through the UI. But that’s secondary to nailing down the manual approach. Face it, it will be a long time before people are going to be able to configure much of HA that doesn’t require some tinkering skills.
I’m told they have a discord server, I’ll do some searching.
I’d have to ponder how to do this. 
It’s easy enough to run scripts from python, and the config flow could be made to make the user input the ENV variables. Maybe a simple sensor as a dummy with a single sensor indicating the file timestamp so you know when you last generated the files.
EDIT: or a service …
Updating is simple enough. The INI values should be forward compatible, so running the script will create/update a LOCKNAME directory for each associated ini file.
You may have noticed most people that have issues are the ones who haven’t renamed their lock entities the way the package expects to find them. I only have one zwave lock, and don’t expect that to ever change, so it’s difficult for me to test this beyond 1 lock. Do you know what happens when you add multiple locks? For example, if your first lock has a LCD of schlage_allegion_be469zp_connect_smart_deadbolt, what would the second lock’s LCD look like?
One thing I’d very much like to do is to add functionality to rename the entities programmatically instead of manually appending _LOCKNAME at the end. Once the LCD for the lockname (and optional sensor) have been identified, this should be fairly simple to do. It would just require iterating through a list of predefined entities (alarm_level, alarm_type, etc). Keeping the original LCD name as part of the entity is unnecessary and makes the code a bit unreadable as well.
I was thinking of adding a lockmap.ini file which would look something like (assuming the 2nd lock had _2 appended to the name
schlage_allegion_be469zp_connect_smart_deadbolt = frontdoor
schlage_allegion_be469zp_connect_smart_deadbolt_2 = backdoor
and instead of having schlage_allegion_be469zp_connect_smart_deadbolt_frontdoor and schlage_allegion_be469zp_connect_smart_deadbolt_2_backdoor we would simply have:
frontdoor_alarm_level , frontdoor_alarm_type, …
backdoor_alarm_level , backdoor_alarm_type, …
This approach would take away the somewhat burdensome requirement that the end user have to rename every entity correctly. All that would be required would be for them to identify the LCD name they want to use for a door location.
Okay thanks. I haven’t touched the yaml files, and I’m fairly certain my ini is correct, I think it’s just the missing entities that are causing the package not to function correctly.
first has suggested mapping some values using template sensors, so I am going to see what I can do there.
Luckily the lock manager is not critical for me. And even with it not setting or clearing codes yet, at least I can store all the existing codes in one location.
Yes for the second lock it adds the _2 to each entity. However I went through and renamed them all to _frontdoor or _garagedoor as needed.
My ini is set correctly (I’m pretty sure, other than the sensor and cover I don’t use but did not leave blank).
Might be a function call that could be done, if not there’s always the REST API, but then the user would have to generate a token 
I have to say, I love this and thank you for the work. One issue I have though is that this appears to write a random 4 digit code to the user code slot when a code is disabled from within the app itself. My kwikset lock appears to have a ton of zeros written in the other code slots that have never been used. I don’t like that I have a random code someone could potentially use instead of actually wiping the code entirely out. Is there a way to change this behavior?
At the moment, there is no way of deleting a code, this is why we overwrite it. Yes, it’s not preferable. We are hoping the new OZW will allow a proper code slot delete.
Another option (not sure quikset supports it) is to set a specific code you know, vs a random code. Schlage allows for the same code to be loaded into multiple slots. So you could make up a random code of your choice, load that code into “cleared” slots. The only possible issue would be that it may not report correct slot if used. But I’m sure you could come up with an automation to notify you if that code is used anywhere. Like if an “empty” slot is used to unlock the door, let you know.
Also, you could just accept the random code (I eventually did this), because on my schlage, if you enter the wrong code 3 times, the door stops taking codes for a minute or so. It would take a long time for someone to sit outside trying all the possible codes if they can only enter 3 at a time. Again, only speaking for schlage be469, but there is an alarm setting I usually keep off that would trigger if a code is entered wrong a specific number of times.
That’s my take on it as well. I suggest if you hardwire a “blank” code, make that the code you use for yourself. It will always work.
Kwikset locks (last I checked the manual) did not support the option to delete a code, so you either set it to a random code or use an existing code.
One other thing you can do is change the User Code Type to 255 / No corresponding user code to disable the code slot.
One more option, but I think it’s a little extreme and also don’t know about quikset. On the schlage you can change code length from 4 to 6, doing so erases ALL slots. Then you can set all the codes back that you want using the lock manager.
Also one last “common sense thing” Most people dont add and remove from all of their slots. So me for example. I have two/maybe three slots that are scheduled based. The first 5 slots never change, So slots 6-8 are cleared from time to time. The means that no matter how many times I “clear” the slot, there would never be more than 3 random codes. When I first started setting random codes, I had this vision of 100’s of random codes being loaded since I was clearing and loading on a schedule.
Not an option, at least on my 910.
Can you change the PIN length? Just curious for the most part
Nope it accepts 4-8 digits by default, no config.
From the manual (Kwikset 910):
Deleting a user code
In order to delete a user code, you must override the code by adding a different user code in the same
position. For example, if you want to delete the third code, add a different user code in position three.
Test the old user code to make sure it can no longer unlock the door.
If you cannot remember the user code position, you may wish to perform a factory reset to delete all
codes associated with the lock.
I had no idea that you couldn’t overwrite the code on the lock. Thanks for the information and for setting me straight.
You can overwrite, just not delete (without a factory reset). 