Using the implicit variables almost always makes the rule shorter and clearer than the alternatives.
I’m not certain that it’s relevant in this case though.
Looking at the rule, you probably only want it to run when an Item changes state, not a mere update, so I’d start by changing the triggers to changed as @rossko57 suggests. That will constrain slightly when the rule triggers and should make it easier to track what’s going on (events.log doesn’t log out updates to Items, only changes and commands).
That’s not really how it’s supposed to work so we would need to see the code to understand more.
Rules like this tend to become easier to read and simpler if you use my Design Pattern: How to Structure a Rule DP.
rule "Update fanspeed"
when
Item Fancontrol_automode changed or
Item Fancontrol_nightmode changed or
Item Fancontrol_venting changed
then
var speed = 3;
if(Fancontrol_automode.state == OFF) speed = 2
else if(Fancontrol_nightmode.state == ON) speed = 2
else if(Fancontrol_nightmode.state == OFF && Fancontrol_venting.state == OFF) speed = 2
SonoffiFan03_Fanspeed.sendCommand(speed);
end
Obviously you would structure the conditions as desired (it might help future you understand what’s going on if you list out all the possibilities instead of defaulting to 3 and only checking for the 2 states). But by separating the sendCommand from the conditions it’s really easy to add stuff. For example, add some logging which will help us understand what’s going on, or a check to only send the new speed to the fan if the new speed is actually different, add some hysteresis (more important for a sensor driven rule), etc.
Anyway, when you call MyItem.state, you get the state of that Item right now. Where one runs into trouble is right now may not be completely up to date, especially with commands. Or the Item might have already changed state when the rule starts running which also can cause problems.
A changed trigger won’t occur until the Item has actually changed so that first problem shouldn’t be a problem if you change the triggers. It used to be the case that a received update trigger would not happen until after the Item was updated too. I’m not so sure that’s still the case, though it doesn’t make sense otherwise. I’m pretty sure it’s the Item itself that generates the event.