Okay, well that seems like a big + for Hubitat. This is something that have been breaking my balls in Home Assistant, where I found no way to do this.
Oh well, still on the look out for something that does everything I guess.
Hubitat also allows for creating a GROUP of Zigbee bulbs. If all devices in the group are Zigbee, you can enable Zigbee Group Messaging. This eliminates the “popcorn effect”. Another cool feature that ST, at least, didn’t have when I used that platform.
Actually they don't all need to be zigbee, they can be mixed, the app knows which are which...
2 Likes
Ah, that’s even better! Thanks for the tip, Mike!
Surely, that's a nice functionality, to make sure there is never any popcorning going on.
I must admit however that I have never experienced that this was a problem. If I call 3 bulbs to turn on through Home Assistant > deCONZ > ZigBee bulbs or through Homey > ZigBee bulbs, there is no visible popcorning at all.
That's why the biggest annoyance I have experienced are missing scene features. Say the lights in my bathroom, they turn on at 100% brightness in a energizing white/blueish color during daytime. After bedtime(either through a time condition, or bed presence detectors), they turn on with a scene that is orangeish and just 1% - you know, only to make sure you can find the toilet in the middle of the night (yes I am that old).
This works very well with the Hue system as standard, and also works great with deCONZ scenes.
But with the Homey, the first time the light was to turn on to the night scene, it would kinda flicker and flash around, which can sort of flash you, and also hurts my OCD so deeply.
And again, for Hubitat, this is not working either.
I still have a hard time understanding why this isn't a feature that is highly sought after, and a ton of people asking about it. I assume everyone else just accepts the inconvenient and non-smooth transitioning between scenes?
1 Like
I have a similar setup in my master bathroom. However, I use Lutron Caseta in-wall dimmers with dumb LED bulbs. I have no problem whatsoever as these dimmers perform a soft startup and ramp to the desired dim level. Bright during the day, and very dim in the middle of the night.
I have had that functionality on past systems, and don't miss it at all. In fact, the way I use different modes/scenes I LIKE the visible transition as it is a indicator to me of a time/mode change. You obviously don't, and that's cool, too. Different use cases, different opinions - all good.
I don't find it "inconvenient" at all. That is your opinion, not everyone else's... So don't project. 
Fact is, in over a year of reading these forums, I've never seen anyone except you ask for this. That doesn't mean you are wrong, or that your request is invalid though. But it likely does mean that it is low on the priority list.
I understand for time/mode changes that happen while the bulb is on. I can for sure understand why this gives a nice transition feel to it.
The problem for me, is when turning a bulb on, into a different scene than it was last on. Are these really the visible transitions you like? I have a hard time understanding how you can like these, as they are aren't natural at all. I assume everybody wants a transition between the two states a light is switching between. In this case, we're switching from off to a given scene(for example a night scene). So the effect of this missing functionality gives us two transitions here instead, one from off to the previously used scene(in this case maybe a day scene) and then again quickly transition to the wanted scene.
Transitions are a necessary evil, used to smoothen the change between two different states. I therefore really cannot understand why you would say that you actually like a double transition that you are seeing due to the fact that the light cannot work as intended.
Yeah, that would be annoying.
Mine go straight to the desired level the way I have it set, so I don't get double transitions with on/off. But my setup is completely different than yours - GE zwave plus motion dimmers, and trigger light on/off based on motion. So I directly set the value to begin with when motion is detected - no double transition.
We rarely (never?) use the wall switch because it is so handy to use the motion detection, being hardwired/no batteries/etc. If I were to turn it on from the wall switch, I would probably get double transitions I guess. Been so long since I've touched a wall switch on one of my dimmers, I honestly don't remember.
And I don't use color changing bulbs, as I don't like them (not high enough lumen, and I don't like different rooms to have different light color/types). I'm not interested in circadian lighting schemes. I could see that being a potential coordination issue between modes though. I did full colored bulbs in my last house, and after a few years ended up just putting them on the kelvin setting I like, and left them there. lol.
Good, then we are aligned 
That is exactly the annoyance I have. Motion sensors / wall switches do the exact same thing in relation to this. They are only the trigger. So what you see with your motion sensors is the exact same thing a wall switch would do.
The problem is primarily that I use different kelvins depending on time of day.
Understood.
Hubitat heard your request. I just think you need to temper you expectations of this getting done 'soon' as I doubt it will - although I'm not the decision maker on that.
Yeah I've learned not to rely on waiting for requests to be fulfilled. So unfortunately, it looks like I am leaving Hubitat before even really joining.
It is a bit unfortunate, as this functionality is the only reason I ordered a Hubitat in the first place. It turned out pretty expensive when adding the EU specifics, shipping and customs on top. Actually a total of 230 USD. So I will take a pretty massive hit on the losses when selling it as second-hand now. Unfortunately, returning it is also out of the question, as the shipping price, restocking fee and lost customs would defeat the purpose 
I was already burned by Athom Homey, not being able to do what I assumed it could. So this this I thought I would make entirely sure and get it in writing, but still did not help with the luck this time. So I am a bit hesitant about which system to buy into now and give a go. I guess I will have to find actual users that have this functionality working, that can share me videos about it.
I guess I'm missing something here, I personally don't use or need any scenes as I accomplish what is stated in this thread by using rule machine and mode manager, but I also use sengled bulbs and not hue.....(which is probably what I'm missing as I didn't buy into the Hue ecosystem)
I've learned to live with the "two transitions" thing, but there are ways you can mitigate that problem. If you're just changing the level, a setLevel command alone will cause most (all?) bulbs to also turn on to that level; you don't need to send a separate on, and certainly not first. I think setColor does the same, which may be particularly useful during scene changes. I can't remember off the top of my head if it's the same with color temperature. I still see this issue sometimes (especially when switching between color and CT modes), but I've learned to live with it. If you're writing your own app or rule, you can experiment with the order of things to see which works best. Obviously, if you're using someone else's or a stock app, you're bound to what it provides (unless you modify the custom one).
That being said, I'm not sure anyone else who's commented here so far has used smart bulbs (or at least color/color temperature bulbs). I do, and I understand your problem. (EDIT: Except the Sengled person above. If these are the color bulbs, I've still seen that problem there. And even with group messaging enabled, I still see a popcorn effect when I turn the group off. All probably a bit less since it's at least all Zigbee, but if you've ever used a Hue-only system you'll see how much smoother it can be.)
If you have the Hue Bridge, and it sounds like you do, it can coexist with Hubitat, as it looks like you might also know: there is a LAN-based integration with the Bridge that provides access to Hue groups and bulbs. Unfortunately, as you probably also discovered, this does not include Hue scenes. I feel like the bulk of these issues would be resolved if it did--Hubitat could tell the Bridge to activate a Hue scene, and the bulbs should all change as specifie, with no unexpected side effects, since it could do it over ZLL, possibly using information stored in the lights themselves (but even if the Bridge had to use its information, I imagine it would still probably be faster than Hubitat emulating this behavior on individual lights or groups).
There is a third-party integration called Hue B Smart that lists access to Hue scenes as one of its features. I haven't tested that particular feature to see how well it works, but you may want to try exploring that option. I do wish the native integration had this feature--maybe someday. And it's certainly possible to create "real" scenes as-is with a properly-written Zigbee driver, but I don't think anyone besides Mike around here knows how to do that, and I'm not sure that's on his priority list. Still anyone could knock themselves out with the Zigbee docs and try (OK, so those are for ST, but aside from namespaces it should be pretty similar). 
Sounds like you know exactly what I am talking about.
The funny thing is you mention that this behavior would still be present, even if using the Hue bridge, as that cannot expose scenes either. I am not sure what is right or wrong in that respect, but Hubitat support did tell me otherwise.
What happened is, before I bought my Hubitat, I contacted their support to make entirely sure that the functionality I needed was present. Unfortunately, obviously the advice I was given was unfortunately inaccurate, which is why I am currently in the position I am in now. This obviously adds insult to injury, as I really tried this time around to get it in writing before purchasing, due to the fact that I had made plenty bad purchases prior to this. So anyway, I asked Hubitat about what they could offer me in terms of compensation for my loss based on the inaccurate advice, but did not really receive an answer to that. Instead I was told the advice I was given was based off of the functionality when using the Hue bridge.
This makes me really curious about whether the unideal functionality I am seeing, is the exact thing as would have been seen with the Hue bridge. If that is the case, I feel like I might be missing something, and that could potentially affect where I go from here.
Have you personally tried this with the bridge.?
Tried what with the Bridge? I didn't create Hubitat scenes using Hue Bridge bulbs because I already had Hue scenes set up and Hue devices (Tap, Dimmer, etc.) I could use to activate those. I can't imagine it would be better than what you see now, however, since it would have to individually address each bulb or group (depending on which you choose) over the LAN, and I did have some Hubitat automations that changed color or color temperature (not using Hubitat Scenes but effectively accomplishing the same thing) and did notice the transitions.
What should theoretically be possible is for Hubitat to access existing Hue scenes, then send one command over the LAN to have the Bridge trigger the activation of that scene. That should be fast with no unexpected wrong/double transitions. The scenes would still be configured on the Hue side (not Hubitat), so it's not ideal in that you have two places to do things, but until Hubitat supports something like this natively, it's probably the best option. As I stated above, the built-in Hue integration can't do this, but the Hue B Smart app/driver set from the community is supposed to be able to. If you don't change your Hue scenes much, you could also probably use a virtual device (or rule, etc.) to send an HTTP command directly to your Bridge to trigger that activation, too.
Sorry did you not read my post this is possible but you will get a transition for the colour this is NOT hubitat issue it's the lamps its self. You can try enabling pre staging (this is it's job) but if the lamp doesn't support it your stuffed. So rather than throwing in the towel before you have tried why don't you give it a go with a different driver.
Oh I see. Sounds like that might be the only viable solution currently, if going the Hubitat route for the functionality I am seeking.
Unfortunately, I cannot simply go back to the Hue bridge, since my Hue bulbs are critical routers for my zigbee sensors
I did read your post, but I do not agree with you on not being the softwares fault. When other software can do it, obviously Hubitat can too.
Pre staging also does not work. It breaks the device completely till turned back off.
I can try with different drivers, sure, but it didn’t sound like it was on any kind of serious priority to @mike.maxwell so I did not want to push on that.
You may end up with a issue here as ZigBee lamps are known bad repeaters of ZHA which is what hubitat is. If you have both ZHA and ZLL products it better to separate them.
