Sticky timers

Just rambling here. Seeking comments on the viability and value of creating sticky timers.....timers that did not reset when a new trigger occurs. So, if I create a rule with 4 triggers, and 4 actions determined by those triggers, one trigger would not inhibit the other 3 actions. I suppose this would invite a never ending merry-go-round effect.

Can you provide a concrete example of either something you're doing now that doesn't work the way you expect or an automation you want to create that works in a specific way?

In general, you have two options for "timers" in rules: waits and delays. Waits do get cancelled automatically when a trigger event fires; delays do not (but you can do so manually). So, in that respect, you already have options. Second, it's not clear to me whether you want one rule with four triggers for four different sets of actions, one corresponding to each trigger; in that case, I'd say it's better to simply write four different rules (as used to be common saying, "rules are free," though Rule 4.x is more powerful than its predecessors and does let you do more in a single rule than was previously possible, so it's not quite as commonly heard anymore).

My Auto Off user app seems to have died recently, so I was trying to create a rule with multiple triggers that would turn off various things when a time period expired. Here is the beginning of my rule - which I feel won't work because of triggers resetting timers.

image

So I think that's basically the second issue I raised above: while the general pattern is the same, what you have is different triggers doing totally different things. One problem this raises is how to make only the specific set of actions run for a specific trigger, which your rule doesn't actually handle in all cases, though it does in some. Consider what happens if the Sengled bulbs turns on when Computer Lamp is already on--both conditions in your rule above will be true, so both sets of actions (and "timers") will run. Nothing makes only the actions for your Sengled run, though that will indeed happen if Computer Lamp is off--which is presumably your intended action (and only this) in all cases if the Sengled was turned off.

(If this doesn't make sense, triggers are events and conditionals are states, and that's why this works the way it does. The trigger fires if an event on the platform happens, like a switch turning on or off; conditionals, as you can use in actions, check the current state of one or more devices or other conditions--which may or may not be the way they currently are as the result of a recent event.)

This isn't a totally unsolvable problem, but it gets messy. Rule Machine doesn't have a way to save devices to variables like, say, webCoRE does; if it did, you could do that and then use a single set of actions on whatever the triggering device was. (Since it doesn't, the only workaround I can think of if a string comparison of the triggering device name, %device%, but I would not recommend that.)

However: this is easily solved by just creating one rule, one for each device. Then you have simple triggers and simple actions. For example:

Trigger: Computer Lamp turns on

Actions:

Wait for event: --> elapsed time 0:01:00
Off: Computer Lamp

I don't see many downsides here; again, since Rule Machine doesn't have a concept of variables as a reference to a specific device, you're duplicating each action in your rule anyway, so it's not much of a difference in terms of typing/clicking. The only difference is that they'll be separate rules--and less clicking in each since you don't need a conditional (which again, I don't think will work as you expect even in the rule above). But "rules are free." :smiley:

EDIT: I should also add that when I find myself writing the same rule multiple times, I consider whether an app would be a better choice. I usually prefer a "yes" answer to that question (but, of course, you may have different preferences). So, if you want to re-visit the app you're using, asking for help in the thread the developers usually create for their own apps--or just somewhere else here if not--might be easier in the end. Good luck either way!

2 Likes

Thanks for your detailed response Robert. You are one of my favorite contributors on this forum. I appreciate all the time and effort you put into helping us novices with our problems. The only reason I considered consolidation of several rules into one was to keep everything in one place so to speak. That is what formed the thought about permissive cancellation of timers. Anyway, you are quite right that I should pursue the cause of my auto-off app failure. I'll do that and in the interim I will write a few individual rules to accomplish the same.

1 Like