Interval Query - Sustaining tripped state in future intervals

pier_da · November 24, 2020, 11:29pm

Hi Rigpapa!

I’m very seriously impressed with the functionality of Reactor and decided to create plenty new sensors and some with schedules to take advantage of it.

I have gotten a little stuck while trying to create schedules that repeat X days in the future and I was hoping you may be able to offer some advice.

For example, if I want a light to turn on and stay on tomorrow, Wednesday the 25th of Noveber 2020 at 3.30pm until Thursday 9.30am, I have been able to do this with “Date/Time: between Nov 25 2020 15:30 and Nov 26 2020 09:30”.

If I want this to happen every 7 days, I assume that I must create an OR interval of 7 days. I have tried this relative to Time and to the above condition but it is not turning green!

I read in the Wiki that the interval is only a brief trigger, so does that mean my approach is wrong and if so, what would be the best way to correct it?

Thanks in advance and awesome work on Reactor.

rigpapa · November 24, 2020, 11:46pm

Welcome! And thanks for the “atta-boys”!

I’m not sure I’m entirely clear based on your explanation what the real goal is. I’m kind of reading it as you want something to happen every Wednesday and Thursday? You could factor in a Weekday condition for this purpose. The combination of a Weekday condition and a Date/Time condition that specifies only time (no date parts) could be used to control when on those weekdays things are active. Maybe a little more detail on this and I can guide you in the right direction.

The Interval condition… a few things to know. First, I regard it with great suspicion and some regret. It is probably the most misunderstood, and abused, condition type. The intention of the condition is not as much to gate other conditions as it is to cause repeated action. Second, much of that functionality the way people have commonly applied it has been replaced by the repeat behavior in the condition options (for conditions other than Interval, and groups). My ~~rule~~ guideline of thumb right now is, if you’re using an Interval condition, you’re doing it wrong. That’s a guideline, not a rule. There are some legitimate and good, clever uses of that condition type, but generally speaking, it’s the wrong place to start, and people get easily screwed into the ground about using it when there are better approaches available.

You are correct, the Interval provides only a brief trigger. So brief, in fact, that it may not show on the UI, depending on your settings. This is also true of the changes and updates operators on other conditions. Using a delay reset option in condition options for either the condition or group can be used to streeeeetch out the brief pulse these produce so the UI can catch up and display them.

In any case, give me a little more detail about how you want this to work. If it really takes an Interval, fine, that’s what it’s there for, but I’m guessing there’s a better way, I just want to understand the goal, and I’m not sure I do at the moment.

Refs:

Condition options: Condition Options - Reactor

Weekday Condition: Type: Weekday - Reactor

Date/time Condition: Type: Date-Time - Reactor

Interval Condition: Type: Interval - Reactor

pier_da · November 25, 2020, 12:17am

Thanks for the ridiculously quick and detailed reply Rigpapa and it’s a little more than atta-boy by-the-way!!

Essentially the between Date/Time condition is exactly what I want - a defined period of time in which a condition will remain true, like a light staying on for example.

In my case I want to repeat that condition on a 4 week rotating basis, and also on Wednesdays. So for week one, it is true all day Saturday for example, week 2, all day Sunday, week 3 all day Monday, week 4 all day Tuesday and returning to week 1 thereafter. Wednesday is a weekly case so achievable with your weekday suggestion.

I created a number of separate Date/Time conditions for the 4-week situations and then had an OR statement with each with a 28 day interval. Unfortunately the condition is not sustained so for the first week, the light will stay on all day Saturday, but 28 days later will only flicker at midnight!

Is there a way to replicate the conditions on a schedule, perhaps wihout the interval function if you think this is the wrong approach?

Thanks again.

rigpapa · November 25, 2020, 1:56am

I think I get it. This looks like a problem that seems, at least to me, better approached mathematically than through mechanical machinations. Have a look at this:

I have a number of expressions here… you could write them as compound expressions and have fewer of them, but I think breaking it out like this will help make it more clear what each part is doing and make it easier to watch in Status view. First thing to note… the time() function returns seconds since midnight Jan 1, 1970, as is typical for *nix systems. This makes it easy to do math with the time. Here:

index - This takes the current time (stamp) and subtracts the timestamp for January 1 2020 from it, giving you the number of seconds since then. Divide this by 604800, the number of seconds in a week, and you’ve got the number of weeks since January 1 2020. Modulo (%) 4 keeps it in the range of 0 to 3, so as the weeks roll by, this expression will result in 0, 1, 2, 3, 0, 1, 2, 3, … repeating.
weekdays - This is a just a fixed list of the day numbers on which the lights should be on for each of the four weeks in the cycle; 7 is Saturday, then 1 is Sunday, 2 is Monday, 3 is Tuesday.
active_day picks the active day for the current date/today from weekdays using index. We have to add 1 because index runs 0-3, but the array/list indices are 1-4.
today_day simply picks out today’s day of the week. (1=Sunday,… 7=Saturday).
acitve_day produces a boolean true of today_day equals active_day, in other words, true if today is the day of the week that is the “active day” for this week in the rotation; false otherwise.

From there, it’s a simple matter of two conditions in an OR group, since you indicated that lights are always active on Wednesdays, in addition to whatever the cycle day for that week may be. So the active_day Expression Value condition checks to see if today is the active cycle day, and the Weekday condition just adds Wednesday to the mix.

In the first week, the “Lights On” group will be true on Saturday and Wednesday. The next week it will be Sunday and Wednesday. The week after, Monday and Wednesday. And finally Tuesday and Wednesday, then it goes back to the beginning (Saturday and Wednesday).

This will work indefinitely, without Interval conditions or any other re-evaluation or external stimulus.

Does that capture your goal?

pier_da · November 25, 2020, 8:23am

This is fantastic and it would never have occurred to me that you could create an expression that cycles the weeks with the likes of the Modulo operator. This makes this much easier now, thank you!

I oversimplified my goal slightly, not realising it would need to be done in expressions. The period for the light to be typically straddles one or more days and has different start/finish times, as follows…

Weekly - 3pm Wed to 10am Thu
Week 1 - 10am Sat to 12pm Sun
Week 2 - 10am Sun to 11am Tue
and so on

I tried to use the expression that indicates which week (1-4) in conjunction with mechanical conditions but find that I cant define a period that straddles two days with it without it becoming quite complex.

Is there an expression that could return true if, in the example of week 1, (10am Sat) < X < (12pm Sun) would return true. I could use that with the week indicator to hit my goal then. Also, would it best to use expressions to achieve the Wed/Thu period as otherwise I would have to create two in conditions (Wed to midnight + Thu from midnight)?!

Appreciate your help Rigpapa as I get the hang of Reactor’s abilities. Out of curiosity are expressions superior over conditions in terms of efficiency, cpu use, etc or is there much of a difference, and would you recommend any particular place to learn/get reference for the LUA used in Vera? It will be handy to learn this going forward.

rigpapa · November 25, 2020, 2:56pm

OK. Here’s a revision, explanation below. I’ve only shown two of four weeks, but you should see the pattern:

First, I removed all of the expressions except the index expression that computes the rotating week number 0 through 3.

For each week, there is a parent AND group “Week n” with an Expression Value condition that matches the corresponding value of index (0 for week 1, 1 for week 2, etc). The group also contains an OR group called “Times”, and this is where the day and time components are factored in. A time range “10am Sat to 12pm Sun” is, in Reactor logic: (weekday is saturday AND time > 10am) OR (weekday is sunday AND time < 12pm). Notice how the parentheses in that pseudo-expression turn into groups in the logic.

The trick to the way this works is that “after 10am” really means “between 10am and midnight”. Likewise “before 12pm” really means “between midnight and 12pm”. So in combination with the weekday controls, the two AND groups within the Times OR group will be true for the unbroken span of time between.

I’m not sure if you meant “11am Mon” here, or you really did mean Tuesday, but I set it up for Monday, since previously you talked about the ranges basically just spanning about 24 hours.

From this, it should be clear to you how to set up weeks 3 and 4. Just use the same pattern as 1 and 2.

For the Wednesday rule, just create a group at the same level as “Week n” (not within any Week n groups) and just use the “Times” pattern (OR group containing to AND groups).

Notice here that the “Wednesday” group is an OR… I could have left it AND like the others and just added a “Times” OR subgroup, but that just makes an extra group layer that isn’t necessary, so I “promoted” the “Times” pattern up a level for “Wednesday”. This group will be true from 3pm every Wednesday to 10am Thursday. Since it’s every Wednesday, there is no index test condition.

So in all, here’s what it looks like in the Conditions editor with the groups collapsed:

The last group, “Lights On”, is a style thing for me. If there are multiple ways a single light can be turned on and off, I like to boil that into its own rule that looks at the other rules, and place the light on/off actions in activities there, rather than having activities spread out over all of the other groups. I find it easier to maintain, and if there’s ever a change where the on/off times end up overlapping, it works properly rather than having groups fighting each other for dominance. That group looks like this:

So you can see, it’s an OR group, and it’s just looking at the states of all of the other main groups that tell us when the light should be on. Because it’s an OR, if any of those groups is true, then the “Lights On is TRUE” activity can turn lights on, and when it goes false, the “Lights On is FALSE” activity can turn them off. If you ever need to add a light or change the controlling device, it’s just those two activities in isolation to modify.

pier_da · November 25, 2020, 11:36pm

That is really helpful and so detailed, thank you sincerely for going to all the trouble.

It’s actually justabout as complicated as I thought it would be! But the before and after times makes it certainly simpler than how I would have approached it. I have put the entire structure together as you have suggested and for the most part, putting in trial dates seems to be working. I assume the time() function is coming from Vera so the Reactor test time function can not influence this. I note that the seconds changed between your two posts from 1583038800 to 1577854800, should these be the same?

One reason I thought this might not work however is because the on time not only straddles the day but the week on occasions. From what I read the first system day of the week is Sunday, so technically the situations where there is a Saturday overnight case, the week changes also, which would unfortunately break this setup.

I can split the conditions further out into separate weeks for those situations but wonder would the original approach of using the interval be less complex and could Reactor somehow watch for that trigger and keep some form of latch for X hours depending on the week work? Just a thought! Thanks again Rigpapa.

rigpapa · November 26, 2020, 1:35am

That’s actually incorrect. If you set a test time on the Tools tab, Reactor runs its own clock from that point. you can see it running in the Status view (assuming you are Reactor 3.8, the current release version).

I was playing with different dates…

I’m not clear what you are at here, and what I think you are trying to say is also incorrect. What you do need to do, however, which I forgot to include in my prior instructions, is you need to set that subtracted constant in index to midnight of a Sunday in your timezone. You can generate a constant for a Sunday midnight in the past on this site: https://www.epochconverter.com/

pier_da · December 8, 2020, 8:46pm

Hi Rigpapa, thanks again for clarifying the timing, I think I have it exactly as intended now with your help! FYI, perhaps it’s the way I have it setup, but for me changing the test time in Reactor was not changing the index value and therefore week number, so I just changed the epoch time being subtracted by a week to test and it worked fine.