[RELEASE] CoCoHue: Hue Bridge Integration (including scenes!)

Found a fix for this. If you're doing a manual install, you only need to update the app driver, though I'd recommend the Bridge driver as well. It should be in HPM as well, and the bundle/ZIP has also been updated for those who install that way.

Version 4.0.2: Fix for error when adding sensor devices.

3 Likes

I forgot to try this again. I had tried it around the time .123 I think (the one that was rolled back) came out and it didn’t work, but I just chalked it up to a hub issue. I’m glad someone else mentioned it :blush:

Thank you for your fast response!

I updated the app in HPM. Adding the sensor resulted to this:

Now I can’t access the app at all, it just shows me this error :blush:. Lights are working still though.

I tried restoring a hub backup and did the update again, same result.

Oh wow. You can just delete that line in the code, or I'll reupload soon! Literally mashed my fingers on the keyboard...

EDIT: Updated file, did not change version. Can repair in HPM or download file manually if needed, or just delete the offending line in the app code.

4 Likes

I've updated using HPM but I'm not seeing the new option to push hue events in the app. I opened the app for both of my hubs and clicked done but still nothing. Am I missing something obvious?

I'm getting a lot of these errors in the logs:

Looks like some piece of the code didn't get updated, probably the app code. An HPM repair should fix that, or you could just grab the app code from GitHub and copy/paste over to be sure.

Turns out I still had the child app and a duplicate older app that was being used. Deleting the child app code and pasting the new version over the old code like you suggested did the trick.

2 Likes

this is constant in my logs, I read the previous posts and the consensus is that this is fine right?

Yes that log spam appears to be normal at the moment. I found that if you go to the actual Bridge DEVICE (the device using the CoCoHue Bridge driver) and disable the info logging, that makes it stop logging it at least.

4 Likes

I changed the name of a hue group in the hue app. do I need to delete that group in CoCo and re-add? I refreshed but it doesnt change the name automatically

Like Hubitat's built-in integration, CoCoHue will not automatically update device names in Hubitat based on changes in Hue (this allows you to keep them different if you want, like "Kitchen" in Hue vs. "Kitchen Lights" in Hubitat, for example). Unlike Hubitat's built-in integration, however, you can match up Hue vs. Hubitat device names on the appropriate pages. For example, go into "Select Lights" and you'll see a list of devices that have (and haven't) been added and their names on both Hue and Hubitat, so you can compare and change one if you want.

Or if you know exactly what the device is, just go to the Hubitat device page (which you have to do even if you find it via the above--except the above will provide a link to get you there). There, change the device name and/or label (Hubitat will use the device label as the display name if you provide both a name and label, otherwise it will use the name).

1 Like

Thanks! I assume it's the same for scene naming as well.

Yep, all devices. (Scene names are actually different to start with by default: scene name plus group name, otherwise you'd have multiple things like "Read" that would be hard to distinguish.)

1 Like

I just got some additional Hue lights, and I'm trying to think of all usage scenarios. Right now I have a couple of pistons that configure the Hue lights, based on motion, to certain levels/colors depending on the time of day. However, what I've found is that if I change the Hue lights via the mobile app or via my stream deck, that as soon as my motion piston fires it resets the lights to the piston settings.

Is there a way from the API to detect if programmatic/manual changes are made to the light settings, which a piston could detect, and then NOT reset the light settings when motion is detected?

With the v2 API, not really--I'm moving to just read data back from the event stream, which should see changes made from inside and outside Hubitat equally. (With v1, this is more or less possible--the immediate data comes from what was sent if the Bridge received the request, rather than waiting for the next poll, so the data is there--but not implemented, and I'm still not sure it would be worth it.)

Would it work to just configure your motion automation to not adjust things if the lights are already on? This is an option in some built-in Hubitat apps, like Motion Lighting, but you could make a webCoRE piston do the same.

1 Like

Not adjusting if lights are already on would be a good solution...let me mull that over and see what I can program. Thanks for the idea!

I noticed in log something like this:

image

Not sure what it means and not sure if that is something to worry about..

I believe that is ultimately the same issue that @MrPancake reported above:

It seems that when a bunch of changes on Hue are made at the same time, either Hue or Hubitat is cutting off part of the data that is getting sent in. (If you happen to have debug logging enabled at that time and can send the full raw data to me, possibly in PM, that might be helpful.) The result is unparseable/malformed data, resulting in that error.

It was also suggested to add a refresh after receiving this error so the updates will still appear on Hubitat without needing to wait for the next interval--a workaround, and one I'd rather not have to do at all, but possibly not a bad idea...

1 Like

Since that reply, I disabled eventstream altogether because the bug kills many automations I have.
Things like "turn on this switch when this light turns on" are an issue because even though the light turns on, the error makes hubitat think its off until the following refresh.

Is your Hue firmware 1.49.1949107040? Mine just updated to this version Monday night sometime and the events from the eventstream seem to be coming across faster. I don’t have anyway to measure it, just perception. @bertabcd1234, have you noticed any improvement (if your hub has updated)? I’m hopeful that this keeps improving, since using hue lights in Homekit automations is instant, just too limited.