Using Wait for Event - Logic check please

Can someone please check if my Rule Machine Logic is correct please?

Context:
1/ I have a pump in my garden that pumps water from the pond and returns via a stream;
2/ This rule controls the activation of the pump and an 'End of Day' Rule turns it off (and set's the Mode to 'Night' amongst other actions);
3/ In the winter, I don't want the pump to run if the temperature is below 5C. (I have another rule that shuts the pump off if the temperature drops during the day.)

My question is primarily around the 'Wait for Event'. (I don't want to turn it on, on the off chance that temp rises above 5C later in the evening, if the End of Day rule has already run.)

I'm not sure that the ELSE-IF Mode is Night is required?

Right - I don't think the the else-if mode is night is required since the rule will stop executing anyway. I think the logic is OK... have to test it and see. You could create a virtual temperature sensor and put an OR in your wait statement, then manipulate the virtual sensor and see if the rule fires as you expect. Otherwise you'll have to wait until the temperature really drops that low :slight_smile:

Thanks - I've removed and inserted it twice so far! I'll take it back out! :rofl:

I dont think it will change the behavior of the rule... just an OCD thing.

I think you could really simplify your rule by using a Wait for Expression instead of Wait for Event.


Trigger
When time is Sunrise-30 minutes

Actions to Run
Wait for expression: Temperature of Patio Motion Sensor is > 5.0
IF (Time between Sunrise-30 minutes and 23:58 AND NOT Mode is Night) THEN
    On:  Pond Pump L Ext HA
END-IF

If the temperature it already > 5 when the rule triggers it'll go to the next Action otherwise it'll wait for the > 5 expression (condition) to be met.

2 Likes

That is much more elegant, thanks. I'll test this later. :slight_smile:

I've got a question in light of the replies.

Looking at this some level the logic here could be handed by the new Required Expression feature in RM.

No? And if so, is or isn't it a Best Practice to employ that where it can be used?

Do you have an example of how you were thinking of using the required expression feature in this case? In general, I wouldn't say there is a "best practice" with regards to whether or not you should use it versus a conditional in your actions (or any other means to accomplish the same outcome). In many cases, it can simply be a question of how you prefer to write rules. In others, there could be some theoretical advantage (the expression being false prevents the rule from triggering--and generally from even waking for the trigger event, so if events related to the expression happen less than those related to the trigger, the rule may wake less often, possibly resulting in less hub resource usage)--but even then, in many cases, that distinction may be (a possibly slight) one purely of runtime statistics with no real-world impact.

I do see some people "overuse" the required expression feature (maybe because the box is there and they really want to turn it on and find some way to use it), by which I mean that they use it even though it results in an outcome that isn't quite what they want and would be better suited with conditional actions that can be made to do what they want. That's my main hesitation with recommending it--it doesn't seem to be in need of help getting discovered. :rofl: (But, of course, that's not a reason to not use it when it does work...)

That's basically the root of my question.

The OP has three different conditions at play; a temp threshold, a time window, and Night mode. Maybe the temp and Night mode would have been overriding Requirements to be met before even bother teeing up the rule.

But as you suggest, maybe it maters not. And maybe I'm making the mistake of using Required Expressions as a gatekeeper to my new rules. I won't say it's been painless, case in point I think it and/or Set Private Boolean may be adding to the headaches recovering from a power outage "in-the-middle-of-a-rule-in-waiting".

Thatā€™s solveable by appropriate initialization actions in a rule triggered by systemStart. Thatā€™s how I do it.

1 Like

Yes, I've read some of those threads and I'm getting there. It's so easy to whip up a rule, spend time debugging, and not spend the time power-proofing it as many need to be.

VERGING OFF TOPIC
This is a HIGHLY underrated subject that newbies should be encouraged to look at right from the start. It's placated by the "buy a UPS" but I've found sometimes mine don't switch over fast enough to prevent the burp. I am not sure if there is a system App in the making there (I think I recall folks making a point about that)
END OFF TOPIC - WARNING - DO NOT EXPAND ON HERE - OR DO SO AT YOUR OWN RISK :wink:

1 Like

My understanding of a Required Expression is that it creates a filter that restricts the number of times a trigger is evaluated. In this scenario, I want a normal flow to turn the pump on at a scheduled time, with an alternative flow to delay that action until the temp is above 5C.

I can't see an obvious way of using a Required Expression to cover both the Normal and Alternative flows of this Use Case.

There are many ways to write a rule to achieve the same outcome. As you can see, I've suggested an alternative that I believe is "cleaner" but doesn't achieve a different result. Yes, the OP could rewrite to use the Required Expression. One way would be to make the temperature the trigger but restrict the rule's firing on time window and mode (or NOT mode). I would then suggest that the rule's Private Boolean be used to also restrict to one time firing so in this instance I think the Required Expression could make the rule a little more complicated. I think the OP's approach of checking conditions is the correct approach in this instance.

I think the most important thing to do is to write a rule that you understand. When things aren't working right it's your logic that you'll be trying to understand.

3 Likes

I'm trying to discern when it's ideal to use the Required Expression over the Conditions versus ideal to use Conditions over Required Expressions. Does anyone have a good example of when and why to use one over the other? I understand they're interchangeable in many senses but I feel as if I'm missing their intended niches and why both exist ...

It may be better to post your question in a new topic, but first it may also be worth checking out the documentation in case there are any pointers in there.

1 Like

I'll try new thread. I've covered the documentation and understand what it's outlining but thought maybe someone had a good real world scenario and outline the consequences of using RE in one and Condition in the other and the different outcomes.

2 Likes

One quick think that I learnt a little while ago is that a required expression is essentially evaluated before a trigger fires, so, for example, if you only want a rule to fire on the transition from night mode to day mode, your RE would be mode equals night with a trigger of mode becomes day, but this is not something you could achieve, at least as easily, with a conditional action.

But others will likely have other examples and it would be good to cover them in a separate topic.

Required Expression applies to the entire rule so all triggers. For example, if you only want to trigger the rule on the front door or back opening between sunset and sunrise then use a required expression.

Required Expression
Time between sunset and sunrise

Trigger Events
Front Door, Back Door any opened

What if you want to trigger the rule if the front door opens between sunset and sunrise OR the back door opening between 9:00 and midnight? For this use Conditional Triggers

Trigger Events
Front Door opened - ONLY IF (Time between sunset and sunrise)
OR
Back Door opened - ONLY IF (Time between 9:00 PM and 12:00 AM)
2 Likes