Assuming I have some switch and want to make it assume a given state by a scene, I’d do something like that:
scene:
myscene:
switch.myswitch: off
However, as it appears, that will actually turn _off the switch, even if the switch is already off.
Currently, I’d say, that is not desirable behavior. However, it could be changed in too many places for me to just go and fix things:
Scenes could only call services, if need to. This could be implemented in the reproduce_state type funtions.
The turn_off action itself could do the check. But that would prevent people from force issuing turn_off if needed for some reason.
Each component/platform/whatever could implement such checks in their turning off functions. That would be hard to track and keep consolidated.
For my case (I have template lights) this can also be solved in the turn_off script. That’s easy, but not a general solution.
So, I was wondering: is this intentional? What is the design philosophy behind switches, scenes and turn_off? Is there a difference between assumed states and known states?
My preferred choice would be having it in reproduce_state. The basic design philosophy behind this could be: When turning on scenes, run as few as possible services.
What do you guys think? What do the core dev’s think?
Are you counting the microwatts of energy expended to command a light to turn off even if it’s already off?
For most situations, it’s a non-issue. The only edge-case where it might make a difference is if you were to command dozens zwave/zigbee/Wi-Fi/Bluetooth lights to turn off that were already off. in that moment when all those commands are being transmitted, it might delay some other command. In all other situations, it’s a blip on the radar.
You’re right, of course: Most of the time, it’s a non-issue. One issue is a possible delay in communications.
But here’s another aspect: I have switches, where switching them has undesirable side-effects. For example, my receiver only accepts a toggle command. So, switching it off (if already off) will actually switch it on. (Thus my question regarding different handling of assumed states and known states, which I have not tested. It might already be solved in a sensible way.)
Another aspect is some (ok, rather unusual use case) where I have split a light in two different dim segments (using template lights). So, a lowly dimmed wall lamp is my “night light”. A highly dimmed wall lamp is my “reading light”. If my reading light is off (i.e. the dim level of the physical lamp is below a certain threshold), switching it off again will still set the physical dim level to zero, thus also switching off the night light.
So in summary, my use cases are a bit special. They are probably solveable with custom templates or scripts. But they could be solved in a cleaner and more consistent way, ideas of which I have collected in my first post.
That is why I asked the question in the philosphical form: Is there a philosophy? If yes: which one? If no: which one should be the good one?
My own preference would be what you suggested: if a device is already off (or on) then a command to turn it off (or on) is ignored.
I’ve been using another home automation software (Premise) for over 10 years. It works the way you described. In Premise, if a light’s state is currently true, a request to set it to true will be ignored (no command will be sent to the light).
For example, this is how you turn on a light in Premise:
Home.Kitchen.CeilingLight.PowerState = true
The light is called Home.Kitchen.CeilingLight, it has a property called PowerState and if you set it to true, the light turns on. However, the on command is sent only if the light is currently off.
If you wanted to send an on (or off) command to a light that’s currently on (or off), you would use a function called SetValueForced().
Anyway, that’s how it’s done in Premise (which was discontinued in 2006). I don’t imagine this behavior will be adopted in Home Assistant unless someone with the required programming skills chooses to undertake the project. Effectively, a service call such as light.turn_on would only act on entities whose state is off. However, then you’d probably need a new service like light.turn_on_forced. I don’t imagine anyone wants to make so many changes to Home Assistant.
So, Premise did it the 2nd way in my list. And had a separate force_turn_off service. I think, the force service is essential in that solution and you’re right: no-one will invest that much effort.
What do you think about the 1st solution: Only do these checks in scenes (as far as possible)? Would that break many things?
I haven’t looked at the underlying code for Scenes but that seems like a good compromise that would involve less development work (and not be a system-wide breaking change). Effectively, scenes would have a special behavior, different from setting the state of groups or individual entities. If that were a Feature Request, I’d vote for it.
I just noticed, where else the current scene handling disturbs me:
I have a (currently dimmed) light to be ‘on’ in a scene. That turns my light to full brightness. Although just keeping it dimmed would be enough to fulfill ‘on’.
In this case, I would certainly expect scenes with/without requiring a given brightness to behave differently.