Z-wave lock doesn't update status

I just started with HA and I’m using 114.4 on an RPi3B. I’ve configured z-wave (beta) w/ mqtt. All is going pretty well. Now I just added a Yale (Assa Abloy) YRD110 keypad deadbolt (lock). It added fine and I can control it but if I lock or unlock manually, it doesn’t update the status on the dashboard.

Now I know that this lock doesn’t send an updated status on manual operations but it does send an alarm. The device PushButtonDeadbolt.xml even says that it will trigger a poll when an alarm report comes in for this very reason. Doesn’t seem to be working for me.

So first question is why not. How do i track down this apparent failure.

Next is the simple question, how did HA figure out that it was a lock and handle it with the lock intgration? It figured out my thermostat was a climate part and handled it with the climate integration and it seemed automagic as well.

What about lock template? When would it be of use?

Finally, I saw a simplified lock manager here. Is it in common use? Should I be considering it?

So many choices. So much terminology (integration, device, class, template…). Still trying to work it out.

Return the lock?

Sorry for giving you a “get a Mac” answer. One thing you might be able to do is poll the lock every second with an automation. But I think you probably have another issue going on, because I’m surprised it’s not reporting correctly. @firstof9 is the resident guru on z-wave locks here. I’m sure he will chime in.

Post the Command Class 113 (Notification Command Class) XML block from your ozwcache_0xXXXXXXXX.xml file.

I see on many, many posts for Yale locks where the alarm type and alarm value were used to create a sensor that specifies what has just happened to the lock (e.g. locked manually, tamper, unlocked by user code 2 etc.). It kinda implies I’m not alone.

Gladly, but where do I find that. I have terminal access and can docker exec into any container but I don’t know where that file is (looked in zwave container). I’m using ozw (i.e. beta)

Should be in /opt/ozw/config inside the container.

Found it in /data/ozw/config. Stupidly, I had a typo in my find command so it didn’t show up at first!

                        <CommandClass id="113" name="COMMAND_CLASS_NOTIFICATION">
                                <Compatibility />
                                <Instance index="1" />
                                <Value type="byte" genre="user" instance="1" index="512" label="Alarm Type" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="240">
                                        <Help>Alarm Type Received</Help>
                                <Value type="byte" genre="user" instance="1" index="513" label="Alarm Level" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="1">
                                        <Help>Alarm Level Received</Help>
                                <Value type="int" genre="config" instance="1" index="514" label="Automatically Clear Events" units="ms" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="-2147483648" max="2147483647" value="5000">
                                        <Help>Automatically Clear Events sent by a device after a number of Milliseconds</Help>
                                <TriggerRefreshValue Index="6">
                                        <RefreshClassValue CommandClass="98" RequestFlags="0" Index="0" />
                                        <RefreshClassValue CommandClass="98" RequestFlags="0" Index="1" />

There’s your problem. The index should be 512 not 6.

I am not sure how to modify that in the addon since ozwdaemon has to be stopped in order to modify the cache.

I don’t understand this part of the .xml, but can I edit the device .xml file then refresh? The TouchDeadbolt.xml device file section looks like this

  <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="6" Instance="1">
      <RefreshClassValue CommandClass="98" Index="1" Instance="1" RequestFlags="0"/>

Looks like I could just change it there and submit a PR on the device file if this is wrong for everyone. As I say, I don’t understand this part.

Yes but make sure you change the revision number at the top to something like 999 so it doesn’t get overwritten by the automatic download.

Basically it’s looking at index 6 in the 113 command class to change in order to trigger a refresh of the lock status. Since index 6 isn’t valid for your lock, because you only have 512 and 513, it never updates the status.

@firstof9, your help is incredible and will lead me to a complete solution bu bear with me, please so I can do the right thing when submitting a PR.

I just saw in the device xml (sorry, the actual file is PushButtonDeadbolt.xml) that an edit was made very recently saying to change it to 6 to allow refreshes to occur. I also see that there are two lock models in this same file: YRD210 and YRD110. If I just change it to make YRD110 work, I might break YRD210 locks. So I ask what is index 6 or 512 or 513? Where did you find these? How do you know I only have 512 and 513? What are they?

Asking a lot of you, but I don’t just want to patch for myself, I want to understand it and fix it for everyone.

1 Like

You posted them from your XML.

Boy do I feel stupid!

Many, many thanks. I will fix the device file and submit a PR.

I’d make it it’s own XML file, you’ll need to modify the manufacturers xml as well.
Ie: yrd110.xml

I thought the same…

It worked perfectly. I’m going to contact the guy who changed it and see why. Then we can collectively make sure it is appropriate.

Likely because it effected their newer lock so you have to suffer :stuck_out_tongue:

Excited to see that someone has a fix in the works for this issue, I had to drop back to the built in 1.4 integration because of it (I have automations to automatically lock doors that weren’t working due to the missing status updates and nobody in this house locks the door anymore since they got used to the automations…)

Time to condition them with the siren :wink:

Alas that also won’t work if the automation can’t tell if the door is unlocked :yum:. Although I could just make one go off (and have the Alexa devices blast “lock the door” over and over on repeat) every time the door is open. Or just enable polling on the lock, but that seems barbaric on a battery powered device…

1 Like