Yes, if this is how you want to solve the problem, it's possible. You can make a trigger and a rule to do this.
The first trigger, activated by a switch assigned to your scene (or whatever you choose) would turn on the lights and repeat the actions every x seconds.
Action
And the action of the first trigger also sets the private boolean of the second trigger to True.
Action
The second trigger, is activated by the first trigger setting its private boolean to true and then after a delay, it will stop the Repeat Actions of the first trigger.
Note: You have to build the second trigger first, so you can select it to set its private boolean to true in the first trigger.
Well the latest update did not fix anything for me with SL. I created a group for the 13 potlights and turned on the Zigbee Group Messaging. I then added that group to my SL rule and it only turned on 10 out of the 13 lights. I can go back to the portal, devices and turn on the 3 missed lights with no issues, so it is not a signal issue. Even my turn off rule that I run at 11pm doesn't turn all of them off.
This sounds as though some of those devices don't actually support Zigbee Group Messaging. This has nothing to do with Simple Lighting. Could you try removing some of these from the Group just to see if that might be the issue?
Or, another question for you: If you turn on the Group manually from the Group device, do they all come on and all turn off?
The problem lies with Zigbee Group Messaging. It sends out a broadcast message, instead of the normal handshake protocol. So if a device misses the broadcast message for whatever reason, it won't turn on or off. That's a weakness in Zigbee Group Messaging. If this behavior is prevalent, we'd be better off just not even offering this feature --- OR putting big caveats out there about the fact that it may or may not actually work for a given set of bulbs.
Broadcast is always a hit or miss proposition. If it works, great, you get a nice simultaneous on effect for some bulbs. But you're seeing the downside of it.
@bravenel Yes all of them did not come one. I have 3 Sylvania Smart+ outlets around the house in the same place as when I was using SmartThings. I had no issues with ST after I added these 3 outlets, but I am having issues with HE.
But I didn't have any issues with ST. HE is on the Zigbee channel 19 as the ST was (ST hub currently unplugged). The repeaters are in the exact same location when I was using ST, so it has to be something with HE.
Not necessarily. When did you add the repeaters and when did you add the bulbs? Your mesh might not be in the exact same state as it was in ST. It sometimes takes days for a mesh to self-heal, especially if you've been adding a bunch of devices.
I'm seeing similar issue of lights not being turned on or off when in groups. I had to create RMs to basically check if any members of the group were in an opposite state to the group master/parent.
Also periodically refreshing everything that can be refreshed helps HE keep state with the actual lamps.
Neither of these should be necessary if the transport layer was reliable.
Might be useful to include this functionality in the Group app itself.
I'm my case its all z-wave its happening to currently. I have ordered some A19's to give Zigbee group messaging a try, to eliminate the popcorn effect.
Heres a thought, it seems others may be seeing similar issues with other devices eg locks. Could this be an issue when firing commands to multiple z-wave devices at the same time, that message delivery gets unreliable under these conditions? maybe they should be spread out in time, or serialized differently to not be talking when it should be listening for state change messages coming back?
I'm interested in just the Logs from the app itself, which would show any errors thrown by the app. If for some reason it threw an error part way through the list of devices to turn on, that would kill it. That would be one possible explanation for what you're seeing.
