Capture action only capturing bulb state, not colour

[AlanB]

Hi there
I've got a rule where I'm trying to capture the state of a RGB bulb, then flash green or red for some checks and then go back to the original state. I run the capture and restore actions but the bulb stays the last colour and does not go back to the original white when the capture command ran.
Am I missing something?
Alan

[bertabcd1234]

Does this only happen if the original bulb state was off? Or does it also happen when it's on? I'm asking because the Hue Bridge (I'm assuming these are Bridge bulbs) does not accept color or level commands in conjunction with a command for bulb on/off state, so it's likely either Hubitat only sends the latter or it does but Hue ignores the former (can't remember off the top of my head if it throws an error on the Hue side or if it just silently ignores it, so I'm not sure what they would have chosen to do).

This issue recently came up in another thread, but I'm not sure the poster ever tried exactly what I suggested (for one: for the purposes of testing, only manipulate the bulb from Hubitat to avoid refresh-interval issues) and provided a clear answer afterwards as to whether it worked, but perhaps you could see if it does for you:

Lights go red on contact change

I'd just define a local boolean (true/false) variable, then do basically what you were doing before, except capture the on/off state to this variable (so you know what it was before you changed anything), turn the bulb on and capture its state (so RM gets all color/level attributes, etc.), change it to what you want (red at 50%; I only did 50% in my example because I used a dimmer and not a bulb), then restore it (so it will get all the correct color/level states), and turn it off it was off ori…

[AlanB]

Thanks.
So, tested with light on/off initially. Works perfectly when light is on initially but not when off. Will try switch on first through action and see how that works out.

[AlanB]

@bertabcd1234

I'm not sure the poster ever tried exactly what I suggested (for one: for the purposes of testing, only manipulate the bulb from Hubitat to avoid refresh-interval issues)

Do you mean remove the bulb from the hue bridge and connect directly to HE? I may try that when I get time (which could be a while with a stressful job and 2 & 6 year old kids running around. Only play time I get is for about 15min in bed just before I go to sleep).
Most checks are done off that bulb so may do that permanently anyway. Don't want to take all bulbs off hue ss they don't cause issues with zigbee repeating

[bertabcd1234]

No, I just meant capturing the state yourself and making sure it's in when capturing and restoring from RM, then handling the on/off thing yourself. I would definitely not pair the bulb directly to Hubitat, at least not if you have other Zigbee devices.

[RogerThat]

I think the app, The Flasher, might do what your looking for.
A lot of cool apps from @bptworld.

bptworld/Hubitat

RogerThat

[AlanB]

Thanks. I'll have a look at that.

I did a test with the bulb (Innr bulb, not Philips). I removed it from the Hue bridge to test and ran a capture both with it on and off. When off, it only captured the on/off state. I thought it would capture all since it was in essence powered, but I thought wrong. When on, it worked fine. So, it's the bulb that is limiting this and not the Hue bridge

[bertabcd1234]

I didn't mean pairing directly to Hubitat, but that's certainly something you could try (but I wouldn't recommend it for most Zigbee bulbs). Most Zigbee bulbs do indeed support receiving color and level information when off, but most Hubitat drivers are set to not only send those commands but also turn the bulb on of it's off, unless the driver has a prestaging option (pretty much what doing this without turning on would mean) and you have that enabled. Without prestaging enabled (the default state) on in drivers that don't support prestaging (many don't), this ensures uniform behavior where a setColor, setColorTemperature, or setLevel command will also turn the bulb on of not.

Because of this behavior, my suspicion is that RM would be heistant to send any information besides on/off state back when restoring if the state it captured was off. Capturing the on/off state yourself, then turning the bulb on (from Hubitat), capturing its state, doing whatever you want, and then restoring its state (which if on should get everything) and then turning it back off yourself if needed (per the value of your saved variable) was my idea for how to work around this limitation.

@AlanB

not the Hue bridge

It most certainly is also a limitation of the Hue Bridge, as the Bridge (unlike the bulbs themselves, really) does not accept any color/level commands in conjunction with an "off" command or while the bulb is in an off state. I am quite familiar with this part of the Hue API, having written a custom integration for Hubitat and various scripts on other platforms before Hue had good physical control devices.

[AlanB]

@bertabcd1234

but I wouldn't recommend it for most Zigbee bulbs

I'm kinda inclined to leave it on HE, at least to test for a while. It's the only bulb not on the Hue bridge and there hasn't been any issues with other zigbee devices (so far). I was getting a bit annoyed with the inconsistencies of response (sometimes having the Hue bridge not respond at all sometimes and other times varying delays). With it on HE it's a lot more consistent.