Simple automation on/off fan for heating

Hello,
I have a sensor I like to control a switch controlling a heating fan.
I like the switch to turn on at below +5 degrees and turn off at above +10 degrees.
In my new HA i see:

Trigger Greenhouse sensor temperature change
Above: xx
Below: xx

Can I assume that the trigger goes “false” above the “above temp” and “true” above the Below temp?
So to achieve the expected behavior I need to automation entries, one to go active below +5 and another automation to turn off above 10… or is there a way to fix this with one automation entry in the configuration?
Thanks in advance!

There is a component to achieve exactly this:

No, a trigger is not true or false. A trigger is a piece of code which runs when the conditions are met.
So, the trigger fires when the above condition is met or when the below condition is met.
It is up to you on how the trigger responds, by reading the state of the sensor and determine if the heating fan should turn on or off.
One automation is enough, which has both the above and below set.

But ub your case it might be easier to use the Generic thermostat

Hello,
I will investigate the thermostat feature for the purpose but like to learn a bit.
So the sensor automation sends a trigger when the “Above & below” thresholds are passed?
The I need another automation to listen to the trigger, and when the trigger hits I need to read the value of the sensor and turn off or on the heater.
Is this the correct way and correctly understood?

Sorry but that’s not correct.

triggers are booleans. they are “true” or “false”.

The trigger will start the automation when the things that are in the trigger return a value of “true”. It will not re-trigger until those things become “false” then become “true” again.

Then once the trigger becomes “true” it evaluates the conditions. Which must also return “true” for the actions to run.

OP,

it’s probably best to use the thermostat config as recommended but to explain your original question…

If you decide to go the automation route you will need two triggers - one to turn the fan on below +5 and another to turn the fan off above +10.

You could do it with one automation using both triggers in one automation using the “choose:” function for the actions but it is more advanced and I don’t know how comfortable you are with that.

TBH, the easiest way is to make two automations - one to turn the fan on & another to turn the fan off with only those individual triggers in the automation.

Thanks a lot for the clarification.
I started out with two automations as this seems the simplest but not the nicest, perhaps this is also easier when I need to update and have forgotten what I did :slight_smile: Itried the thermostate and this works also fine and I will try the “choose” just for training purpose!
Thanks all for input!

Hello again…
not sure I really got it…
My automation looks like this example;

Trigger "Greenouse temp" temperature changes
Above 15 °C
Below 6 °C

Will this sensor generate a trigger when it passes above 15 and then again when it falls below 6?
No other cases will make the automation to trigger - right?

I don’t really use HA Automations but you cal always change the values with the developer tools for testing.

You are really not understanding triggers, triggers have no state. A trigger is just a trigger, without any state.
You cannot do a states(“triggers.mytrigger”) or anything like that.
A triggers fires when conditions are met, that is why they are called triggers. (like in a gun, fire and return to be fired again)

Yes, but you did not state which entity to use as input.
Can you post the yaml or screenshots?

You also have a nice debug view of automations, press this button:
image

There you can see the traces when an automation has been fired (execute manually of no traces are there yet)

Nowhere in finity’s explanation does it mention that a trigger is an entity with a state. The states() function can only be used with an entity and finity never said a trigger was an entity with states.

Finity’s explanation of a trigger’s operation is conceptual. When the trigger is evaluated and meets the stated requirements then it is effectively “true” as opposed to “false” when the evaluation doesn’t meet the requirements. For example, a Time Trigger that is evaluated every second is “false” until the current time matches the time specified in the at option, then it’s “true”. You are correct in saying it’s not a boolean state value that can be accessed by the automation but finity never made that claim.

What can be accessed after triggering is the Trigger State Object, now referred to as the trigger variable. It contains properties that vary depending on the trigger’s platform. For example, this is for the State Trigger and its properties are accessible to the automation’s variables, condition, and action.

State

Template variable Data
trigger.platform Hardcoded: state
trigger.entity_id Entity ID that we observe.
trigger.from_state The previous state object of the entity.
trigger.to_state The new state object that triggered trigger.
trigger.for Timedelta object how long state has been to state, if any.
1 Like

I understand what he is trying to say, but that is conceptionally incorrect. A trigger is fired when conditions are met. Is does not become true, nor false.

I know it’s a bit theoretical but you can come across some strange design issues if you qualify triggers as booleans with either true or false.
From there it is a small step to think the can be on or off.

But hey, that’s just my opinion :wink:

In this context, the terms true/false are being used in the same manner as triggered/not triggered. The fact is that, behind the scenes, a trigger is not evaluated only when its conditions are met but also when its conditions are not met. When they’re not met the evaluation’s result is “false”; when met its “true”.

Simplest example is a Time Trigger. If set to trigger at 17:54 the system checks for a match with the current time at each clock-tick. In other words, there are many more “false” evaluations than the one “true” evaluation when the trigger occurs.

Yet, effectively, that’s how all triggers can be modeled. They’re off until they meet their conditions and are momentarily on. It’s the rising edge of this “pulse” that represents the trigger. In fact, another home automation software I have used, for over a decade, has a “momentary boolean”. Turn it on and its immediately turns itself off. It’s commonly used as a trigger for executing other things. Its state-change from off to on is what serves as the triggering signal. Effectively, all triggers in Home Assistant behave like momentary booleans.

It’s hard to know if your automation is set up correctly if you only use pseudo-code.

Please post the entire automation(s) in the correct format so we can see what you have and can tell you if it’s correct.