Inpute Datetime with Trigger and Condition

Hello,

I have this automation:

  trigger:
  - platform: template
    value_template: >
      {{ states('sensor.hz_temp')|float < states('input_number.starttemp')|float }}
  - platform: time
    at: 05:15:01
  - platform: time
    at: 08:15:01
  condition:
    condition: and
    conditions:
    - condition: template
      value_template: >
        {{ states('sensor.hz_temp')|float < states('input_number.starttemp')|float }}
    - condition: or
      conditions:
      - condition: and
        conditions:
        - condition: state
          entity_id: binary_sensor.workday_sensor
          state: 'on'
        - condition: time
          after: 05:15:00
          before: '22:15:00'
      - condition: and
        conditions:
        - condition: state
          entity_id: binary_sensor.workday_sensor
          state: 'off'
        - condition: time
          after: 08:15:00
          before: '22:15:00'

I want to replace the time trigger and conditions with input Datetime so I can control it in the frontend.
Researches here brought me to this:

  trigger:
  - platform: template
    value_template: >
      {{ states('sensor.hz_temp')|float < states('input_number.starttemp')|float }}
  - platform: template
    value_template: "{{ states('sensor.time') == (state_attr('input_datetime.mofr', 'timestamp') | int | timestamp_custom('%H:%M', True)) }}"
  - platform: template
    value_template: "{{ states('sensor.time') == (state_attr('input_datetime.saso', 'timestamp') | int | timestamp_custom('%H:%M', True)) }}"
  condition:
    condition: and
    conditions:
    - condition: template
      value_template: >
        {{ states('sensor.hz_temp')|float < states('input_number.starttemp')|float }}
    - condition: or
      conditions:
      - condition: and
        conditions:
        - condition: state
          entity_id: binary_sensor.workday_sensor
          state: 'on'
        - condition: template
          value_template: "{{ states('sensor.time') > (state_attr('input_datetime.mofr', 'timestamp') | int | timestamp_custom('%H:%M:%S', true)) }}"
        - condition: template
          value_template: "{{ states('sensor.time') < (state_attr('input_datetime.ende', 'timestamp') | int | timestamp_custom('%H:%M:%S', true)) }}"
      - condition: and
        conditions:
        - condition: state
          entity_id: binary_sensor.workday_sensor
          state: 'off'
        - condition: template
          value_template: "{{ states('sensor.time') > (state_attr('input_datetime.saso', 'timestamp') | int | timestamp_custom('%H:%M:%S', true)) }}"
        - condition: template
          value_template: "{{ states('sensor.time') < (state_attr('input_datetime.ende', 'timestamp') | int | timestamp_custom('%H:%M:%S', true)) }}"

Now I have two Questions:

  1. Does that work like the code before or did I miss something?
  2. How can I add 1 second to the trigger template so that I can be sure the conditions are met like it was in the code before?

No, the sensor.time only updates every minute.
If you want second interval update you have to check every second (which is possible) but this spams everything and is particularly high in its consumption of resources. Not recommended in any circumstances.
But if you want to try set a trigger on a time_pattern: seconds: ‘*1’

Your time pattern matching is also a bit processor intensive and could be simplified (I’m working from a phone so can’t comment on the functionality of the whole code)

Instead of : Try : -

"{{ states('sensor.time') == (state_attr('input_datetime.saso', 'timestamp') | int | timestamp_custom('%H:%M', True)) }}"
Replace with
"{{ states('sensor.time') [0:5] == states('input_datetime.saso') }}"``

Also, states. Ie states followed by a full stop is not very fault tolerant so states() is preferred and more resilient.

Didn’t thought that this would be so complicate to achieve.^^
Why is the time pattern more processor intensive? I have that right from the docs

And what do you mean with followed by a full stop?

Isn’t there another way to add this one second, maybe implementing a delay or something?

states.thing vs states(‘thing’) you see the “.” between states and thing ?

Look at the number of operations you are asking it to perform rather than the alternate

Yes that’s always an alternative and preferred but that’s not what you asked.
The template (you’d need two) would have to do some splitting operations but that is doable

states.thing vs states(‘thing’) you see the “.” between states and thing ?

So is this a general advice? Because I do not see any states.thing in my code?

Just out of curiosity and because I just found it, what would this do? (int +1):

"{{ states('sensor.time') == (state_attr('input_datetime.mofr', 'timestamp') | int +1 | timestamp_custom('%H:%M', True)) }}"

Do these two input_datetimes, mofr and ende, have both date and time or just the time?

Just the time

Then I don’t understand why you are taking the input_datetime’s timestamp and then converting it into UTC time (using the True option in timestamp_custom).

sensor.time reports the local time, not UTC time. Unless local time is equal to UTC time where you live, comparing the two values will not work the way you want.

I think what you want is simply this:

"{{ states('sensor.time') == states('input_datetime.mofr')[:5] }}"

EDIT

There’s no need to reduce the clock tick to a 1-second resolution. Simply adjust the test in your conditions:

        - condition: template
          value_template: "{{ states('sensor.time') >= states('input_datetime.mofr)[:5] }}"
        - condition: template
          value_template: "{{ states('sensor.time') <= states('input_datetime.ende')[:5] }}"

I have done it that way because thats what I have found here and the docs and because I do not know it better :blush:

I just saw the >= in the code.^^ Thanks alot, both of you, I will test it but it looks good :slight_smile:
-edit-
Working as expected. Thank you so much!

1 Like

Yo are correct, dunno why I said that maybe I just misread it on my phone

I was just showing you a template for the trigger, conditions need to be considered differently