I, like many HA users, control HA entities with voice commands using Alexa (or Google Home). I would like to create an automation that allows a voice command to turn on (or off) a whole group of appliances (e.g., all the fans in the house) without regard to how many of such fans are currently on, and without regard to how they were turned on. But it is impossible to do this with an input_boolean or template switch because the only permissible states are ‘on’ and ‘off’." For example, say I created an input_boolean called “All Fans” and then created an automation that turned off all of my fans when the state changed from ‘on’ to ‘off.’ That would work presuming that I previously turned on the “All Fans” inbput_boolean (or switch). But if I had turned on several fans individually (without using “All Fans” to turn them all on), saying “Turn off All Fans” would do nothing. “All Fans” would still be in the off state because it had never been turned on, and issuing a command to turn it off would not generate a state change, so no automation could be triggered.
This problem would be eliminated if input_booleans or switches (or a new type of entity) could have a state of “neutral” instead of just on or off. With such an entity in a ‘neutral’ state, an ‘on’ or ‘off’ command would always generate a state change which could be used to trigger an automation. And so long as you included a command at the end of your automation resetting the state back to ‘neutral’, any subsequent ‘on’ or ‘off’ commands would also generate state changes and thus could trigger automations.
How about using an input_select? You can then have as many options as you like, trigger on a state change, use automations to select a particular option etc.
Input_select entities are not recognized by Alexa. So if you had an input_select called “All Fans” and told Alexa to turn it on she would respond there is no such device.
Also, although perhaps a minor issue, if Alexa could see the input_select entities presumably you would have to tell it to “Set [Entity Name] to On.” Its more natural to say “Turn on [Entity Name].”
Well I’m pretty sure that if HA were to implement an input boolean with a third position, you would still have the same issue with Alexa / Google not understanding since they are expecting on/off only anyway.
To be honest your use case is hard to read / understand, but maybe explained better we could automate it another way. From what I can tell you just need to create groups.
If I am understanding you correctly, I think I have already done what you’re trying to do. I created groups for “upstairs lights” and “downstairs lights”. Then I created a template light that uses the state of the group. If ANY light in the group turns on, the template light turns on. When ALL lights in the group are off, the template light turns off.
I then passed the template lights into HomeKit so I can tell Siri “Turn off the upstairs lights” and everything turns off.
I recently did the same thing as a means of controlling several Tasmotized switches via MQTT.
The only difference is that I don’t use the group itself to control the switches; the group only serves to report their status for the Template Switch. To control them, turn_,on and turn_off publish a payload to a Tasmota GroupTopic (shared by all the switches).
Anyway, the upshot is that the combination of a group and Template Switch resolves the OP’s problem (the Template Switch is handled as a switch by voice assistants).
I just realized that template switches are unique in HA in that you can turn them “on” or “off” regardless of their state. That is, my original post only considered half the problem I was facing, i.e., how to turn off a group of fans when some of them were turned on individually. When someone suggested using a template switch with its state determined by the state of a group, I thought that solved my problem. But I didn’t realize that this was only half the problem. If a template switch behaved like other switches, then you would be unable to turn on “all fans” if any one fan was already turned on. In that scenario, the state of the group would be “on” because a single fan was on, and therefore the state of the template switch would also be on. You can’t turn on a regular switch two times in a row. But you can with template switches. Telling Alexa to turn on a template switch (or calling the service switch.turn_on for that switch) causes the template switch to fire the turn on sequence regardless of the template switch’s current state. Thus, using a template switch in this scenario works regardless of how you define the state of that template switch, and you don’t need a group at all.
So maybe I’m just nerding out on this. But I thought that was pretty cool. Opens up some new custom programing possibilities.
I use template switches as momentary switches when you cannot determine the value of a switch . Very usful for remote controls and use virtual bulbs for Alexa to allow 100 different responses to alexa routines
Continuing my nerd-out session: the post you refer to above says that the user created a template switch that runs specified actions and then automatically turns itself off, and the supposed purpose of turning it off every time is to allow it to be turned “on” again and run the specified actions again. What I am saying above is that there is no need to turn it off in order to run the turn_on sequence again. You can turn it “on” five times in a row, without ever turning it “off” and it will execute the turn_on sequence each time. So in reality, the only possible purpose for assigning a value_template in the first place is if you plan on using the state of the template switch in another script or automation. I have removed all of the value templates from my template switches and they work just fine.
It occurs to me that template switches would also be useful for assigning two or more names to a single device. For example, Alexa used to be strict about singular vs. plural, and I had a device named “Kitchen Lights” (plural). Occasionally, I would say turn on/off “Kitchen Light” (singular) and it would tell me there is no such device. This was annoying. So I tried to get around this with an input_boolean named “Kitchen Light,” but I had to create automations to keep this two entities in sync, i.e., making sure that they were always either both off or both on. This worked reasonably well, but if I manually turned the switch on and then off again quickly (e.g., turning it on by mistake and then turning it off again right away) it would sometimes get stuck in a loop turning itself on and off repeatedly, forever until I intervened. But with a template switch, you wouldn’t have to worry about keeping the entities in sync, since they will execute the turn on or turn off sequence, whenever called, regardless of their current state.
No the point is , if you turn the switch on via a lovelace GUI , you cannot switch it on again via the GUI because it is already on . There are alternatives , automations , buttons, etc , but the power of template switch is the value template does not trigger the action. Therfore you can link multiple switches together so when one switch is triggered you can change the state of the other switches without triggering the action. So in your above example you could keep them in sync by using the value template , rather than an automation to link the input_boolean to the switch.
