Are you sure? It was on the list Mike made with capability updates back in 2.2.6, and it seems to work:
The "Advanced Zigbee..." bulb drivers were the first to use these, I think.
What is not on this list are similar commands for CT and color. I noticed a few new built-in drivers already have those unofficially as custom commands, though, like presetColorTemperature() and presetColor(). Could those be what you're thinking of? As far as I know, those are not standard (yet?), though they would be equally helpful. (All of these address the "prestaging preference" problem.)
Yes, I am sure. That list was made in error, and has not been cleaned up as it should be. Those Zigbee bulbs that appeared to support it actually were out of spec (we discovered), and Zigbee doesn't actually support it.
As I said, we have no plans to pursue this in any way, and have some cleaning up to do. It was a path we thought we could go down, but cannot / will not. The only app that could possible be used to deal with it is RM, with custom actions, etc.
New to Hubitat and having a tremendous learning curve with room lighting. Is there a way to easily group lights to turn on all at once. I have 4 colored wiz bulbs in a kitchen fan and in my bedroom fan. I'd like to turn and off all at once. Instead of seconds apart from one another. It take several seconds for them all to turn on. To turn off those lights is the reverse process of each bulb fading off one at a time.
Not sure if it's allowed to talk about the other hub but coming from ST. The group would be in automation and just go on or off all at once. I'm trying to learn how to effectively use the built in app's in HE without resorting back to webcore.
Create an activator device by putting a device name in the field and click update.
Under 'Means to Activate' -> 'Active Lights Options' -> Tick the options for:
Activate even if already partially Activated
Activate as group with ON command
That's it. Use the newly created "activator device" to control them as a group.
Great. Thanks for this step by step response! I'll test it out.
Do I setup temp and level settings for different schedules within that room lighting group or in the actual room's lighting that uses the group?
Also, can you explain what Act/Off/Force is and when do I use those switches? Very confusing. I've read it a few times and from my understanding, I use those switches if I want that specific bulb/switch to be activated or turned off? So if I don't want the light to come on during certain times, I'd need to have un-checked ACT for that scheduled time period, and have the OFF checkbox checked?
That setup would not use the table, ever. You would adjust the lights using the activator device. Bruce does a really nice job of explaining it in this thread. If you want to use the table settings, then you would remove the "activate as group with on command." Essentially, if that setting is enabled, then turning on the activator device just turns the lights on. If it's not enabled, then when you turn the activator device on, the RL instance will apply the table.
Act = will the device be turned on and configured when using the RL table
Off = will the device be turned off when using the RL table
Force = ignore the device's state and send commands anyways. With this turned off, if the RL instance thinks the device is already off, and an off command is sent (like turning off the activator device), then the RL instance will not send the off command (because the device is already off). If this is ticked, it'll send the commands regardless of what state (on/off/color/color temp) the device is in.
The force setting should be fine to leave enabled in most scenarios. It can save on traffic processing/load if you're commanding a large amount of devices. So, say you have 20 bulbs in the RL instance, I would probably uncheck the "force" option (there's other factors that go into this).
I believe I understand how the groups and tables work based on your explanation and reading that group post. Much appreciated for this.
I'm still confused to what option I'm selecting for my scenario. I just want to confirm because it doesn't explicitly state all the bulbs will go on at once if we don't use group with ON option.
There are only 2 options to activate as a group and the other doesn't apply to my scenario, as my bulbs are wifi.
Also, what Type do I select in the table for the activator device/group device in my RL for that room? Do I select CT as the type if the group device has RL color temps and schedules attached to it?
My main goal is to make sure that all lights in that group turn on at the same time when it's triggered by RL for that specific room. However, each group in the room has it's respective temps and colors based on schedule throughout the day.
By default, RL turns the devices on as a 'group' (meaning it tries to turn them all one at a time a few tenths of a second apart). I know the verbiage can trip folks up at times.
If you want to configure the level, color, CT, etc. using the table (and time/mode transitions, etc.) then you want to turn off the "activate on as a group". That's only if you're using the activator device to turn the lights on (like through RM, dashboard tile, another RL instance, etc.).
If the lights are only going to be controlled with the RL instance, then you don't even need the activator device (and consequently, the 'activate as group' setting doesn't matter).
That's the main issue, they have a pop-corn lighting effect. Each one turns on one after another and turns off in the same manner. I just want to group them to turn on at the same time with their time based lighting profile. The same thing is happening with button controller when I use a button to trigger lighting in the bedroom. I figured grouping would be the best option to get them to turn on and off together. I just need to figure out how to group and give them color schedules.
This isn't really true. It turns on devices one by one unless they are in a Zigbee Group Messaging group (which these are not). But, upon activation, all devices that are not already on will be activated one after the other in quick succession.
There is no way to avoid this with WiFi lights, irrespective of the way you turn them on. Each has to be individually addressed, and Wifi are the slowest of all.
The app doesn't wait for a response before commanding the next device. There is some refresh in the UI, as WiFi bulbs are slow to respond and report their new state. But that has nothing to do with commanding them. You can see this in the logs, and with Debug logging enabled, you can see the device responses. You'd see command, command, command, and later response, response, response.
Is that a limitation of the hub and how it sends the command? Does HE's hub communicate to WiZ's API in a different manner? I just don't experience this with ST. I really wanted to move over completely to HE.
On ST's platform, I press my ST button and the scene or routine kicks on the lights all at once. A second at most. I don't have to wait 30 seconds for 4 light bulbs to turn on. Granted first bulb turns on immediately with HE, but then takes 3-5 seconds for another bulb to turn on.
I'd like to attempt to attempt to group them and see if it'll work out better. Do I use Adjust lights on Time Period Changes in other activation options for it to use the schedule table?
I guess my wifi lighting will have to stay on their platform for now. All of my lights are wifi based. I know ZigBee is king, but just started out a few years ago and didn't have much understanding of where I wanted to go with my smarthome and the limitations on wifi products. Glad to see other power users have implemented drivers to work on both platforms, didn't realize they act differently based on how it's coded. I guess it's patience for now and a repurchase of ZigBee bulbs down the line.
I just imported a scene from Groups and Scenes into RL and it showed up like below. The State column in RL shows all of the blinds all off, when in fact all are on/open at the levels indicated in the Level column under the Activation settings. I've tried refreshing the RL page, that doesn't change anything.
When I import a Group the correct state is shown for all devices in the RL table, one example below. I checked w/two different groups and they show correct current status in the State column.
Wondering why the difference in displaying device status in the State column between my imported scene and imported Group. The device state does not change if I activate the scene from the "Activate" button on the RL page.
(All of these address the "prestaging preference" problem.)
I'll test it out.
