Using the following condition for testing:
I had a similar condition that didn’t behave as expected, so I created this test. It didn’t trigger (go true) every 7 days, unless I restarted the RS in question. Today I noticed that if restarted, this condition triggers although it shouldn’t as its tied to a specific date (“relative to…”)
I wonder what others get if you try this out? Should be easy to repeat.
Restart clears all state data for the ReactorSensor, so the date/time condition will go true immediately as if it has run for the first time ever (since the condition is currently met). That will cause the interval to fire its first interval, which occurs immediately upon the true transition (leading edge) of the dependent condition (date/time).
I have automated tests I use for most of Reactor’s functions. This has been working for some time, and I just reran the interval test suite and it’s fine for 3.7, 3.7 hotfix, and 3.8develop/stable. It also tests for stability and accuracy across reloads. No issues.
If you believe it misses an interval, run do not walk to your Vera and pull a Logic Summary for the ReactorSensor. Do not restart the RS or Vera, as this clears the in-memory event log for the sensor and will make the forensics harder. No screen shots, just the Logic Summary, please.
@rigpapa, just sent logic summary via email as my test interval condition failed when it shouldn’t have. Tell me if you need more information
The dependent condition for the 7-day interval (date/time after 2020-09-07 12:00) shows this:
| &-T-trange after 2020,9,7,12,0,,,,, [1600075800 => 1600077600 at 13:00:00; T/T as of 09-07.16:52:13/09-07.16:52:13] <condw8shkkd>
It last went true at 16:52 on 2020-09-07. I’m guessing when you created the test, you set up noon of 7-Sep as the trigger time, but it was already past that time when you finished editing the config. Reactor stores the time the condition last went true, which was 16:52, probably when you finished editing or did a final Restart. The interval would be measured from that point (the time of true). This test therefore isn’t valid. I’ll bet the interval goes true at exactly 16:52, about 10 minutes from now for you, I think? As long as you haven’t gone in and edited the config again (which causes a Restart) or done a Restart manually.
Yes, you’re right, it did go true 16:52. So how do I ensure these interval conditions trigger exactly as defined (in this case 12:00)? I have to always set the relative time to some future date? What if Vera reboots or RS is restarted afterwards, do I have to set (define) these relative times again to ensure they trigger as expected?
Reboots/restarts of Luup do not affect timing. The only thing that will reset timing is either a change of the condition state, or a Restart of the RS (which can occur when editing it), in which case the current state of conditions is flushed and everything is evaluated as if it was being run for the first time.
Interval conditions fixed to time are best configured using a relative time rather than a dependent condition. At the moment, there is no date component to the relative time, but I will look into adding that to the UI for 3.8. The workaround for now is to use a dependent date/time condition as you have done, but make sure the date/time (after) is set to the next trigger interval when you first edit the configuration. As long as you don’t restart the RS or modify its configuration, it will run on time from there. If you do edit or restart it, just remember to move the anchor date into the future.
By the way, we’re a little X-Y here… why are you doing this? Can your goal not be achieved by a weekday condition triggering once a week?
I need an interval of (exactly) two weeks as it’s related to a boiler that does an “extra” heating (legionella disinfection).
Do you think you could fit this feature in 3.9?
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules