So obviously didn't read my post as I said @mike.maxwell found that EU lamps are different to American ones and he created a driver for me unless he gives me permission I cant pass it on. He said his plan is to create separate drivers for eu and America along with other enhancements but it's not high on the list right now.
But untill then with his work around driver I hardly see the transition as it's done in the driver and is super fast.
A slight transition is much better than it sometimes changing sometimes not and with hubitat being super fast it changes with the mode or the motion detector and I don't see it. The issue only with colour to Kelvin changes or visa versa and if the fix is still not good enough for you just right a rule that turns ON the lights if they are off when the mode changes set them and turn them back off again.
Seems to me the that a color prestage would only solve one problem. "True" scenes would eliminate popcorn and probably most of the (small but still quite different from Hue) delays. I did neglect to mention that possibility,mp however, nor have I tried them on my bulbs yet.
And also, I agree: Zigbee smart bulbs tend to be bar routers for non-bulbs. ZHA traffic seems to be too much for them to to handle, so you might end up loosing some transmissions. That's why in my experiment above, I had them on a separate hub (which the Hue Bridge also solves).
Oh, well depending on what he says, I can give it a shot, and then judge from there... @mike.maxwell
This might be off base, but do you have a transition time set for your scene? I had exactly this same problem with scenes using CT bulbs. I had transition time set because sometimes I like a nice, slow transition from one scene to another. Once I removed transition time, the scenes worked as expected: i.e. one “on” to turn on a scene or switch from another scene, one “off” to turn off.
I’m in the US. I am using Hue bulbs via the Hue hub.
I’m pretty new to HE (just a couple of weeks) so I’m far from having everything figured out. So far, though, there’s only one thing I haven’t been able to get working. My kitchen lights are set to 5000K during the day. Just before sunset I want them to change to 2900K over about 5 minutes. If already on, the color should gradually change. If off, they should gradually transition to 100% at 2900K. When I was still with SmartThings, I used Stringify to accomplish this. With the death of Stringify (RIP), I had to find some other method. ST couldn’t do it. I couldn’t write a WebCoRE piston that could do it without popcorning. So I used a Hue routine. I’m still using that same routine. It works great, exactly as I want it to. There’s probably some way to get it to work in HE, but so far I haven’t found it.
Maybe it works fine in my case cause I only have temperature/humidity, motion, vibration and water leak sensors?
None of these have been any issue running with Hue bulbs as routers in either deCONZ or Homey. I did lose connection to specific sensors repeatedly at one point, but after a reset, they’ve been solid, so must have been the sensors problem.
With my sylvania lights I can send sethue and setsaturation or setcolortemperature commands from the drivers without the lights turning on. then a setlevel command turns them on to that level and they turn on already at the color or color temp I sent. Couldn't a scene be set up this way using rule machine or button controller? This uses the bulbs memory for color prestaging.
I just realized that I you are using Hue lights without the hue bridge. I have the bridge with 23 lights connected and I don't experience this issue. The bulbs come on without popcorning to whatever scene is selected. I did have this issue with my Sylvania RGBWs when I first migrated to HE, but since RM3 was released it hasn't been an issue. I just have RM issue setcolortemperature followed by setlevel to the group of lights using zigbee group messaging and they all come on at once to the scene I have selected. I only have issues if there are setcolor commands mixed with setcolortemperature.
Hue Bridge uses their own group messaging, so no popcorn effect.
I can tell you that the Hue Bridge integration performs exactly as you want it to. Tell it to turn on to red, it turns on to red. Then turn off, Tell it to turn on to blue, it will ramp to blue without ever seeing red.
Same with level or CT.
I use it in my house in many different areas. It's local and fast. Supports multiple hue bridges as well if you are over 50 bulbs.
Exactly, I use a few cheap peanut plugs to extend my sensor mesh and run dual zigbee (heck I have a ton of zigbee meshes these days for testing)
It is highly advisable to put bulbs on their own mesh... They simply do not have enough space to handle routing nor were designed to do so for anything other than bulbs.
I also offload my shades and dimmers to lutron because they do it best as well. Hue bridge for all my zigbee bulbs.
Hubitat is the coordinator that makes it all work exactly how I want it, and sounds very similar to how you want it.
Relying on bulbs to repeat sensors is a recipe waiting for disaster, IMO. With the many zigbee channels and having proper zigbee repeaters, my sensors are extremely reliable. Even prior to Hubitat I had nothing but problems when I introduced bulbs into a ZHA mesh...
My next project is to move all the bulbs on to hubitat and wait for @mike.maxwell to implement proper scene support for zigbee so then I can use hubitat the same way I use hue bridge. But I will still keep them separate for stability reasons.
Try the hue bridge integration with a few bulbs and see for yourself. Should give you enough time to wait for scene support to be added.
So Patrick, what you are saying is that it's all Mike Maxwell's fault. 
Actually quiet the opposite, he's the person to add this... Just need to convince him the value of it relative to all the other great things he's working on...
So then it's your fault for not convincing Mike.
I've already started moving my Hue Bridge bulbs to (a fourth) Hubitat hub , but adding true Zigbee light scene support would be amazing. Adding the ability to read existing Hue Bridge scenes to the current Hue Bridge integration would also be a close second, since Hue of course does scenes on its own quite well (though the Bridge doesn't seem to store them in a clear manner--looking at the API output, there are a lot listed for me, and it's not always obvious what they are). I might go back to to using the Bridge, but I just wanted to try this for a while and see if/how it works better/differently. I'd be much less likely to go back should Hubitat get "real" Zigbee bulb scenes, but if this isn't on Mike's plate yet, something else cool or useful usually is, so it's a win either way. 
True, but only if you use the exposed Hue Groups. If you individually address multiple bulbs from Hubitat, I'm pretty sure the Bridge isn't quite smart enough to combine that into some sort of group broadcast (if the API even allows for this--I imagine it's just a bunch of individual calls), but I could be wrong. It's not terrible, but if you've ever changed/used "real" scenes with a Hue Tap or Hue Dimmer (or I guess using the Bridge to activate it--which is probably tehnically possible with a virtual device and a bit of work as-is as I theorized above), the difference is notable.
Thanks for pointing that out. You are correct.
Mine didn't 
again even with the hue bridge and hue lamps there seems to be a difference in the EU + I was unable to join Osram lamps to the bridge like I thought I could.
Even in the Hue mobile app? I have Hue colored bulbs and hue light strips that do this just fine.
Never actually tried them directly within the hue app 
I want my place to be automated so wiping out a app was never on my list. How I tried it was depending on the mode the z-wave motion detectors turned on the lights to different Kelvin levels but in sleep mode they would come on red and 1%. This is when I noticed the issue because if you would trigger the motion after it became inactive but before the time out the lights would go to the correct colour but not before. This is when after working with mike he ordered a EU lamp and tested it then found out the issue.
I then had some fail so got my money back from Amazon, so I brought a set of hue with the bridge thinking they would work and I'll move the rest there. But this didn't work either the lights didn't change until they were in the on state, but with mike's driver on HE they work but there is small transition.
Alright, I have now clarified about some of the points that have come up in this thread, and I thought it would make sense to share.
Apparently a lot of people have the wrong idea about some of the factors around ZigBee.
ZHA and ZLL are higher level in the ZigBee stack and meshing is in the lower part. Therefore this is irrelevant to the compatibility when talking about good routers etc.
Also, Hue bulbs, specifically, are known to be some of the very-most reliable routers you can get.
As ZigBee is open, there can be variances in a lot of things. Most however are at the higher (ZHA/ZLL) level, but some can affect meshing.
So the hub can actually make sure that no problems will occur, pretty much regardless of which things you try to combine in a mesh. What deCONZ does is build a map of the network, and poll devices for their neighbors, which can be problematic with some routers - however with Hue it is not.
Sensors, when paired to deCONZ must always be paired at their final location, because they stick to their routers indefinitely, and can easily break connectivity if routers are powered down.
Hope this can help remove some of the fuzz about all this.
Never heard anyone else say that... Not 100% sure that is fact... Most bulbs have very small memory footprints and have small routing table capability and/or small memory buffers that can get easily exhausted. When exhausted they start dropping packets all over and are not reliable repeaters. That behavior is very sensitive to the size of the zigbee mesh and how many devices are routing through the bulb.
Maybe the Hue bulbs are different (very possible as some bulbs CAN be OK repeaters)?
Pretty sure that is not true as a blanket statement. Otherwise that is how EVERY hub would work, and we would never have mesh issues... Which people do in some configurations, on many different manufacturers hubs.
I didn't think that type of behavior would be compliant with the Zigbee spec? End devices and routing radios aren't supposed to stick to a fixed route. They do stick to a coordinator, but that isn't the same as what you said.
I don't claim to be a zigbee expert (there are a few of those on here, I'm sure they will chime in if not too busy). Just relaying my understanding - and 5 minutes of spot checking/googling didn't prove me wrong...
Well, I’m for sure no expert either. And I didn’t waste time Googling myself to death on it. I just asked a professional in the field to get the rights and wrongs, as I could clearly see some misinformation being spread in here.
I’m not gonna comment too much on your other points. Makes no sense to talk about sticking to a coordinator, as, you know, that’s what they all do. Sticking to their router is a lot more interesting though, and might be the reason deCONZ is better than the competition?
