Hmm, this IS the message I get when I click on the device.
I know it's not supported ... Schlage Z-wave BE469 lock.
I use the same-named-driver provided by Hubitat.
This lock used to work fine, some years back, on my Hubitat C7. I could lock, unlock, change code, check status, you name it.
Then, after a Hubitat platform upgrade I lost the Hubitat controlled lock and unlock function, but I could still 'see' when it was manually locked and unlocked. I had automations that were based on this and they worked as recently as a few weeks ago.
Now, I can't even do that, and all my automations no longer function.
Yet, the lock appears quite solidly resident on my Zwave system and the Hubitat registers at least some sort of message when the lock is manually operated.
That's why I am looking at the debug messages. If the lock is sending a Zwave message and the Hubitat sees it and logs the message, which is clearly occurring, why can't I use that to trigger an automation, like I used to be able to?
Is it the ZP or NP model of lock? I have 3 BE469ZP locking still working fine on the current platform version.
The alarms are possibly the break in alarms built into those locks. I could look up those codes in the z-wave specs tomorrow morning and get back to you.
They’re just a capture of the zwave alarm report (https://sdomembers.z-wavealliance.org/document/dl/634) useful for the driver developer but unless you’re rewriting it nothing you can use to trigger anything. Best place to determine automation trigger possibilities is to look at the events recorded on the device’s event tab.
Wow, your post gives me great hope! I have two of the BE469ZP locks.
I have one as S0 security and the other with none, just in an attempt to see if that matters at all. My Zwave mesh is fairly 'dense' and both locks appear in my Zwave table with 53 and 56 neighbors, respectively, and no route changes. They connect at 40 kbps however.
As mentioned, maybe 18-24 months ago they were both fully controllable by Hubitat. Over a series of Hubitat platform upgrades, they became more and more not-controllable, with the final loss of function just recently.
Most locks refuse to work with no security.
Also, mine are paired with S2? You must have very old models, I thought all the 469ZP supported S2?
Unless you migrated from a C5 which could not do S2 security?
Both locks used to work with no security set up. I did that because they seemed to work faster that way and I have no need for 'security' communications modes.
I only added the security when the lock automation started to not work.
Changing this is kind of a pain as I need to relocate the hub near the lock, and also have the SiLabs-stick-equipped ancient laptop set up to extricate any ghost nodes I inadvertently create.
If the lock posts the event but the rule does not work, thats an issue with your rule then, not the lock.
If you want the locks fully functional again, I hate to suggest this because these locks can be problematic to pair, but I am thinking you may need to exclude and pair them again. BEFORE doing that though make sure you have the Programming code info and the security info (if it supports S2). Both are stickers on the back of the manual for mine, and also the programming code is on the back of the lock, the security DSK and QR code is on the metal backing plate that mounts on the door. Hopefully the mounting plate is the original that goes with the lock attached to it.
Yes, the unpairing, removal, and re-pairing is a pain. The un-pairing always also requires the SiLabs utility to truly get rid of the lock otherwise you have this zombie, it doesn't 'go' through the regular removal process.
Here is the rule I have, which hasn't been changed since it was created a long while ago. Since it used to work I did not want to create yet another variable in the problem solving chain.
