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.