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.
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.
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...
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.
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).
I'm get strange behaviour, if the light is off and I press the set colour temperature with a level it turns on and sets the level and temp as expected
But the same command from motion lighting only set the temp but doesn't alter the level from what it was
Updated to latest version this morning @mike.maxwell it doesn't seem to be fixed in latest pach
