Evaluation of time() comparisons

[CatmanV2]

Apologies in advance, I expect I am going to make a total pig's ear of explaining, so please bear with me....
(and if it's in the manual, just tell me to read the manual)

Going back to my heating scenario:
We have an alarm clock that goes off at a variable time.
We want the heating to go off at a time before that (1 hour)
so we have created the rule set as below:

So if current time is >= to the HeatTime, the first condition goes true.
The second condition is to ensure that nothing (tries to) turn(s) the heating off during that 1 hour window
The interval is there because in Reactor there was precisely that to (from memory) 'make sure the variables updated'
In the current state it kind of works. There is no Reset action, so the heat goes on once every 15 minutes during that hour.
In Reactor I didn't have to include the interval in the rule set. It was a stand alone rule as here:

If I move the Interval condition out of the rule set in MSR, things do not update as time changes (and the rule never sets)

So I guess the question I'm trying to ask it 'what causes expressions like
time() >= HeatTime

To be evaluated, and is there a better way than I've done here?

Apologies again

C

[toggledbits]

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 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?

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.

[CatmanV2]

@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

[toggledbits]

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.

[CatmanV2]

@toggledbits I will try again over the weekend

Thanks
C

[toggledbits]

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.

[CatmanV2]

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]

This is now working perfectly with the Interval in the new group, and being Nul.

Do you want me to try and re-create the 'issue' I observed?

C

[toggledbits]

@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.

[CatmanV2]

Got it. Thanks
Apologies for not noting that in the doc!

C

[toggledbits]

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).

[CatmanV2]

Yes it makes total sense when looked at from that perspective. I just need to find the right perspective

FWIW I am very much impressed by MSR, despite not actually having anything other than OpenLuup / Z-wave on my system (yet)!

C