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:
The moment it ran, it scheduled a new random time for tomorrow, as seen here:
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.
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.
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.
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.
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)
@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:
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.
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.
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?
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.
An alternative would be to force that random time to only be calculated once per day like this:
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”?
Yes, but keep in mind that the command:
IF time happens daily at 8:00AM
will run the entire piston top to bottom.
Alternatively, the "every 1440 minutes" command will only run that one block at the designated time
Stupid question…how can I create a Every / Do / End Every block without the the “with {$location]”?
In the main “DO” section, click on:
+ add a new statement > Add an action > Add a task
It will automatically default to “location”, but it will be hidden from the final code.
While editing, it will look like this:
Once saved, it looks like this:
At what time will “every 1440 minutes” actually run? The 24 hour “anniversary” of the last save of the piston?
It really doesn’t matter, I guess, as long as it runs once daily.
Hi, WC. Is this a better approach to getting an action to occur at a random time in a 40 minute window beginning at 7:40 pm? I put this into a separate Piston.
Either approach should work, although I have not tested your last piston…
I can say with confidence that this would definitely work:
I just noticed your earlier question…
This is usually brought to my attention while editing the expression box.
@WCmore…Hi, WC. Things are working well. Really appreciate your previous help on this project.
I want to improve the functionality a bit. I’ve got a " Aeotec Multisensor 6" in the north-facing living room that SmartThings Smart Lighting uses to turn on living room lights on dark afternoons (when Lux <200 after 1 PM). On overcast days lately, lights have been reliably turning on in mid-afternoon which is great.
The logic we worked on previously starts the lighting vacation randomization one hour before sunset. I want to start the lighting randomization as soon as the lights go on in the afternoon due to low light. To do this, I created a virtual (simulated) switch “vLuxLow” which Smart Lighting sets to On when low lux is measured after 1 pm. I modified the webCoRE logic to use this virtual (simulated) switch such that the vacation randomization now starts when the living room is dim OR one hour before sunset. That way the randomization always starts before sunset even if the room does not go dim. See Lines 32-38 below.
Previously, Line 32 was “Time is Between 60 minutes to {$sunset} and 10:30:00 PM.”
What do you think about this logic change? Is this the right / best way to do this? Note that Line 114 sets vLuxLow Off after 11:30 pm for re-use the next afternoon. Also note I chopped out Lines 50-109 which are just repeats of the if/end if block in 40-49 for other devices.
