[SOLVED] restricting lights from a certain hour
-
@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. -
The log shows that this rule set at 20:28 and ran the "Rainstorm Lights ON" reaction from its set reaction. It remained set until 22:55, when it reset and ran the "Rainstorm lights OFF" reaction from its reset reaction.
The rule remained reset for the remainder of the log. It did not set at 05:30 or any other time, it did not start its set reaction or the "Rainstorm Lights ON" reaction it references.
However, the "Rainstorm Lights ON" reaction was run by another reaction at 05:30. So you've got a mention of this somewhere. I can't easily tell which (I'd need a higher level of debug), but it is probably one of active objects (or something they start):
- Rule Notify: Mode Day ON<SET>
- Rule Notify: Mode Night ON<RESET>
- Rule Notify: Screened room door<RESET>
- Cooling All Modes but Night: ON<SET>
- Reaction Sunset light group on
-
The log shows that this rule set at 20:28 and ran the "Rainstorm Lights ON" reaction from its set reaction. It remained set until 22:55, when it reset and ran the "Rainstorm lights OFF" reaction from its reset reaction.
The rule remained reset for the remainder of the log. It did not set at 05:30 or any other time, it did not start its set reaction or the "Rainstorm Lights ON" reaction it references.
However, the "Rainstorm Lights ON" reaction was run by another reaction at 05:30. So you've got a mention of this somewhere. I can't easily tell which (I'd need a higher level of debug), but it is probably one of active objects (or something they start):
- Rule Notify: Mode Day ON<SET>
- Rule Notify: Mode Night ON<RESET>
- Rule Notify: Screened room door<RESET>
- Cooling All Modes but Night: ON<SET>
- Reaction Sunset light group on
@toggledbits
"this rule set at 20:28 and ran the "Rainstorm Lights ON" reaction from its set reaction. It remained set until 22:55, when it reset and ran the "Rainstorm lights OFF" reaction from its reset reaction."Yes, makes sense as this rule gets included in the @sunset rule for those two lights it controls. That would be sunset (20:28 until sleep time 22:55).
Reaction Sunset light group oncontains the rest of the lights that come on at sunset, of which this is a subset.I'll look at what's happening at 05:30 (IIFC it's just a mode change ruleset).
Rule Notify: Mode Day ON<SET>This is the 05:30 mode change
Rule Notify: Mode Night ON<RESET>I would gather this is Night Mode ON deactivating
Rule Notify: Screened room door<RESET>This is the screened room door sensor alert being turned off after Night mode is deactivated
Cooling All Modes but Night: ON<SET>This is HVAC switching from Night Mode to everything else with the mode change. -
@toggledbits
"this rule set at 20:28 and ran the "Rainstorm Lights ON" reaction from its set reaction. It remained set until 22:55, when it reset and ran the "Rainstorm lights OFF" reaction from its reset reaction."Yes, makes sense as this rule gets included in the @sunset rule for those two lights it controls. That would be sunset (20:28 until sleep time 22:55).
Reaction Sunset light group oncontains the rest of the lights that come on at sunset, of which this is a subset.I'll look at what's happening at 05:30 (IIFC it's just a mode change ruleset).
Rule Notify: Mode Day ON<SET>This is the 05:30 mode change
Rule Notify: Mode Night ON<RESET>I would gather this is Night Mode ON deactivating
Rule Notify: Screened room door<RESET>This is the screened room door sensor alert being turned off after Night mode is deactivated
Cooling All Modes but Night: ON<SET>This is HVAC switching from Night Mode to everything else with the mode change.@gwp1 "However, the "Rainstorm Lights ON" reaction was run by another reaction at 05:30."
Wouldn't it be triggered because of the mode change? Mode (either day or evening) is a trigger for
Rainstorm lights ON- but having the time restriction should stop it from turning on those lights, no? -
No, it looks like something else, not the rule we've been looking at, is running that reaction. The rule never went true/set after 22:55
-
No, it looks like something else, not the rule we've been looking at, is running that reaction. The rule never went true/set after 22:55
@toggledbits
Rule ID: rule-198should runRainstorm Lights ONreactions plusSunset Light group ONreaction together to equal turning on all necessary lighting at sunset. -
Something ran "Rainstorm Lights ON" at 05:30. It was likely one of the rules or the reaction I listed above, as those were active at the time. The rule "Rainstorm: on, off with UV" was not active at this time, so it did not run it.
-
Something ran "Rainstorm Lights ON" at 05:30. It was likely one of the rules or the reaction I listed above, as those were active at the time. The rule "Rainstorm: on, off with UV" was not active at this time, so it did not run it.
@toggledbits Rule Notify: Mode Day ON<SET> This is the 05:30 mode change and the mode change is a condition for the running of
Rainstorm Lights ON- but shouldn't/wouldn't the conditions aroundnot before <xx time>belay that order? (That was my intent, anyway.)Would moving the time conditions to
Constraintsbe a better approach? -
I hope what I'm about to mention applies to your situation... running Rule B's SET (or RESET) reaction from Rule A:
- Does NOT cause Rule B to show as "Set"
- Does NOT leave a lasting trace in the Status page
- Does NOT change the "Last set" timestamp on Rule B
...is therefore sometimes a real challenge to catch in the act, much less diagnose, without lots of Log-intensive scrutiny.
These are the reasons I requested some features along those lines, to help "see" what's happening.
-
I hope what I'm about to mention applies to your situation... running Rule B's SET (or RESET) reaction from Rule A:
- Does NOT cause Rule B to show as "Set"
- Does NOT leave a lasting trace in the Status page
- Does NOT change the "Last set" timestamp on Rule B
...is therefore sometimes a real challenge to catch in the act, much less diagnose, without lots of Log-intensive scrutiny.
These are the reasons I requested some features along those lines, to help "see" what's happening.
@librasun
I'm going to temporarily divorce the @sunset rule from the Rainstorm rule just to see what happens come morning.Moved the day/time/weekday conditions toConstraintsfirst. At least then I can rule that out.Might be harder to track tomorrow depending on how bright it is at 07:30.
I'm wondering if I'm falling into the pit of trying to "make a truth truthier" when it comes to the triggers.
-
@librasun
I'm going to temporarily divorce the @sunset rule from the Rainstorm rule just to see what happens come morning.Moved the day/time/weekday conditions toConstraintsfirst. At least then I can rule that out.Might be harder to track tomorrow depending on how bright it is at 07:30.
I'm wondering if I'm falling into the pit of trying to "make a truth truthier" when it comes to the triggers.
@gwp1 No change, lights still came on at 05:30. I did roll over and grab my phone, load up the MSR UI and manually trigger the ruleset only to have it turn the lights back off. Before retriggering, I looked at the status of the ruleset and it met everything it was supposed to - the lights were just still on (having come on when they really shouldn't have.)
Trying to rethink how to write this to get to the goal.
-
@gwp1 before you change anything, do this: archive your entire "storage" subdirectory (ZIP) and send it to me.
-
@gwp1 before you change anything, do this: archive your entire "storage" subdirectory (ZIP) and send it to me.
@toggledbits Done.
-
The rule "Sunset Lights: On" is the one that triggered at 05:30 and ran the "Rainstorm Lights ON" reaction. It did that because "Day" is an acceptable mode in its first condition (but "Night" is not listed and so this condition was false before), and at the moment apparently 05:30 is before sunrise, so the second condition was also met.
-
The rule "Sunset Lights: On" is the one that triggered at 05:30 and ran the "Rainstorm Lights ON" reaction. It did that because "Day" is an acceptable mode in its first condition (but "Night" is not listed and so this condition was false before), and at the moment apparently 05:30 is before sunrise, so the second condition was also met.
@toggledbits Talking this thru...
Ruleset "Sunset Lights: On" should have run at sunset 20:29 (local sunset time on Friday 06/11/2021). It should include two Reactions, "Sunset Light Group On" and "Rainstorm Lights On" (done this way to prevent race condition/overlap if the same lamps were included in both reactions as well as prevent a gap at sunset when I'd have to turn off "Rainstorm Lights: On" lamps one minute before sunset kicks in.) I don't know why "Sunset Lights: On" would have run at 05:30 as it shouldn't be driven by mode but only by
sunset/sunrise.Day would be an acceptable mode for ruleset "Rainstorm Lights: On" because, well, that's basically the point - we need these lights during the day as a storm has made it very dark during non-traditional times. I would expect "Rainstorm Lights: On" to run at 05:30 when mode switches to Day - but that's the reason for the
after <time>conditions/constraints - to prevent it from taking action until after those time stops.EDIT: Ok, looking harder at that last half a sentence you wrote: "05:30 is before sunrise so the second condition was also met" - that would explain why "Sunset Lights: On" ran which would explain why Reaction "Rainstorm Lights On" ran. Since that reaction doesn't have the constraints, it seems that's overriding the ruleset "Rainstorm Lights: On" ?
*Hubitat C-7 2.4.1.177
*Proxmox VE v8, Beelink MiniPC 12GBs, SSD*HASS 2025.6.0
w/ ZST10-700 fw 7.18.3*Prod MSR in docker/portainer
MSR: latest-25139-fbd67abc
MQTTController: 25139
ZWave Controller: 25139 -
@toggledbits Talking this thru...
Ruleset "Sunset Lights: On" should have run at sunset 20:29 (local sunset time on Friday 06/11/2021). It should include two Reactions, "Sunset Light Group On" and "Rainstorm Lights On" (done this way to prevent race condition/overlap if the same lamps were included in both reactions as well as prevent a gap at sunset when I'd have to turn off "Rainstorm Lights: On" lamps one minute before sunset kicks in.) I don't know why "Sunset Lights: On" would have run at 05:30 as it shouldn't be driven by mode but only by
sunset/sunrise.Day would be an acceptable mode for ruleset "Rainstorm Lights: On" because, well, that's basically the point - we need these lights during the day as a storm has made it very dark during non-traditional times. I would expect "Rainstorm Lights: On" to run at 05:30 when mode switches to Day - but that's the reason for the
after <time>conditions/constraints - to prevent it from taking action until after those time stops.EDIT: Ok, looking harder at that last half a sentence you wrote: "05:30 is before sunrise so the second condition was also met" - that would explain why "Sunset Lights: On" ran which would explain why Reaction "Rainstorm Lights On" ran. Since that reaction doesn't have the constraints, it seems that's overriding the ruleset "Rainstorm Lights: On" ?
@gwp1 Thinking further...
Removing the Reaction "Rainstorm Lights On" from this ruleset of "Sunset Lights: On" because it's redundant - let ruleset "Rainstorm Lights: On" handle the heavy lifting all on it's own.
You can reference the ruleset from earlier images, this is the
Set ReactionReset Reactionto that ruleset.
-
@toggledbits Talking this thru...
Ruleset "Sunset Lights: On" should have run at sunset 20:29 (local sunset time on Friday 06/11/2021). It should include two Reactions, "Sunset Light Group On" and "Rainstorm Lights On" (done this way to prevent race condition/overlap if the same lamps were included in both reactions as well as prevent a gap at sunset when I'd have to turn off "Rainstorm Lights: On" lamps one minute before sunset kicks in.) I don't know why "Sunset Lights: On" would have run at 05:30 as it shouldn't be driven by mode but only by
sunset/sunrise.Day would be an acceptable mode for ruleset "Rainstorm Lights: On" because, well, that's basically the point - we need these lights during the day as a storm has made it very dark during non-traditional times. I would expect "Rainstorm Lights: On" to run at 05:30 when mode switches to Day - but that's the reason for the
after <time>conditions/constraints - to prevent it from taking action until after those time stops.EDIT: Ok, looking harder at that last half a sentence you wrote: "05:30 is before sunrise so the second condition was also met" - that would explain why "Sunset Lights: On" ran which would explain why Reaction "Rainstorm Lights On" ran. Since that reaction doesn't have the constraints, it seems that's overriding the ruleset "Rainstorm Lights: On" ?
@gwp1 said in restricting lights from a certain hour:
Since that reaction doesn't have the constraints, it seems that's overriding the ruleset "Rainstorm Lights: On" ?
You're mixing rules with global reactions. Global reactions are not bound by any rule. If you tell a global reaction to run, it runs. The fact that some rule may run it and at some specific time the rule would not run it is not a factor. The global reaction doesn't even know that rule exists. It's a one-way connection (rule -> global reaction); there is no connection the other way.
-
@gwp1 said in restricting lights from a certain hour:
Since that reaction doesn't have the constraints, it seems that's overriding the ruleset "Rainstorm Lights: On" ?
You're mixing rules with global reactions. Global reactions are not bound by any rule. If you tell a global reaction to run, it runs. The fact that some rule may run it and at some specific time the rule would not run it is not a factor. The global reaction doesn't even know that rule exists. It's a one-way connection (rule -> global reaction); there is no connection the other way.
@toggledbits This actually supports what I'm thinking happens here, then.
The ruleset has
Constraintsbut, because the Reaction doesn't know of it, it's riding right over those constraints.This makes me feel even more confident that removing the call to the Reaction will resolve this issue. The ruleset "Rainstorm Lights: On" has the conditions and constraints necessary to correctly call for reaction "Rainstorm Lights On" - there's no need for ruleset "Sunset Lights: On" to ALSO call the Reaction - it's covered already.
-
@toggledbits This actually supports what I'm thinking happens here, then.
The ruleset has
Constraintsbut, because the Reaction doesn't know of it, it's riding right over those constraints.This makes me feel even more confident that removing the call to the Reaction will resolve this issue. The ruleset "Rainstorm Lights: On" has the conditions and constraints necessary to correctly call for reaction "Rainstorm Lights On" - there's no need for ruleset "Sunset Lights: On" to ALSO call the Reaction - it's covered already.
@gwp1 Ok, bear with me: unsure if this ran correctly as now I saw the "Sunset Lights: On" trigger all lights because it was not yet sunrise but it was after 05:30 which is when DAY mode returns. As Sunset Lights: On runs during Day or Evening modes, it is correct (as currently configured) to act this way.
Doing some housecleaning on rulesets as I fear I may have a few that are duplicating efforts and a couple that need some Constraints.
