How about 2 new options when displaying a Rule:
- Is it presently running (and if possible, how many instances of it)?
- Clone option from the rule screen
Thanks
Alan
I believe I read recently that the second request is coming soon (as well as the ability to clone "any app," by which I assume they meant literally any and not just the handful of built-in ones that already allow it, but we'll see!).
As for the former, "running" is somewhat of a vague term, but in a strict sense it might be interpreted to mean only rules that are currently executing something in the Groovy/Java sense. For most rules, this lasts for only milliseconds or perhaps seconds at a time and would be difficult-to-use information. When you reach a "Wait for...," "Repeat," "Delay," or other action, the app (rule) creates either a device/event subscription or a schedule, then goes to sleep until that event or time happens, at which point it will resume with whatever it is supposed to be doing; in the meantime, it's not really "running." If another trigger event happens, however, it might be notable that the rule has been "re-entered" in some sense.
If "re-entering" is all you care to keep track of, you can do this yourself: create a local number variable, start it at 0 (in the UI), increment it by 1 in your first action, and decrement it by 1 as your last action--making sure that action path is still reachable (e.g., that you don't have an "Exit Rule" that might be reached before it, or a "Wait" that would be cancelled by a re-trigger). You can view the value of this variable in the UI whenever you want (or you could log it, perhaps as your second action, if that works better for you). Note that any time you hit "Done" or "Update Rule," that erases all waits/delays/repeats, so you'd also need to manually re-initialize this to 0 then; you can make changes to a rule's actions (or, of course, just view them) without hitting these buttons, and they'll still be saved, so you can avoid this headache that way unless you really need to "reinitialize" things.
It might be possible for them to do something like this built-in, but I imagine they'd have the same difficulty coding in this logic that you would if doing so manually. 
(When the actions are "done" really depends on how you wrote them, what your triggers are--and what your intentions are for the rule.) Careful planning of triggers and waits or the use of Private Boolean or another method to prevent re-entry is generally good enough to avoid this if re-entry is problematic for your rule. Two instances truly "running" the same time is often problematic (the rule/app only has one shared state in which to track things) and usually easily avoidable by careful consideration of triggers, or addressing issues at the device level if you're getting something like double events. Trigger and Action logging are often enough to show you if this is happening if you're just curious for troubleshooting.
Also, if there is a specific problem with a rule that you are trying to solve, sharing more information about that may be helpful if you are interested in pursuing that route. Otherwise, just some tips that may help in the meantime, since not all feature requests end up happening or are easy/feasible to implement. Good luck either way!
Thanks for the feedback. Glad to see #1 is sort of coming. I just would like for it to show on the interface on the rule creation and not just on the Master App ("Rule Manager" or "Rule Manager Legacy".
#2: I do that already (variable to tell it's running or has run), but want to see something like "Task manager" but on the rule itself if possible. I understand different "states", "delay", etc. Appreciate the comments though.
Alan
Woot! Woot!
Great!
