I would expect when you run a refresh it would actually refresh the state of the lock. I have had my lock get "stuck" in the locked state after it is unlocked by a rule in AM a few times so I was going to add a delayed refresh to my rule to make sure it syncs up with the lock. Testing the refresh command though while the state was wrong, it does not update it.
My lock has been left unlocked for DAYS because of this issue. When my night rule runs I am using the mirror app optimization on the locks so if the lock says it is locked already there is no commands sent to it. I just turned the optimization off but I think its going to cause more issues when I run that tonight.
This is all get from a refresh. Why is it getting the version info every refresh? Seems like a waste on a battery FLIRS device. Should just be getting device state and battery, nothing else IMO. Configure could get the version report.
Here is a successful lock command, which has a delayed refresh built into it apparently, but like I said, it is not even updating the state so it is basically worthless. Unlock is basically the same when it reports back correctly.
Just checked the driver, and it sends a DoorLockOperationGet as part of the refresh (along with battery and version--not sure why on the last one but assume there is a reason someone put it in, and while it might use more time for a FLiRS device, the real solution to any concerns about that would probably be avoiding the refresh in the first place ).
In any case, that should fetch the current state. Why the lock doesn't seem to be responding to that with a report, I don't know... FWIW, the Generic Z-Wave Lock driver does the same as part of a refresh (minus the version get), so if that doesn't work for you, either, it seems likely that something is odd about the device.
Yes, a refresh 10 seconds after sending the command was added at some point in the history of this driver, possibly because it doesn't report back on its own. (Even more mysterious why neither of these does anything...)
I don't suppose it's possible that lifeline association got lost or something? The driver only sets group 2 explicitly, but group 1 should happen on inclusion and shouldn't change unless maybe the device had a firmware update that broke it or something. Just trying to think of anything it could be without having one of these devices myself to test.
Just tried this test : lock is locked, remove 1 battery, unlock, wait 10 seconds, refresh doesn’t update the state to unlocked, but calling lock does lock it again…
What firmware are you on ? 1.05 here.
Might want to email their support, they were pretty responsive last time I did.
Yeah thats the issue, for some reason the refresh is not getting the door status. If you turn on debug it will show everything the lock is sending back.
@bertabcd1234 it looks like the only events mine is reporting is the notification report, not "Door Lock Operation" reports. Is that command class deprecated maybe (I checked specs and it does not seem to be)? I am thinking the refresh might need to ask for an update on the notification class.
In the Alfred app mine is showing firmware DB1V2.01 ? and no updates
Unless there is a z-wave firmware update that has to be applied via z-wave OTA?
I dont use the keypad on this lock very often its mostly just locked when sleeping and open all day (between house and garage). It is sort of a PITA to unlock from the outside, the keypad is confusing for people and the auto unlock never works right.
I am sending battery and the door lock with a 400ms delay.
I tested some different notificationGet commands also but was not getting the right events back. Would probably need to ask for all 4 lock event states but I gave up when the normal report seems to work fine. notificationGet is always hit or miss with "push" notification devices.
Obviously the batteryGet and secureCmd call other functions but you get the gist. These are NOT being sent as supervised commands. Does the Alfred driver do supervised or unsupervised for these?
I compared that to my (much more helpful) debug logs and can see that is the door lock report. So the device is sending the report but the driver is not doing anything with it???
Generic Z-wave Lock does not log the type in the events for the Alfred (digital / physical). This breaks one notification I have setup for physical unlock only, but it is not critical. My Yale using the same driver the type is reported correctly. The Alfred seems to actually respond faster using the generic driver as well, but possibly just because my mesh is pretty quiet at the moment.
No, there's definitely a handler for the DoorLockOperationReport (and I don't see how it could be something odd like a version mismatch either since it's all V1).
But something odd must be going on. I'll do some digging and see what I can find.
I am using v3 in my handler on my test driver, if this helps you at all.
And also look at the Generic driver, that one works fine too.
void zwaveEvent(hubitat.zwave.commands.doorlockv3.DoorLockOperationReport cmd, ep=0) {
logTrace "${cmd} (ep ${ep})"
switch (cmd.doorLockMode as Integer) {
case 0xFF: //Secured
sendLockEvents("locked"); break
case 0xFE: //Unknown State
sendLockEvents("unknown"); break
case 0x00: //Unsecured
sendLockEvents("unlocked"); break
case 0x01: //Unsecured with Timeout
sendLockEvents("unlocked with timeout"); break
default:
logDebug "Unhandled DoorLockOperationReport: ${cmd}"
}
}
If you need to add an extra debug log in the handler and put it in the next update, I can test it further and give new logs. I also think Mike has one of these locks if I recall correctly?
OK, I see what's going on. The DoorLockOperationReport is getting skipped (at the very beginning of the handler, so you don't even see it logged) if state.bin is not 2, which I never see how that would even get set to that value but I think is supposed to happen as part of refresh() (matching some Z-Wave dimmer drivers, for example -- likely a way to handle this only when that was the cause for the report). Locks/unlocks are also handled as part of NotificationReport in this driver, and those are the only ones that set physical vs. digital events. Without having this device and basing this only on how the driver was written, I'm assuming that's because that's how normal locks/unlocks come in.
This would be a quick modification that could end up in the next 2.3.9 if that sounds right...
Ok so the physical/digital is only able to be determined from the notification report because the door lock report does not tell you enough info. The driver is not using the bin -1 or whatever to determine if a command was sent so its in the dark for the door lock report. That makes sense.
So then you want to primarily rely on only the notification report to make sure you get the digital/physical logged, which is important for locks especially. The door lock report is a backup only, hence the bin 2 check. So I think the fix for that thinking would be to set bin = 2 when the refresh is issued so that the handler will work.
I do see the door lock report comes in first, so it makes sense to normally ignore it and wait for the notification report I guess.
I don't really love that solution, but if that's how it was designed to work and its an easy fix then it is better than not working at all.
Ideally also the delayed refresh would be canceled if the door reports back the expected state change before the refresh fires. To avoid extra FLIRS beams when not needed.
Also ideally I would like it to handle either event at any time and just slightly delay posting the door lock event so the notification event with the type designation can take precedence. I think this is something I would explore on my own driver anyway, which I see I may need to make.
The next 2.3.9 (and eventually 2.4.0) will have the change above to make refresh() work, which I think was just an oversight in the original development or perhaps an accidental removal in later refactoring (I didn't look at the history, just what it's doing now -- or not doing, as the case may be).
I'm afraid to touch anything else, neat as the ideas may be, since I don't actually have one of these and am afraid I'd mess something else up. Other than actually handling this report in this case now, this change shouldn't affect anything else about use of the lock.
).
