Condition for one temperature being lower than another?

It’s going to be a case by case basis obviously depending on what you are doing. But I’ve used this to dynamically adjust my aircon for example. I want to make changes when temperature is above, and then still above; just comparing one to the other would only fire once, until it falls below and then again rises above, not much use in my case. I also dont trigger every minute, its only every 10, but same point.

Just firing once, might be exactly what you want, again case by case basis.

  1. Yeah, I guess I could cast to float. Would probably make a small difference on the “warm” end of the scale with 24.1 to 24.9 (one digit accuracy on temperature measurements) counting as “too_warm” where it isn’t right now.

  2. I don’t want the electric window winders on our clerestory windows to be actuated when they are already in the desired position. They are finicky and not cheap. Already had to replace two when I over actuated them using manual buttons in the past.

  3. Not exactly sure what you mean by the flip-flop automation… if you are talking about service_template: switch.turn_{{trigger.to_state.state}} in your earlier example. That won’t work in my case. I’ve got two separate, physical switches, one to open and another one to close the windows.

Our window winders have three cables/connections; one neutral connection, one active connection to actuate for opening, and another active connection to actuate for closing. So I installed two Sonoff Minis to be able to active the corresponding active connection for the winders.
In other words if you look at the entity_ids in my automation action, you’ll see I have different switches to turn on :slight_smile:

from the code it just turns on a switch. if you use the same (or similar code without any acrobatic in the action section), you also just turn on something, is that correct?

yeah. could you post your config?

yes, it’s still the same. I’m trying to get what is the advantage of relying on time and then comparing temperatures rather than monitoring temperatures’ changes directly.
I understand that it does not suit you when the automation is executed only once and all I want to know is why you need it and what you do in your automation that suits your needs.

Without posting something you are likely to not understand without context (as its perhaps my most complex single automation), I’m basically adjusting the aircon set temperature according to the current temperature.

My aircon temperature sensor is poorly located (way up in the duct), and on cold days it sees the room temperature as much lower than it really is, and on hot days, much much hotter than it really is. So you can’t just set the temperature to 24C for example, as it will just run until the room temp is <20C on a hot day, or 26+C on a cold day.

My automation gradually tunes the set temp on the aircon to keep the rooms at a temperature much closer to the actual ‘desirable temperature’. A bit of a sh#t way of fixing a sh#t aircon in a rental I have no control over.

1 Like

ok, got it.
the question is - how (roughly) do you “tune” your temperature provided the temperatures reported hasn’t changed and it’s just another 10 mins interval? something like “It’s already running for N minutes, it should get colder soon so I’ll tweak (increase) the target temp”?

Ouch ! Understood

Yeah, I saw that, and sometimes you can’t use the same automation to both turn on / off (in this case we’d turn A on or turn B on) but it’s not super critical and I sometimes spend ages getting “this just right” to absolutely no benefit at all.

I’m impressed with how you’ve picked this up and the wrinkles of implementation you have already got thoughts on, you wouldn’t happen to be an engineer would you ?

Good luck with it

Lol… No. I have an IT background though. Been ‘playing’ with computers since grade 6 (am getting close-ish to retirement)
‘Gave up’ professional IT work and am now farming and driving a local school bus. However can’t completely give up IT… :slight_smile:
Just doing it for myself now. Not having to deal with a project manager is heaven!

Ah … You mean “used to having to get things to work even if it takes a really big hammer”
:rofl:

Yeah and learning that good enough is sometime all that’s needed :wink:
Pretty sometimes doesn’t make a difference. There are some bits of fencing that I definitely wouldn’t call “professional looking” but even these bits of fencing keep animals in and out as needed :slight_smile:

Just had a thought, if they break with overuse.
You might want to rotate duties.
I’m assuming you have multiple windows with individual controls ?
So day 1 window A, day 2 window B, day 3 window C, day 4 back to window A etc.
Spread the wear
But that may mean they all fail in the same week
:rofl:

hay bro
you automation look a bit wrong

    - below: '24'
      condition: numeric_state
      entity_id: sensor.outside_temperature

you have a condition: numeric_state and yet you have below: ‘24’ the 24 is a string as you have a quote around it

try

    - below: 24
      condition: numeric_state
      entity_id: sensor.outside_temperature

Hi StePhan

The automation has evolved since the initial post. I am currently using the automation as per reply at: https://community.home-assistant.io/t/condition-for-one-temperature-being-lower-than-another/185718/19?u=faramir

But thanks for checking it out and giving feedback :slight_smile:

Interesting idea… right now they are all ganged up, actuating all at the same time off the same power. They are quite high up and a bit of a pain to get to, so I’ll probably leave them alone as long as they work :wink:

All good bro I made the same mistake took a couple of hours to work out why not working
it just one of thos thing you see when you made the same mistake

Do like the sensor given me a idea thanks

Appreciate that… been there done that :smiley:

Funny thing is, that the initial automation was done through HA interface / Lovelace… So I didn’t decide to put the number in quotes… it was in this case Lovelace :grimacing:
Got to remember that for the future :slight_smile:

I think there is no harm in quoting here.

I decided to use float as Mutt suggested instead of int, purely because I found that was actually easier to think about; i.e. more explicit.

Especially in the case where the inside temperature is 24.1 - 24.9 . Casting to int will represent all these values as 24 making the comparison of in > 24 basically a comparison of in >= 25 without explicitly stating so.

You can see below that I’ve changed the casting of temperatures to float and adjusted the comparison to in > 25. With floats, looking at the code I get a quick feel for what it’s supposed to do, without having to think about casting of values and the effects of that cast.

So “final” automation set-up is now:

input_select:
  clerestory_window:
    name: Clerestory Window
    icon: mdi:window-closed
    options:
      - Closing
      - Closed
      - Opening
      - Open

binary_sensor:
  - platform: template
    sensors:
      should_clerestory_be_open:
        entity_id: sensor.dining_temperature, sensor.outside_temperature
        value_template: >
          {% set in = states('sensor.dining_temperature')|float %}
          {% set out = states('sensor.outside_temperature')|float %}
          {% set too_cool = in < 20 %}
          {% set too_warm = in > 25 %}
          {% set cooling = out < in %}
          {% set warming = out > in %}
          {{ (too_cool and warming) or (too_warm and cooling) }}
        friendly_name: Should Clerestory Window be Open

automation:
  - alias: Clerestory - Auto - Open
    trigger: 
    - platform: state
      entity_id: binary_sensor.should_clerestory_be_open
      to: 'on'
    condition:
    - condition: state
      entity_id: input_select.clerestory_window
      state: Closed
    action:
    - data: {}
      entity_id: switch.openclerestory
      service: switch.turn_on
  - alias: Clerestory - Auto - Close
    trigger: 
    - platform: state
      entity_id: binary_sensor.should_clerestory_be_open
      to: 'off'
    condition:
    - condition: state
      entity_id: input_select.clerestory_window
      state: Open
    action:
    - service: switch.turn_on
      entity_id: switch.closeclerestory
      data: {}

Thank you very much for the valuable templates, I integrated them in my HA-system to automate my electric windows. Works fine so far, except for one specific problem I have:

I wanted to compare my bedroom temperature with outdoor temperature. For that I have a temperature sensor on my terrasse. As the temp on the terrasse is warmer than the outside air-temp, I tried to use the weatherbit local temp. As this temp is not always 100% accurate for my flat, I calculated a mean temp of weatherbit and my terrasse sensor.
So far so good.
Only problem I have is that there seem to be short “outages” where the mean temperature jumps to one of the values. You can see it in that picture. Green to red/blue.

It happened yesterday that my windows opened and closed themselves because the temperature jumped around…

Do you have an idea how i could solve that problem?
Thanks.

I made one more change after my last post here.

I now use 5 minute averages for temperatures measured. This seems to smooth out these ‘jumps’.

For the averages I use the excellent Average Sensor available in HACS or at:

1 Like

thank you very much, the ha-average sensor works perfectly! No problems with jumpy values anymore!

Did anybody integrate some kind of hysteresis to prevent on/off switches like that:
grafik

Thanks!