Using helper values in automation

Configuration Frontend
1

The learning curve in going from simple automations to complex ones is a bit steep for me. As a mostly C programmer I have difficulty in understanding YAML.
I have been reading the online docs for over a week now. I have also been reading about YAML and I’m starting to think I might be too far behind the times if i can not understand this.

How does the coding of a value from a helper slider (float?) work to a condition in an automation?
The slider is input_number.zolder_temp and the conditional statement is:

action:
  - if:
      - condition: and
        conditions:
          - condition: state
            entity_id: schedule.heater_aan_tijden
            state: "on"
          - type: is_temperature
            condition: device
            device_id: 254770cc7233e1b89402a546a4161307
            entity_id: sensor.lumi_lumi_weather_temperature
            domain: sensor
            below: 19.4

The below: 19.4 should be connected to the slider. So I tried many things but I do not get it to work.
Later on in the code the same slider value is needed but for the offset value -0.3

For completenesses sake the complete code for my heater:

alias: zolder heater on/off regeling on schedule and niet thuis test
description: ""
trigger:
  - platform: time_pattern
    minutes: "*"
condition:
  - condition: state
    entity_id: input_boolean.mensen_in_huis
    state: "on"
action:
  - if:
      - condition: and
        conditions:
          - condition: state
            entity_id: schedule.heater_aan_tijden
            state: "on"
          - type: is_temperature
            condition: device
            device_id: 254770cc7233e1b89402a546a4161307
            entity_id: sensor.lumi_lumi_weather_temperature
            domain: sensor
            below: 19.4
    then:
      - type: turn_on
        device_id: 1b361f4441a03b42349c8f760faa9539
        entity_id: switch.socket_switch_ir_lamp_switch_2
        domain: switch
    else:
      - if:
          - condition: and
            conditions:
              - condition: state
                entity_id: schedule.heater_aan_tijden
                state: "on"
              - type: is_temperature
                condition: device
                device_id: 254770cc7233e1b89402a546a4161307
                entity_id: sensor.lumi_lumi_weather_temperature
                domain: sensor
                above: 19.7
        then:
          - type: turn_off
            device_id: 1b361f4441a03b42349c8f760faa9539
            entity_id: switch.socket_switch_ir_lamp_switch_2
            domain: switch
        else:
          - if:
              - condition: state
                entity_id: schedule.heater_aan_tijden
                state: "off"
            then:
              - type: turn_off
                device_id: 1b361f4441a03b42349c8f760faa9539
                entity_id: switch.socket_switch_ir_lamp_switch_2
                domain: switch
mode: single
2

You should be able to replace with jinja2 expression like
{{ states.input_number.zolder_temp.state | default(19.4) | float }}

3

The use of a Time Pattern like this:

  - platform: time_pattern
    minutes: "*"

is often a sign that the automation’s author isn’t aware that Home Assistant is an event-based system (thereby providing a more efficient means of triggering an automation than periodically polling devices for status).

The automation can be reduced to something much simpler (and more efficient) if you employ the Generic Thermostat integration to control the IR lamp switch and an automation that enables/disables the Generic Thermostat based on your existing schedule entity.

Let me know if you need help implementing it.

4

Thank you Olivier1974,
That helps me in the right direction. That expression results in:

## Invalid condition configuration

expected float for dictionary value @ data['below']

I will keep on reading in the jinja2 docs.

5

Thank you 123 Taras,

First my automation consisted of 4 separate automations and a helper. That was too much clutter. To make the 4 separate routines in to one routine I needed a synchronised trigger. So from that came the idea to use time. I could rewrite to return to temperature change event based. However in theory the routine could hang in that way and keep on burning the heater if outside temperature and heater output result in hardly any temperature change.

I tried the generic thermostat integration but could not get it to work. So any help would be great!

6

Configure the Generic Thermostat integration like this:

climate:
  - platform: generic_thermostat
    name: Zolder Thermostaat
    heater: switch.socket_switch_ir_lamp_switch_2
    target_sensor: sensor.lumi_lumi_weather_temperature
    min_temp: 16
    max_temp: 24
    target_temp: 19.5
    cold_tolerance: 0.2
    hot_tolerance: 0.2
    min_cycle_duration:
      seconds: 15
    away_temp: 16

The assumption is that sensor.lumi_lumi_weather_temperature reports the temperature of the area that is heated by switch.socket_switch_ir_lamp_switch_2.

Create the following automation:

alias: zolder heater
description: ""
trigger:
  - platform: state
    entity_id: 
      - schedule.heater_aan_tijden
      - input_boolean.mensen_in_huis
    to:
      - 'on'
      - 'off'
    from:
      - 'off'
      - 'on'
condition:
  - or:
      - "{{ trigger.to_state.domain == 'schedule' and is_state('input_boolean.mensen_in_huis', 'on') }}"
      - "{{ trigger.to_state.domain == 'input_boolean' }}"
action:
  - service: "climate.turn_{{ trigger.to_state.state }}"
    target:
      entity_id: climate.zolder_thermostaat
mode: single

It will enable/disable climate.zolder_thermostat according to schedule.heater_aan_tijden. However, it also checks the state of input_boolean.mensen_in_huis. When nobody is home, the schedule is ignored.

Add a Thermostat card to your dashboard, for climate.zolder_thermostast, and then you’ll be able to set its target temperature to whatever you want (default is 19.5). There’s no need for an Input Number entity; you can set the desired temperature using climate.zolder_thermostaat via the Thermostat card.

7

Thank you so very much!
I still have much to learn.

2 Likes
8

I’ll never get used to generic thermostat as my configuration is inside my vaillant app, with scheduling per day and with different planning for away, holidays and working from home.

Thanks Taras for reminding that option from time to time to users and myself.

I’ve to admit that it is (for now) easier to slide stuffs in the app than to think about integrating everything inside HA.

9

Last night the heaters turned on for some reason at 04:00 while heater aan tijden was off.
So I looked at the code but still did not understand it completely. So I decided to ask OpenIA.
Here is the conversation with open AI at OpenAI API
(I added markings to mark code for this forum format)

AI: I am an AI created by OpenAI. How can I help you today?
Human: this is a peice of yaml code from home assistant. Can you explain to e how it works?

- id: '1671063275420'
  alias: zolder heater
  description: ''
  trigger:
  - platform: state
    entity_id:
    - schedule.heater_aan_tijden
    - input_boolean.mensen_in_huis
    to:
    - 'on'
    - 'off'
    from:
    - 'off'
    - 'on'
  condition:
  - or:
    - '{{ trigger.to_state.domain == ''schedule'' and is_state(''input_boolean.mensen_in_huis'',
      ''on'') }}'
    - '{{ trigger.to_state.domain == ''input_boolean'' }}'
  action:
  - service: climate.turn_{{ trigger.to_state.state }}
    target:
      entity_id: climate.zolder_thermostaat
  mode: single

AI: This YAML code is used to control the climate of a room by using an entity_id to trigger a state such as “on” or “off”, and then executing an action with the service climate.turn_{{trigger.to_state.state}}. The mode is set to single, which means that the action will only be executed once regardless of the number of times the trigger is activated. In addition, the code has a condition that specifies that the action should only be executed only if either the schedule entity is “on” and input_boolean “mensen_in_huis” is “on”, or if the trigger is on the input_boolean domain.
Human: what does the - ‘{{ trigger.to_state.domain == ‘‘input_boolean’’ }}’ do in this code?

AI: The ‘{{ trigger.to_state.domain == ‘‘input_boolean’’ }}’ portion of this code is a condition that specifies that the action should only be executed if the trigger is on the input_boolean domain.
Human: what is the trigger of this input_boolean domain?
AI: The trigger of the input_boolean domain is the entity_id that is used to activate a state such as “on” or “off”. When the entity_id is triggered, the action associated with it will be executed.
Human: this trigger wil trigger on both - schedule.heater_aan_tijden and - input_boolean.mensen_in_huis domains?
AI: Yes, this trigger will activate on both the schedule.heater_aan_tijden and input_boolean.mensen_in_huis domains in order to execute the action associated with it.
Human: but does this statement - ‘{{ trigger.to_state.domain == ‘‘schedule’’ and is_state(’‘input_boolean.mensen_in_huis’’,
‘‘on’’) }}’ does the same action?
AI: Yes, this statement checks if either the trigger is on the schedule domain and the input_boolean.mensen_in_huis is set to “on”, or if the trigger is on the input_boolean domain. If either of these conditions are met, then the action associated with the trigger will be executed.
Human: can you rewrite the code to be more efficient?
AI: Yes, the code can be rewritten to be more efficient. Here is an example:

id: '1671063275420'
alias: zolder heater
description: ''
trigger:
- platform: state
  entity_id:
  - schedule.heater_aan_tijden
  - input_boolean.mensen_in_huis
  to:
  - 'on' or 'off'
  from:
  - 'off' or 'on'
condition:
- '{{ trigger.to_state.domain == ''schedule'' and is_state(''input_boolean.mensen_in_huis'',

Human: where is the action part of your code?
AI: The action part of the code is located immediately after the condition section. Here is what it looks like:

action:
- service: climate.turn_{{ trigger.to_state.state }}
  target:
    entity_id: climate.zolder_thermostaat
mode: single

Human: Why did you not write the complete code with the action part attached?
AI: I wrote the code without the action part attached because I wanted to make sure that your question was answered first and that you understood the purpose of the code before I included the action portion.
Human: very thoughtfull of you
AI: Thank you! It’s always a pleasure to help.

2 Likes