Are they the new smart + ones with a QR code on?
On the Lightify. Although the Samsung plugs (2018) are Zigbee 3 and should do well with xiaomi as well.
I think they are the newish ones with Smart+ instead of Osram written on the side as well as old Osrams. I’m not sure where @iandogherty is from, but I haven’t seen the new Zigbee 3.0 Smart+ for sale over here yet.
1 Like
I'm in the UK. They're a mix - mostly older mixup of Osram Lightly and Smart+ branded with a small handful (maybe 5) Zigbee 3.0 with the QR code on the side.
Awww, there is the issue then my friend! Park that for now I have a few things for you to do to test/prove it but basically it's not going to work as you expect right now. It will soon though and technically it also didn't work on ST it's just that is so slow in comparison you hardly ever saw it.
These can stay on the main hub it's just the Osram lightify ones that are the issue. Depending on there age you may be able to get them RMAed and replaced to the new smart + ones.
1 Like
All this from the device page.
So if you turn them ON and set them to red for example then send a OFF. Then send blue or a kelvin level, the light will turn on but it will still be red if you now send the blue or kelvin again it will now work. Then do a OFF and flip what you did and your see the same, what is happening is the lamp refuses to change its attributes while in the OFF state the only thing that will work correctly is set level.
The fix is a new driver that @mike.maxwell is planning to do, this will handle the commands better and stagger the ON/level and the attributes.
The current work around is to stagger what you send ie if you want to set a colour send the level 1st then a 0.5s delay then the colour. The same with the kelvin. This is the same with the group device's.
This isn't a issue when using RM as you can do it, the issue is the built in apps are designed for all this to happen at once because the american lamps can do it. This may change though as all the zigbee 3.0 ones i have tested all have the same "issue"
1 Like
Oooh, tell me more. What's coming? And yes, I think I knew it didn't really work on ST it was just masked by that hideous latency. I guess my current little workaround of addressing both Group and Individual Bulbs means I'm sending the commands at least twice, therefore they all have time to process.
And just so I'm clear, is this new driver part of a general fix or is that just for the 3.0 devices?
Exciting times, thanks so much for the help and advice.
It should be a general fix, hopefully all 3.0 will work and the rest of us will use this same driver for these lamps. I think the issue is the only thing that had been tested was the American versions and why would the rest of the world with exactly same lamp just different PSU be any different? But unfortunately it is, then due to the issue it's not really a "issue" it just make things seem irregular and as if things skip a beat, so due to this I don't think it was picked up for a long time. It took quite alot to convince the team there was a issue because of this and I did load of debugging with mini apps with @mike.maxwell until eventually he gave up and he ordered one from the UK. Once he had a go and got the same results he was like they flat out refuse to except the command!
What he did say though was within the standard that aspect of it is abit grey and could be taken both ways. So that looks like exactly what's happened the developers in America did it the opposite to the rest of the world (I say this because the issue seems to be for everyone else except those that are across the pond).
1 Like
Thanks for the clarification! I have seen your previous posts on this issue and am flabbergasted that this could happen under the umbrella of a single company. I had assumed (obviously wrongly) that you were having some kind of mesh or hub issue and couldn’t believe that a company would have different implementations with the same device. Of course, there have been different zigbee controllers used in these and the model numbers have continued unchanged, so I’m not actually that surprised. I think, from what you have posted in the past, that we got the better deal over here with regard to functionality. Do you know if this behavior is due to some sort of regulation over there that the U.S. doesn’t have?
1 Like
Not sure but mike thinks it's this.
Purely that in the zigbee standard that this part is unclear. quote from mike below.
"one section of the zigbee color spec states that if the device is off, color commands are to be ignored, though I read somewhere else in the spec the opposite..."
1 Like
This is very good news, and I shall await the new driver with glee. Slightly frustrating is that I've tried more than once to raise issues with the team on weird behaviour of my RGBWs in Groups and Scenes - mike and bruce - and whilst they are responsive they are dismissive. It's no sweat, I manage teams of developers, I know what they're like, but it is a bit annoying that they've actually been squirreling away in the background on a known issue to do with zigbee rgbw!
In other news, the meshes seem to be settling a bit now and whilst I don't yet have the ability just to address Groups and the less said about Scenes the better (in my experience they just don't work at all, ever [not quite true but they are so unreliable they may as well never work]), it feels like I'm making progress.
Any tips on how to get Scenes to work?
It's probably the same issue I gave up on scene when I found the issue and in my case I haven't found a need for them yet. All my stuff is based on modes.
In fairness to them most people's issues are mesh related and as @Ken_Fraleigh put it seems like most people were ignoring my ply when I mentioned it. I also don't think people realise the issue so they don't point it out to Bruce and the team, so that is probably why it's been a over a year now since my testing! Like I said I have a work around but as no-one else is complaining about it, it gets pushed down the list. But it rose it's ugly head again with the new ZigBee 3.0 lamps and as the team are working on the Aurora stuff which has the same issue as they are 3.0, it's been brought forward but not priority.
So please don't just take my word for it send in a ticket about the issue aswell, state what's happening and that it's a driver issue and hopefully it will be pushed through quickly 
.
1 Like
Is your work around to turn switches on, then set ct and level with a slight delay?
1 Like
Also interested in what the workaround is - I tried swtching on the Group, then pausing, then setting Level of Group, then pausing, then setting CT of Group. Didn't make any difference! Still completely unpredictable.
You should be able to set level (which also turns on the lamp). Then put a delay on the CT value with a delay of 0.5 s that should do the job 
Edit yeah.
Interesting. Almost exactly what I'm doing - some differences but I would argue the flow is the same (is it?), and I get unpredictable results. All bulbs are switches that are ultimately groups on the other hub, those groups are setup exactly as per your screenshot with Group Messaging on and 'on' indication set; the only difference is that I do not have Optimization on after experiencing it on ST! (No idea if it's any better on HE but it was so utterly bad on ST I've steered well clear of it.)
Perhaps worth mentioning that the Bedroom All Lights Group comprises three sub-groups - BEdroom Spots, Bedroom LEDs and Bedside Lights - I get inconsistencies across all those groups.
You can delete the 'ON' as that isn't doing anything here and just creating more traffic.
What driver are you using?
Where is this Rule? On the light hub or the main? I would think the rule should be on the light hub with the button exposed too it best.
Yeah much better, but it shouldn't cause a issue here either way, unless you have mesh issues.
Yeah I haven't tried it in that set up, have you tried creating a new group with all the lights in directly rather than the group's. That way it's one ZigBee message rather than 3.
By the way just to be clear, the group's NEED to also be created on the light hub otherwise it won't work. You can't create them on the main that's not the same as creating the group on the light hub and exposing that to the main.
1 Like
I'm using the Zigbee Generic RGBW driver: when I was still on one hub I had tried the Tamed driver, but it didn't make much odds so I've reverted to stock for now. (Generally I'll use Stock where possible, keeping it simple avoids too many complications to debug. Happy to switch to another though if you have a recommendation.)
The Rule is on the 'Other' hub where the switch is, with all the Lights and Groups and Scenes created on the Lightify hub and shared back to the 'Other' hub. The Lightify hub has all the Osram bulbs on it and nothing else (other than their Groups and Scenes) - no zwave radio, no other zigbee devices, no Rule Machine. The physical switch is an Aeotec Quad so sits on the 'Other' hub.
I hadn't considered sharing devices from the 'Other' hub to the Lightify hub; do you think that's preferable?
I'll try re-creating my 'All' group with all the individual bulbs rather than other groups.
Yes I believe generally that's what people do they keep all light things in one place, it's just the ZigBee your separating. Think of it this way in terms of events what's the most cost effective. Sending one event from one hub to the other (i.e the switch) then the local hub doing all the work directly or one events triggering the rule and then all the multiple events it needs to send through hub connect and in turn on the other hub to then turn on the lamp. Also the delays may be getting lost?
I have my lights on one hub and almost all of my button controllers, motion sensors, contact sensors, and automations on another hub. A few automations are on the hub with the lights and I can’t tell any difference in speed versus automations on the other via HubConnect.
