Evaluation of time() comparisons
-
Not fully getting what you're on about, and with statements like "it kind of works" but no explanation of what doesn't seem to work, I'm not sure how to reply except with some generalities.
First, the rule is evaluated whenever any dependency changes. Your dependencies for what is shown are the Alarm Clock entity and the Interval, pretty much nothing else. The local variables are updated first during rule evaluation, before trigger conditions are checked, so that's when
time()is updated. With the Interval condition in triggers, that means the variables will be updated every 15 minutes, and 15 seconds after that (because the eval happens when the Interval goes true and again 15 seconds later when it goes false).The issue I see overall, I think, is that you are ANDing the Interval with your other conditions, meaning the rule state is only going to be pulsed (because Interval is a pulsed output) rather than sustained. I'm not sure that's what you want? If you want your
HeatOnandHeatOffconditions to produce a sustained state, move the Interval to a new group (as a sibling to the existing group), and have that group use the NUL operator so its state doesn't affect the trigger output. The existence of the Interval will then still cause periodic evaluation and update of the variables, but the rule state will be held true during the entire period betweenHeatOnandHeatOff, which I'm betting is what you're actually after?Also, the Interval controls the resolution of the timing in this logic, so if you're alarm clock is set for 5:05am, you likely won't get the heat turned on at 4:05am, but rather at the next 15 minute interval after that time. If that's OK, fine; otherwise, you need to reduce the interval.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
Not fully getting what you're on about, and with statements like "it kind of works" but no explanation of what doesn't seem to work, I'm not sure how to reply except with some generalities.
First, the rule is evaluated whenever any dependency changes. Your dependencies for what is shown are the Alarm Clock entity and the Interval, pretty much nothing else. The local variables are updated first during rule evaluation, before trigger conditions are checked, so that's when
time()is updated. With the Interval condition in triggers, that means the variables will be updated every 15 minutes, and 15 seconds after that (because the eval happens when the Interval goes true and again 15 seconds later when it goes false).The issue I see overall, I think, is that you are ANDing the Interval with your other conditions, meaning the rule state is only going to be pulsed (because Interval is a pulsed output) rather than sustained. I'm not sure that's what you want? If you want your
HeatOnandHeatOffconditions to produce a sustained state, move the Interval to a new group (as a sibling to the existing group), and have that group use the NUL operator so its state doesn't affect the trigger output. The existence of the Interval will then still cause periodic evaluation and update of the variables, but the rule state will be held true during the entire period betweenHeatOnandHeatOff, which I'm betting is what you're actually after?Also, the Interval controls the resolution of the timing in this logic, so if you're alarm clock is set for 5:05am, you likely won't get the heat turned on at 4:05am, but rather at the next 15 minute interval after that time. If that's OK, fine; otherwise, you need to reduce the interval.
@toggledbits said in Evaluation of time() comparisons:
If you want your HeatOn and HeatOff conditions to produce a sustained state, move the Interval to a new group (as a sibling to the existing group), and have that group use the NUL operator so its state doesn't affect the trigger output. The existence of the Interval will then still cause periodic evaluation and update of the variables, but the rule state will be held true during the entire period between HeatOn and HeatOff, which I'm betting is what you're actually after?
I'm betting you're 100% correct. I shall observe tomorrow. Many thanks (as ever)
Tangentially, the reason it's sustained is because if it's not the logs show that the ruel goes from Set to Reset, then immediately (10s of ms) goes back to reset and the Set activity never runs.
I'm happy to (try and) demonstrate what I mean with log entries etc, if this is not expected.
Thanks, as ever/
C
-
Yeah, I'd want to see logs for that, because I use this feature and it's working for me. Make sure your Reset reaction is completely empty, not even a comment.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
Yeah, I'd want to see logs for that, because I use this feature and it's working for me. Make sure your Reset reaction is completely empty, not even a comment.
@toggledbits I will try again over the weekend
Thanks
C -
I just ran my unit test on it, which is just a one-minute Interval condition trigger, and a Set reaction containing only a toggle of a switch. The light toggles on and off on the minute as expected. If I add a delay of several seconds before the toggle (so that the Rule fully resets before the command to t he switch can go out), the light still toggles as expected. If you see otherwise, a full log and a summary with the ID of the Rule involved would be helpful.
-
I've not tested but to be clear I had no delay but I did have Reset reaction (which was correctly executed)
Happy to test once I've got past tomorrow morning to validate where we are now (which according to the logs looks super, as the conditions are being evaluated every 15 minutes)
C
-
I've not tested but to be clear I had no delay but I did have Reset reaction (which was correctly executed)
Happy to test once I've got past tomorrow morning to validate where we are now (which according to the logs looks super, as the conditions are being evaluated every 15 minutes)
C
@catmanv2 said in Evaluation of time() comparisons:
I did have Reset reaction (which was correctly executed)
Then the question is answered... this is why you think your Set reaction didn't run. Because of the way the Interval was AND'd to the group before, the rule output was a 10ms pulse controlled by the Interval condition -- a set followed very quickly by a reset. The Reset reaction pre-empted the Set reaction, which is by design. This is why I asked if your Reset reaction was empty or not. If it's empty, the Set reaction isn't pre-empted, but if it's not empty, preemption happens. This is a documented feature/function of both Reactor for Vera and Multi-Hub Reactor. With that short pulse, the Set reaction on your rule was enqueued, but never got a chance to start.
@catmanv2 said in Evaluation of time() comparisons:
Do you want me to try and re-create the 'issue' I observed?
No need. Mystery is solved.
-
No worries! It's a bit of an odd feature, but important... my idea when originally done (in Reactor for Vera) was that most rules would have "do stuff" activities when the conditions were met, and "undo that stuff" activities when they were later not met (e.g. turn light on between dusk and dawn, off when it's not dusk-to-dawn), and it would probably be bad if both of those could run at the same time (i.e. one is trying to turn on lights while the other is scrambling to turn them off). So I made the design decision to have them pre-empt each other. That has carried over into Multi-Hub Reactor (aka MSR).
