If you’re polling every device every 5 minutes aren’t you significantly increasingly network load and so in danger of creating mesh collisions and drop outs that way? Not to mention possibly increasing energy usage? And in physical fixture arrangements (multiple smart bulbs physically close together) isn’t there a danger that multiple zigbee end devices have chosen the same parent, potentially overwhelming it?
My understanding is that the whole reason for push sensors is that mesh networks are inherently bad at supporting frequent polling use cases. Fixed traffic architecture is a much better match to those requirements. Lots of factory floor installations take devices that need to be polled frequently out of the mesh network altogether and hardwire a hotline to devices that require frequent state checks from the control station (as opposed to push updates from the end device).
I just bought my first Hue Lux to replace a GE Link in one of our lamps as its a nicer white. But can’t get ST to see it nor will it see my Hue Hub to start discovery!
Really looking forward to seeing the new version of the App with better Hue control as they are a core part of my ST setup!
Also…in the Zigbee Pro standard which will form the basis of Zigbee 3.0, a failed delivery will result in the parent resending the message 3 more times. So polling a device which is off generates 4 times the traffic you expect at the parent. Keeping the parent busy with multiple (and perhaps overlapping) poll requests could degrade the network in that area. Add high density node areas as is typical in lighting installations and it could get really bad.
The alternative to coordinator based interval polling is a smart switch that creates a “turning off” event or even a “maybe turning off” event that THEN triggers a hub poll (limited to one time) of the devices controlled by that switch.
There are lots of ways to do this, depending on the type of switch being used. Obviously something like the ACTion dashboard or the ST app itself can do it easily when the off request is received.
Secondary controllers like the Aeon Minimote can do this by placing each off request in a scene that initiates the one time poll after a 5 minute delay.
Dumb switches like a retrofit lamp switch can still be captured as a “maybe turning off” event through a nearby proximity sensor that triggers the one time poll. This does mean you’ll poll anytime someone moves close enough to the switch, but it’s still a lot better than interval polling.
Granted, these smart switch approaches all require user education if only for device deployment. But most consumers can understand that they would need to install a smart switch OR physically lock the dumb switch if they want to always know accurate status. And network load will be much lighter.
BTW, Philips recognised exactly this issue and addressed it with a smart switch: the Hue Tap. Not with interval polling.
Hi @JDRoberts, In this case the polling is to the HUE bridge that is a LAN device to get the status of the bulbs. You can request every second but this will increase the load on the cloud side and not your setup .
@juano2310 My hues are not updating their status correctly when turned off via an external app. A refresh is only bringing over the current color, not the current state of the bulb. Is this being addressed in the upcoming release?
Hi @jodyalbritton, I discovered that if the name of the bulb was changed by the user they lose reference and they stop updating correctly. I’m working in a solution as well as adding new light bulbs.
@juano2310 Is it related to that? I have never ever changed the name of my bulbs and to the extent that the names are same as in hue site. But I don’t think it ever refreshes the state as of now if triggered by third part app. Do you mean that in the next update? If what @jody.albritton is talking about can be achieved it will be a great step. We are so anxiously looking forward to the update that you all are talking about.
Is there currently a fix for this? I don’t have my hues tied to any smart apps, I could easily delete them and bring them back into ST. I did change the names after bringing them over so that makes sense.
@smart@juano2310 As a test, I deleted all of my hue bulbs and the bridge. I set the names to what I wanted them to be in the hue app, and then I re-added them to ST. As of this moment it appears they are picking up on changes that I make outside of ST. I can turn them off via the Hue app and the status is correctly reflected in ST. It is not instant as you have to go back to the dashboard and it allow a refresh, but it does eventually sync up.
From stuff George Yianni has said in multiple places, in at least the original Hue Bridge release they rejected forced polling of the end devices because of concerns about network load. So the Hue Bridge status could and did lag behind real world state when end devices were turned off with a dumb switch. That was exactly the issue the Hue Tap was supposed to address. The bridge does limited polling, so that eventually the bridge gets the end device status, although it could have gotten out of synch again in the meantime.
So frequent interval polling by ST of the Hue Bridge still wouldn’t give you true real time end device status, since the Bridge itself isn’t necessarily current. Only replacing dumb switches with smart switches fully captures switch change states.
Or has the Hue Bridge introduced forced polling? And if so, doesn’t it raise the same load issues, at least within the ZLL mesh?
@JDRoberts this is correct, we poll the bridge for the information it has. This doesn’t mean that this force polling of the end devices nor that the information is accurate for the examples you mention.
The only assumption we make is that if the bulbs aren’t reachable they are off considering that the power source is off. I will meet with HUE engineers next week to talk best practices and improvements.
Polling is the only way at this point. Hue does not have a mechanism available in the API to send a rest request on state change. It has been frequently asked for, but they have only said they are aware of the issue and will make no forecast as to when they will fix it.
I tested the Harmony/Hue integration. It is also on what looks like a 5 minute poll schedule. The only way around it, is to shorten the polling interval.
Ok… I checked. For some reason not all the hues are polled at regular intervals. If it gets polled in the 5 minutes period then it shows the right state then. Cannot confirm or concur for sure.
Update: sorry to say @juano2310 it does not work as expected. They do get missed. And another thing to note is that not all of them are polled for some reason.
@smart, I think that I have to dig more on this issue before I have a definitive solution. @jody.albritton increasing the polling wouldn’t be possible right now because this will increase also the traffic to the cloud, maybe in the hub 2 we can do something locally and only update cloud when it changes
The highlights of thats there is:
Hue connect has both Hue Groups and Hue Bulbs (Working on not getting it to add each group twice)
Hue transition time from the API is included in the device types.
Hoping to bring in timers and alarms from the API into the apps.
If anyone is interested on helping out or have any suggestions for me, please let me know.
