OK, I found something here. The "new" API apparently doesn't send color/CT or level events with changes to the group--no idea why, as it's still poll-able via the "v1" API. I can work around this by not ignoring these attributes when the command that generated them originated from Hubitat (I was if the new API was in use, otherwise you'd get duplicates--and still will for the bulb drivers, but apparently groups are different). I also had a bug in the group driver that always ignored these attributes anyway, even if the command did come from Hubitat and even if the Bridge was polled, so not even polling would have helped.
I'll have a second beta shortly to address this issue.
I forgot the group I thought was updating was actually a bulb, not a group, syncing non Hue bulbs using the Mirror App. Thanks for looking into this obviously better than I did.
Groups will now update color- and CT-related attributes and level when a successful command is sent from Hubitat (they were previously ignored if the new eventstream API was enabled in hopes that the events would come in through that; only switch on/off appears to do that, so this parsing was added back for all cases)
Fix for polling not updating group states
Because the new API does not send as much information for groups as is available via the old API, I would still recommend leaving polling enabled to some extent. This is practically necessary if you make changes outside of Hubitat or use scenes and care about a group state and not individual bulbs (possibly the case if you use CT scenes like "Read," "Concentrate," or "Relax" where all bulbs--effectively the entire group--get set the same). But you may feel more comfortable lowering the interval.
And again, this API is totally undocumented and I've mostly just been trying to make sense of the data it spits out. Most of it makes sense, but then there are oddities like this. So, let me know if anyone discovers anything else!
Not sure if what you are seeing is different than what I see in my code. For me, I receive all the color related events for groups -- if the changes were applied to the group directly. The implied attributes (other than on/off) that are computed based on changes made to individual lights is when I do not get those attributes. May be worth looking into closer.
So, if a group is off and I turn one of the "member bulbs" on when previously off and when their last "on" state was a different color/CT (so I might expect some group event for color), the only events I see for the group are:
This sounds consistent with what you said. If I send a command directly to the group (you can see the "raw" API commands as a Groovy Map in the bottom log entry below), I still don't get color information back. This is when the group was off but again previously on to a different color or CT, so I'd expect some event:
The top line is the eventstream data, stripped down to just the information for that particular group ID. (I did also check the entirety of the data and see something for every light in the group, with all the data I'd expect--just nothing besides on/off for the group itself.) The same is true whether I do this from Hubitat or the Hue app, though it's a bit more difficult to deal with the Hue app given its tendency to want to use XY data for color and CT.
It seems like this second thing is different from what you're seeing.
Not sure what to make of this, other than that hopefully we'll know more if/when they ever document this. A far more annoying problem for me is the tendency of the eventsocket to falsely report disconnects when, in fact, data is still coming in, so I'm never sure whether I can trust the current status...not sure if documentation will help with that. Ha.
Hi Robert, first of all, this is excellent work!
The event stream is working brilliantly for me, status updated almost instantly.
I don't know if you remember, but I have 5 hue bridges. I wanted to ask you a few questions if you don't mind:
Eventstream is not updating CT, only On/Off. I think you mentioned before that this is how it's communicated in the API, right? So only polling can update the CT?
My logs are being flooded with
CoCoHue Bridge 08DAE8 (Hue Bridge MBR) eventStreamStatus is connected
CoCoHue Bridge 08DAE8 (Hue Bridge MBR) eventStreamStatus is disconnected
I know you mentioned you can't trust the disconnected messages. Do you think I should just ignore it, and even disable description text logging on the bridges?
I used to have polling at 1 minute, now with event stream I set polling to 5 minutes. Do you think that eventstream, even with all these connects and disconnects, would be lighter on hub resources than the polling at 1 minute?
Thank you so much once again for making this a reality!
This isn't normal for bulbs, but in my experience, it is for groups. (Nothing is documented, so who knows what is actually "normal.") However, if the commands are sent from Hubitat, this should all be compensated for, as it was previously, by assuming that the group (or bulb) is at those settings if the command was sent successfully.
Yeah, this is a known issue:
Not sure if this is a Hue or Hubitat issue (unlikely to be CoCoHue-specific unless there are settings on the EventStream connection that could be different, but nothing I can try seems to matter and I can't imagine what it would be).
You can probably ignore it, but disabling descriptionText logging will just stop the logs, not the actual events. It actually waits a few seconds after the disconnection to report it as such, given that in my experience, most of the time, the message is not accurate--but apparently it takes longer in your case. I'm tying to figure out ways to handle this better without causing problems if it is, in fact, disconnected.
I have no idea, but I don't personally find that polling is heavy on hub resources, and I used to have mine at like 15 or 20 seconds. (Some in the community [I don't think I've seen this confirmed] do believe HTTP calls are subject to memory leaks, but in my hub I cannot find a difference in historical free RAM trends with that vs. the 1-minute time I switched to...which I realize isn't that long and I'll probably go longer eventually, but still should be 3-4 times less already.) Event generation also uses some platform resources--mostly just committing it to the database--which is why I'm trying to get rid of spurious "disconnect" events whenever I can, but I don't really know how one versus the other would stack up resource-wise (guessing the event generation would still be less heavy? but again, I haven't had issues either way).
Only if you configure the scene this way on the Hue side. I'm pretty sure there's a transition time parameter you can set, though I don't think the official app exposes it (third-party ones may). But it's not something you can specify when activating the scene, and that's all that CoCoHue is doing.
I ended up having to disable the event stream in two of my bridges because of the Json truncated bug.
Even with polling, the problem is that in one of those bridges I have a rule set as:
If this group(a hue group) turns on, turn on this z wave light.
However, since that group's status didn't change to on until polling, because of the Json bug, the rule wouldn't fire as expected.
If we can figure what's causing that, or have some sort of failsafe. Something like:
If there's a Json error, poll the bridge.
Seems like a temporary measure but would solve my issue at least.
Go figure - I enabled eventStream on the problematic bridges and now I'm not getting any errors. I'll keep it on and observe, but seems to have magically been resolved.
Ok, I'm able to reproduce:
If I use a rule to turn on my Kitchen Group + Kitchen Table Lamp (so one group and one bulb), I get the json error and the kitchen group status doesn't get updated. Here are the logs:
What's even more interesting is that if, in the rule, I first give an On command for the single bulb, then for the group, there's no errors. The error is triggered if the group is turned on before the bulb.
Last time I'll post about this in the CoCoHue thread since this clearly is a Philips issue::
I've been doing some further experimentation with "my" 1% issue. In the room with three adjacent bulbs that frequently exhibits this behavior, I replaced the middle bulb with one of the newer 75W/1100 lumen bulbs -- a hail mary in case it had subtly different firmware that might behave different. No change, in that the 1% thing still occasionally triggers.
Separate from the 1% issue itself, I observed a behavior: Sometimes the bulbs turn on and seamlessly begin ramping up to the requested level, other times there is a noticeable pause between these two event. I guess this must mean the bridge sends two discrete commands to the bulbs. For whatever reason it seems that second command doesn't always get executed. When this happens, the native Hue app reflects the requested-but-not-delivered level. Even after some period of time, this "wrong" level does not self correct (on the bulb or the app). However in this state, once I request a change of level they immediately react.
This doesn't feel like like RF interference because that first command -- the ("on") -- is always executed on. It's the follow-up that doesn't always happen.
Clearly either the bridge or the bulbs are doing the wrong thing, but I have very little faith I'd ever be able to actually connect to someone in Hue dev close enough to the bulb firmware to help sort it. My environment is likely a corner case for them, with 90+ bulbs and LED strips spread across 4 hubs. I guess I'll just hack in a follow-up setLevel after 100ms or whatnot as a workaround.
Thanks for sharing that experience! I never noticed this before, but recently (last few months or more?) I've seen the same thing, or at least something similar. I'm not sure I've never seen it fail to actually ramp up, but I have seen them turn on dim, then go up to the desired level (usually 100% for me) with more of a lag between the two than normal. I'm only sending one command to the Bridge for this, not two (or more), so I agree that it seems most likely to be something the Bridge or bulb firmware is doing--and possibly something that changed recently-ish, since I don't think I ever noticed this before.
I connected a rgbcct lightstrip to hue bridge. It appears i cocohue as rgbw bulb . But the colour controls dont work at all in cocohue. In the gue app works flowlessly. Is it possible to make it work in hubitat as it works philips hue?
Thank you
I can't really say anything without seeing logs from the device. Turn on "Debug logging" for the RGBCCT strip in question and look for lines in "Logs" from this device that start with "Preparing to create events from map."
But if you want me to use ESP and guess, here it is: I'd guess the controller you're using doesn't support the hue/saturation (HS) color model, only XY. Hubitat's "native" color model is HS, and I have not been able to reliably convert between the two. If that is the case, for the time being, you would only be able to use color temperature (assuming the device supports that via CT and not just XY as well...), or you could use the device as part of a scene and recall that scene to set that color.
I have only seen this happen with third-party Zigbee products, and not a lot of them (Ikea is notable one). All Hue products I've used work with both HS and XY color (and CT).
Because the Hue app can use any color model: HS, XY, or CT. Hubitat can only work natively with HS and CT. And you do not normally run into this problem on Hubitat because most color-capable devices that support XY also support HS, including all first-party Hue devices I know of and most third-party compatible devices I've seen (but not all--and I'm guessing yours is one, but again it's impossible to say anything without logs; I just can't imagine what else it would be).
Its Livarnolux smart strip.
from the log:
dev:8882021-11-12 19:46:32.211 debugSkipping colorMode and color name event creation because light not in hs mode
(Some in the community [I don't think I've seen this confirmed] do believe HTTP calls are subject to memory leaks, but in my hub I cannot find a difference in historical free RAM trends with that vs. the 1-minute time I switched to...which I realize isn't that long and I'll probably go longer eventually, but still should be 3-4 times less already.) Event generation also uses some platform resources--mostly just committing it to the database--which is why I'm trying to get rid of spurious "disconnect" events whenever I can, but I don't really know how one versus the other would stack up resource-wise (guessing the event generation would still be less heavy? but again, I haven't had issues either way).
