I have a question on rules. Suppose I have a fan (iFan02 with Tasmota), which has a state: Switch_sonoff_WZ_fan_spd . I attached a rule like the following:
rule "Monitor Temperature at Ventilator - Wohnzimmer"
when
Item Switch_sonoff_WZ_fan_temp changed
then
val currMonth = now.getMonthOfYear
if(currMonth >= 10 || currMonth <= 3){
if(Switch_sonoff_WZ_fan_temp.state >= 25.5 && Switch_sonoff_WZ_fan_spd.state == 0 && max_WZ_T_mode.state == 'AUTO-MODE'){
sendCommand(Switch_sonoff_WZ_fan_spd ,"1")
}
else if(Switch_sonoff_WZ_fan_temp.state <= 24.8 && Switch_sonoff_WZ_fan_spd.state == 1){
sendCommand(Switch_sonoff_WZ_fan_spd ,"0")
}
}
end
This rule enables the fan during winter time (October-March), in case the heating system is on AUTO, if the temperature at the ceiling (fan_temp) reaches 25.5 degC and turns it off when the temperature is below 24.8 degC.
I wish however not to turn off the fan if I enabled it (e.g., via web GUI).
As well if in the last 5 minutes the fan was on via this rule, then it should move to the next speed (Switch_sonoff_WZ_fan_spd ,“2”).
Do you have suggestions for me? Is this rule robust enough in your opinion?
Let’s work on that bit.
What do you do at your UI to “enable it”, what “it”?
How can your rule detect that happened?
When does it stop being “enabled”, is that another UI action,or does it last an hour or a day etc.?
“it” is the fan, where “enable it” means that I changed the fan_spd.state via UI from any value to any other value… Values are a map 0…3, where 0 is OFF and 3 is max speed.
open for suggestions…
It shall stop when I want to stop it, i.e., via UI I am selecting OFF (mapped to fan_spd.state = 0).
So basically if my system detects that the user is turning ON/OFF/LOW/MID/HIGH, then the user is responsible to shut the fan OFF. Should then a check on previousState = 0 of Switch_sonoff_WZ_fan_spd right before executing the first if(...) solve my issue or would it then lock it out (–> not executing the else if to turn the fan OFF)?
There is no way to separate a command issued to an Item by UI, from a command issued to Item by rule. In other words, if you want to command Item X by rule you cannot also detect UI commands by rule.
That’s why I was interested in this part up front.
What you want can be done of course, but it quickly gets complicated.
One way, have Item X linked to your real device, but put a dummy Item Y on your UI.
A rule can mirror state change of X to Y for display.
Another rule can mirror UI commands at Y to X for action. This rule can also manage a “manual” flag on and off, a global variable or another dummy Item.
Finally, the rule that carrys out the automated stuff can work directly command to Item X, but only when the manual flag is off.
Persistence? Well, I suppose you might want that if you needed your “manual mode” to survive a reboot. I wouldn’t bother, you don’t expect to reboot for months at a time.
But if you want persistence/restore, then you will have to use an Item.
Otherwise I’d just use a (global) variable.
