The polling is rather intensive which is what drove me to write the advanced hue bridge integration app. It allow for a refresh plot individual groups and bulbs. This per device refresh helps keep jSON parsing to a minimum so the system can be free to deal with other things.
Over time, the hue hub 2.0 spec was released, which enables the hue hub to notify client apps when changes occur. It is not perfect but it is much better and far more responsive since the Ingres events require no polling to work.
The trade off between our 3rd party apps is that we cannot integrate our hue bulbs as HE hue bulbs, as such, the Alexa integration (for example) has hue specific logic which does not apply for our devices.
Additionally, our apps have support things that the HE does not, like scenes. With scenes, on HE, each bulb is commanded one after the other. With our hue scenes, there is on command to the group or zone and that command is to activate the hue scene. This enables a more organic feel, and lets the hue hub do what it was made to do.
The hue hub has a hard limit to how many commands it can process. If I remember correctly, that is 3 groups / second or 10 bulbs / second. So, if you have a large HE scene, you cannot put more than 3 groups or 10 bulbs in the scene, doing so can result in delayed operations or failed operations -/ another reason I wrote my integration.
@bertabcd1234 and I collaborated on the effort to enable hue event stream on Hubitat, and our products seem to be very similar. I have not used his. I believe either will prove to be a better overall experience than the native driver if you have a desire to use hue button controllers/dimmers, motion sensors, etc, or want to do away with polling.
With the event stream solution we implement, you get the added bonus of being able to use hue automations, and having the HE hub kept up to date of the changes as they occur.
