How would I go about creating a type of logical OR switch that controls a physical switch?
I have a high ceiling fan that I want to turn on when a generic_thermostat (created in yaml measuring temp near ceiling) turns on, OR when my upstairs HVAC turns on, or when the downstairs HVAC turns on. (HVAC is Ecobee, so may need to use some kind of automation to monitor state)
I do not want the fan to turn off when any one thermo turns off, only when all inputs are off.
Advice please?
You have described the requirements for an automation. Specifically, an automation with three triggers (one for each of the three events you described) and a single action (that turns on the fan).
A separate automation can be used to turn off the fan. In addition to three triggers, it will need three conditions (each confirms one of three inputs is off, as per your description).
What do I create for the generic_thermostat heater “toggle device”, it needs to be some kind of synthetic switch, that I can then use as input on the automation?
When you used the Generic Thermostat integration to create a climate entity, you had to specify a switch entity (that is responsible for controlling the heating device). Use a State Trigger in your automation to detect when that switch is on.
It is that switch I want to control, I cannot use the same switch to monitor and control.
I need some kind of synthetic switch for the thermostat to control, then I monitor that synthetic switch, and set the real switch that powers the circuit.
I found input_boolean, trying that, thermostat seems happy to control that.
Now I created an automation that will turn the fan on when the HVAC equipment is running on input_boolean is on.
But this is an OR in the automation, and as an automation there is not a state output, just a control, so once the fan is on it will never turn off.
How do I turn the fan off when all inputs are off, i.e. really like a logical OR with a state as output.
You said you wanted to control a fan.
If I have understood your description correctly, you want to turn on the ceiling fan whenever the (heater) switch is turned on by the Generic Thermostat integration. That’s why I had suggested using a State Trigger to monitor the switch (that’s managed by the Generic Thermostat integration).
You can create a helper of type “Group”, mode “Any”.
If you add all your sensors to this group, the output will be “on” if any sensor is on, and “off” if all sensors are off.
Then add an automation to copy the output of this group to your fan’s setting.
I use it with motion detectors: when any detector in the corridor detects someone, the output of the group is on, and the lights turn on.
I also said I want to turn the fan on when the upstairs or downstairs HVAC fans are on, thus switch state is an OR of inputs.
electrical_switch = generic_thermostat OR climate.upstairs OR climate.downstairs
As I explained in my first post, that’s just two more triggers in the automation, each monitoring the upstairs/downstairs HVAC systems.
List the entity_ids of all entities involved in this project. My guess is there are at least three climate entities and one or two switch entities (and maybe one fan entity).
What kind of group, I add group, and am then offered different types of groups, seems each type is the type of entity allowed in the group, so I can’t get e.g. climate.fan as a state and input_boolean in the same group, at least not in the GUI I can see?
To be more specific, I created input_boolean for my generic thermostat, I want to group this with the climate.fan attribute from my Ecobee thermostats.
I am now here: input_boolean: stairs_ceiling_fan_control: name: Stairs Ceiling Fan Cont - Pastebin.com
I created an OR automation to turn the fan on when any of the inputs are “on”.
I created a second NOT automation to the fan off when none of the inputs are “on”
Turning on seems to work, but the fan does not turn off again.
Is there something wrong with my turn off action, or do I misunderstand how a NOT condition works?
Any ideas please?
If you create a template binary sensor and put something like that in the template it should work:
{{ "on" in (states('input_boolean.test_toggle'), states('binary_sensor.dm1_rc_palier_occupancy'), states('switch.r2_escalier_lumieres')) }}
This makes a tuple out of the states of the various sensors mentioned, the result is for example (“on”,“off”,“off”). Then it checks if “on” is in the list, that means one of them is turned on.
Note the first thing that comes to mind is:
{{ states('input_boolean.test_toggle') or states('binary_sensor.dm1_rc_palier_occupancy') or states('switch.r2_escalier_lumieres') }}
That doesn’t work, because “off” is not False, it is a string, and it is not empty, so it has the logic value True if you use it with “and”, “or”, etc… Also it uses short circuit evaluation so it stops at the first one, and HA never sees that the template needs to listen to the 3 sensors.
The list approach works. This also seems to work, it’ll give the number of activated items:
{{
("on"==states('binary_sensor.dm1_rc_palier_occupancy'))
+ ("on"==states('switch.r2_escalier_lumieres'))
+ ("on"==states('input_boolean.test_toggle'))
}}
Yes, I had trouble with the “on” tests because it can also be “unavailable” or “off”, that is when I found some google posts suggesting to use the NOT operation that is what I was looking for.
And I just got the fan to turn off, my bad in what I copied for the paste is not what I saved, I missed a trigger.
Yes. The one with the list will work even if some devices are unavailable. The list will simply contain a mix of “on”, “off” or “unavailable” ; so by testing if “on” is in the list, it will do what you want.
Once you have this template sensor, its state will be “on” if at least a device is on, “off” otherwise. So you can use an automation to trigger on it.
Why are both automations using State Triggers to monitor the state value of climate.upstairs and climate.downstairs?
It’s an odd choice for the following reason:
The state value of a climate entity reports the HVAC equipment’s operating mode. It’s the hvac_action attribute that indicates when the HVAC equipment is actively working (heating or cooling).
Don’t you want turn on the fan when either HVAC system is actively working? Because you now have it triggering when the HVAC system simply changes operating modes.
climate.downstairs/upstairs are the ecobee entitites, any state change evaluates the fan attribute state to test if the HVAC fan is on (fan on by itself or fan on as part of heating or cooling).
Does it matter that I evaluate on any state change for the entity, vs. only on e.g.:
trigger: state
entity_id:
- climate.upstairs
attribute: fan
And to check, my automation is only turning on/off if the fan attribute is in the correct state:
- condition: state
entity_id: climate.upstairs
attribute: fan
state: "on"
If the ecobee’s fan attribute indicates on whenever the HVAC system is operating, then I suggest you consider using the following. By specifying the exact requirements for triggering, no conditions are required.
alias: Stairs Ceiling Fan On
triggers:
- trigger: state
entity_id:
- climate.upstairs
- climate.downstairs
attribute: fan
from: 'off'
to: 'on'
- trigger: state
entity_id:
- input_boolean.stairs_ceiling_fan_control
from: 'off'
to: 'on'
conditions: []
actions:
- action: fan.turn_on
target:
entity_id: fan.stairs_ceiling_fan
mode: single
I overlooked to mention that I don’t know what are the valid values for the fan attribute and simply assumed they are off and on (my climate entity isn’t ecobee and doesn’t have a fan attribute). You may need to replace off and on, in the example automation I suggested, with whatever are the actual values used by your climate entity.
I’ve been using a different approach successfully for ceiling fans and a bunch of other equipment.
I call it the “Demand” approach.
Understood, for me it is just easier to separate triggers from conditions, and in my naive view the computational cost is the the same.
Re. on/off, there is also unavailable, so testing for just on is easier.
Interesting, I’ll keep the binary sensor template in mind if/when I need to change this, so that allows for more interesting logic to not be in the automation.
Your original version of the State Trigger will trigger more often because it doesn’t specify an exact state-change. It triggers for any state-change. Each time the State Trigger triggers, it proceeds to evaluate the automation’s conditions and then, regardless of the outcome (i.e. even if the conditions aren’t fulfilled) it will produce a trace.
The version I posted only triggers when necessary and then executes its action and produces a trace.
So no, the computational cost is not the same.