[SOLVED] restricting lights from a certain hour
-
I have "rainstorm lights", those couple lights in the house that come on during the day when it's gotten so dark due to weather that it's almost like night inside. The trigger for this is mode + solar radiation level.
However, this gets triggered in that last hour before I wake in the morning due to the fact that I switch the house from NIGHT mode to DAY mode at 05:30 so climate control has an hour to warm the house appropriately before I rise at 06:30 weekdays (07:30 weekends.) To circumvent that I've added two "excludes" for hours "not between".
Everything is working great with the exception of blocking the pre-alarm hours. I'm posting what I've created for another set of eyes to review and point out my obvious-to-all-but-me error.
-
At first blush, everything you've got there looks correct to me, and I would not expect the lights to go on during your "exclude" hours.
Some quick mental notes I made while reviewing:
- The XOR might be overkill in that last group; OR should suffice, since a day cannot be both a Weekday and Weekend;
- I prefer placing time constraints in Constraints, with the faster-moving conditions in Triggers;
- When you click on STATUS, does MSR throw you any warning message concerning host time vs. browser time?
Other than that, I got nothin' for ya at this early hour of the morning.
-
Is the day vs night coming from modes on Hubitat? It's quite likely that the time is not in perfect sync between the Hubitat hub and your MSR host. If the Hubitat goes to day even 1 second before the MSR host thinks it's 05:30:00.000, your restrictions won't work. You might try buffering your time a little bit (that is, opening the restriction window a few minutes earlier).
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
Is the day vs night coming from modes on Hubitat? It's quite likely that the time is not in perfect sync between the Hubitat hub and your MSR host. If the Hubitat goes to day even 1 second before the MSR host thinks it's 05:30:00.000, your restrictions won't work. You might try buffering your time a little bit (that is, opening the restriction window a few minutes earlier).
@toggledbits Makes me wanna write a "Time Sync Warning" rule that compares MSR's time with that of each controller, and sends out a message if they drift apart too far.
-
Is the day vs night coming from modes on Hubitat? It's quite likely that the time is not in perfect sync between the Hubitat hub and your MSR host. If the Hubitat goes to day even 1 second before the MSR host thinks it's 05:30:00.000, your restrictions won't work. You might try buffering your time a little bit (that is, opening the restriction window a few minutes earlier).
@toggledbits Yes, coming from Hubitat. So you're saying back up to 05:25?
-
Try that. How are you setting mode? Where is that coming from?
-
Try that. How are you setting mode? Where is that coming from?
@toggledbits Had to go verify as I'd done that originally in Hubitat but then shifted to MSR because I didn't want "some stuff here, some stuff there" model.
-
At first blush, everything you've got there looks correct to me, and I would not expect the lights to go on during your "exclude" hours.
Some quick mental notes I made while reviewing:
- The XOR might be overkill in that last group; OR should suffice, since a day cannot be both a Weekday and Weekend;
- I prefer placing time constraints in Constraints, with the faster-moving conditions in Triggers;
- When you click on STATUS, does MSR throw you any warning message concerning host time vs. browser time?
Other than that, I got nothin' for ya at this early hour of the morning.
-
OK. Keep in mind that there's no guarantee to the order of rule evaluation. If two rules A and B both have conditions for 05:30, there's no guarantee which will be evaluated first. If it happens that B also depends on A directly, or on something A does, it's possible that if B is evaluated first, it will be looking at the "old" state of A because it hasn't updated yet. This may cause B to do some unexpected reaction. And worse, a moment later, A will be evaluated to its new state, and then B will see A changed and re-evaluate to the correct, expected state. This will happen so fast that the only way you'll see it is by examining the logs (or, you can add Notify/Alert actions to your reactions as a poor-man's debug stream). Leaving a wider window on time conditions can help with this as well. Other mitigation strategies may include moving time conditions that are often repeated into a rule, and then using the rule instead of the date/time condition(s).
In this particular case, you also don't really care if it's 5:30 in the constraints. You're thinking that way because that's when your day mode changes, but in fact, your time tests should probably just be before 6:30 and before 7:30. This would not be true if your "night" mode starts after midnight, but if it starts before, you're being too specific here.
If you don't change it to before, then put your ending times back to 6:30 and 7:30. You don't need to change those.
-
OK. Keep in mind that there's no guarantee to the order of rule evaluation. If two rules A and B both have conditions for 05:30, there's no guarantee which will be evaluated first. If it happens that B also depends on A directly, or on something A does, it's possible that if B is evaluated first, it will be looking at the "old" state of A because it hasn't updated yet. This may cause B to do some unexpected reaction. And worse, a moment later, A will be evaluated to its new state, and then B will see A changed and re-evaluate to the correct, expected state. This will happen so fast that the only way you'll see it is by examining the logs (or, you can add Notify/Alert actions to your reactions as a poor-man's debug stream). Leaving a wider window on time conditions can help with this as well. Other mitigation strategies may include moving time conditions that are often repeated into a rule, and then using the rule instead of the date/time condition(s).
In this particular case, you also don't really care if it's 5:30 in the constraints. You're thinking that way because that's when your day mode changes, but in fact, your time tests should probably just be before 6:30 and before 7:30. This would not be true if your "night" mode starts after midnight, but if it starts before, you're being too specific here.
If you don't change it to before, then put your ending times back to 6:30 and 7:30. You don't need to change those.
@toggledbits Wouldn't be the first time I've over-complicated the thinking...
This is where I am now given 99% of the time NIGHT is invoked before midnight. My m-i-l always says "nothing good happens after 9pm"
-
I think I'd "widen" those time slots by another 30 minutes (i.e. 5-7am / 5-8am), and give it another day of testing. Something tells me it's too precise for now, still. Nothing else jumps out at me, but as you've already pinpointed, Logs are your friend as is watching the Rule's live status in RuleSets.
-
I disagree. Unless the controller is down at the moment, one minute would be sufficient widening to prevent a race condition. There's something more here than meets the eye.
@gwp1 if you're going to send logs, don't snip, send me the whole thing, and also send all rules involved (if you click on the rule name in the Rule Sets list, it shows you the rule ID under the conditions -- there's a JSON file in your reactor/storage/rules with that ID as its base name).
-
Actually, before we go any further, look at this more carefully:
Let's say for the sake of argument that it's 4am. Your "not between" conditions are going to be true (4am is not between 5:30 and 7:30), so the condition is true, and that means your "exclusion" isn't.
For me, based on what I understand your intent to be, and working within the existing structure, you really want these to be after operators with the earliest time you're willing to accept the lights coming on.
-
Actually, before we go any further, look at this more carefully:
Let's say for the sake of argument that it's 4am. Your "not between" conditions are going to be true (4am is not between 5:30 and 7:30), so the condition is true, and that means your "exclusion" isn't.
For me, based on what I understand your intent to be, and working within the existing structure, you really want these to be after operators with the earliest time you're willing to accept the lights coming on.
@toggledbits Hmmm... that's an interesting approach. Mode + After alarm time = lights allowed. Let me try that.
Edited to add screenshot of updated ruleset:
-
@toggledbits Hmmm... that's an interesting approach. Mode + After alarm time = lights allowed. Let me try that.
Edited to add screenshot of updated ruleset:
@gwp1 Sadness abounds. Lights this morning. I've emailed @toggledbits the logs he requested in full.
Of note: when I was originally creating this rule I noticed something with the
WeekdayandWeekend"button/links"... when saved, the days chosen by using those were blank again. Only way I could save them visibly was by manually checking them. I should have filed a bug - work intervened and then it slipped my mind. Perhaps unrelated - perhaps not, if the choices aren't really saved.
