In reviewing a rule for potential editing, I realized that I have both of the following:
When x trigger occurs, turn Light A off
When x trigger occurs, if Light B is on, Then turn Light B off
They both end up doing the same thing: If either A or B is on, their respective rule turns them off.
In example 1, if LIght A is already off, HE just sends an extraneous command to turn off; nothing happens if the device is already off.
In example 2, the rule only runs if Light B is on; if Light B is off HE presumably goes on to the next command line.
So is one better than the other? Is it better to use the If/Then rule so HE is not sending an off command to a light that is already off? Or does it matter?
I donāt think it matters in practice. Itās one less command sent to the device, at best.
You could avoid the conditional action in a few ways. First the switch action itself has an option āonly control switches that are on/offā. You could also set a required expression for the switch being on for a rule with triggers to turn off (or a conditional trigger if thatās a better fit).
I personally prefer to avoid running the (unnecessary) action to reduce log clutter and simplify troubleshooting
It really doesn't unless you are spamming it a couple of hundred times a second.
I have a custom lighting app that whenever motion is triggered it turns on the lights. It doesn't care if they are on or off. I also send a color temp and level command to every light that is on every minute or two. They don't mind.
I don't do it, but perhaps the If statement could add to reliability. Say, if multiple commands are going out at the same time, less chance of missing one.
If HA needs to communicate with the module to see if it's ON or OFF, then that takes at least 1 command back and forth, so just sending an OFF command would be less traffic.
Well, the state for switch is stored in the driver, so the IF will cause RM to get the current value from the driver for that attribute state. The hub "knows" it because it is a value stored in the device object, but RM has to get the value. The off command will send a command to the device driver to turn off the light, and the driver will probably send a switch "off" event to the hub when it sets the attribute state to off again.
So with the IF statement, RM gets current value from the device, and then sends an off command to the device if it is on, which is up to two interactions with the device. Without the IF, it is always going to send one command to update a state, without having to get current value ever. However, saving a hub event from happening must be more efficient than saving a get current value call.
Rule Machine may be optimized to already not send a command if the state is already at the correct value, checking first every time. I don't use RM enough to know if there is a setting for that. In Webcore it does this optimization by default, but it can be turned off when needed.
So, I say it is more efficient to check and then update when needed, rather then to always update, but this optimization may already be in place in RM.
