I am not aware of any changes that would affect on/off parsing for groups with any of the recent releases, particularly in V1 parsing (which has not been touched in some time), which seems ultimately like the main question above. Even if it did, duplicate state changes are generally filtered out by the app before they make it to the platform and by the platform itself unless an all specifically subscribes to an unfiltered list, so I'm not exactly sure what would be causing this issue for you, but seeing the actual logs and event history (events matter for RL; device logs don't but can be interesting if the device is not working as expected) as well as the RL logs and your RL setup may be interesting. If not related to this integration, a topic elsewhere may be appropriate, but without seeing more, I'm not sure if that is really the case or not.
I'm getting a series of these regularly on one of my Hue hubs and also it often struggles to load the contents of the screen (the rooms etc) in the mobile app. Lights are sometimes laggy or none existent and my bedroom light randomly turns on (major WAF impact).
Edit - also with debug
Any idea what I can do to fix?
The Hue mobile app? Sounds like a network connectivity problem with your Bridge. I would check that.
I do see a lot connections/disconnections of the eventstream on Hubitat, but the integration filters them out if they occur within a few seconds of each other, as the disconnections seem to be spurious. But yours are accompanied by an HTTP 408, which is an HTTP timeout, further fueling my suspicion of a network connectivity problem with your Bridge. If you don't have a reserved IP address for your Bridge, that could also help with this occasionally (though the integration will catch up after the first failure), but I don't think IP address changes can account for what you're seeing this frequently.
There's a lot of discussion on this above but is basically an occasional error you'll get when the JSON data with event changes from Hue is quite long and truncated (presumably by the hub, cause TBD, for some reason). States should catch up on the next poll.
yep i was just debugging it and see the whole end of the json string is cut off.. should i turn polling on.. since without it i dont think device states would ever catch up when this error occurs.. for me it happens when i have a light switch linked to 4 hue color downlights and turn on/off the master switch.
i only have hue bulbs and never control them directly from the hue app or outside of hubitat so really never needed polling..
also not sure if i should have the v1 api for polling on or not.. currently off and i have reneabled polling to 5 minutes.
That is up to you--and whether any of your automations depend on these states--but it is the default and recommended setting, as indicated in the UI and documentation, for that reason.
Not CoCoHue, but the new built-in V2 integration which I gather work largely like CoCoHue: I’m just about to migrate to the new integration. I have a good night automation that runs daily that turns all lights off (and I’ve only got Hue lights in the house) using a virtual switch that all RL instances are using as a means to turn off. Am I correct in assuming that I will be affected by this issue as well then when there is such a large amount of lights turning off at the same time?
No, there are no guarantees when it happens. 
I can't reproduce it on demand (one reason any troubleshooting is difficult), and just an off state might not be enough data to even make it more likely.
But it's one reason I don't recommend disabling polling entirely (unless have no reason to xare about the actual states).
Thanks. Sorry for highjacking the CoCoHue thread but just one follow up question on the built-in integration (feel free to split it off to somewhere else more suitable otherwise). For other integrations where poll is being used I have been able to programmatically trigger a poll when I know there is likely to have been a change in status. Is it possible to call the V1 poll command of the integration from RM?
A refresh command on the bridge device does the same as a poll (with either integration), so you can automate that if you want to.
Ah, brilliant. Thank you! And just to clarify: it'll do a V1 poll then?
It will use your app settings unless you call refreshV1() specifically. The default and recommended setting uses V1, however.
i found what i think is a bug.. as previously mentioned i turned on polling becuase of the intermittant error. but then i started getting these lines in the bug i am not sure if that is also an error.. but anyway, i then turned polling OFF again and it appears to not turn back off.. i still get these lines about disconnection in the logs.
The eventstream interface in Hubitat occasionally reports disconnections, whether on its own accord or because of something from the Bridge, I don't know. Spurious disconnects are the norm. If they (disconnects and reconnects) happen quickly enough together, they are ignored; if it's more than a few seconds, they are passed through as events under the assumption they might be real. Yours are just long enough that this appears to be what is happening in your case.
There's no reason polling should be related to either -- the eventstream is not used by polling, a poll does not connect or disconnect it (explicitly), and its whole use is for the V2 API, which I see you have enabled, so its continued use is normal.
That being said, if you can reliably reproduce anything related to this particular setting, let me know. So far, I have not seem anything.
I have an issue with two new Hue bulbs that I have added to the system.
I added them in Hue App, then added them through CoCoHue.
They were working for a while, but now something strange is going on. I have a button controller to activate certain scenes. One of the 5 buttons (Pico Controller) turns off the lights.
What I am seeing now is this: I can turn them on with the scenes, and off with the device as well. Something happens overnight that requires me to do a power cycle to get them to work. (HE states that they are on, but they are acutally off)
Logs:
I turn them off within HE, but then 6-10 seconds later they turn on again. And yet the lights themselves are still not on.
To reset everything, I need to do a power cycle.
Any ideas? Anything else I can supply for troubleshooting?
My original pair of lights in another room have no issues whatsoever.
I'm not sure what you can do, but that second-from-top log entry shows that an event from your Hue system is coming in showing that they are reporting as on, assuming all these logs are from the same device. That's coming from the Hue Bridge, and unless you have V2 polling enabled (the default is using V1 for polling), it's an "unsolicited" message coming in from the Bridge that would generally only be from a state change. Why that's happening I can't say, but it doesn't look like anything the integration is doing besides dutifully reporting what the Hue Bridge is telling it.
Power cycle what?
Another thing you could try is a reset and re-pair of the Hue bulb itself, though you may need to reconfigure things on the Hue and integration side of things after that (if you didn't remove it first, the Hue Bridge used to remember the ID and match it up again, just like Zigbee on Hubitat, but I'm not sure if it's still that smart).
Thanks!
I have a physical wall switch that I can use to power cycle the lights.
SHould I be using V2 polling? or perhaps turn polling off altogether?
I had this on as it stated as being recommended.
I don't think that will matter. It will just show you the same information, possibly slower. (Though that won't matter since you'd normally already have the event from the instant status updates. The issue is really why Hue is reporting that device as on if it's not...)
Found something interesting - in the Hue app, once I turn the lights off, they turn back on!
No schedules are enabled. Very strange.
Maybe best that I remove them from HE, then from Hue, and add them again.
Missing the scene toggle is something that drives me crazy. It would be so easy just use for example natural lights scene and toggle it on and off. Now I need to turn scene on and turn group off. Same thing on Home Assistant integration and with automations. Why Philips why..
Is there a possibility to add group off action to cocohue scenes sot that in automations on would turn scene on and off would turn group off?
