Newbie Day 5.
I know exactly what I want to do, but don't have a grasp on rules yet. Here is what I need.
I'm assuming this is not all that difficult, but I just can't grasp it.
during your 7 minute cycling duration, How fast are the loops?
So you have a rule which triggers and is true so long as DDD is on and 7 minutes has not expired.
the missing part is what regulates the looping. Every 1 second perhaps? Flash lights every 10 seconds. Some random period.
Then what state should the triggering device be returned too at the end?
Untested off the top of my head I scratched out this.
Not sure the off action after the END-REP will wait for the reps to end.
There are other ways to do this. Like setting a variable turn and looping until it gets set false. Most of my rules go through several refinements before they actually work as hoped.
Sorry, I was getting confused between Rules and my old X-10.
Maybe this will make more sense.
I did it this way because I did not know exactly how Flash works or if it can be done to switches. I have no objection to using Flash if that is better.
I honestly hate Rule Machine logic. This is how you can do it in Webcore. Note that Webcore reads very much like your 5 steps.
Edit: I would be happy to help you write this rule in Webcore if you chose to. Some of the things there, like adding the addMinutes() method in an expression, may not be clear for new users.
Also, you will need to seed the lastRun time for the very first run, by setting it in the Variables section of the piston page by clinking on the edit button, and setting a time greater than an hour before present time.
This is my 6th day of being in the Hubitat world. Your message is the first I have seen anything about "Webcore". As a former programmer, I totally understand your example, and it seems like something I should learn.
Flash is a bit dependent on the device driver for the timing or if it works at all. That was one of the concepts In the Hubitat learning curve. It is not all rule. But device and it's driver plus trigger events. Triggers can be part of the logic.
I am interested in that too. From what I gathered, it is a cloud based service required to create "rules" they call pistons which are then loaded into an app on Hubitat which runs them locally. Some know enough about coding and their devices to run their automation using GROOVY.
Webcore started with SmartThings when they still had the Groovy cloud. Many of us here now jumped from SmartThings when they eliminated the Groovy cloud based approach, because Webcore also ran on Hubitat, since it is Groovy based. Samsung killed the ability to run any Groovy apps in SmartThings, including Echo Speaks, when they killed Groovy. There are still apps around in this forum that were converted from SmartThings apps to run on Hubitat.
So, for Webcore pistons on Hubitat, all processing is local on the hub, the difference is that the dashboard for creating and editing pistons is in the cloud. Not a bad thing, as you can write and edit pistons from anywhere in any browser, and the pistons get updated on the hub when they are saved.
Webcore was a community app, and it still is, but it is also a built-in app now. So you can just install it as a built-in app on the hub. In settings when you open the app, you have to choose the devices that Webcore can use. Then you get a code to authorize any browser, or just open the dashbaord right from the Webcore settings page on Hubitat.
The dashboard page is where you create new pistons. A piston is like a container for your rules. You can have as many independent rules in one piston as you want (well, there is a limit on how big it can be), but generally pistons are used for organizing your logic rules. A piston should be focused on things that make sense to go together. Since each piston has has its own local variables, you would combine rules that might need to access and modify those variables in the same piston.
Further, you can call other pistons from a piston, and send them data values as parameters for it to run with. You can make a "common" piston that does something that multiple pistons can call. This allows for code reuse among multiple rules in other pistons.
I just like how it mimics actual code, so the logic flows just make more sense in Webcore, at least to me. I will need to really study a complex RM rule to figure out what it is doing, but Webcore reads like it runs.
Community
Getting to Know Webcore
Becoming a Master with Webcore
String Functions
Edit: I didn't mention it, but arrays are really handy in Webcore. You can make a local variable that is an array, though they are really maps, though they are labeled arrays. You can use numerical indexes, but you can also just use key:value pairs to store data.
Edit2: One thing I missed early on was the use of the device variable. You can set a device variable that contains a bunch of devices as an array, and then there is a "For each device" loop you can use, that will iterate through all the devices in your device variable list, for when you need to do something like that.
I'm not sure you need a loop. The flash command, when supported, is persistent until you turn the device back on or off. How about:
Trigger: when DDD turns on
Actions:
Devices with drivers which support flash will have a preference for setting things about the flash. Those preferences often can be pushed to the device with attributes from a rule.
I think I'm better off controlling the flashing in an on/off loop. I have a bunch of devices and I want them all to flash in sync. A loop allows me to easily experiment with different on/off times.
Probably are. But if your flash rate gets to high you risk saturating your mesh with on off commands. The only devices I have which support FLASH are smart bulbs. None of the switches or dimmers do. Makes sense as there could be a design limit for off/on cycles.
My Switches and Dimmers support Hubitat's FLASH command. I use Lutron Caseta switches and dimmers. Prior to Lutron, I used GE/Jasco Z-Wave switches and dimmers - I believe those also supported FLASH.
My Philips Hue bulbs, connected via Hubitat's built-in Hue Bridge Integration, also support FLASH.
Good luck with that!
If they do then do they support parameters for the flash function? If they do, you could update the parameter for rate and what else then send the flash command and be good for a while. Every thing we are able to off load is a win.
Agreed!
There is one possible way to do it if one uses all Zigbee devices (directly paired to the hub). One can create a Group of Zigbee devices, enable Zigbee Group Messaging, and then use the Group Device to control them all at once without the popcorn effect.
While the Hubitat Flash Capability states that an optional parameter is available, none of the device drivers that I use support passing in that parameter. 
Update: It appears you're referring to changing/setting Z-Wave device parameters programmatically, correct? If so, that would be very device dependent. I do not use any Z-Wave devices these days, so I can't be much help there. 
Download the Hubitat app
