Room Lighting + Zigbee bindings

New to Hubitat, so I'm still trying to wrap my head around all the knobs to dial in what I want.

What I want:

  • Wall switches that turn on and off the lights
  • Lights that adjust to time of day (bright cold white in the daytime, warm dim in the evening, and very dim red at night)
  • Fast & robust (family won't mutiny if Hubitat goes down)

This appears to be achievable with these pieces:

  • Hubitat to drive Modes based on time of day (Room Lighting seems to be the current tool for this job)
  • Smart lights that can change colour
  • Smart switches that keep (nearly) the ergonomics of standard switches
  • Zigbee Group Messaging for robustness + speed

So I've got Hubitat C-8, bulbs from Ikea, Sengled, and Hue, and Inovelli Blue switches.

I figure the setup would look something like this:

  • Group bulbs together, as desired, in RL and enable ZGM
  • Find the group ID and bind a blue switch to it
  • (somehow?) have RL change the colours as HE's Mode changes
    • Ideally using Preset Level if the bulb is OFF so that when it turns ON it's immediately at the correct colour/dimness

I'm stuck right at the binding stage; haven't got to the adjust-according-to-HE's-modes yet.
I can bind just fine. And it is FAST. I LOVE IT! Family approves.
Buuuut, the bulbs don't seem to update their state. As far as HE is aware/reporting, the bulbs haven't turned on/off. I tried this with some Ikea bulbs and Hue bulbs.

Bulb1 & bulb2 in a group with ZGM enabled. Click ON on the virtual Activator Device. The lights turn on. HE reports both bulbs as "switch: on". Click OFF on the virtual Activator Device. The lights turn off. HE reports both bulbs as "switch: off". Press UP on the Inovelli switch. The lights turn on. HE reports both bulbs as "switch: off". :see_no_evil: Press DOWN on the Inovelli switch. The lights turn off. HE reports both bulbs as "switch: off". A broken clock and all that.

What am I missing? Without Hubitat having this information I don't see how automation would work to adjust the brightness/colour at the right time without accidentally turning on lights that it thought were on, but were really off.

All the bulbs are using the Advanced Zigbee RGBW Bulb. AFAICT that's the most up-to-date driver for bulbs.

This is very similar to what I have, but there are several moving parts:

  • Mode changes based on outside brightness; not supported by Mode Manager, so I have a Rule Machine rule to manage that.
  • I'm currently using the older Groups app to manage my grouped bulbs, but you could also create the groups in Room Lighting.
  • Rule Machine fades a virtual bulb's color temperature up and down over the course of the day, also stashing the current CT value in a variable.
  • Room Lighting adjusts brightness according to mode and applies the current value of the variable to the lights when they're told to turn on.
  • Virtual Prestaging sends the new CT value to all currently-on bulbs as the virtual bulb changes over time.
  • Switch Binding is used to make light switches "turn on" when the lights they control turn on, so that the LEDs stay in sync. I also use it for a few older switches that aren't scene controllers, though that's awkward.

Happy to share screenshots or links to any of that you want more detail on.

Rule Machine fades a virtual bulb's color temperature up and down over the course of the day,

You are my new best friend. I'll hit you up for this later after I get the basics sorted.

Switch Binding is used to make light switches "turn on" when the lights they control turn on, so that the LEDs stay in sync.

  1. Are you also using the switches to turn on/off the lights? Or only using them for their LED indicators?
  2. If you're using them to control the lights, is that done via the binding, or via scenes/button controller/etc?
  3. If via bindings, when you hit a switch, is Hubitat aware of the new on/off state of the bulbs themselves?

If the answers are Yes/Bindings/Yes, then I'd love to see your group setup (happy to go to the old app if that works better for this), and any info on the bulbs (brand/driver).


Always control -- light switches on the wall should always work. While we mostly let the lights turn themselves on and off, manual control still needs to exist.

That depends on the switch. As my collection has grown over the years, things aren't uniform.

Some of my older switches aren't scene controllers, so there are no button events. For those, Switch Binding will sync any changes from the switch to the group activator, or from the group activator back to the switch:

For the ones that do support scene control, I can do it in Button Controller and have finer-grained control:

...but I still have a one-way Switch Binding just to ensure the LED indicator is correct if the lights change from a source other than the switch:

In this case, I mean the Switch Binding app, not anything that's happening outside of Hubitat's control. So yes, Hubitat always has current state of all devices.

Just to add on here, @mbishop is talking about [RELEASE] Switch Bindings. You are doing Zigbee binding that is happening generally outside of Hubitat's control which is why the light state is not following the switch state. If you set up a one-way switch binding with the switch as the master, Hubitat will automatically update the light group to on/off as you press the switch. If you turn on the bulbs with other things beyond the switch, you would not want the Master switch, and instead, set up a two-way sync.

Ahh. Thanks for the clarification. So the binding is still going through the hub. Presumably that means if the hub is unavailable for any reason, then the wall switch cannot turn on/off the lights, right?

I'll look into that if I can't get Zigbee bindings to work out. I very much value local control. Switch->Light with no Hub. Switch->Fanciness->Light with no Cloud.

Knowing nothing of Zigbee, I was expecting that devices "announce" their state when it changes. When a sensor detects open/close it would "announce" the change. I imagined that when a bulb changes on/off it would "announce" it. So I expected Hubitat to be in the loop of the true state of lights even if it didn't instigate it.

Shutdown your hub and confirm that your Zigbee bindings are still working. Assuming that they are, you just need either the App or a Rule to keep the bulb state the same as the switch. This will allow you to do the color transitions as desired and allow the hub to know which light is on and off.

This is generally true of all devices except for light bulbs. If you connect a bulb directly to Hubitat, the expectation is that Hubitat will control the light. When using Zigbee bindings, it is basically the same as a smart switch with dumb bulbs. The control of the bulb is happening outside of Hubitat.

Shutdown your hub and confirm that your Zigbee bindings are still working.

Shutdown + unplugged Hubitat. No loss of lightswitch raves. Looking good.

you just need either the App or a Rule to keep the bulb state the same as the switch

Here when you say 'App', are you referring to Room Lighting (telling it to trigger on state change of the switch) or the Switch Bindings app that @mbishop is using?

I'm guessing the latter. And from your earlier comment I think a 2-way binding is the way to go. But is that going to cause duelling banjos? I hit the switch to turn the lights on, it sends a ZGM to the lights directly, Hubitat sees the switch changed to ON. It updates the ... Activator Device I'm guessing? to ON. RL sees that turn on and sends a command to the lights. Presumably this should be "fine" as long as I'm not doing on/off quickly where commands can get interleaved, and hopefully it doesn't cause flicker of the lights themselves with ON-ON... I guess there's one way to find out.

This is generally true of all devices except for light bulbs.

:joy: :sweat_smile: :person_shrugging:

You should be fine with a two way binding. My bindings contain a switch, Hue group, and a Room Lighting Activator which allows me to have maximum flexibility to use either the Hue app, switch, or a button scene controllers to always set the right light that I want for the moment. They can handle the double command and I bet your Zigbee group can too.

Thanks. It seems to be working. I'm seeing a bit of stuttering when I turn it on: lights come on, lights increase in brightness to a point, then pause, then increase the rest of the way.

I'll take that minor inconvenience over a delay any day of the week.

I'll sit with this for a bit and see about tweaking some knobs like transition times. Then I'll be back to debug or add bells and whistles.

Okay, so I've had it running for a couple days now and I think I'm ready to add in adjust-throughout-the-day. Doing that in RL (keyed off Hub Modes) leaves a bit to be desired -- it adjusts shortly after turning on. Which is expected given the ON is sent immediately and RL activation comes only as fast as a round trip to the hub + logic can happen. A little ugly in the day turning on for the first time comes up in night mode spoiling the immediacy of the switch. More troublesome is coming on at daytime brightness in the middle of the night before adjusting back down. :see_no_evil:

What's the recommended way to go about this? Sounds like maybe Rule Machine to play around with "desired brightness + temperature". Given that Room Lighting (presumably all reactive apps) are slow[1] off the start, should I be looking more into Rule Machine or something else to issue PresetLevel? I see there's no equivalent for Preset CT :cry:

@mbishop you mentioned "Virtual Prestaging" -- what exactly is that?

I'm really curious how Hue handles this. Before moving to Hubitat I had a hue bulb + bridge + switch and "turn on at the right colour/temp/intensity" was blazingly responsive. But the ecosystem was too confining.

[1] 'slow' is relative here -- of course Hubitat is far faster than anything that has to head out to the Internet and back. But it is slower than a direct command.

So there are several factors here.

The first is the command being sent to the bulb from whatever app. You can improve your odds by sending the bulb a command that includes level and CT, as opposed to just "on" and then adjusting those values. Sending a bulb a non-zero level implicitly turns it on. You can play with what the device itself does by sending it commands directly from the device page. (As an aside, none of my bulbs go directly to the desired CT when commanded, somewhat to my annoyance. They turn on at the last-used CT and transition a fraction of a second later. I live with it.)

Next is getting that command sent from the activation device. If your switches are Scene Controllers, you can set the behavior of the button to send that command; that's one of the screenshots I had earlier.

[PRERELEASE] Virtual Prestaging catches anything that falls through the cracks, plus maintains it over time. When a target light turns on, it gets sent the CT value from its source and immediately sends the CT command to the newly-activated light. It also sends commands to all the target lights that are on if the source changes.

Thank you. I've installed both Virtual Prestaging and the Circadian Daylight I found in that thread.

I'll get it wired up and test it out over the next few days.

A couple of things that jump out:

1.) You can try adding your switch as a Means to turn On in Room Lighting and see if that triggers things a little faster. It might save a step, which is really just a couple of milliseconds, but it might help.

2.) You might look at using Rule Machine to fade your lights down to 1 and then off. This would at least help with some of the ugliness since the color transitions would happen at level 1.

3.) With Circadian Daylight, you can use it to set a hub variable. From there, the hub variable can be used as the Color Temperature in Room Lighting. This way, Room Lighting will always turn on your bulbs at the correct temperature. You can then use Virtual Prestaging to take over. This is probably not necessary for your use case since you are using Zigbee bindings, but it is something that can help.

4.) With your Hue bulbs, I strongly recommend using [RELEASE] Philips Hue Zigbee Driver (not using Hue Bridge) as your driver. It supports prestaging both level and color/CT.

Personally, I use lutron and picos to control hue bulbs on the hue bridge. If Hubitat goes down, I can always use the app, Google Home, or Apple Home as long my internet and/or just power are still working. As you noted, Hue Scenes set the bulbs immediately to what I need.

1 Like

Okay, more knobs and dials to fiddle with. But I think I need to move my experiment setup from Ikea bulbs to Hues.

Maybe, but I'm not sure if it is going to matter. I'm pretty sure even with the prestaging built into that driver, it would not apply until Hubitat knows that the bulbs have been turned on. The same is true with Rule Machine. Without Hubitat in the middle, there will always be a delay/flash of the previous color.

Have you tested the switch in just smart bulb mode with Hubitat in the middle to see if it meets your speed requirements?