Not following, do you mean preference settings?, and if so which ones...
It should be, colors will never match...
1 Like
Which transitions?, there's level, color to color, color temp and on we go...
1 Like
Sorry, just mean dimming.
Is color prestaging a possibility for wifi bulbs like LIFX and Yeelight?
I don't know, not reviewed so there of these from that context. I beleive, but have not verified that this is possible with the hue bridge...
Which zigbee bulbs are confirmed to work with prestaging?
I think the better question is, which device/driver combo is confirmed to work with prestaging and still report correctly? I've noticed that the Sengled color bulbs report as off when turned on in CT mode if prestaging is enable..
I've not tested every single bulb, but the option is there in the drivers already , it's also a mandatory command for the zigbee color cluster...
Sengleds get all new drivers in 2.1.4, so if there are remaining issues we won't be fighting with breaking other bulbs...
The big change for these drivers being power loss state reporting and fade on and fade off support via a default transition time preference.
Many like these to fade on and off, others dont, now you can choose...
Unfortunatly these bulbs do not support setting the fade time in hardware, so fade on and fade off will not work with zigbee group messaging, they will default to their rather abrupt transition time.
4 Likes
I'll see if I can add it - I think I was asked at some point to force a bulb on when changing colour or temperature.
Just to be clear, does that mean you want to be able to issue colour/temperature/level commands and then follow that with an on command? Not sure what the implications are there for the duration settings for a colour transition. There is a duration for the on/off though
If the device is capable of changing color while off, such that turning it on will reflect that previous color, then one just needs to set the transition time to 0, or as fast as possible.
The whole concept of prestaging is so that some other app can worry about setting colors, levels and color temperatures behind the scenes, this allows rules that manage the light to simply have to deal with on or off...
It also allows you to control, ie eliminate color transitions if they are distracting or undesired.
1 Like
Scratch that, it looks like it is capable of receiving CT before on/off. It does force them on though. When using "CT per mode", it works as expected, so there's no need to make any changes. It doesn't work with the Circadian Daylight app though, which is where I was getting confused. That's due to how the Circadian app is written though, not anything to do with the LIFX drivers. The Circadian app waits for an on/off report from the bulbs before changing the color.
The drivers do default to turning on the bulb if it's currently off, although that happens after the colour/temperature change.
Ah, thanks for those clarifications 
Makes sense.
Yes, so rules can be written to simply set the CT in order to turn them on. Although whether this is ideal will be determined by whatever standard this thread is attempting to set.
For color temperature, I'm thinking it might be possible to use a number of rule 4.0 variables for those who desire a higher gradient of CT changes above just 'per mode'. If so, you could just have the bulbs reference the variable, which would be set by time of day - and no prestaging necessary, unless that particular bulb has trouble with it.
You mean have the driver reference an rm variable?
I guess I'm not understanding...
No, have rules reference RM variables. Just thinking of ways to use more time-based CT options natively within RM. (I'm just now changing all my rules to 4.0 and thinking of new stuff to do.)
1 Like
