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.
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.
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)
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"/>
</TriggerRefreshValue>
</CommandClass>
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.
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…)
Alas that also won’t work if the automation can’t tell if the door is unlocked . 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…