To directly answer your question, this is possible, exactly as written (using simple conditionals) or with an IF THEN ... ELSE-IF (or ELSE) ... END-IF, i.e., using the "full" conditional actions, the other alternative just posted.
As usual, there are lots of ways you could do this. FWIW, I'd suggest doing it as @Sakman did above--it's easier to write, arguably easier to read, and makes a little more sense from the hub's perspective in that you can just trigger on what you want and subscribe to things "on demand" in the actions rather than triggering on anything and then needing to do work in the actions to figure it out. The only functional difference is that this type of rule will only turn the fan off if the temperature went above this reading in the first place to start your actions; if you really want something that does on or off, regardless of anything else, you'll need an approach like the above. (Or two rules--again, lots of ways. )
One thing that got me thinking though, RULES with trigger that happens on change means it's firing every so often right? Thus using the TEMP on-Change as trigger may not be good for the hub specially if you have a lot of rules?
And wouldn't this mean also that every temp change that's above 25c will trigger the ON action, and thus this action is fired repeatedly even if the fan is already ON....
So it got me thinking, it might be that the best/optimized way to do this is just make 2 rules , each triggered NOT on TEMP CHANGE but rather when a specific TEMP is hit...
I mean, i dont know how the hub works internally... it could be that the hub is evaluating all conditions on change anyway , regardless of my trigger rule, and if that's the case, then either method shouldn't matter right? - in terms of resource/cpu cycle
Regardless of whether the trigger is "temp = whatever" or "temp = changed" the result is that the rule subscribes to "temp" events (which equate to "changed") for whatever device is selected. If you set the trigger as "temp = whatever" then the rule is implicitly checking the temp change for the selected value before entering into the ACTIONS portion of the rule. If you set the trigger to "temp = changed" then the rule is just triggering every time there's an event. If the first action is to check that temp value, then you, in theory, are using the same resources as triggering based on "temp = whatever"
One thing to point out that was hinted at in this solution:
Is that your original conditionals would ignore temps that equal 25. It is often overlooked to include all conditions that could occur. I ran into this with time based lighting controls that got triggered across a specific time because I forgot that when you run if/then conditionals, you need to include all possible conditions that could occur or add a global else statement that covers outlier conditions. (Sometimes that works out to a default no action and that is okay. But, more often than not, it will cause problems) Whenever doing conditionals, it is important to think about what happens if none of the conditions specified occur.
Note that this isn't necessarily a problem for a rule like this; when working with temperatures and heating/cooling, it gives you some room to work with if the temperature hovers around a certain value without constantly turning the switch on or off, which if anything is probably more desirable. But yeah, not so much if it's time-based lighting or something where you always want something to happen.
Agreed that it might not be in this particular situation. However, I see this logic causing all kinds of problem when people are not expecting it. Just pointing it out as I think the original intent was that one of those should be a <= or >= the way he wrote it. For temps, I would space it a few degrees just like @kahn-hubitat did. But, it would have been done with intent and consideration.
)
