Inconsistant triggering

Hi,

I have an issue where the defined trigger states are not recognized in my automations, most of the time. Sometimes (it seems random) a trigger is recognized and the action is taken.

I made a simple example for this topic.
When the temperature on my terrace is higher then the temperature in my basement I’d like to receive a notification on my phone.
The temperature on my terrace is always higher then the temperature in my basement, so it should always trigger.
Nothing happens though.
When I create an automation with a time interval as a trigger (1 minute) and as a condition the same information as the trigger from the first automation, the automation will work every minute and I will also receive a notification every minute.

What am I missing here?

I created these two automations in the GUI, not YAML.

First automation (the one that doesn’t trigger):

alias: Temp terras above basement
description: ""
trigger:
  - platform: numeric_state
    entity_id: sensor.terras_temp
    above: sensor.gk_temp
condition: []
action:
  - device_id: 665e1de5daaaedefd9e0e553a5b0249e
    domain: mobile_app
    type: notify
    message: Temp terras above basement
mode: restart

Second automation (the one that works):

alias: Temp terras above basement (time interval trigger)
description: ""
trigger:
  - platform: time_pattern
    minutes: /1
condition:
  - condition: numeric_state
    entity_id: sensor.terras_temp
    above: sensor.gk_temp
action:
  - device_id: 665e1de5daaaedefd9e0e553a5b0249e
    domain: mobile_app
    type: notify
    message: Temp terras above basement (time interval trigger)
mode: restart

Fires when the numeric value of an entity’s state (or attribute’s value if using the attribute property, or the calculated value if using the value_template property) crosses (and only when crossing) a given threshold. On state change of a specified entity, attempts to parse the state as a number and fires if the value is changing from above to below or from below to above the given threshold.

Only when it crosses the threshold.
And this

trigger:
  - platform: numeric_state
    entity_id: sensor.terras_temp
    above: sensor.gk_temp

means sensor.gk_temp is a string.

trigger:
  - platform: numeric_state
    entity_id: sensor.terras_temp
    above: "{{ states('sensor.gk_temp') | float(0) }}"

Now it is a template and thus a value

Pfff thank you.
I did know this before but forgot it.
I’m just starting to learn HA.

Sorry!

Your last comment about the string is new for me, also thanks for this one!

Are you sure you want a new notification every minute?
What is the real goal here?

I see now I forgot the float filter in the template.

No, I did this just for testing.
Because of a moisture problem in the basement and the use of a dehumidification device I’d like to have an automation where if the humi and temp outside are lower then the basement the air ventilation should turn on.
Now I know that I need do this by checking with a time interval and this doesn’t need to be every minute.

See… You have the automation right there in plain text.
No need for a wasteful time pattern automation.

So, the following code should work?
There’s no need for a cross above for the condition?

alias: Luchtverversing AAN (Temp/Hum)
description: ""
trigger:
  - platform: numeric_state
    entity_id: sensor.werk_temp
    above: "{{ states('sensor.cp_temp') | float(0) }}"
condition:
  - condition: numeric_state
    entity_id: sensor.werk_humi
    above: "{{ states('sensor.cp_humi') | float(0) }}"
action:
  - type: turn_on
    device_id: 102103dc3ec38e21c9c878478ca2bde0
    entity_id: switch.droger_stopcontact
    domain: switch
  - type: turn_on
    device_id: 58913d5702500b426a217c63eb1b979d
    entity_id: switch.lucht_toevoer
    domain: switch
mode: restart

You need both as triggers and both as condition.

alias: Luchtverversing AAN (Temp/Hum)
description: ""
trigger:
  - platform: numeric_state
    entity_id: sensor.werk_temp
    above: "{{ states('sensor.cp_temp') | float(0) }}"
  - platform: numeric_state
    entity_id: sensor.werk_humi
    above: "{{ states('sensor.cp_humi') | float(0) }}"
condition:
  - condition: numeric_state
    entity_id: sensor.werk_humi
    above: "{{ states('sensor.cp_humi') | float(0) }}"
  - condition: numeric_state
    entity_id: sensor.werk_temp
    above: "{{ states('sensor.cp_temp') | float(0) }}"
action:
  - type: turn_on
    device_id: 102103dc3ec38e21c9c878478ca2bde0
    entity_id: switch.droger_stopcontact
    domain: switch
  - type: turn_on
    device_id: 58913d5702500b426a217c63eb1b979d
    entity_id: switch.lucht_toevoer
    domain: switch
mode: restart

I generally use call service => switch turn on => then entity.
This is a (in my opinion) better option since the device id is fixed to this particular device. If/when it breaks you can’t get a new device with the same device id, but you can name a new entity the same.
So if you want to plan for devices breaking on you, use entity id and call service.
If you want it easier now then use device.

This is really helpful, thanks. I’ll use the call service action from now on.

Could you please explain why I need both as triggers and condition?
Why is one as a trigger and the other as a condition not correct?

If you only have one as trigger then it could be happening in the wrong order.

You had temp as trigger, so let’s say the temp crossed the threshold, at 10:00.
An hour later the humidity goes above it’s threshold, but the humidity is not a trigger so the automation doesn’t trigger.

If you have both as triggers and both as condition then the automation will trigger once but die because of condition, and the second time it triggers both conditions are also true and it fires.

Edit
You could also create a template trigger that will only trigger once when both temp and humidity true.

This really is something I wish the HA developers would change about the UI. It currently defaults to ‘device’ but in reality, we all learn over time that using entities/states are better. Most people end up going back and refactoring their code after they use HA for a while to get rid of non-needed device IDs… I digress.

It’s traps built in to the software to keep you tinkering with the automations.

Device id and time pattern is two big traps that gets a lot of people…

Ok, I’m trying to understand this.
Triggers need crossing.
If one of the two triggers crosses above, the other one doesn’t also cross exactly on that moment.
So then there will never be a time where the automation triggers?
Or does it remember the first trigger and then when the second one triggers an hour later both are triggered and both conditions are also met, if the first one didn’t change?

No it does not remember anything.
That is the issue here. Because it does not remember the the temp has already crossed and triggered then the automation will not fire if you only use one trigger.
(Except the template version I will post later, just a bit busy now).

The other way to have only one trigger is wait for state in actions.
Its a very bad idea so don’t think about it, but you could get away with one trigger using that method.
The issue is that as soon as you reboot HA or save any automation then it will not wait any longer, the automation is reloaded and all memory is lost.

@Hellis81 means something like this. It will trigger whenever BOTH are true.

trigger:
  - platform: template
    value_template: >-
      {{ states('sensor.werk_temp') | float(0) > states('sensor.cp_temp') | float(0) 
       and states('sensor.werk_humi') | float(0) > states('sensor.cp_humi') | float(0) }}

with that trigger, you won’t even need your conditions at all but it won’t hurt to leave them if you want to convert them to templates. Not really needed though.

Like this:

alias: Luchtverversing AAN (Temp/Hum)
description: ""
trigger:
  - platform: template
    value_template: >-
      {{ states('sensor.werk_temp') | float(0) > states('sensor.cp_temp') | float(0) 
       and states('sensor.werk_humi') | float(0) > states('sensor.cp_humi') | float(0) }}
condition: []
action:
  - type: turn_on
    device_id: 102103dc3ec38e21c9c878478ca2bde0
    entity_id: switch.droger_stopcontact
    domain: switch
  - type: turn_on
    device_id: 58913d5702500b426a217c63eb1b979d
    entity_id: switch.lucht_toevoer
    domain: switch
mode: restart

Ok, thank you!

I tried using the code you provided, with double triggers and the template value after above:

alias: Luchtverversing AAN (Temp/Hum)
description: ""
trigger:
  - platform: numeric_state
    entity_id: sensor.werk_temp
    above: "{{ states('sensor.cp_temp') | float(0) }}"
  - platform: numeric_state
    entity_id: sensor.werk_humi
    above: "{{ states('sensor.cp_humi') | float(0) }}"
condition:
  - condition: numeric_state
    entity_id: sensor.werk_humi
    above: "{{ states('sensor.cp_humi') | float(0) }}"
  - condition: numeric_state
    entity_id: sensor.werk_temp
    above: "{{ states('sensor.cp_temp') | float(0) }}"
action:
  - type: turn_on
    device_id: 102103dc3ec38e21c9c878478ca2bde0
    entity_id: switch.droger_stopcontact
    domain: switch
  - type: turn_on
    device_id: 58913d5702500b426a217c63eb1b979d
    entity_id: switch.lucht_toevoer
    domain: switch
mode: restart

But I get an error:

Message malformed: expected float for dictionary value @ data[‘condition’][0][‘above’]

If I google it then find a post on here that says:

I see no evidence in the docs that you can use a template in the above: or below: parts of a numeric_state condition. You could, however, replicate that with a template condition. You should be able to use an input_number , but if that isn’t working, the answer isn’t to try to use a template.

I’ll wait for your template version, no hurry.

Thank you!
I’m going to give this one a try.

If you want to ‘test’ it, you can go into the developer tools under /states/ : /change states/ and update the values of the two sensors to trigger the automation manually for testing purposes.

Thank you, I tested it and it worked!

I did not know you couldn’t use templates in conditions.
I’m shocked to see this, a few years ago a lot of fields that was just values was made to values or templates. Strange that this was not fixed.

But yes the way Rob posted was what I was thinking.