Has anyone tried this Z-wave LR lock? It doesn't appear that Hubitat is listed as one of the compatible hubs. Not sure if this was an accidental omission.
I can't imagine it wouldn't work with the Generic Z-Wave Lock driver; depending on where you saw the compatibility list, the seller may have simply not tested it with the hub (I doubt the manufacturer has...).
If not, Z-Wave is fairly standard, and it should likely be easy accommodations.
I've tried using it with the Generic driver, and the driver is throwing internal errors:
java.lang.NullPointerException: Cannot set property '1' on null object on line 617 (method setCode)
java.lang.NullPointerException: Cannot get property '1' on null object on line 502 (method parse)
Turn on debug logging and reproduce the errors. Debug logs should show what message it is trying to parse. Post a screenshot of the logs please.
Also what hub model and what platform/firmware version?
Hi, @jtp10181. I'm running a C-8 Pro with the latest firmware (150), which I updated today before adding the lock. I added it as an LR node using SmartStart.
The debug logging was actually on, but the logs are pretty sparse from the built-in Generic Z-Wave Lock driver.
The above are the only long entries from the entire time the lock has been paired to the hub, even though I've been locking/unlocking manually from the inside, with the user codes from the outside, and from Hubitat.
FWIW, the lock responds to lock/unlock commands from the hub, and somehow it successfully handled a single status update from 'unknown' to 'locked', but it no longer updates its status at all, has been unable to fetch any codes above 99 (i.e., last code fetched is stuck at 99 after multiple tries, even though the device details page correctly reflects the lock's tech spec of max codes 250), and is unable to set any codes or actually store in state any codes fetched from the device.
First, shut down the hub and unplug for 30 seconds. Radio might be jammed up from trying to run the get codes multiple times. Also power cycle the lock by pulling the batteries.
Install my z-wave scanner driver: [RELEASE] Z-Wave Universal Device Scanner
Change the device to that and enable trace logging. You do not need to run configure or any of the other commands at this time.
Then try manually operating the lock and get a screenshot of any logs that result. This should log every incoming message, it is very verbose and easy for my to understand the messages from the device. This is to get a baseline of what the device is sending.
Then switch back to the generic z-wave lock driver, turn on debug logging, operate the lock manually and again capture any logs (if no logs try a single lock/unlock from the hub and then get logs from that).
Last go to z-wave details page, click refresh statistics button, and get a screenshot of the entry for this lock in there.
2 Likes
Hi, @jtp10181. Okay, I’ve gone through the above, and some notes:
- I’ve been unable to get any additional logs using either your driver (which is great to know about — thanks!) or the Generic Z-Wave Lock driver. All I have are exactly the logs I excerpted/screenshotted above, even after restarting the hub, power cycling the lock, etc., and then un/locking manually and with code.
- The lock/unlock commands from the hub work fine, and the Generic Z-Wave Lock driver must be following those with a poll to the device to pull its status, as the status updates correctly a couple seconds after sending lock/unlock commands from Hubitat.
- The lock/unlock status never updates after un/locking manually or with the code, however, so assuming the device is trying to push status updates to the hub, the driver must just not be handling the device’s pushed events correctly (?)
- If I Refresh, the status changes from un/locked to unknown, so the hub is getting some events but not handling them correctly? Or is the generic driver setting its internal status to unknown before starting the refresh?
- The code fetch nevertheless completed (250 codes fetched) earlier when I wasn’t paying attention (probably after I restarted the hub).
- I’ve been able to add/remove codes from Hubitat but not reliably. I succeeded in adding two codes initially, wasn’t able to add a third (device page stuck on the “requested change”), was able to delete one of the two codes, but now can’t add the same second code back (stuck on requested change).
My driver should have a command to set the lifeline association. Try that and make then see if it will send back replies after that.
Done. Setting the lifeline doesn't appear to have changed which reports the hub is receiving (battery reports, successful code adds/removes, and what seem to be the status updates that the hub pulls after the user sends un/lock commands — still no reports from un/locking the device manually or with code).
On the logging issue, I wonder if the log entries about the null pointers have somehow corrupted the device's log data so the device driver just quits listing log entries when it gets to that point (?). I'd try excluding the device and re-adding it, but I think I've seen that device logs will persist after devices are removed and added back (?).
No log entries will get removed until they naturally get purged out, but if you remove the device from the hub, there will be no "connection" between older and newer log entries, as they are tied to the hub-database-assigned numeric device ID, which will be different each time the device is added.
This is quite unlikely, if not impossible.
Did you run the setCode() command at some point here? I really don't see how at least one of those line numbers could have been reached if you didn't (whether you or an app you may have configured to do this, such as Lock Code Manager).
If you don't see anything on the hub when the device is physically locked or unlocked, it's most likely that the device isn't sending anything to the hub (a Zniffer would tell you what's really going on, but debug logging is a close second). If there were something, it would likely be something the driver could parse into an event (if it's not already), but if there's not...it seems odd.
1 Like
No log entries will get removed until they naturally get purged out, but if you remove the device from the hub, there will be no "connection" between older and newer log entries, as they are tied to the hub-database-assigned numeric device ID, which will be different each time the device is added.
I get that a device would look totally new to the hub if you delete it and create a new instance of it in the database, but would old/new devices in the database get linked if I'm using SmartStart with the complete DSK? I've been experimenting with the Ring contact sensors (g2) to try to get them to work, and I'm pretty sure I saw the logs carry over from one join to the next, even if I deleted the device from the SmartStart list and added it back. I thought it was a weird behavior but assumed maybe the devices were getting uniquely identified by their DSKs, that the hub was retaining logs for debugging reasons that wouldn't be visible to users, and that that was why the logs were carrying over from one join to the next.
EDIT: I went back and confirmed that I had seen or remembered this incorrectly — can disregard.
This is quite unlikely, if not impossible.
Okay, well, what I know is that the device continues to handle events (battery reports, etc.) that appear in the events list, and I have debug logging enabled, but the device logs that I'm able to see have not changed for over 24 hours and lots of testing.
Did you run the
setCode()command at some point here?
Yes, I've set/deleted codes a couple times from the software interface.
If you don't see anything on the hub when the device is physically locked or unlocked, it's most likely that the device isn't sending anything to the hub
Sure, and this is what I was trying to look into with @jtp10181's Universal Scanner driver. I would find it unusual if a relatively new Z-Wave 800LR device didn't automatically report status changes to the hub, but it's not impossible 
That seems more like pre-Plus Z-Wave behavior, when we had to rely on polling…
I might just see if I can find some community Z-Wave lock driver and build my own for this device. I had just been hoping there might be a way to troubleshoot the Generic built-in driver and not have to make one 
Thanks!
If the device is not reporting states back a new driver won’t do you any good.
Can you provide the data section from the device info tab please?
I would actually exclude, factory reset the device, and pair it again. See if it has a better go this time.
1 Like
Where did you purchase this lock?
Experiencing same issue as Hans above. Bought mine from Smartest House
Currently out of stock…
Yes I placed an order shortly after they listed them
Back in stock now FWIW Philips 800 Series Z-Wave Long Range Door Lock DDL240X-15HZW - The Smartest House
Did anyone have any luck getting this to work with Hubitat?
I did.
Just using generic lock driver? Currently cant even get it to pair. Performed factory reset on device as well. Struggling.
Steps im trying:
- Factory reset lock
- restart Hubitat
- Start lock inclusion on device
- Start Hubitat Lock Inclusion (generic ZWave lock driver)
- Detects the lock, click "include without security"
- Says "The device is completing bootstrapping and no further action is needed. It will show up below once joining has completed."
- Lock announces "pairing completed"
- Lock never appears as a device.
- Says "pending" in zwave details UI
