I sent a request to to Hubitat support on 3/20 but haven't heard anything back so I thought I would try the forum to get some help. Frequently the lock status (lock/unlocked, open/closed) do not agree with the actual lock status. I think I finally caught the problem in the log today, see the 2 screenshots attached.
At 12:28:51, I closed and locked the door
At 12:28:51.780 the lock status is received
At 12:28:51.789 Hubitat interprets the payload as door condition 1 which is door closed and locked
At 12:28:51.846 Hubitat reports the door as being closed but no comment on the lock status
I checked the device status (screenshot) and it shows the door as closed and unlocked
I then pressed the refresh button on the device page which updated the lock status to locked
At 12:32:20.163 the lock status is received
At 12:32:20.171 Hubitat interprets the payload as door condition 1 which is door closed and locked
At 12:32:20.179 Hubitat reports the door is locked
If I’m interpreting the log correctly there seems to be a problem with the interpretation of the lock status. This does not seem to be a communication problem as Hubitat is receiving the correct lock status, it’s just not responding to it correctly. Is my interpretation correct?
This almost certainly isn’t a Hubitat issue. There are threads all over about zwave issues from August. I have three and thougth I’d be so happy to hook them to Hubitat and HomeKit and get rid of the garbage connects. And then I find major zwave issues. Here is a recent thread. I’m seriously considering trashing all my august garbage and going with somethine purely local.
I'd have to dig my ST device driver up for this device but I'm nearly positive the lock is supposed to send (and does send in most cases) two separate events for closed and locked. You should see a closed there and then a locked.
Turn on the most verbose logging for the device that you can. Then separately I would test the consistency and speed that these events take place and are shown on the hub. Open and close the door repeatedly while watching the contact attribute for the lock. Then lock and unlock the door repeatedly while watching the lock status attribute for the lock. I would do each 40 to 50 times and fairly rapidly (but not too crazy). If you ever notice one of these events not come through or come through very late or repeated you can guess that this is a signal quality or mesh issue.
If they always come in consistently separately then we can run it up the chain as a potential driver bug. I have this lock (uninstalled now) but it worked fine on HE. My wife did not like the way it looked. Functionality was fine but it had a repeater within 2 feet of it.
Thank you all for the replies. codahq, you're right the lock does normally send two separate messages, first that the door is closed then that the door is locked. In the case I captured in the log, the door closed transmission is missing. What's curious is that HE responded to the door locked message with the 'door is closed'. The normal door condition sequence is 2 > 3 > 1. In the case I captured it went from 2 > 1. I wonder if the driver can't handle that condition since it's expecting 2 > 3 > 1. The last transmission from the lock was correct the door was closed and locked but HE missed the fact that it was locked. The answer of course should be to improve the communication but that seems like an issue for many. In my case my HE is dedicated to the lock, it does nothing else. They are 9 feet apart direct line of site, I'm not sure how to make it any better. I suspect there are bugs in the lock software that make this a much more difficult problem to solve.
