Execute Routine at 8 PM +/- 15 minutes

#1

What is the best way to execute a Routine once every day at a random time in the 7:45 PM to 8:15 PM time winow?

The following looks promising, but how do I use a specific time (e.g., 8:00 PM) instead of “$sunset”?

WC%20-%20Random%20time%20every%20day

#2

There are a few ways to do this… I would probably create a ‘time’ variable in the define section up top, and set it to 8pm right there… Then in the code snippet you have shown here, you should be able to replace the $sunset with the name of the variable you created.
(this also lets you easily change the 8pm if you ever decide to edit it in the future)

#3

Thanks, WC. I created a variable afterDinner = 9:45 pm.

Does this look right to you?
WC%20snippet

#4

I believe so, but I am not at a computer to test it. You could easily test though by changing the time up top (in the variable) to 4 minutes in the future, and change the 15 & 30 to 1 and 2… If it works, it would fire off either 1 minute early, on time, or one minute late. You can set back to 15 & 30 after testing, of course.

#5

Thanks. That’s actually the test I’m running now. Normally “afterDinner” would be 8 PM. I set it to 9:45 PM temporarily to conduct the test. I didn’t change the window interval fro this test. It should fire in five minutes from now.

#6

Just checked Notifications / Activity Feed in the IOS App and it worked just fine. The three Kitchen & Dining Room lights reduced their brightness to the “after dinner” setting (down from 100% bright).

Thanks for your help!

#7

Excellent! Glad to be able to help.

Feel free to mark as a solution so others can benefit from our conversation…

#8

I just noticed I was missing a third close parentheses. It seemed to work fine even with the missing close paren. WC didn’t throw an error with mismatched parens. I just added the missing close paren.

Is there no dynamic error checking for invalid statements?

WC%20snippet%202

#9

Good eye, yes, there should be 3 closing

#10

That won’t work. The expression won’t cause your piston to fire. Expressions can’t be triggers. I would set that to a variable at another time during the day. So, at noon every day, you’d run a piston setting your variable to:
addMinutes($sunset,random(15))
You also don’t need the math in the random function. random(15) will return an integer between 1-15 (inclusive). No need to do the nested math.

Then execute your Happens every day at according to your variable.

#11

Sorry to be the one to tell you this, but you are incorrect.
I tested exactly as posted above, with a 2 minute random, and it ran one minute early as seen here:

temp

The moment it ran, it scheduled a new random time for tomorrow, as seen here:

temp

Beautiful, and exactly what he asked for…

As far as your other ‘observation’…

@OldPro’s math is good…
He wants it to fall between -15 and +15, as seen in the very first sentence in this thread.

#12

Let’s see the whole piston. when did you save the rule? Was it right around that period of time? How can it decide when to set the random number if it is not called at some other time? Think about it. Try to do this with the variable set an hour off into the future and you’ll see. It has to decide at some point what to use for the random and then schedule the piston to run. Think about the math…when is it going to decide when to apply the random factor and add the minutes on.

Or don’t trust me and just do whatever you want without listening.

#13

Any piston can ‘break’ if incompatible code is added to it

The moment it runs, it schedules a new random time for tomorrow (as seen above)

If I was coding this from scratch, I may turn the random into a time variable first, and then refer to that variable in the ‘every day’ section, but the above layout does the trick as well. The time (and random) is checked each time the piston runs.

#14

What if the time it schedules it for is later within your window? Then you’re going to get duplicate executions. IMHO this isn’t going to work the way you want it to.

#15

If there are multiple triggers in the piston, and within that time frame, the piston ended up triggering twice by some other means, then theoretically, it could run that ‘every day’ block twice that day (or even skip a day).

This is why I mentioned that any piston can ‘break’ if incompatible code is added to it.
(why would you intentionally try to break a piston though?!?)

The piston I posted above is meant to only have the one trigger.
(although multiple time triggers should be OK if they don’t overlap)

#16

@WCmore, @Ryan780…ok gents, here’s the entire piston. An overall review would be appreciated.

The high-level objective is to make the house look lived in while we are away – your typical “Vacation” problem.

I decided that my basic lighting control would be performed using ST Smart Lighting (“ST SL” or “SL”) run locally which I like because of the probability of an internet outage at our house. ST SL turns lights on at some offsets from sunset and off around 11 PM. ST SL turns lights on around 6 AM and off at offsets from sunrise. I originally used Scenes with SL, but learned those depended on the Internet, so switched to SL control of individual devices to remove all Internet dependence for the “core” lighting control.

To get some randomization of lighting for a more lived-in look, I am running webCoRE logic “on top of” ST SL logic. I set the randomization times to occur within the window of when ST SL has turned the lights on.

The objectives are:

  1. Have a subset of lights turn on/off randomly during the time that ST SL has them on for the evening or morning. Main “Only When/Do” block at 26.
  2. Make sure that webCoRE doesn’t turn a light on outside the ST SL window and have that light stay on all night long. This is done in the “Else/Only When” block at 103, 11:30 PM to 5:00 AM.
  3. Dim the kitchen and dining room lights at 8 pm by executing the ST SL “After Dinner” routine. This is done in the “Every Day/Do” block at 130.
  4. Make sure that the Living Room lights are never off at the same time. This is done with the “Only When/On Events/Do” block at 113.
  5. Dim exterior porch lights around 11 PM (done in ST SL, not WC).

The author of the Piston shows as “Brandon Pines” because I borrowed the core logic from his work (how can you change the author?). Original source was dct7c at Vacation Lighting Piston. Look about 2/3 way down, post by schilling3003.

Vacation%20Piston
Vacation Piston.png1178×2405 377 KB

#17

It looks real good @OldPro, but it is important to keep in mind that with all the various events triggering the piston, the final block of code could potentially not work as expected. (the random time is recalculated each time the piston fires) I would move lines 130-137 into it’s own piston, or drop the random in that one block. Either would resolve the potential problem.

#18

Thanks. If I drop the random from that block, then I can just dim the lights in Smart Lighting. The “random” is the whole reason for that block.

But, if is it really a bad thing if it recalculates a new random time each time the piston fires? I don’t care when the lights go on in the 30 minute window. If it initially was going to dim the lights at Minute 29, then recalculated to dim the lights at Minute 8, it’s no big deal, is it?

#19

Let’s assume the -15 and +15 minutes centers around 8pm. (so 7:45 thru 8:15)

If a trigger happens in the middle of the day, and the random determines that 8:14 is the routine time. all is good. BUT what if another trigger fires off at 8:10, and the random determines that the routine time is 7:50. It will skip that block for that day.

The reverse may happen as well… If an earlier trigger sets the random time to 7:50… and it successfully fires at 7:50… but let’s say a different trigger fires at 8:00, and the random is now determined to be 8:10. That block can actually run twice that day.

So while I like the coding, it is meant to be placed in a new piston with only the one trigger.

temp

An alternative would be to force that random time to only be calculated once per day like this:

temp

#20

Great explanations of the possibility of trigger running 0X or 2X per day instead of the intended 1X per day. Thanks.

2X is not a problem because it would dim the lights twice (and I’ve noticed that ST will not execute a line if no change of state occurs, so even 2X would be blocked from executing [I think]). 0X would fail to run the Dim routine leaving the lights bright until the Off time, so it’s not the end of the world. But good to know about how this logic executes.

I like your approach of calculating the random execution time once per day by using 1440 minutes. That’s slick. Is it possible to calculate dailyRandom every day at a specific time (say 8 AM) rather than “every 1440 minutes”?