In troubleshooting random disconnects of my Zigbee Coordinator I noticed a setting under “System Options” related to Zigbee polling which is enabled by default. While the polling concept is clear, what is not clear is in what cases it is needed.
Do only specific devices (maybe old ones pre Zigbee 3.0) need to be polled or do all Zigbee devices benefit from it being enabled?
Assuming only specific devices need to be polled, and there are none on the mesh network, does it make any difference in terms of performance/traffic whether the option is on or off?
I am guessing it is enabled by default as a compatibility measure for older or poorly implemented Zigbee devices. I wonder what the performance cost of having it enabled is and whether there is a benefit to get rid of any devices that require polling so that the polling can be disabled.
With Zwave, from what I recall, there was a real benefit. A patent prevented the switches from reporting their status change but when it expired and new 500 series devices came out, performance improved greatly by eliminating all the older devices (or at least it did on my 100+ zwave network). What is the deal with Zigbee?
As I understand it, ZHA defines it’s own polling schedule. You can turn off polling and write your own automation to do it at intervals you define, but I don’t think that would have any impact on performance (Common tasks - installation independent - Home Assistant) nor do I think you would see any performance gains.
Devices themselves aren’t polled, but the coordinator is for status and such. What the interval of that is, I don’t know.
AFAIK, there are very few (even pre-Zigbee 3.0) devices that are poll only. I honestly cannot name a single Zigbee device that is poll only. They all (and I could be wrong here) pull/push from the coordinator at some point on their own schedule and due to device triggers. That schedule is entirely up to the device as it is setup through it’s clusters (reporting).
However, with all that said, what are the “random disconnects” that your coordinator is experiencing? That might be a whole topic in and of itself. 
1 Like
@code-in-progress Thank you for the info.
I wish I knew… all the errors I see are related to some UART issue where the stick just stops talking to HA. As far as I recall this issue persisted even replacing the entire PC that runs the HA VM and even the stick (with an identical Sonoff P stick). As of yesterday I managed to disable the power saving feature on all USB ports of the computer running Proxmox VE. I read a number of threads talking about disconnects with other USB devices that were caused by “autosuspend” so I figured I’d try to disable it. In any case, the only USB devices connected to the PC are zwave, thread and zigbee (3) radios so I never want, or need those to go in power saving mode anyway.
