Restricton vs Condition

[lflorack]

I have the following Halloween-specific piston that keeps my house dark - indicating that no one is home for trick or treating:

As you can see, the two triggers include the same two conditions (presence and date). I previously had them as only-if restrictions for the whole piston because it seems better than repeating them twice. I moved them to conditions because I worried that they wouldn’t work properly after recently reading here about Restrictions versus Conditions in a Timer (‘every’ statement).

Did I move them unnecessarily? Help me understand please.

TIA

[Mike1616]

But you aren’t using a Timer. You’re using Time. So different rules apply. There are good use cases for both though…so you just have to use the right one for the task you want to do.

However, it’s true that if you want to place restrictions on a Timer that might change AFTER the Timer was set then you have to take that into consideration. (Things that might change are Presence, state of a switch, location mode, etc.)

Here’s an example of a bad Timer. You might try to use this if you had a Master (virtual) switch setup so that you could prevent your piston(s) from running when you turn this switch ON. But in this case, the Timer does not know anything about the state changes of the Switch (switch 7 in this case). So it will just hum along happily and continue to fire regardless of how you change the switch. What ever way the switch was set when the Timer was initiated is how it will react when the timer is up.

Here however is a better Timer. This one has a few extra lines of code to it so it is now aware of the changes to the Master switch. So you can change the state of the switch and the piston will react appropriately.

Finally, this is your other option with a Timer. This piston will still execute every 30 seconds, but when it does execute it will check the state of the Switch and react appropriately. Personally this is the way I like best…but that’s just my preference.

[Mike1616]

Now as to why you might use Time versus a Timer…

There are some cases when only a Timer will work. Let’s say you want something to happen every 45 minutes. That would be rather difficult to configure using “Time”, so you’d absolutely use a Timer for that.

Also, trying to use “Time” with some of the preset values of sunrise and sunset can be challenging as well. Setting up a piston to run like this:

Time happens daily at sunset

Has been known to run more than once in a day if Sunset is getting later each day. However, setting up a piston to run like this:

Every day at sunset

Works just fine.

So again, there are use cases for each. The way you do things depends on what you’re trying to do and perhaps a bit on personal preference.

Personally I’m not a huge fan of the syntax “Time happens daily at 6:30 AM” I just prefer “Every day at 6:30 AM”. Functionally there is no difference whatsoever in just those two things, however, they can react differently when you start putting restrictions on them.

[lflorack]

But you aren’t using a Timer. You’re using Time. So different rules apply.

Ahh! I somehow glazed right over timer (do every) vs a specific time AND I didn’t realize that different rules apply either. Thanks! I’ll probably put the two Conditions back as Restrictions.

[lflorack]

@Mike1616
So, I now have changed it to this:

Thanks again.

[Mike1616]

I think your use case is truly one where either way will work just fine. The difference being that yours will wake up 2 times per day every day and run the piston to determine that it’s not Halloween and then go back to sleep.

This one below will wake up one day per year and evaluate things on that day.

But it will show a countdown in the dashboard for when it will run next. Again, largely personal preference.

[lflorack]

I think your use case is truly one where either way will work just fine. The difference being that yours will wake up 2 times per day every day and run the piston to determine that it’s not Halloween and then go back to sleep.

This one below will wake up one day per year and evaluate things on that day.

image.png1178x719 32.9 KB

But it will show a countdown in the dashboard for when it will run next. Again, largely personal preference.

image.png1289x52 1.29 KB

I like the idea that it will run only on Halloween and I like the dashboard countdown, but in my example, there’s an additional timer that turns the flag off and the lights back on at 22:00. When I recreated the piston, the 22;00 block ended up inside the Do Every loop - which only runs at 17:00. It appears I’ll need a second “do every” block - or separate piston?

[Mike1616]

it’s in there…although I’ve never tested this type of functionality within a Timer. I know that pistons like to execute from the top down, so the question would be whether or not that would work when the piston wakes back up again (meaning whether or not it gets past the 5:00 part).

But I’m positive you could do it with a 2nd timer in the same piston. At that point you wouldn’t nest them. You’d have them both out at the root like in your examples as their own Triggers.

[Mike1616]

Well, I just tested it…and this one worked.

I even manually turned off the first switch during the 10 wait and when the piston spun back up again it left that switch off and proceeded to the next step. So conceptually it will work, but 10 minutes is not the same as several hours…so another (longer) test might be warranted.

[lflorack]

Well, I just tested it…and this one worked.

I even manually turned off the first switch during the 10 wait and when the piston spun back up again it left that switch off and proceeded to the next step. So conceptually it will work, but 10 minutes is not the same as several hours…so another (longer) test might be warranted.

Excellent! Thank you for the feedback and assistance on this. My wife and I often take fall vacations, and sometimes they have us away on Halloween. In some cases, we’re in Europe so with the difference in the time zones, doing this manually is not an easy thing to do. I had it working as it was written previously, but this new version is cleaner and doesn’t it doesn’t have to run it every day to just check if it’s Halloween - and it has the added benefit of showing up properly in the dashboard too.

Anyway, here’s what I have now:

[Mike1616]

Anyway, here’s what I have now:

Well, now you’ve ventured back into “Restrictions on a timer” and you have to account for that. See my post #6 up above for my recommended way to do this. (Basically nest an IF inside the timer rather than putting the restriction on the outside of it). That’s very important, especially for something which will only run one time…several months from now.

[lflorack]

Well, now you’ve ventured back into “Restrictions on a timer” and you have to account for that. See my post #6 up above for my recommended way to do this. (Basically nest an IF inside the timer rather than putting the restriction on the outside of it). That’s very important, especially for something which will only run one time…several months from now.

An obvious miss on my part, so thank you again very much. I think this one will work: