Frustrated with trying to integrate Caseta and Hue

TLDR version at the top: If you were starting from scratch trying to integrate a bunch of Caseta/RA2 devices and Hue in a single room using Hubitat and/or Homekit, with the only lighting controls being a 4 button scene controller capable of cycling through scenes with multiple button presses (Bright, Entertain, Relax, Off) how would you go about doing it?

Long story: I've had Hubitat since late last year and mostly love it, and for 95% of my needs it's working quite well. However the biggest thorn has been trying to integrate my mixture of Hue and Lutron Caseta seamlessly.

For most of the house this integration works fine as the lighting is relatively simple, with only a few basic scenes and handful of lights. But in my living room & dining room (this is a 1,400 sqft house so they're more or less one room, and I mostly treat them as 1 for the purpose of lighting) it is quite a bit more complicated with probably over a dozen Lutron dimmers and Hue bulbs.

Right now I'm using Hubitat to expose Pico remotes for basically all of my button based controls, most importantly in this case Lutron 4 button scene Picos and it's where my problem most shows up. The scene keypad is set as follows:

Bright -> Room Lights app "Living Room Bright", controls Lutron dimmers individually and controls Hue as a CoCoHue group setting color temp. Mostly works fine, has minor variations in color temp on the Hue lights using hub modes.

Entertain -> I use the entertain button for controlling the various Hue RGB scenes (along with dimming/turning off Lutron dimmers per scene) I have several various Room Lights apps for each Hue scene. Each app controls the Lutron lighting independently as with the Bright Room Lighting app, for the Hue lights I have them triggering CoCoHue exposed Hue scenes. I figured offloading this to the Hue bridge lowers the load on Hubitat but it would seem not. Primarily when messing with Hue scene activation via this method it will frequently overwhelm the Hubitat leading to elevated, severe loads and ultimately Zigbee radio shutoffs.

Scenes are cycled here by a button controller app using if-then-else logic; I've done this by "if x scene is on then scene-on else next-scene" and also alternatively using it track button keypresses cycling through 1-5 using a local variable, so it doesn't have to read the states of the Room Lighting apps

Relax -> Same as the Bright RL app, has button controller app to cycle between a "relax" and "relax low" scene. Seems to mostly work fine.

At this point I kind of want to start from scratch on my living room lighting control. Should I abandon direct control of Hue scenes in CoCoHue and just use Room Lighting to control each RGBW bulb? I've also been a long time Homekit user prior to Hubitat, however I've only used it as a front end for app-based control; could it play a role here in tying the two systems together?

Sidenote: I have a second Hubitat C-7 that I picked up on one of the open box deals, I planned on using it for testing/development so as to not mess with my main hub. Perhaps I could offload the living room lighting apps to it?

Can you show a sample of one of your Room Lighting instances from the Entertain category? Are you directly setting your Lutron dimmers from Room Lighting or activating Lutron scenes? How are you activating your Hue scenes (via Switch or Button)?

1 Like

Just so we get clairty, what exactly are you trying to fix? Is it the hub load getting high at times, or a problem with the automation only working partially?

My initial though is if you want to use Hue Scenes you will have to lean on the Hue hub to some extent. Maybe there is a more efficient way to do the management in the Rule/BC, but it sounds like you got it donw pretty good.

Are the Hue scenes dynamic? with multiple colors, or are they just one color set to multiple bulbs?

I do similar things and don't have the issues you are seeing. I think you'll need to turn on and watch logs to gather more information about what is going on to cause high load issues. Pay attention to your cycling apps and CoCoHue. @bertabcd1234 can comment on whether calling Hue scenes via CoCoHue can cause load issues.

Switches for now. Is there a big difference between triggering a scene with a switch vs. a button? Here's an example:

I'm not using Lutron scenes, but I could. I've just tried to keep as much centralized on Hubitat as possible so as to not have to configure things on 3 different bridges. I've used Hue scenes in Room Lighting as they're already programmed on the Hue bridge, plus doing that offloads the changing of numerous RGBW bulb settings at once to the Hue bridge instead of Hubitat having to control each bulb individually.

To be clear, the biggest issue is the hub load issue. When the hub isn't overloaded the automations trigger fairly reliably, at least enough to my expectations. I've cleaned up & re-tooled these quite a bit and gotten them better, but the load issue seems to keep popping up ever now and then.

Scenes are not dynamic, just basic setting of RGBW & levels.

A few questions:

Have you been able to identify which apps/devices are contributing to the high load? Is this easily reproducible?

How many scenes are being activated at one time?

How many lights are associated with each scene?

It seems like CoCoHue is the culprit, but I'm not sure if I'm reading the logs correctly in that regard.

By my count there are 11 Hue bulbs being controlled by Hue scenes/groups (so only one logical device that Hubitat controls) and 4 Lutron dimmers (controlled individually by Room Lighting).

Do you collect any performance data using HubInfo deriver and influxdb logger or hubigraphs pluging with webcore?

Have you reviewed the App and device stats page under logging to see what apps and devices are using the most CPU?

I suspect those two items are not to blame as they are fairly proven tools.

I do something similar to you, but do not see the hub load. Granted, I also use buttons for all my Lutron and Hue scenes as that minimizes the work of Hubitat. It just pushes two buttons and the other hubs do their designed work. See my example below.

I would do this for all possible combinations for your three settings. From there, I would put all activator devices into [BETA] Single Active Switch. This way only one activator device can be active at any given time, but turning off an activator device does not turn off any lights. Only your off button on the pico will.

1 Like

Quite unlikely, as it just sends a single command to the Hue Bridge. With CoCoHue (or any Hue Bridge integration, including the built-in one), what's most likely to contribute to "load" (really the over-time stats) is polling. This happens at a specified interval regardless of what does or doesn't happen on the Bridge. If you are using the new/experimental eventstream option, you can consider significantly reducing or even eliminating polling, though I don't quite recommended that last thing for most users at this time.

The other thing that can contribute even with eventstream is lots of changes--the Bridge sends things to the driver in real time, which has to wake and parse that data. This usually ends up being far less than polling over time, but if you have something like a dynamic scene, maybe not.

In any case, I've yet to see any case where any option has truly been problematic. Even with a high percent of busy time, the percent of total is usually still pretty low, and that's what really matters. (Also no problem on the hub where I went nuts and enabled 10 or 15 second polling, but that's also not something I'd normally recommend!)

1 Like

Ahh, I do have the eventstream option enabled although my polling settings are less frequent and/or disabled where I can.