I am have been a user of C8 for a few years. My setup included a 10 year old schlage z-wave lock on my main door which worked great. Recently, I replaced the worn out door and bought a new lock to match the door color.
The locked paired without a issue and can be controlled via Hubitat C8. Several switches nearby so communication is not a problem.
The issue that I have is related to the reporting of the manually unlocking of the lock. I am not generating a physical unlock event. Instead I get this event -> Front Door was unlocked [digital].
My expectation is --> Front Door was unlocked [physical] This is how my previous lock works.
However, if I look at the log, it shows the physical unlock and some other unexpected stuff.
I have rebooted, repaired, included, excluded, but no changes in behavior.
I was using the physical unlock event in RM as a condition to keep lights from turning on when I left the house.
I now know that Schlage is no longer on the supported list, but it also looks like it is very close to working. Since the 10 year old schlage z-wave lock worked so well, I did not think to check the supported list.
Any Ideas on how to get the lock to report the physical open?
I have no Schlage knowledge but for my Yales, the "thumb turn" is a code number outside of the settable range. If my lock supports 255 "slots" for codes, then code 256 is what is used for a 'thumb turn'
What I'm suggesting is that the WORDS may have changed in the code on the lock and you just need to understand the new logic it offers.
Yes, it shows in the log but it does not trigger an event. Below is the one entry in the event log. My observation is that there is an inconsistency between the log and the event. Is this the function of the driver?
Also note the duplicate entries in the log generated at the same time.
I tested both 1 knob turn unlock and 1 knob turn lock 2 minutes apart. Here is the log. The events show only a digital unlock and lock. My expectation is that the EVENT would be a [physical] unlock and lock.
The logs are a bit hard to follow because it's not clear what entries correspond to what real-world events and how many of them. But it would also be good to enable debug logging so you can see more about what the lock is actually reporting to the hub, not just what events things are getting parsed into; that would be the best clue as to whether there is any data to work with in the driver.
That being said, it sounds like this is a new lock. There are various firmware versions for these devices, and it's possible they do not all behave the same (there are definitely some Z-Wave differences, as people have had various luck depending on that -- just not sure whether this trickles higher up the stack where we're looking, too). These devices are not on the official compatibility list due to some of these oddities, some of which again may be related to firmware. You may have just had different luck with the others than with this one, so you might just need to tweak your automation for this device. But the above, and debug logging in particular, will give more clues if you wanted to see whether there's anything the driver can do to help.
In addition to what @bertabcd1234 asked for (debug logs), is “command retry logic” enabled for this lock? If it is enabled, can you disable it - the logs in your first screenshot suggest it is enabled.
I will enable the debug logging when I get home from work and respond. The real world event was ONE physical turn to unlock then two minutes later ONE physical turn to lock it. Yes, each turn generated 3 sets of entries in the log-always and one entry in the event list (at least the example provided). I have seen some inconsistent behavior in the event list.
I have four of these locks all using the same driver as the OP. All have the same issue of physical unlock/lock events creating a digital lock/unlock event in the event log. C8 on 2.4.1.177
OK, just to be sure what I'm looking at: a single physical unlock spawned 30+ seconds of log entries?
You might also want to compare the firmware versions of the two devices, likely under the Device Info tab in the Device Details table. Nothing you can do about it (older ones aren't upgradeable; not sure about the Plus models, or if they've ever released any even if it's technically capable), but it could explain some of the differences.
Not 30+ second. 10 seconds (10:47:20-10:47:30) with detailed logging on for just the unlock (once). The last entries are me locking it again. This lag was not seen in my unlock log posted previously, but now I noticed that the delay was present in the locking (same screenshot).
Interesting observation. How do we determine if the lock is sending multiple signals or Hubitat is? What is a payload number? That changes. These AlarmReports and Event Parameters are also of interest.
Yes, the firmwares are different. The other lock is 10 years old. The new is on firmware 0.11.0. Schlage support won't tell me the date associated with this, and I could not find anything on the internet.
Thanks for looking.
Looking into this driver a bit, there should be an "Ignore door operation reports" preference you can enable that will take care of some of the Z-Wave messages that appear to be a good chunk of the issue. Those will always get parsed as digital events, so if this is in response to a physical event as you say, it should eliminate that problem. (I don't remember exactly what this preference was added to address -- it was just added a couple years ago, not there originally -- but I imagine it was some issue like this and again suspect it's probably related to device firmware versions and resulting behavior differences.)
There are still a few seemingly duplicate AlarmReports, which based on your data are (correctly) getting parsed into the "unlocked by thumbturn (physical)" events. That's still odd, but it shouldn't cause any problems without the other events getting in the way, as the actual events are likely to be filtered out unless some app is specifically excluding that default behavior in its event subscription for any of your automations.
I might also rule out something on your hub: check "Events" and see if any of your apps are sending a "refresh" or additional commands in response to some other event that might cause this. The "In use by" section on the device detail page might also be useful to look at and get other ideas.
Otherwise, I wonder if it's just some oddity of this device and its particular firmware version. Another possibility is something with your Z-Wave network, like "ghosts," the particular repeaters in the path of this device, etc.
But hopefully the above preference helps with any practical implications of this behavior!
Yeah, my guess is the same as the above: that different firmware versions and hardware versions of these might do slightly different things. Mine don't do it, either.
I don't think I actually have any of the BE469ZP, just the BE469, for what it's worth -- though if that's accurate, I just realized that the claim in the original post that the 10-year-old device is the same model can't be accurate either, as the "ZP" (Z-Wave Plus, I assume -- and in any case, that's what it is) model wasn't introduced until 2019 or so. More fuel for the above explanation.
