Wondering why the IoT class classification of the ZHA integration (i.e. the built-in native Zigbee Gateway) is only catagorized as only using “Local Polling” and if that is really correct? Is it not also also “Local Push” too depending on the device?
Does the ZHA integration not use both? …if not both then why not change to only “Local Push”(?).
As I understand it “Local Polling” or also “Local Push” is per device in Zigbee(?), and especially older devices (with old firmware / old Zigbee stacks) used to require pulling, but most newer Zigbee devices push their reports to the Zigbee Coordinator?
Note that this is also a marketing thing, as many users prefer integrations that uses “Local Push” instead of “Local Polling”. 
As such very relavant since users are confused by this and think the ZHA integration will be slow because it says it using pulling. People associate pulling with slow and delays.
The question is if the ZHA integration is today really only “Local Polling” or only “Local Push”, or does it in fact support both and it depend on the devices being used and attributes being read? So should maybe say “Local Polling and Local Push”?
I thought Zigbee supported both “Local Push” and “Local Polling” but that it will depend on what each device user uses supports?
You use push when you change state, like a switch to ON or OFF, and then use pull when you check something like power monitoring. It is confusing that the ZHA integration say that it uses pulling if it also uses pushing too depending on the command. Or?
-
Local Polling = “Offers direct communication with device. Polling the state means that an update might be noticed.”
-
Local Push = “Offers direct communication with device. Home Assistant will be notified as soon as a new state is available.”
POLLING THE LOCAL DEVICE
These devices will offer an API that is locally accessible. The home automation will have to frequently check if the state has been updated.
Advantages:
- Does not depend on the internet.
Disadvantages:
- To be pollable, a device needs to be always online which requires the device to be connected to a power source.
LOCAL DEVICE PUSHING NEW STATE
The best of the best. These devices will send out a notice when they get to a new state. These devices usually use a home automation protocol to pass it’s message to a hub that will do the heavy lifting of managing and notifying subscribers
Advantages:
- Near instant delivery of new states.
- Able to get a long battery life by going into deep sleep between state updates.
Disadvantages:
- If it does not also support polling, home automation will not be made aware of the state after booting up until it changes.
- If using deep sleep and Wi-Fi, it will suffer a delay when waking up because connecting to WiFi and receiving an IP takes time.
Compare this to the Z-Wave JS and the Matter integrations
To compare; Z-Wave JS integration is classified as “Local Push”, and Z-Wave uses very similar architecture/technology to Zigbee:
So if can only pick one or the other and Z-Wave which use similar protocol says “Local Push”, would it be better to say same?
And maybe more interestingly, IoT class for the the new Matter integration is listed as “Local Push” while the Thread integration and the Open Thread Border Router integration are listed as “Local Polling”, though believe all probably do both?
