Polling is Hubitat making a request to a device to get the device's status and is really only necessary on old Zwave devices. In those older devices, if the switch is changed manually, it wouldn't update Hubitat. Therefore, Hubitat has to poll the device to keep the device status in app in sync with actual switch. Polling does not apply to you sending a command from the app. In those cases for both ZWave and Zigbee, it is very quick.
I have never heard polling needed for a Zigbee device. How often your TRV reports its temperature back to Hubitat could be every thirty minutes but that wouldn't be considered polling. Your TRV would be sending that data without a request. Most, if not all, of my temperature devices send updates based a set change of temperature; whether that be one degree, half degree, etc.
When you say you have polling set to 30 minutes, that is technically not polling because Hubitat is not asking for an update, it is being sent without a request in the TRV's settings.
Thanks for the useful info. Appreciated.
So, to confirm, do you think what I have described is normal the- that any changes made on either HE or the zigbee device are reflected on the other device instantly?
Also, what I've quoted below is incorrect for commands being sent to either zigbee or z-wave devices. In both instances, a command would be sent to the device immediately. What @stephen_nutt wrote is accurate.
Yes. And to more clarify what @stephen_nutt said about polling upthread, before z-wave plus there was z-wave. Due to lutron patents, they were not allowed to build in instant descriptive updates. Hubitat got around this with the polling app. Once the patent expired z-wave plus came along and as part of the spec it had instant descriptive update. So the update to on/off/dimmer level etc was now reflected instantly on a dash. Now that is NOT to say even when you send a command to non plus devices, while not reflected (lets say on a dashboard) the device does react instantly. You just don't know it. (in your case for up to 30 seconds with your older devices). Zigbee has always had instant reflective updates. Now that said, you mention battery life. One thing that helps battery life repeaters (you can't have too many). Adding a repeater between your CRV (or any battery device) and the hub will help. Any main's based device be it zigbee or z-wave repeats.
Where did you set this? On the device or in a rule?
Also I think everything stated above is a little misleading. It mostly seems to be focusing on mains powers devices, not battery powered.
If you send a command to a zwave BATTERY (sleepy/sensor) device it does not work instantly. They will wake up on an interval, usually every 12 hours. The driver must wait for this wake up before it sends the command.
Zigbee battery devices somehow are always listening, I have no idea how it works. So yes you can send a command to a battery zigbee device any time and it usually responds right away. So your concern is valid.
Zwave is actually more efficient with batteries and because of this I found they usually have less / smaller batteries. My Zigbee devices last just as long if not longer but they are using two AAA batteries.
Final note, most battery devices are Sensors, they only send updates out and do not take commands (just configuration). For zwave if you have a battery device which needs to take actual commands, like a door lock, they are a special kind of battery device called FLIRS. They actually wake up every 60 seconds.
So why do zwave deadbolts respond pretty much immediately to commands?
If the wake up interval is 12 hours?
My understanding is that FLIRS and LSS devices wake up very frequently to listen for a command. But send a periodic status update to the controller every 12 hours (assuming there is no command in that intervening period).
I guess all Iβm saying is that at least some LSS/FLIRS devices (like actuators) must listen more frequently β¦.. while others (like sensors) do not.
Yeah I added a note about FLIRS to the bottom of my post. I assume based on the original post they are comparing the battery Zigbee device to zwave sensors that are not FLIRS?
Sincerely not trying to quibble here, but I believe the bulk of those battery-life improvements are related to the 800 chip itself (regardless of LR-vs-mesh pairing).
I have no clue which (ZW or ZB) is more efficient -- as long as some device isn't chewing through batteries at whatever I'd consider to be an abnormal rate for it, I just figure it is what it is
Z-Wave LR offers up to 10-year battery life on a single coin-cell battery by leveraging dynamic power control. This new feature enables the Z-Wave Long Range device to automatically adjust and optimize the radio output power at every transmission. Dynamic power control is critical to supporting future-proof Z-Wave device installations as one of the most compelling use cases for sensors with increased battery life is the ability to deploy them in hard-to-reach places, such as attics, basements, or behind walls, to support evolving applications such as context-aware and AI for IoT technology.
Z-Wave and Z-Wave LR are also designed to co-exist on the same network, with LR network nodes reserved for new or existing Z-Wave mesh network devices to preserve both backwards and forwards compatibility and sustain interoperability between certified Z-Wave devices.
My experience so far with battery devices paired LR has not resulted in any huge gains - it's been a wash in most cases, maybe a little better in others.
As most of us have found, LR's grand promises (distance, battery, etc) have not lived up to the hype. So far, anyway.
I have two Zigbee contact sensors and I can send them config or firmware updates any time without having to wake them up. I only have 3 zigbee battery sensors total so I am just going off the ones I have and how they work.