Thermostat Scheduler query

Fairly simple question, does Thermostat Scheduler ensure requested state changes are carried out and resend commands if they aren’t?

Last time I tried it it didn’t.

I have a pair of battery powered Zen Zigbee thermostats that don’t always do as they are told. As a result I’ve had to build rules with checks and repeat logic to ensure things turn on /off when they are supposed to.

PS running 24VAC to them isn’t an option for me.


No, generally no built-in apps check behind devices to make sure they carried out the commands sent to them.

This seems like an oversight, especially given the stateless design of HE.

I never have this issue with zwave devices, but for some reason Hubitat Zigbee drivers don’t bother to check that a command was received and executed.

I’ve seen this behaviour with my Zigbee door locks from Yale too.

FWIW I’m using channel 25 and I have an external antenna.

You knew I was going to suggest that you need to strengthen the Zigbee mesh. I will still do it, anyway :-).

More often than not, people have missed commands on the Z-Wave side, because of weak mesh. Missed commands are 99.9999% a mesh problem or device problem, or a combination of both.

I have 25 devices in my Zigbee mesh, 20 of which are mains powered. That averages 2 in each room of my 4 bedroom house. I really don’t think more devices is the answer.

My zwave network is double that due to every room using Aeotec nano switches or dimmers.

Not at all, it's intentional. Think about this: if you have a weak mesh you want us to double the traffic on it? That makes no sense. Strengthen the mesh so this is not an issue. Users with solid Zigbee meshes do not report missed commands to thermostats.

I have a very solid mesh, heck my upstairs thermostat has actual line of sight thru my study doorway to my C7 and still misses commands. It’s 3 meters away!

Downstairs looks good too:

My mesh is good enough that my mailbox Sensor, 15 meters from the front of the house, works just fine.

Both Z-Wave and Zigbee manage their routing tables, and what seems straight forward path to our naked eyes, may not alway be what the radio thinks is the appropriate routing. Your device may route through a different device even if it's sitting next to the hub. The quality of all nodes in a mesh is critical to its overall performance.

1 Like

It’s only the 4 battery powered Zigbee devices I have issues with, everything else is perfect, including my battery powered Iris v3 security key pad (which is right next to the front door lock).

To me this strongly suggests the Hubitat drivers for the Zen and Yale devices are not ensuring that the device is fully awake before sending commands or that they are not checking for the Zigbee acknowledgment responses and operating in a fire and forget style.

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.


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.


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.

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


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. :man_shrugging: