Fair enough, here in Australia you do get a discount, but they donāt care what system you have and donāt require proof of it being certified.
1 Like
Install the reliable lock app. That said, the ultimate failsafe is use your key to lock the deadbolt
1 Like
It's not a security offering, we have never said that it is, and furthermore have said numerous times that it is not. Here is one more such statement.
We do not recommend using Hubitat Elevation as a security system. That's not the intent of Hubitat Safety Monitor. It's intent is to provide very basic monitoring and notification about certain smart devices. None of the smart devices being used rise to the level of common security devices, at least not any we're aware of. Battery powered sensors? Wireless devices using mesh networks? These aren't true security devices, so HSM is not a security system and should not be relied on as one.
There are valid reasons that we don't retry commands, some of which have been stated above by others. As you've proven, you can do this yourself if it's important to your use case -- we provide you the means to do so. You have to bear in mind that "your use case is not my use case". It is unwarranted to impose your particular views on these subjects on all users.
3 Likes
Well played sir! 
How is asking for reliability features to be utilised* in a system that manages a ānetworkā imposing my views?
*ack is a core feature of any network, including Zigbee.
I was referring to your specific suggestion above:
If you want 3 time retry, you can do that. This is not something we find acceptable to do for devices that don't respond.
1 Like
The thing is, Hubitat knows when there is a failure, itās part of the Zigbee spec. All Iām asking is for the Zen thermostats at least, Hubitat does something with that info.
Wireless control, however, doesn't usually have the same remedies normally associated with a cell phone call, of moving to find better reception, or waiting to try back later. The ZigBee Alliance understands this, and so the ZigBee specification reflects this need.
ZigBee uses a 16-bit CRC on each packet, called a Frame Checksum (FCS). This ensures that the data bits are correct.
Each packet is retried up to three times (for a total of four transmissions). If the packet cannot get through after the fourth transmission, ZigBee informs the sending node so something can be done about it.
https://www.sciencedirect.com/topics/computer-science/zigbee-specification
We don't know why any given device does not respond at any given time, and have no way to tell. It could be a stupid device that doesn't wake up properly (e.g. Zen), it could be a dead or weak battery, it could be a weak or damaged mesh, it could be transient RF conditions, it could be any number of things. Retrying could be a good thing or it could be a bad thing to do in any particular circumstance. There is absolutely no guarantee that retrying will remedy whatever the problem is, while it might in fact make things worse in other ways. Those are the reasons. It has nothing to do with the Zigbee spec.
3 Likes
I had a look at this and it seems to be oriented to locks that donāt always report their status correctly, rather than locks that donāt receive commands and need a retry.
