I have an Alfred DB2-B deadbolt with Z-Wave module. Overall it works quite well but I've noticed that the lock only reports the current lock status when it changes. I.e. if it is either locked or unlocked (either physically, or digitally via Hubitat) the current lock state reports to the hub immediately. My issue is that when manually refreshing, the lock doesn't report the lock state, it only reports the battery.
I've gone through the standard suggestions I've seen in this community such as factory resetting the device and re-pairing it. I've reached out to Alfred and they've been helpful but they believe, as I do, that the Device Handler just isn't requesting this from the lock. In their words: "The developers state to get the current status of the lock, the correct command class should be "Command DoorLock Get". The video shows the command class "Command Battery Get" being used which only reports the battery level."
This appears to he Hubitat's driver and closed source code so I have no way to verify that (I don't think).
Alfred did send me a new Z-Ware firmware for the module, just in case. I've installed this but to no surprise there was no change in the behaviour.
Ultimately, I feel that the device handler/driver should be querying the lock state from the lock. Hoping someone from Hubitat who has access to the code can check and see if this is something that can be enhanced.
Specifically, if you operate the lock manually (i.e physically) does the device page show status changes for the lock (i.e. locked/unlocked)?
If it does that then everything is working as intended. The refresh command will only show a change in status if a prior physical operation did not register at the hub.
Hi, sure. Maybe it would help if I describe what led me down this path. I have various apps that will lock the door when I go to bed, and/or notify me if the door is unlocked, etc. A few weeks back I glanced at the door in the morning and could see that it was unlocked. I looked at the device in Hubitat and the status was "Locked". I hit refresh, but the status remained as "Locked". I went to the door and connected to it using Alfred's app (via bluetooth) and the lock itself was reporting that the lock was "Unlocked" which it was. Went back to Hubitat, refreshed again, still showing "Locked".
So, I ask myself, is there a problem with the Z-wave module and it is reporting "locked" to Hubitat, or is the Hubitat driver not even asking the lock, via the refresh command, for the lock's current status and is instead reliant on real-time reporting from the lock to update the lock status? The driver is a black box to me so I have no way to answer this question.
I understand that in the device events I'm not going to see the lock state unless it changes, even if I refresh. However, in the logs, you can see that it reports the battery every time it is refreshed and the device driver is logging this. My assumption is that if the device were also reporting the lock status (locked/unlocked) that the driver would also log this information even if the state hasn't changed, just like it does for the battery - it is not.
All of the above leads me to believe, based on the little information I have available to me, that either 1) the driver isn't requesting the lock state from the device when I hit refresh, or 2) the lock isn't reporting it when refreshed by hubitat for some reason.
Totally agree. For the first issue, I also entertain the option that the lock just failed to report the status at all for some reason. This and the z-wave mesh issue are the thrust behind apps like "Reliable Lock" which creates a virtual device that wraps around the lock device and uses refreshes to make sure the lock/unlock command actually executed on the device and the device is reporting back the expected state. If the driver's refresh command isn't querying the lock state an app like that doesn't work.
Ultimately, I would like to request that Hubitat review the device driver and if possible update it to query the lock state upon refresh. Is that something you can do?
First, I have had the db2-b for two years and I have never witnessed the locked/unlock status in HE being out of sync with the lock itself. That really sucks that the HE driver page was showing you an incorrect state.
I agree with @aaiyar that it sounds like a zwave mesh issue.
Re: refresh. Since this is a battery operated device, when you hit refresh I am surprised that it actually report even the battery level back. But sure enough, I just tried it and it reported back the battery level. I turned in debug logging and it even should back the FW version etc, but no lock status.
Btw. I am in FW version 3.03. Just curious what versions you were on and what version they gave you.
I've been using two DB1s for several months, I don't remember either of them going out of sync with the hub, but beyond Z-Wave communication issues, it can theoretically happen if the lock is operated while the hub is down / crashed, in the middle of updating firmware / rebooting, etc.
I think it's possible to work around this possibility as the driver issues the lock command to the device regardless of its locked state on the hub. If the lock actually moves, the driver generates a "locked" event. I assume it's the same for unlock. To test this:
unlock the lock.
issue a lock command from the device page. state becomes locked. a locked event is fired.
issue another lock command. no locked event is fired,
take out one battery. unlock the lock, reinstall battery. state still says "locked", so it is out of sync now.
issue a lock command (state is still "locked" on hub). the lock complies and a locked event is fired.
The phone app does retrieve the correct lock status over BT... I don't see a justification for a refresh to only return battery status over Z-Wave.
So I've had this lock for maybe 3-4 months and I've only ever seen this happen one time but given the purpose of the device it shakes my trust a bit. I can deal with an occasionally out of sync device as no mesh is perfect and there can be glitches etc like something being rebooted etc, but what shocked me was the refresh not pulling in the actual lock state.
Sorry I'm not sure how to get the level of detail you provided for it, is that an app for getting device details? Mine shows the below on the device's page. Interesting that the firmware they just gave is slightly older than yours.
Yeah. The file name of the firmware upgrade they provided was ZW1797_DB2_DoorLock_US_20191018.otz. Given the date on the end I didn't have much confidence that it was particularly new lol. I'm still on the C7 as well though I have the C8 sitting in front of me, just haven't migrated yet. I definitely don't get the same level of detail you're seeing...
I wonder if the difference in the amount of data showing up could be due to the firmware version. I expect so.
Silly question - you are using the Alfred zwave driver and not the Generic zwave lock driver?
They did a change to the driver after I had my Alfred connected. I could be seeing info that the previous driver populated and the current one may not.
I'm using the Alfred driver, yes. My hub is completely up to date and I believe that Hubitat published drivers are delivered in their updates so I should be using the latest.
It is paired with S2 security, yes, and like you this is my only device using that.
Do you have that firmware version because you updated it or did it come with that?
Just wanted to add. You mentioned the Generic Z-Wave Lock driver so I thought I'd give that a try. When I switch to that one I can see it getting the lock status every time I refresh. Maybe that's the solution for now until (if) the Alfred one is updated...
