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?
the whole premise of zigbee is that its a mesh network and it "HEALS" itself so sticking to one route would defeats that purpose?
That's not exactly the whole premise. It is one thing that is possible, yes, but also one thing that is prone to breakage. So deCONZ apparently left that out, to make sure it is stable. Who goes around moving their sensors anyway?
it's not about that its about ensuring the message always gets through, so if one device dies or is down powered the mesh takes care of it.
But if you just use good and stable routers like Hue bulbs and put constant power on them, what is it then you are worried about?
Stable static routes are, in my opinion, always preferred to dynamic routes.
Download the Hubitat app
