I'm new to Hubitat, switching over from SmartThings so I can maintain my Groovy app. I noticed that my Groovy app isn't functioning correctly with Hue bulbs. After doing some digging I narrowed it down to how Hubitat has to poll for Hue device states to maintain the correct state if it changes from a source other than Hubitat. I saw in the integration app configuration that the polling is set to one minute, however, the state doesn't appear to be updating within that minute timeframe (or at all) like it is supposed to. I also tried changing the polling rate to 10 seconds to see if it would help but had no luck. The switch state being inaccurate is causing issues with my Groovy app. Does anyone have any ideas on how to fix this?
I just did a quick test and my 1 minute poll took about 1 1/2 minutes to refresh. The web page won't show it but the refresh does happen. If you reload the device page you'll see it.
1 Like
Iād try using the CoCoHue app as it has the experimental v2 of the hue API that might be able to help. @bertabcd1234 knows way more about this stuff and could go into more detail about how it works.
Either polling isn't really happening as scheduled, or the bulb data isn't getting parsed correctly by Hubitat despite the poll because of some oddity, most commonly the bulb (or room/zone) being in XY color instead of HS or CT mode, which are Hubitat's native color/color temperature models and which are difficult to reliably convert. This tends to happen if you recall Hue scenes and use third party bulbs; all Hue bulbs I've seen report CT or HS eventually (and accurately), even if they are in XY mode internally, but third-party bulbs vary.
Enabling debug logging on everything will likely show more. Scheduled jobs on the App Status page of the Hue Bridge Integration app would also let you know if that job really got scheduled (you should see something with a cron schedule representing your selected interval). This should get scheduled if you hit Done in the app, one thing I'd try if you didn't (or either way--it can't hurt).
That being said, CoCoHue is one way to work around this by using the experimental v2 API. 
(But the XY color thing is a problem either way...)
1 Like
I tried this and made sure to explicitly refresh the page the morning after you posted this, although (I think) I refreshed the page before and definitely waited several minutes, and also saw in the logs that it wasn't changing. After doing this the next morning I did not see the issue, but at the same time, I didn't see the issue in my Groovy app I was seeing before, so I'm wondering if it was fixed by me toggling the polling rate.
The app I wrote is an advanced motion lighting app that turns on an app with motion, but only if the light wasn't turned off before the motion inactivity time limit was reached (and has a number of other features that are unimportant to the context of this). I was having issues with the lights not turning off when they should, and issues with the lights turning on when they shouldn't. The issue with the lights not turning off hasn't happened since I noticed the light states were updating. The lights turning on when they shouldn't turned out to be related to the event history limit (because the app utilized logs to determine if the lights were turned off before the inactivity limit).
As of now I don't know if this was the solution, but it seems like it is the closest to the solution, so I am going to mark it as so.
