Inconsistency between time trigger and condition?

[nonnull]

I have several automations which I throttle to prevent them toggling too often.

I do this by having an input datetime *_pause_until, which does exactly what it sounds like. The automation is triggered on its usual events, but also on said datetime, and with a condition to skip the automation if we’re before pause_until.

As a result, the start of each automation looks like this:

trigger:
  - at: input_datetime.dehumidifier_pump_pause_until
    platform: time
[...]
condition:
  - condition: template
    value_template: >-
      {{now().timestamp() >=
      state_attr('input_datetime.dehumidifier_pump_pause_until', 'timestamp')}}

(Related WTH: why is there no condition: [date]time?)

…only, sometimes (not always; not never) the automation ends up with the following bizarre & inconsistent trace:

1. Triggered by said time trigger.
2. Condition fails (???)

…and then of course the automation misses updates and I’m sad.

This is inconsistent. Triggering due to the time trigger indicates that we’re at (or after) input_datetime.dehumidifier_pump_pause_until, but failing the condition means that we’re before input_datetime.dehumidifier_pump_pause_until.

For now I’m working around this by adding a clause to the condition to check if the input trigger was said pause ((trigger.platform == 'time') or ..., at least assuming no other time triggers), but this seems incorrect regardless.

(Two other things I checked for the sake of argument: pause_until wasn’t updated during the automation run, and the system time didn’t change.)

Am I missing something here?

[Rofo (Ro)]

I’m not sure I understand the logic here.
The trigger fires when the datetime helper is ‘now’, so the condition is always going to evaluate to true ?

[nonnull]

There are other triggers to the automation too, where the condition won’t always hold.

In this case it’s the time trigger that triggers, which “should” always result in the condition being true as you mention… and yet sometimes the condition evaluates to false.

[Rofo (Ro)]

Have you checked the history of the datetime helpers value ?
I can’t remember if they persist after (say) a home assistant restart

(EDIT:- I believe they do now, so thats probably not it)

[nonnull]

I’m not sure how that’d be relevant here unless HA was restarted in the middle of the automation (which I’ve checked: it wasn’t - and if it was the automation wouldn’t resume in the middle anyway).

Nevertheless: the input_datetime remained the same.

This is an inconstancy between either a) the input_datetime or b) now(), read in two subsequent steps of the same automation run.

[Rofo (Ro)]

It is strange that this seems to be intermittent.
Not sure if anything from this thread will help you:-

Comparison of an input_datetime and now() - can this be achieved simply?

Hi there, One of my automations requires me to compare a day from my input_datetime with a current date. After some studying of HA docs I came across to the below config: - condition: template value_template: '{{ (states.input_datetime.grass_next.attributes.timestamp| int | timestamp_custom("%Y%m%d", False)|int)|string == (now().year ~ "%02d"|format(now().month) ~ "%02d"|format(now().day) ) }}' One of the problems is that the timestamp_custom filter outputs the month and day number with a …

There are suggestions on how to evaluate dateimes that are slightly different from yours.

[arturpragacz]

By how much off are they?
If it is not by much, then it could happen due to rounding, if the two values use different internal precision.

[Didgeridrew]

What type of Input Datetime are you using?

[parautenbach (Pieter Rautenbach)]

Post the full automation, please, or at least the full trigger and condition blocks.

[nonnull]

@arturpragacz

By how much off are they?

Is there a way to tell? The trace merely shows that the condition failed, not every step in the calculation.

@parautenbach

Post the full automation, please

Sure:

alias: Dehumidifier Pump Control
trigger:
  - at: input_datetime.dehumidifier_pump_pause_until
    platform: time
  - entity_id: sensor.151732605496952_tank
    platform: state
  - entity_id: input_number.dehumidifier_pump_threshold
    platform: state
  - event: start
    platform: homeassistant
condition:
  - condition: template
    value_template: |-
      {{now().timestamp() >=
      state_attr('input_datetime.dehumidifier_pump_pause_until', 'timestamp')}}
action:
  - if:
      - above: input_number.dehumidifier_pump_threshold
        condition: numeric_state
        entity_id: sensor.151732605496952_tank
    then:
      if:
        condition: state
        entity_id: switch.dehumidifier_pump_switch
        state: "off"
      then:
        - service: switch.turn_on
          target:
            entity_id: switch.dehumidifier_pump_switch
        - data:
            timestamp: "{{ now().timestamp() + 1*60 }}"
          service: input_datetime.set_datetime
          target:
            entity_id: input_datetime.dehumidifier_pump_pause_until
    else:
      if:
        condition: state
        entity_id: switch.dehumidifier_pump_switch
        state: "on"
      then:
        - service: switch.turn_off
          target:
            entity_id: switch.dehumidifier_pump_switch
        - data:
            timestamp: "{{ now().timestamp() + 10*60 }}"
          service: input_datetime.set_datetime
          target:
            entity_id: input_datetime.dehumidifier_pump_pause_until

(I have reformatted this slightly. For some reason the YAML copy/paste had the if/then/else out of order. I know it doesn’t technically make a difference, but it certainly makes it more difficult to read…)
Note that this is not the only automation that adjusts input_datetime.dehumidifier_pump_pause_until.

[arturpragacz]

@nonnull

Is there a way to tell? The trace merely shows that the condition failed, not every step in the calculation.

Add variables before the condition and store the two sides in separate variables. This should show in traces.

[nonnull]

I changed the automation to:

condition:
  - condition: or
    conditions:
      - condition: template
        value_template: >-
          {{now().timestamp() >=
          state_attr('input_datetime.dehumidifier_pump_pause_until',
          'timestamp')}}
      - condition: template
        value_template: "{{trigger.platform == 'time'}}"

…which works around the behavior while making it visible in the trace if this behavior occurs.

By manually doing a service call to update pause_until I’m able to trigger this behavior:

service: input_datetime.set_datetime
data:
  timestamp: "{{ now().timestamp() + 1 }}"
target:
  entity_id: input_datetime.dehumidifier_pump_pause_until

@arturpragacz

Add variables before the condition and store the two sides in separate variables.

Will do…

[nonnull]

@arturpragacz

This should show in traces.

I changed it to the following:

condition:
  - condition: or
    conditions:
      - condition: template
        value_template: >-
          {% set now_timestamp = now().timestamp() %}
          {% set pause_timestamp =
          state_attr('input_datetime.dehumidifier_pump_pause_time', 'timestamp')
          %}
          {{ now_timestamp >=  pause_timestamp }}
      - condition: template
        value_template: "{{trigger.platform == 'time'}}"

…but the trace does not have any information about the variables.

Am I misunderstanding something?

If you mean adding a variables action - I can’t do so because this is the condition block of the automation, which is run before any actions.

I can try turning the condition block into an initial if/else return in the automation actions I suppose, though that’s a more major change to the automation.

Suggestions?

[arturpragacz]

No, not the action, just add variables before condition section. You have to do it through YAML, there’s no UI for it.

[Didgeridrew]

@nonnull

…but the trace does not have any information about the variables.

Am I misunderstanding something?

I think what Artur meant was something like:

condition:
  - variables:
      now_timestamp: "{{ now().timestamp() }}"
      pause_timestamp: "{{state_attr('input_datetime.dehumidifier_pump_pause_time', 'timestamp') }}"
  - condition: or
    conditions:
      - condition: template
        value_template: >-
          {{ now_timestamp >=  pause_timestamp }}
      - condition: template
        value_template: "{{trigger.platform == 'time'}}"

[nonnull]

Oh interesting!

I didn’t know you could define variables in the condition block. This appears to be undocumented. Is it something I can rely on, or should I just use it for debugging?

I’ll try that and get back to you.

[arturpragacz]

I’m not sure this is correct. I meant like that:

variables:
  now_timestamp: "{{ now().timestamp() }}"
  pause_timestamp: "{{state_attr('input_datetime.dehumidifier_pump_pause_time', 'timestamp') }}"
condition:
  - condition: or
    conditions:
      - condition: template
        value_template: >-
          {{ now_timestamp >=  pause_timestamp }}
      - condition: template
        value_template: "{{trigger.platform == 'time'}}"

[arturpragacz]

It is documented, but in unexpected place.

[Didgeridrew]

Where can you put variables in your automation and state based trigger templates and template sensors

Automations: YAML variables can be defined multiple places, their scope depends on where they are defined. trigger_variables: var_1: true #script-wide (only Limited Templates and static values allowed) variables: var_2: "{{ true }}" #script-wide trigger: - platform: state entity_id: sensor.x to: y variables: var_3: "{{ false }}" #script-wide but, if you have multiple triggers, this value applies only when this specific trigger initiates the automation condition: - var…

[arturpragacz]

@123

In both cases, there’s not much utility to define script variables for this application because they’re referenced in just one template (more useful if they needed to be referenced by multiple Template Conditions). You could just as easily define them as Jinja2 variables within the template.

Please make sure to read a thread you’re commenting before saying something unneeded. Thank you.