I’ve got a bug in Scenes 1.2 - I’m using Osram RGBW Zigbee bulbs with the Advanced Zigbee RGBW driver. If a scene changes a bulb from color mode to CT mode, the level is never sent to the bulb; I have a nightstand that ends the night at 5% and red before it gets turned off. My morning scene is supposed to set it to 100% at 4000°K, but it only ever comes on to 5% brightness. For testing purposes I did turn on metering and dialed the delay all the way up to 1000ms jus to make sure there was no chance of the bulb dropping commands while it was changing modes. Unfortunately, no joy: the bulb sits at 5% every time.
Please turn on logging for both the Scene and the device. Then try it, and post a screenshot of the resulting logs here.
Hi there,
Here's a screenshot as requested. Interestingly, it does look like the level command was sent, but .002s after the power on command, even though metering is enabled for the scene and set to 100ms. The problem device here is named "Nightstand" and you can see it about 2/3 of the way down the log. The actual level of the bulb remained at 5% through completion of the scene activation and never brightened.
Have you tried using the generic Zigbee driver with these? I think metering is between devices, not commands to the same device, but not positive on that.
I used to in the past, and don't remember problems like this (I'm also having very similar problems with the same type of bulbs in groups here, which I was going to track with another thread), but I've not specifically tested that here as it's my understanding the Osram bulbs are supposed to play well with the Advanced driver. I do get some nice color fade and transition effects with the advanced driver, so I'd like to keep it if possible.
Here's another run at it with the bulb logging in debug, if it helps.
After many edits: conclusive results of what is going on below:
What is actually happening is this:
A CT or RGB change, coupled with a power level change, coupled with a level change, in the same command, will cause the bulb to do this:
- Start, and complete, the power command.
- Start, and fail, the level command.
- Start, and complete, the CT/RGBW command.
I was led astray earlier because the failed level command puts the bulb in an indeterminate state: its actual output is at whatever the level was before the commands were issued, but internally it is at what the commands instructed it to be. So the next command the bulb receives, regardless of whether or not it includes a level at all, will result in the actual level output finally arriving at the commanded output.
This can be repeated as follows.
Start with the bulb off. Then run the following:
- Execute HE power command: on.
- Execute HE set CT command: 4000, Level 100
- Execute HE set Level command: 5.
- Execute HE power command: off.
- Execute HE set CT command: 1700, Level 100
- Execute HE set power command: off.
- Execute HE set power command: on.
The actual resulting bulb output as a result of each command will be:
- On
- On, temperature 4000, level 100.
- On, temperature 4000, level 5.
- Off.
- On, temperature 1700, level 5.
- Off.
- On, temperature 1700, level 100.
I don't know if this can be fixed in the driver, but it doesn't seem like it can be worked around in the settings. I experimented with transition times in the settings and there's no way I found to get the bulb to do all three at once, regardless of what the bulb's default transition times are specified as or what the state change command requests. The results will always be the sequence above where the bulb internally believes it's completed all three, but will not actually output the desired level until the next command.
Many moons ago I used these bulbs with Osram's gateway, and it didn't do transitions at all for level or CT/RGB changes; the bulbs simply snapped to the commanded state. In that particular configuration, they'd be able to execute any arbitrary combination of power, CT/RGBW, and level. I was unable to recreate this immediacy by changing all the transition times to ASAP.
We will take a look at the driver for this, and see what's up.
1 Like
Awesome! If there's any more data or testing I can help provide, let me know and I'm glad to do so. Thank you!
I can say that this also happens with Ledvance rgbw bulbs. It says it goes to the level on the driver page, and actually does start dimming up, then bounces back down to 5%. Weird.
We've got the same equipment. 
They can't seem to settle on a name, but Osram, Lightify, Sylvania, LEDvance, and SMART+ are all the same thing. Confusingly, they have also started using the SMART+ brand for WiFi and BLE bulbs and plugs, but I'm all-in with Zigbee.
Osram and Ledvance use different Zigbee controllers and firmware. The weird thing is they didn’t change the model number.
Also, Ledvance lights transition one and off, where my Osram bulbs (rip) would snap on and off.
Is that so? I've amassed my collection over time. Some came in Osram boxes, some came in Sylvania boxes, and the base of the bulbs has varied between Osram and Lightify markings. For me, they're all running the same LEDvance firmware with HE, in any case.
The on/off transition default was introduced in one of their later firmwares, IIRC. I remember seeing it in the release notes in the old Lightify app.
On HE my bulbs labeled “Osram” on the side of the bulb would snap on, the ones labeled Sylvania Smart+ Transition. I remember being able to set the transition time in the Lightify gateway, but it didn’t seem to work in HE for anything but level changes on the Osram bulbs. If I used setlevel 0 they would transition, but on/off would snap to the level or off. Since most of my bulbs were Sylvania Smart+ I retired the Osram so they would match. They also didn’t match color temperature. 1500K was much richer for the Osram bulbs.
Yeah, there's a bug in the advanced driver (ct and rgbw), specific to using the level parameter within the setColorTemperature command to turn on the bulb if the level was different when it was turned off...
it either ignores the level or initially transitions to the new level, then back to the previous level.
A fix for this will be in the next 2.3.0 patch release...
4 Likes
I've had this same issue using the generic driver. I tried both drivers during troubleshooting but ended up just making all the rules two step.
I would be happy to test any fixes as I have at least two dozen Sylvania and Sengled bulbs on a dedicated C5 hub. I will be transitioning that mesh to a C7 but not until the GE outlets come back down in price.
That sounds like it will fix it! Will the bulbs need the configure button re-run after the patch?
I just noticed this as well with the Generic Zigbee rgbw driver. If I send the CT/Level/Transition, it doesn’t change the level or turn on the light. It just sets the CT (color prestaging is enabled).
Nope
1 Like
Right, prestaging won't turn the bulb on, that's how it's supposed to work...
But shouldn’t the level command turn it on?
