Has there been any progress in getting groups of the Sylvania/Osram Lightify bulbs to use the [start level change] and [stop level change] state variables that are available for the individual bulbs? I have tried to do this by addressing multiple bulbs individually, instead of as a group, and the result is (at best) popcorn effects.
What do you mean? This feature isn't available for group devices because there's no way to know if the group contains devices that support it. Plus, how are you going to do this for a group of devices all at the same time? The messaging would be a nightmare!
Sorry, but I'm a bit of a novice here. I simply made an assumption that because zigbee devices supported group messenging for the on-off commands, that the other state variables could be handled in the same way. I gather from what you say that it simply isn't so.
Zigbee group messaging basically floods your network with commands for the devices to get them to come on at the same time. If you were going to try and start/stop level change it would need to flood your network with messages over and over and over. Also, that's only for zigbee devices. Z-wave devices don't do that. So, when you "stop level change" which devices level should all the devices go to? They all might not be at the exact same level at that particular moment. It's a lot more complicated than what it appears.
Thanks for the explanation.
Zigbee Group commands are multicast, clasifying them as "flooding" your network is misleading...
Devices that are not a member of the given group just ignore the command, just as they would ignore any other command not destined for them.
1 group command is much more efficient than 20 individual commands sent at the same time.
Start/stop level change are two separate commands only issued once, they are not issued while a bulb is in transition.
For a zigbee bulb group levelChange would probably work reasonably well, it won't work for a zwave or mixed group as the commands could not be delivered to the endpoints at the same time.
That's the main reason it does not exist as a group command currently.
2 Likes
Which is exactly what I said.
But if it can be added for zigbee (only) bulb groups, like a bunch of Lightify bulbs, that would be cool.
@mike.maxwell’s clarification makes it sound like that’s entirely possible. I have several Lightify bulbs in a couple groups and would also appreciate this feature.
1 Like
The control device that is created for groups is the same for all groups. Even if you only have switches in the group, the group shows up as a dimmer with color and color temp control.
Understood, but maybe an update to the way the groups and scenes app creates group virtual devices would allow for something like this in the future.
Yeah, i struggle with the same thing. Currently the app only supports one virtual group type, that being an RGBW device, which works fine for mixed device type groups, not so well for groups of bulbs that are the same physical device. I need to think about how to add some options or advanced settings without breaking the current ui simplicity of just creating a very basic mixed device type group...
3 Likes
I have a question. Rgbw Lightify bulbs when they are connected to their own controller will retain the status of previous light parameters(hue,saturation,etc.) when the bulb is turned on by dumb switch. But when connected directly to HE the light status is not retained and the bulb turns on by default as 3000K white. Is it possible to retain the status of the bulb connected to HE when it's turned off by a dumb switch?
Perhaps creating multiple virtual devices akin to the Group Bulb Dimmer and then adding a single drop down for selecting the device type in the group creation?
Do you mean if you pull power from the bulb? You really shouldn't use a "dumb" switch to control smart bulbs. If you turn them off by a switch, you are pulling all power from them so they cannot be turned back on from the hub.
I guess I wasn't quite clear. I perfectly understand that if the power is removed from the bulb it's impossible to use it from HE. The question was whether the color bulb can retain its color parameters if the power was removed and then restored with the dumb switch. The color is restored with dumb switch when Lightify bulb is connected to their own hub, but is not restored when connected directly to HE. For example Sengled bulb color is restored using the dumb switch when connected to HE. My wife still wants to use switches, so I have to do something to improve the WAF
That's a feature that isn't a part of the bulb, but of the hub. The Lightify hub maintains a memory state for each device connected to it. To accomplish this in HE, they would need to have a specific driver for the OSRAM/Lightify bulbs. Sengleds store their state in the bulb's onboard memory.
However, with that said, there might be a workaround that you can use. Create a rule in RM that triggers on the bulb turning off (should be Switch>Off). For the actions, Capture the state of that bulb. Then, in another rule triggering on bulb turning on (might be either Switch or Physical Switch), restore the captured state.
I don't know if this will work or not. As far as I know, Sengleds are the only bulbs that send a last will message when power is cut to them, but it might be worth a try.
But wouldn't that also trigger if you turn the bulb on with a setLevel command, totally screwing up whatever level you just set the bulb to?
I don't know if it would work or not. I don't know if the generic zigbee CT driver sends a turn on before a setLevel.
That's not what I mean. I mean when the switchState changes from off to on, it will set the bulb back to the stored settings no matter what you had set it to already.
Ohhhh, I see what you mean. The RM rule should capture the current state of the bulb when the switch goes off and then restore it when it comes back on. But, on a setLevel, it wouldn't capture. Yeah, the OP would have to create rules to handle all that and constantly capture based upon any property of the light changing.
