Having had some issues with my Hue Bridge and/or interface recently, I'm re-thinking the wisdom of having a large number of my devices connected to a separate hub so have just moved a few of them over to be connected direct to Hubitat. It went really smoothly if anyone wants to do the same - just delete them from the Hue Bridge in the Hue app and that leaves the bulb in pairing mode which Hubitat then found instantly as a Generic Zigbee Bulb and they work great. I have been careful not to move over any that are likely to be picked up as repeaters for other Zigbee devices as I know they can cause problems with that.
But the question is, when connected directly to Hubitat, can you chose the behaviour of the bulbs when they start up (eg after a power cut) as you could when they were connected to the Hue bridge? My bulbs have all had the firmware update to allow that feature in Hue and were set up to retain last settings there. But having just turned one off at the switch and back on again to test it, it came on even though it was previously off.
The bulbs I have moved are in bedrooms, so it would be a bit annoying to have them all come on if we had a power cut in the middle of the night which isn't unknown here. There is nothing in the Generic driver to set start up behaviour, and I couldn't see a specific Hue bulb driver other than the huebridge ones.
This very likely is configured in the firmware of the hue hub and therfore the firmware version of the bulb probably won't be helpful unless you are using the hue hub. Hopefully I'm wrong here but I think what youi want would need to be handled by an app and that app would need to know when there is power outage.
Before Hue made the power on changes, I had the exact problem in my bedrooms and the fix took 2 steps to resolve. I had to setup a way to know when there was a power outage and then set the Hue bulbs to what they were before the power was cut. My solution did/could not prevent the bulbs from turning on, but at least they would turn of a couple of seconds later on their own.
I no longer use the app I created but it is located here:
For power outage detection, there are a few option depending on your skillset
@Geoff_T, I just thought of something else. I never connected my hue bulb directly so I don't know what the logging looks like but...if you turn on debug logging and cut the power to the bulb and then turn it back on, you can see whether the bulbs send a zigbee report back to the hub. If they do send a "power returned" message of some kind, then @mike.maxwell may be able to use this zigbee report to set a power on behavior like you requested...or at least to set an attribute that you can tie into an app like RM.
Even when connected to the Hue bridge though, wouldn't the start up behaviour have to be coded into the bulb itself somehow? If not by the time the bridge was back up and running to be able to send anything to the bulb, it would have already turned on the instant the power was back wouldn't it?
If I had to guess, the Hue app via the Hue Bridge sent a custom setting that is likely stored on the bulb itself, so unless it's following some ZLL/ZHA convention for how this is done, the traffic would likely have to be sniffed and, if reverse-engineered, added to a special driver Hubitat driver for Hue bulbs. Mike will probably know. But I agree it's likely not the Bridge "listening in" and fixing things after the fact since the behavior is instant (you could test this by powering the Bridge off and seeing what happens when you flip a switch on the lights, I guess).
On Hubitat as-is, you'll have to use some solution like the above. I never got quite that fancy--I just had a rule that watched for a bunch of lights I wouldn't normally turn on at the same time all coming on and staying on for a certain amount of time, and then notified me to check on things.
PS - Did the Hue Bridge integration get worse for some people? I recently experimented with moving some bulbs from the Bridge directly to Hubitat (a separate hub I set up for this--I wouldn't recommend doing it this way if you have other Zigbee devices on the same hub, as you know). Turns out that's not perfect, either, partly due to the lack of true "scenes" causing everything to be a bit slower than Hue was. Right now I'm half and half and might stay that way to see which ends up working better.
PPS - I'm not sure if it's 100% necessary, but you might also want to keep your Hubitat hub on a ZLL-compatible Zigbee channel so it's easier to move bulbs back to Hue if you can't properly remove them from Hubitat first for some reason (I think you'll have to find another way to reset them like a Hue Dimmer or Lutron Connected Bulb Remote if you can't, otherwise I'm not sure if they'll be able to "listen" even with the serial number to get "stolen" back to Hue...but I could be wrong).
If I had to guess, and I am, the power on options set while the bulbs were connected to the Hue bridge, would likely have been wiped from the bulb when you removed it from the bridge.
I can confirm that this is true. (I suspect there's something, like the motion sensitivity on the Hue Outdoor Motion Sensor, whose traffic could be sniffed to discover the setting that configures this on the bulb itself to allow configuring this when paired to Hubitat. But I'm definitely guessing on this part.)
I'm getting that with directly-paired bulbs, too, though I'm not sure I've seen it on Hue bulbs. I have seen weird values on Sengled, but I think it was something like turning on to 44% instead of 100% like they were told. That being said, I don't think Sengleds show a big difference between 1% and 44%, so unlike Hue I can't tell by looking and am only going with what Hubitat tells me.
I'll do some more playing with mine to see if I can narrow this down at some point.
It's been a while but I just skimmed the above and don't see any mention of a "brief" power on, just the typical issue with most smart bulbs turning on (to their last state) when power is lost and then restored. Some newer bulbs, like Inovelli's Z-Wave bulbs, have an option to determine what happens when power is physically restored; some (maybe Ikea, if I remember correctly?) have an unchangeable setting that is "last known" including off if it was off (with a way to really turn them on if needed, like flicking the switch a couple times), and recent-ish Hue bulb updates allow their default power-on state to be configured to a variety of options. As far as I know, Hubitat has not figured out how to allow setting this for directly-paired (Zigbee, not LAN/Bridge) Hue bulbs, though many of us have guessed that it's just Zigbee configuration that could be sent if anyone reverse-engineered what it was.
The only "brief power on" thing I can think of is that Philips says first-gen Hue bulbs might briefly turn on even if they're configured to stay off if they were off and then power is cut and restored; my guess is that they didn't have enough room to implement this on the bulb firmware like they did for the others, so the Bridge is probably involved here and doing a bit of magic (again all just a guess as to how it works). But that's a bit of a different issue.
Or in fewer words: yes, that is still a dream.
I'd be curious how you decide to proceed. If it were me, I'd just consider replacing the Hue Bridge. If you do pair the Hue devices directly to Hubitat instead, I'd recommend a second hub, as you probably know, given that many smart bulbs are known to be "bad" repeaters and may cause problems if mixed with other kinds of Zigbee devices (motion sensors, dimmers, etc.) on the same network. I've also been experimenting with deCONZ and it's not bad if you want a more DIY (but still largely proprietary) option; it has a Hue-Bridge-esque API but also has a websocket connection, so things like button devices and motion sensors--and bulbs, for that matter--can push events in real time to Hubitat without polling, making any of them theoretically usable (I've forked CoCoHue to work with this, though I haven't formally "published" anything). But no "default power on" settings, there, either--Hue is the only system I know of that lets you configure this for Hue bulbs.
Platform 2.2.5 will include a series of advanced zigbee bulb drivers, amoungst other features they also include a power state restore preference setting.
This feature is implemented in the driver and so far has worked with hue, Sylvania, osram, aurora, linkind and adurosmart, basically every bulb I have except sengleds.
(I suspect there's something, like the motion sensitivity on the Hue Outdoor Motion Sensor, whose traffic could be sniffed to discover the setting that configures this on the bulb itself to allow configuring this when paired to Hubitat. But I'm definitely guessing on this part.)
