Thanksgiving lighting took a holiday

[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