From what I can see it looks to be roughly the same, apart from a slightly longer ping time of 10 in CocoHue.
That said, I only have my hue dimmer switches through AH, not my groups and scenes. Not sure if that would reduce the data being sent back from the Hue bridge.
With debug logging on AH, messages seem to come through as individual events..... maybe it's the polling in CocoHue that is producing the large message?
I use WebCore to handle the automation of the lights thru httpPut calls directly to the Hue Bridge. The CocoHue Groups on Hubitat will then have to wait until the next poll to be updated. As my house is completely over-automated, I've occasionally run into problems caused by this delay in the updating of the CocoHue devices (caused by the Hue Bridge not pushing events). To reduce my server load, I choose to have CocoHue poll the Bridge only every minute.
So....I added the following a new command, "setSwitchState" to my CocoHue Groups device code to allow me to immediately change the switch state of a group when I send I command to the Bridge. You can call the command in WebCore and in RM after turning the group on or off via an automation. Just send a string param of "on" or "off" when you call the command.
In the metadata of the code, add:
command "setSwitchState"
and in the body, add:
void setSwitchState(newState) {
if (device.currentValue("switch") != newState) doSendEvent("switch", newState, null)
}
In my code, when I receive an update for a light, I push a refresh, so that I can get the group updates. I recommend asking for such a feature from coco hue if it doesn’t do similarly. I am sure the developer is open to enhancement ideas.
Yes, that was another option, but this has the advantage of not updating every one of my lights, groups, and scenes.
How so? The event stream from hue does not send all the changes for groups and lights when a group is updated. A refresh forces all devices to update /sync up with hue. So, what I do, is I queue up a refresh to run 250ms in the future for the whole hue system. If other messages are being processed, the refresh canceled and a new refresh scheduled so that the last refresh happens 250ms after the last message is received. As long as you aren’t using hue animations that change something very aggressively this guarantees all devices are updated.
I have a pending update that when a group is updated, that I refresh all the lights in the group, and another that when a light is updated, I refresh all the groups that the light is in, so the updates require less overall processing and run faster, but this only serves to reduce HE hub load, and doesn’t impact processing.
Either way, this is off topic now. I have not looked at coco hue code. What I do is to parse one line At a time, and to queue up the messages to to processed shortly after receiving them. It is possible, that I did this because of how a hue sometime breaks up messages and sometime aggregates them, and this ensured a consistent solution to simplify parsing. Maybe that is where they differ and where issue arises? Maybe it has to do with how many devices and groups are changing at once?
Without getting into the details, you cannot deny that my solution is substantially less chatty than sending two separate commands to the hub. More importantly, the state change is instantaneous.
I am not challenging anything here. I am just trying to provide some additional insight. The how so (typo had it as how do) was in regards to the less updates reference. I am just curious.
All,
I've just released an update, version 4.1.3, with some changes that mostly affect group processing (but could affect any time the eventstream includes multiple devices in the payload). So, if you were one of the people who noticed group states were not updating on/off or other easy attributes (so not necessarily RGB color...) right way, this should help. 
(Thanks to the user who noticed the underlying cause, who I don't know if is on the forum.)
As usual, for updates, you can:
Let me know if there are any issues!
Can you use a CocoHue scene as a trigger in Rule Machine?
If activated from Hubitat and done via a button commands like push(1), yes. Other methods (e.g., switch state) or activation from outside Hubitat are less reliable or won't work at all.
I think that the last update has caused a problem with Hue groups in Motion Lighting. I have checked my logs and Events, which show that CoCoHue is turning groups back on milliseconds after ML turns them off. Let me know if you need any logs, I can send you whatever you need once I’m back at my computer.
Interesting. I'm not using Motion Lighting, but I'm not able to reproduce this by sending an "Off" command to the group, which I imagine is all ML should be doing, too. For troubleshooting, the most helpful pieces would be Logs isolated to the CoCoHue Bridge device and the group device in question (the app or "member bulb" logs may or may not be helpful too if these aren't alone, but it would probably be cleaner to start with that).
Sorry, I forgot to say debug logs with debug logging enabled! However, even with just the Events page, it looks like something is calling setLevel() on the device, thus turning it on (is that app Motion Lighting?), though I can't tell why.
I’ll have to get back to you on this. I switched back to 4.1.2 for the bridge driver and the problem is gone. It looked like the call to turn back on was coming from the bridge. As soon as ML turned off the group, it would be on at 1%.
Have you integrated the Hue Sync Box to CocoHue?
I've been reading on other threads that you might have.
Someone else did a while back, though I do not know if it still works. I have never worked on this myself, nor do I have a Sync Box to write or test an integration with. But maybe some day.
Was pointed here from posing a question elsewhere.
Any plans/ideas for dynamic scenes? Right now I use a "wake up" automation
I addressed this question in the other thread already:
Sorry I guess I meant to include in my question moreso about the timing. The v2 api appears incomplete but encouraged to be used, and so from the integration side is there any sort of timeline/is it a maybe/etc.
Download the Hubitat app
