How to Limit Automations to Once-Per-Period-Of-Time? (when the start-time for the period is dynamic; i.e. based on an event)

[sgnihttrams]

e.g.

IF: THING1 turns ON (or whatever; doesn’t matter)

THEN: do something (doesn’t matter what)

LIMIT: only once per any 10 minute period

i.e. If the trigger happens multiple times within the initial 10 minute period since the first one, ignore it, and don’t react again until it happens again AFTER that 10 minute period.

Back when I was still using RuleMachine, I basically asked this same question on the ST forum (here), and I was eventually able to fumble around enough to get something that mostly worked.

Now that I’m in webCoRE though, I figured I’d go at it again.

As of right now, I am using a virtual switch to act as a monitor or gauge or whatever; like this…

[terminology, and component naming logic aside (because it doesn’t really matter. I just want to get the functionality figured out here and now. I can make it pretty later…]

Only while LIMIT-SWITCH is ON

IF: THING1 turns ON (or whatever; doesn’t matter)

THEN: do something (doesn’t matter what)

THEN: turn LIMIT-SWITCH OFF

THEN: Wait 10 minutes

THEN: Turn LIMIT-SWITCH ON

Basically, what I want is for the thing to not happen again within ‘the next 10 minutes’ (i.e. the 10 minute period starts when the rule fires the first time).

Any ideas for how to do this better?
Should I ditch the virtual switch and use a variable (or something else) instead?

[milhouse]

I tried this just today:

Smart Switch Piston not working

Sounds good. Oh you mentioned a lock out… can I actually lock a piston from running for a period of time once it activates? That would be pretty cool. I’d also like to look at adding a condition to see if there is already a running piston or scheduled to run piston that way I don’t start multiple timers.

Use local variable for the lockout time - don’t run unless now is later than lockout time.
Then, each successful run of the piston (when you enter the THEN statement set lockout to now + 10 minutes.

The example in the link above is exactly what you need.

[sgnihttrams]

@milhouse

First-off, I know this is way too much detail.
No expectation whatsoever. If you’re willing to check it out, and lend me a hand, then here ya go…

Thanks. I think I’m starting to track with it here, but I need a bit more hand-holding. lol

Here’s a better explanation of the situation I’m trying to deal with…

I have an Android tablet on the wall, running ActionTiles (the best SmartThings-integrated Home Automation Control Panel SmartApp available). Well, I actually have multiple of them around the house, but this one has a problem…

For some reason, the mechanism that I have configured (using a combination of Tasker, SharpTools, etc) to get the screen to turn on doesn’t work like it does on all of the other ones (i.e. if any motion sensor in the room goes active, or if the door opens, turn the Android’s screen ON. Again, this works just fine on the others. So, I know it’s not a matter of not knowing how to do this…there’s just something goofy about the combination of ‘things’ in this room in particular that is causing it to break, and I gave up trying to figure it out a long time ago).

Now, I have already done a LOT of troubleshooting, and have not been able to figure it out. So, for now, I’m simply using a work-around (which has been in place, and mostly working, for over a year…i.e. this is NOT a new problem…I’m just rethinking the work-around in the context of webCoRE).

The work-around is to use a smart plug/outlet as the source of power for the Android tablet. On Android (well, by default on these ones anyway), if its power source goes away (by being turned off, or unplugged), the Android’s screen turns on. That way, I can get its screen to turn on by cycling the power source; which is the reason for using a smart plug/outlet.

The way I was doing it before was basically like this…

If door opens, or if motion is detected, turn the smart plug off, wait 5 seconds, and then turn the smart plug back on. Then, in order to keep it from cycling the power way too many times, it would also turn a virtual switch off (a switch that acted as the pausing mechanism for this power cycling system).

Then, I had another rule that would watch for that virtual switch turning off. When it did, it would wait for 10 minutes, and then turn that virtual switch back ON (i.e. re-enabling the power-cycling system…the first rule would only work when this virtual switch is ON).

Now, I set it up the same way here in webCoRE, but it’s not working.
So, I basically got rid of the limiting/pausing mechanism, and only have it doing the power-cycle thing whenever the door opens (i.e. not allowing it to work off of the motion sensors at all in order to keep it down to only power-cycling the Android once in a while).

As of right now, I only have a single piston. Do you think that this kind of thing requires a separate piston for the pausing mechanism, or should I be able to build in right into the main piston that is handling the processing of cycling the power for the smart plug?

Lastly, any chance you’d be willing to post me a suggestion of how to use the method you pointed out to take the place of my way of doing it with the virtual switch?

[Mike1616]

should I be able to build in right into the main piston that is handling the processing of cycling the power for the smart plug?

I’ll chime in. This mechanism is fairly tried and true (and I guess simple is better and thus more reliable).

You can do everything in the main piston. Take a look at my example below. If the conditions are right, then the piston will run and then it will set a variable equal to the next time in the future it is allowed to run again.

[sgnihttrams]

Thanks, Mike.
I will give this a try sometime today, and report back…

[sgnihttrams]

I’ll chime in. This mechanism is fairly tried and true (and I guess simple is better and thus more reliable).

You can do everything in the main piston. Take a look at my example below. If the conditions are right, then the piston will run and then it will set a variable equal to the next time in the future it is allowed to run again.

OK…so, it took me a while, but I eventually got back around to this…then just forgot to ‘report back’.

I set it up pretty much like your example, and it worked just fine.
So, thanks again for the assist.

Now, where should I go to actually learn what I just did, and/or how to ever do it again…on my own…without just copying this one, and pasting it somewhere?

i.e. The wiki page on Variables (here) - as helpful as it is in telling me what it’s for - seems way too limited to teach me how to actually do it.

[Mike1616]

Now, where should I go to actually learn what I just did, and/or how to ever do it again…on my own…without just copying this one, and pasting it somewhere?

There’s no short answer to that question. I’ve spent quite a bit of time looking at what others have done and reading through the threads there to gain some insight into how all of this works. It just takes time, and even more time if you don’t have a background in programming. The wiki pages are a nice place to start, and the Examples section is also very helpful. Other than that…ask specific questions. Many people are here to help.

Speaking of which…I did just create a post in the Example section to show some of the options that are available if you want to restrict how/when a piston runs. I tried to go into more details, let me know in that thread if you have more questions and I’ll elaborate there.

Multiple ways to restrict the execution of a piston

As we all know, there are many built-in ways in webCoRE to restrict either the full or partial execution of a piston. You can select things like time of day, days of the week, whether it’s before or after sunset, location mode, presence status and many more. However, there are times when even all of those options are not enough. Below I will explain multiple different methods that you can use to restrict either the full or partial execution of a piston. These are not intended to be examples …

[aruffell]

In the example above the TimeOutValue is not initialized. How can the IF statement ever be true if the variable is uninitialized? If the IF statement is never true, then the variable should never get set as it is in the THEN section. I used this code and it worked for me just like @Mike1616 wrote it but I am trying to understand why it works. An assumption I am making must be wrong…

The piston below is controlling a blower that pushes cooler air sucked in from the soffit and blows it into networking switches installed in the attic. Even with the restriction switch set to off, the piston was running every 5 minutes. I modified the piston in an attempt to make this less frequent but all I did was limit the cycling of the fan to every 10 minutes (if temp also changes). Given the temperatures in the attic do not change that frequently I accomplished nothing.

[WCmore]

How can the IF statement ever be true if the variable is uninitialized?

Good observation, and excellent question.

I think the reason it works is because “Date & Time” is a HUGE number ($now=1535479522383), and at first run, TimeOutValue is null (zero). When it comes to Date & Time, zero is some point in time back in the 1970’s, so technically, todays date and time is after 1970.

---

SIDE NOTE :
There are certain pistons I have made in the past where I did have to force the beginning variable in the code. I just ran it once (to populate the variable), and then I manually deleted that line of code.

[WCmore]

all I did was limit the cycling of the fan to every 10 minutes

Your current piston uses the same 10 minute delay for both on and off, so that is expected.

---

To help me understand your goals better, when it is hot:

• How long do you want the fan to come on for?
• How long do you want the fan to remain off before repeating?

Also, Correct me if I am wrong, but I think when it is cool, you want the fan OFF 24/7…

[aruffell]

@WCmore - Thank you for the detailed answer on the variable! I had not thought of that but makes 100% sense.

The intent is for the blower to turn on if the temp is over a certain limit and simply stay on until the temp goes below the low threshold. This could result in the fan running for days, weeks or months depending on my thresholds and the current temperature. Right now it would likely run 24/7 as I live in Texas and it gets over 50C (122F) in the attic during the day and close to 30C (86F) all night.

I don’t want the piston constantly running to check whether the temperature is above or below my thresholds if it taxes the system or floods my mesh networks/hub with unnecessary traffic. I’d be more inclined to have it check once every 30 minutes or so (value to be tweaked). Right now, I am only allowing the piston to turn the fan on or off with a maximum frequency of 10 minutes but that is pointless given the temperature doesn’t even vary that often.

While writing this I thought of the “execute every” option… I could simply execute the IF every 30 minutes and that should achieve what I am trying to do.

[WCmore]

The intent is for the blower to turn on if the temp is over a certain limit and simply stay on until the temp goes below the low threshold

In your case @aruffell, I would be very tempted to drop the periodic checks entirely. As long as you are subscribed to the Attic’s Temp sensor, (lightning bolt in the left margin once saved) it should automatically update the hub when there is changes. You could probably build upon this:

IF Attic Sensor’s temperature RISES ABOVE 28
Then turn on Attic Fan
End IF

IF Attic Sensor’s temperature DROPS BELOW 26
Then turn off Attic Fan
End IF

By using the phrase “Rises Above” or “Drops Below” the trigger will happen at the point in time when the temp crosses your threshold.