[Solved] Logic review: Arm for xmas season lighting
-
I brought this over from Reactor for Vera back in the day. It's worked flawlessly, arming the lights for the xmas season which the various lighting rulesets point to. First night is the Friday after Thanksgiving and the last night is 01/07 as it covers the Russian Orthodox holiday.
This year, it stopped running at exactly midnight on 01/01.
Anything stand out in my logic that I've missed?
-
I brought this over from Reactor for Vera back in the day. It's worked flawlessly, arming the lights for the xmas season which the various lighting rulesets point to. First night is the Friday after Thanksgiving and the last night is 01/07 as it covers the Russian Orthodox holiday.
This year, it stopped running at exactly midnight on 01/01.
Anything stand out in my logic that I've missed?
I played around with the from/to specific dates and it looks like you have two choices...
Option 1: break it into two rules connected with an OR... rule 1: "After Nov 1st any year" and rule 2: "before Jan 7th any year". Or
Option 2: add specific years... "From Nov 1st 2021 to January 7th 2022" works as you want it to.
-
Given the fact that it stopped running at exactly 01/01 midnight makes me wonder if there's a difference between MSR and RFV that isn't handling the crossover between years. Random guess - as I noted, this worked flawlessly (mostly because @toggledbits helped me thru the logic in RFV as I was very new to it) and was simply imported into MSR from Vera.
-
It's a bug in MSR. One extra check missing from the implementation on MSR. MSR and RFV necessarily implement the date comparisons very differently (although the valid expectation is that there should be no difference in the result). I thought I had all the edges tested, but I guess I missed a case. I opened PR 0000287 for it. I'll have it fixed later today. Still working on a requested item that I want to get out as well.
-
It's a bug in MSR. One extra check missing from the implementation on MSR. MSR and RFV necessarily implement the date comparisons very differently (although the valid expectation is that there should be no difference in the result). I thought I had all the edges tested, but I guess I missed a case. I opened PR 0000287 for it. I'll have it fixed later today. Still working on a requested item that I want to get out as well.
@toggledbits Thank you for leaving my sanity intact on this first day of the shiny new year lol
You also forced a test of the "Arm For" logic for non-holiday lighting as there'd been no non-holiday window of time since I'd corrected/updated it. So... #win?
-
It's a bug in MSR. One extra check missing from the implementation on MSR. MSR and RFV necessarily implement the date comparisons very differently (although the valid expectation is that there should be no difference in the result). I thought I had all the edges tested, but I guess I missed a case. I opened PR 0000287 for it. I'll have it fixed later today. Still working on a requested item that I want to get out as well.
@toggledbits Loaded up - see what happens tonight!
-
Nothing will change at the rule level, because you have a latched condition that is no longer latched driving an AND group all the way to the top.
The only way to change it would be to set the "test time" back to the fourth Thursday in November 2021 to get the latched condition latched again, and then remove the test time to resume normal operation. If you want to try that, here's how, but before you do, understand that I don't know what other automations you have and how they are set up, and what effect the test time may have on those other automations. Again, it's home automation, not nuclear launch codes, so I suspect the worst will be some lights coming on when you don't expect, etc.
-
Find the
enginesection of your Reactor.yaml file. If you don't have one, add it with the same indent level asbaseurlas shown below:baseurl: http://something:8111 engine: enabled: true -
Indented two spaces from the
engine:line (i.e. the same asenabled), add a linetest_time: "2021-11-25T08:00:00+hhmm"and where I have put +hhmm put your current timezone offset from GMT. Note also that I've shown 08:00:00 for the time, but you can use any time of day that you think will have the least side-effects with other rules.engine: enabled: true test_time: "2021-11-25T08:00:00+hhmm" -
Restart Reactor. The latched condition should go true and the rule should SET. You've basically time-warped the system backwards.
-
After that's done, remove or comment out (with a '#') the
test_timeline, and restart Reactor again. -
Observe that the rule refreshes and should remain SET, with the latched group true and that last date/time condition (11/1 to 1/7) also still true (green).
Also remember that I don't know what other rules that you have that may depend on this rule, so if there are date/time or sunrise/sunset rules that work in concert with this rule, they may not trigger unless the test time happens to also meet those rules. Just focus your attention on this one rule.
-
-
Nothing will change at the rule level, because you have a latched condition that is no longer latched driving an AND group all the way to the top.
The only way to change it would be to set the "test time" back to the fourth Thursday in November 2021 to get the latched condition latched again, and then remove the test time to resume normal operation. If you want to try that, here's how, but before you do, understand that I don't know what other automations you have and how they are set up, and what effect the test time may have on those other automations. Again, it's home automation, not nuclear launch codes, so I suspect the worst will be some lights coming on when you don't expect, etc.
-
Find the
enginesection of your Reactor.yaml file. If you don't have one, add it with the same indent level asbaseurlas shown below:baseurl: http://something:8111 engine: enabled: true -
Indented two spaces from the
engine:line (i.e. the same asenabled), add a linetest_time: "2021-11-25T08:00:00+hhmm"and where I have put +hhmm put your current timezone offset from GMT. Note also that I've shown 08:00:00 for the time, but you can use any time of day that you think will have the least side-effects with other rules.engine: enabled: true test_time: "2021-11-25T08:00:00+hhmm" -
Restart Reactor. The latched condition should go true and the rule should SET. You've basically time-warped the system backwards.
-
After that's done, remove or comment out (with a '#') the
test_timeline, and restart Reactor again. -
Observe that the rule refreshes and should remain SET, with the latched group true and that last date/time condition (11/1 to 1/7) also still true (green).
Also remember that I don't know what other rules that you have that may depend on this rule, so if there are date/time or sunrise/sunset rules that work in concert with this rule, they may not trigger unless the test time happens to also meet those rules. Just focus your attention on this one rule.
@toggledbits Seems like it has worked...
I also had a yellow warning about the system being in "test_time, not reality". But the true test came when I commented out the
test_timeline inreactor.yamland restarted MSR and all the holiday lights came on.The Russian Orthodox will have their Christmas lol
Thanks very much for this tool/tip - definitely will keep this around. And thank you for the really prompt fix on the bug, sir. I joke about the lights but it really wouldn't have ended the world if my lights were done for the season.
-
-
Apologies for interfering with tradition and observance!
I'm glad the test trick worked out, and indeed, it can be very handy. I'll make a note to add that to the Troubleshooting section of the docs as well. -
Apologies for interfering with tradition and observance!
I'm glad the test trick worked out, and indeed, it can be very handy. I'll make a note to add that to the Troubleshooting section of the docs as well.@toggledbits Just confirmation that this all did do what it was to do: I was still in my office and watched the xmas lights do their thing!
