The Zen thermostat out of the box doesn't wake up often enough and can appear sluggish and or miss commands altogether, our driver resets the checkin interval in an attempt to sort this out.
As to being fully awake, Zigbee devices are supposed to wake up at least once every 7 seconds to receive pending commands from their parent router, it's the routers job (hub or repeater) to retry these commands during that interval.
I have had users report this issue with the Zen as particularly problematic when the device is running only on batteries.
None of Hubitats drivers (Zigbee or Z-Wave) check for command execution and retry if not executed.
3 Likes
Surely this could be changed for known problematic devices like the Zen thermostats?
Also, surely youād want things like door lock drivers to guarantee actions are received and acted on?
Otherwise you could potentially be sued if someoneās house was burgled due to door locks not engaging when the owner left the geofence?
Iām not saying Iād do this, but Murica is a notoriously litigious country.
I think assuming folk have perfect a zwave and Zigbee mesh and battery powered devices will do as they are told is naive.
No. Because a command may not be received (or acted upon) by an end device like a lock for a multitude of reasons, including loss of power, radio interference, transient or permanent motor failure, the deadbolt being jammed etc. etc.
Under all these circumstances, the "failsafe" scenario you envisage would still result in the lock being in an undesired state (locked vs unlocked), but jam up the mesh by repeating transmissions ad nauseum. The other zigbee coordinators I have worked with also do not verify that an end device has acted upon a command that is sent.
Unlikely for the reasons stated above are out of Hubitat's control. And the HE hub isn't positioned as a security product.
2 Likes
Iām not a lawyer but I think itās safe to assume they have looked into this possibility and it is extremely remote. Anyone can file a lawsuit here in the US of A for the most frivolous of things if they really want to. But that doesnāt mean they have even a snowballās chance in hell of prevailing.
This platform is not marketed as a home security system.
Iām not suggesting that Hubitat drivers spam the network, Iām just suggesting a sensible retry policy be implemented eg try 3 times over a given period, instead of fire and forget.
All Zigbee devices return ACKās, surely it canāt be that hard to retry if thereās no ACK received by the hub?
I would suggest this assertion ignores the existence and promotion of HSM.
https://docs.hubitat.com/index.php?title=Hubitat_Safety_Monitor
Safety != Security. Theyāre actually very careful not to do so.
When you offer āintrusion alertsā and āarmed / disarmed ā states, I think trying to argue it isnāt a security offering rings rather hollow!
You can verify and notify lock command status using an update to the mirror app that was released in 2.3.0
2 Likes
Iām not sure about Australia, but in the US if I needed a security system, I would get one that meets UL standards. Thereās a reason why homeowners insurance companies require that if they offer a discount for having one. Hubitat doesnāt meet that standard, because itās not designed to.
1 Like
I implemented my own retry logic.
Guys, please donāt take this as an attack on Hubitat, I love my C7ās, are they perfect, no. However, they are the best home automation solution on the market by a country mile.
Iām just a little frustrated that I have to implement my own rules to manage battery powered locks and thermostats.
Iād suggest that new users might find this a deal breaker. 
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.
