I resolved my issue…
There was a typo in one input_boolean:
input_boolean.allow_automation_execution
was input_boolean.allow_aautomation_execution
I fixed that and set it to on and now I can use the UI to set codes!
My overlay of lock_manager_common.txt from the ozw_beta worked.
1 Like
Now to figure out how to get the latest log record from this Vision ZM1702 lock. In HomeSeer there was a child device “Get latest record” and when that was activated, the last notification record was retrieved from the log which updated another child device “Notifications”. I had events that triggered on lock state change that would activate get latest record which then populated the Notification device. With my Kwikset Smartcode deadbolt I did not have to do that in HS as it automatically sent the latest record to the Notification device. However, I do not see anything like this in OpenZWave for these locks. I haven’t set up the Kwikset in LOCK MANAGER yet to see if it behaves differently than the Vision. The long and short of it is, I do not see which code unlocked the door and when or how the door was last unlocked…
Sounds like this lock behaves fundamentally different than the Schlage lock. The status report sensor is geared towards the Schlage lock, and is kind of the glue of this entire project. Have you looked at @ptdalen project and see if your lock is supported? If so, we can probably handle yours too.
Hello again,
Im sorry I had to leave town for the past 2 weeks but I’m back now trying to get this all sorted.
So I tried to add a new code and got the following error:
- maindoor Add Code: Error executing script. Unexpected error for call_service at pos 1: Error rendering data template: UndefinedError: ‘None’ has no attribute ‘attributes’
- While executing automation automation.maindoor_add_code
hold tight, we’re reworking some of the templates for less errors 
Alright everyone, the latest version is now up on FutureTense’s repo:
Please point your HACS to his repo as that is where any further development will occur.
If you are using OZW make sure to enable betas in HACS.
Steps to enable beta:
- Click the 3 dots.
- Select ‘Reinstall’
- Toggle ‘Show Betas’
Once you do that you’ll see the -ozw versions in the drop down.
You are no longer required to rename your sensors, except to help you determine which door/sensors are which. Updated README is still in progress.
2 Likes
If you’re running the beta, yes, otherwise there’s the regular 0.0.6 for zwave you can use, same rules apply no more having to rename the sensors, etc …
so I can just use the built-in weave integration, no need for any additional z-wave ad-ons like the beta – correct?
That’s correct, just make sure you don’t grab a version tagged with -ozw at the end, or leave the Show Betas toggled off.
1 Like
Yikes that was it, sorry not sure how I grabbed the wrong but it shows now - Thx
1 Like
“If all goes well, you will also see a new directory (by default <your config directory/packages/lockmanager/> ) for each lock with yaml and a lovelace files.”
Do I need to do something for this package to show or should it be auto generated?
With the latest code it should generate when you press ‘Submit’.
Did you add the integration?
The adding the integration was the missing piece for me. I started filling out the form and stopped when it asked for the Alarm Type & Alarm Level sensors. I have a Schlage BE469 however I don’t have either of these entities associated with the lock. A number of other sensors and binary sensors but not Alarm Type or Alarm Level. Will this be issue to utilize this setup? Can they be left blank? Maybe the bigger question is why I don’t have them if it seems like I should for the BE469.
That Alarm Type and Alarm Level will only let you select the appropriate sensor, if I recall correctly. If you click the dropdown only one entity should be listed.
1 Like
^ This
No
Sorry I should update the text to say Alarm Type/Access Control and Alarm Level/User Code. The readme is still getting worked on to help clarify these things as well. Also, if you don’t have a door sensor you can pick any binary_sensor as it’s only used if you are monitoring the opens and closes of the door, or make yourself a “dummy” template sensor and use that.
ah, I do have Access Control and User Code sensors. I’ll try those. Thx
1 Like
I switched over to the OpenZWave integration, and in hindsight I wish I hadn’t. It was a royal pain in the neck getting things working. Even when I decided to abandon that approach and go back to the original Zwave network, it was headache after headache.
The one thing I learned is that after doing anything with zwave devices is to be extremely patient after removing and adding nodes (secure or otherwise) to your network. It sometimes takes minutes, or even hours for your devices and associated entities to appear in Home Assistant.
Another thing to be aware of, is don’t go “toggle crazy” turning input_booleans on/off to test if a PIN is part of a lock. I’ve been having unreliable performance, where the PIN is not matching the visual state of the lock.