@ericleejoe can you please post the xml from your zcfg file? I was able to get my locks to at least match each other as far as the sensors go by modifying the xml.
@ericleejoe - Here are the latest details on how the locks are working with ozwdev. May or may not be related, but still having issues. the xml changes ended up not fixing the issue, the lock hung up.
I had a tough time adding the lock to my network, solved the problem, and figured it would be good to share with everyone.
I’ve rebuilt zwave network a few times now and the lock is always a problem. I knew that I need the controller within 1 ft, it should be excluded first, and I add secure from HA zwave panel.
I had the usb stick, connected to the small factor dell desktop, on the kitchen counter and 6" from the back door lock. I was able to include it without difficulty but the ozw logs complained about it. Nothing would work.
The batteries that were in the lock seemed fine but I replaced them with new batteries and the include worked flawlessly. no errors.
tldr: If you are having trouble and followed all the other suggestions, use fresh batteries, even if the existing ones seem good.
For what it’s worth, I added my Schlage to my Aeotec from about 15 feet away with no issues. First time, like a charm following the steps I outlined above.
Here is the most current xml from the openzwave git hub repo. You can stop HA, and then edit your current zwcfg file to add any of these parameters:
<?xml version="1.0" encoding="utf-8"?> Enable or disable the beeper. </Value>
<Value type="list" genre="config" index="4" label="Vacation Mode" min="0" max="255" size="1" value="0">
<Help>
Prevents all user codes from unlocking the deadbolt.
Enable for extra security while you are away for
an extended period of time.
</Help>
<Item label="Disable Vacation Mode" value="0" />
<Item label="Enable Vacation Mode" value="255" />
</Value>
<Value type="list" genre="config" index="5" label="Lock & Leave" units="" min="0" max="255" size="1" value="255">
<Help>
When enabled: Press the Outside Schlage Button to lock the
deadbolt. (Default setting).
When disabled: Press the Outside Schlage Button and then enter
a user code to lock the deadbolt.
</Help>
<Item label="Disable Lock & Leave" value="0" />
<Item label="Enable Lock & Leave" value="255" />
</Value>
<Value type="list" genre="config" index="7" label="Lock Alarm Mode" size="1" value="0">
<Help>
The alarm is turned off by default. After installation,
you will need to turn on your alarm.
Activity
Alarms when the door opens or closes.
Perfect for monitoring doors while you re at home.
After the alarm is triggered, there is a built-in 3-second
delay for it to reset.
Sounds two short beeps.
Tamper
Alarms when the lock is disturbed, while locked.
Senses subtle activity at the lock.
Sounds 15 second Alarm (90 dB)
Forced Entry
Alarms when significant force pushes against the
door, while locked. Perfect for nighttime or
when you re away from home.
Least sensitive mode
Sounds three-minute shrill, steady alarm (90 dB)
</Help>
<Item label="Alarm Off" value="0" />
<Item label="Activity" value="1" />
<Item label="Tamper" value="2" />
<Item label="Forced Entry" value="3" />
</Value>
<Value type="list" genre="config" index="8" label="Activity Alarm Sensitivity" size="1" value="3">
<Help>
Each alarm mode is preset to a sensitivity level of three.
If your alarm is sounding too frequently, or not frequently enough,
try changing this setting.
If you change the alarm mode, the sensitivity will revert
back to the default setting.
</Help>
<Item label="Most Sensitive" value="1" />
<Item label="Medium/high Sensitivity" value="2" />
<Item label="Medium Sensitivity" value="3" />
<Item label="Medium/low Sensitivity" value="4" />
<Item label="Least Sensitivity" value="5" />
</Value>
<Value type="list" genre="config" index="9" label="Tamper Alarm Sensitivity" size="1" value="3">
<Help>
Each alarm mode is preset to a sensitivity level of three.
If your alarm is sounding too frequently, or not frequently enough,
try changing this setting.
If you change the alarm mode, the sensitivity will revert
back to the default setting.
</Help>
<Item label="Most Sensitive" value="1" />
<Item label="Medium/high Sensitivity" value="2" />
<Item label="Medium Sensitivity" value="3" />
<Item label="Medium/low Sensitivity" value="4" />
<Item label="Least Sensitivity" value="5" />
</Value>
<Value type="list" genre="config" index="10" label="Forced Entry Alarm Sensitivity" size="1" value="3">
<Help>
Each alarm mode is preset to a sensitivity level of three.
If your alarm is sounding too frequently, or not frequently enough,
try changing this setting.
If you change the alarm mode, the sensitivity will revert
back to the default setting.
</Help>
<Item label="Most Sensitive" value="1" />
<Item label="Medium/high Sensitivity" value="2" />
<Item label="Medium Sensitivity" value="3" />
<Item label="Medium/low Sensitivity" value="4" />
<Item label="Least Sensitivity" value="5" />
</Value>
<Value type="list" genre="config" index="11" label="Disable Local Alarm Controls" size="1" value="255">
<Help>
Enables/Disables local alarm on/off, mode change, sensitivity changes
</Help>
<Item label="Disable local alarm controls" value="0" />
<Item label="Enable local alarm controls" value="255" />
</Value>
<Value type="int" genre="config" index="12" read_only="true" label="Electronic transition count" />
<Value type="int" genre="config" index="13" read_only="true" label="Mechanical transition count" />
<Value type="int" genre="config" index="14" read_only="true" label="Electronic failed count">
<Help>
Each failed electronic attempt increments this count by one.
</Help>
</Value>
<Value type="list" genre="config" index="15" label="Auto lock" size="1" value="0">
<Help>
When enabled, the lock will automatically relock 30 seconds
after unlocking. (Disabled by default.)
</Help>
<Item label="Disable auto lock" value="0" />
<Item label="Enable auto lock" value="255" />
</Value>
<Value type="byte" genre="config" index="16" label="User code pin length" min="4" max="8" value="4">
<Help>
User Code PIN length, a value between 4 and 8.
IMPORTANT: All user codes must be the same length.
</Help>
</Value>
<Value type="int" genre="config" index="17" label="Electrical High Preload Transition Count" read_only="true">
<Help>
A subset of Electronic transition count, the number of transitions
with high preload.
</Help>
</Value>
<Value type="byte" genre="config" index="18" label="Bootloader Version" read_only="true">
<Help>The version of the bootloader</Help>
</Value>
</CommandClass>
<CommandClass id="113">
<!-- These Door Locks don't send a DoorLockReport when the
Lock Status is Changed, but instead send a Alarm Message -
So we trigger a Refresh of the DoorLock Command Class when
we recieve a Alarm Message Instead -->
<TriggerRefreshValue Genre="user" Index="0" Instance="1">
<RefreshClassValue CommandClass="98" RequestFlags="0" Index="1" Instance="1" />
</TriggerRefreshValue>
</CommandClass>
Two questions?
- Where could I have gone to find this file?
- Can you verify your post is formatted correctly. I looks like th first part of the xml is not included correctly.
Thanks so much. Might try this out and report back.
I start by looking at the mfg id and product type/id from the zwcfg file. I take that and find it in the manufacturer_specific.xml file (link below). This will point you to the xml definition file for that device (second link below).
When you add a device to your zwave fabric, the zwcfg file in HA is populated based on what it knows from HA at the time. So even if you could update the base files in HA, or HA is later updated with newer zwave data, you still have to manually update any missing info in the zwcfg file.
<Manufacturer id="3b" name="Schlage">
<Product type="6341" id="5044" name="BE469 Touchscreen Deadbolt">
I am definitely interested to know what version of HA you are running? or Hass.io. I’m asking because although, I’ve managed to get both my deadbolts added and what I believe to be the correct sensors for the flavor of openzwave I’m running, I cannot see any reference to
BE469NXCEN Touchscreen DeadBolt
in the openzwave xml files.
I have a feeling that there have been minor changes to how the schlage is handled with the latest openzwave.
I have the following, I’m sure it’s paired right. It probably even had the data I need.
lock.back_door_lock
sensor.back_door_lock
sensor.back_door_lock_access_control
sensor.back_door_lock_burglar
sensor.back_door_lock_power_management
sensor.back_door_lock_system
sensor.back_door_lock_usercode
For example, you don’t have sensor.back_door_lock_usercode
This looks to be to me the usercode used to open the door, my only issue is it is very slow to report.
It’s funny but at one point during pairing, I got the deadbolt to pair, but it only exposed 3 sensors. I knew it was wrong, but… It returned instant status, like within a second when the door was locked, unlocked manually or with code, and told me which code. I should have left it, haha.
Anyway, if I knew the version you were running, I could better compare the xml files
Thanks
I have mentioned before. I run HA on Raspbian (I am currently on version .59.2) but in process of building a new system with current version.
oh yea, sorry!! Thanks!
Yea for me. At least I found the name change. 
Thanks for this info. I’m definitely learning quite a bit. My files are updated as shown above.
Can you answer a question or two?
Mybe469.xml file is exactly as you posted. When I add my locks I get this for CommandClass ID=“113”
<CommandClass id="113" name="COMMAND_CLASS_ALARM" version="3" request_flags="2" issecured="true">
<Instance index="1" />
<Value type="byte" genre="user" instance="1" index="2" label="" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="0" />
<Value type="list" genre="user" instance="1" index="9" label="Access Control" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" vindex="5" size="0">
<Item label="Not Active" value="0" />
<Item label="Access Control - Manual Lock" value="1" />
<Item label="Access Control - Manual Unlock" value="2" />
<Item label="Access Control - RF Lock" value="3" />
<Item label="Access Control - RF Unlock" value="4" />
<Item label="Access Control - KeyPad Lock" value="5" />
<Item label="Access Control - KeyPad Unlock" value="6" />
<Item label="Access Control - Unknown" value="254" />
</Value>
<Value type="list" genre="user" instance="1" index="10" label="Burglar" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" vindex="0" size="0">
<Item label="Not Active" value="0" />
<Item label="" value="0" />
<Item label="Burglar Intrusion" value="1" />
<Item label="Burglar Intrusion" value="2" />
<Item label="Burglar Tamper - Cover Removed" value="3" />
<Item label="Burglar Tamper - Invalid Code" value="4" />
<Item label="Glass Breakage" value="5" />
<Item label="Glass Breakage" value="6" />
<Item label="" value="8" />
<Item label="Burglar - Unknown" value="254" />
</Value>
<Value type="list" genre="user" instance="1" index="11" label="Power Management" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" vindex="0" size="0">
<Item label="Not Active" value="0" />
<Item label="Power Applied" value="1" />
<Item label="AC Power Lost" value="2" />
<Item label="AC Power Restored" value="3" />
<Item label="Power Surge" value="4" />
<Item label="Power Brownout" value="5" />
<Item label="Power - Unknown" value="254" />
</Value>
<Value type="list" genre="user" instance="1" index="12" label="System" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" vindex="1" size="4">
<Item label="Not Active" value="0" />
<Item label="Hardware Failure" value="1" />
<Item label="Software Failure" value="2" />
<Item label="System - Unknown" value="254" />
</Value>
<Value type="byte" genre="user" instance="1" index="200" label="UserCode" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="5" />
<TriggerRefreshValue Genre="user" Instance="1" Index="0">
<RefreshClassValue CommandClass="98" RequestFlags="0" Instance="1" Index="1" />
</TriggerRefreshValue>
If I remove all of the section and replace it with
<CommandClass id="113">
<!-- These Door Locks don't send a DoorLockReport when the
Lock Status is Changed, but instead send a Alarm Message -
So we trigger a Refresh of the DoorLock Command Class when
we recieve a Alarm Message Instead -->
<TriggerRefreshValue Genre="user" Index="0" Instance="1">
<RefreshClassValue CommandClass="98" RequestFlags="0" Index="1" Instance="1" />
</TriggerRefreshValue>
</CommandClass>
I lose all of the sensors that were there, which I understand, since they were part of the 113 section I just removed.
I guess my question is… If my be469 file is exactly as shown, then were do the entries for
sensor.back_door_lock_access_control - Manual Lock, Manual Unlock, Keypad Unlock,
sensor.back_door_lock_burglar - Not Active
sensor.back_door_lock_power_management - Not Active
sensor.back_door_lock_system - Hardware Failure
sensor.back_door_lock_usercode - 1, 2, …
come from?
Thanks again for your patience. At this point my locks are “working” probably as intended, I’m trying to watch why happens to each sensor as I lock, unlock, etc. Some things update quickly. some slowly, etc.
Again, I am running the ozwdev flavor of openzwave, but from what I can see the master branch and the dev branch are identical for the schalge be469.
Once I get all the details figured out, and determine how to run automation/scripts based on who unlocked the door and hopefully instanst status on that, I’ll be sure to write it up here.
Sorry for posting so much on my own comments. When I get the chance, I will try adding the following to my locks
<Value type="byte" genre="user" instance="1" index="0" label="Alarm Type" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="21" />
<Value type="byte" genre="user" instance="1" index="1" label="Alarm Level" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="1" />
I believe that these are the missing sensors. What I do not know is what will happen if I just add these sections even though they were not “discovered”
If they don’t exist the would just stay default values of 0 usually.
I know on my Kwikset lock the user who unlocks the door comes in as an update to the “lock status” attribute rather than using alarm type/level, even the error messages go there ie: “Lock Jammed”.
Likely you won’t need those sensors.
Good info, thanks. The thing is these two devices seem to exist for everyone else on this thread with a working Schlage lock. It seems to be the only way to pull user codes, but again, many of the posts are older, or people are running older versions of HA, so maybe these will do nothing for me.
I’ll report back on how it turns out.
Adding the items did not work, as expected. I tried one last time, I removed the deadbolt from the door and put it 6 inches from the controller and re added. Same as before it added just fine, just not with the same sensors as others. Specifically one new one “Usercode” and missing alarm type and alarm level.
Looking closer at the sensors as I completed various actions, I noticed that one of the sensors does update in real (or near real time), that is the Access control. It returns
Manual Lock, Manual Unlock, KeyPad Lock and KeyPad Unlock.
I could not find any code numbers in the other sensors (or at least they did not update quick enough to be relevant.
This is what I found in the ozwlog
2018-05-10 17:48:26.891 Info, Node079, Received Alarm report: sensorSrcID=0, type:Access Control event:Access Control - KeyPad Unlock, status=true
2018-05-10 17:48:26.891 Detail, Node079, Refreshed Value: old value=0, new value=0, type=byte
2018-05-10 17:48:26.891 Detail, Node079, Changes to this value are not verified
2018-05-10 17:48:26.891 Detail, Node079, Refreshed Value: old value=1, new value=6, type=list
2018-05-10 17:48:26.891 Detail, Node079, Changes to this value are not verified
2018-05-10 17:48:26.891 Warning, Localization::SetupValue: Localization Warning: No Entry for ValueID - CC: 113, Index: 200
2018-05-10 17:48:26.891 Detail, Node079, Notification: ValueChanged
2018-05-10 17:48:26.896 Detail, Node079, Notification: ValueChanged
2018-05-10 17:48:26.900 Detail, Node079, Notification: ValueRemoved
2018-05-10 17:48:26.901 Detail, Node079, Notification: ValueAdded
I was hoping the old value new value was the code, but I tried a few different codes and the values were the same.
At this point I’m just going to leave these alone for a while. I dont have a pressing need to know which code did what, but I would definitely like to be able to do things in the near future with user codes.
I did find that the usercode sensor updated to the last used code, but so far it only did that on restart. Maybe I can increase the polling frequecy on that as well
This is a curious entry… were you able to find the zwave manual for this lock?
Just this one
I will say that it looks like index 200 is “usercode”
Sounds like the lock tried to update what usercode unlocked it via the keypad.
Have you tried excluding the troubled lock, swap fresh batteries into it, then re-add it via Home Assistant?