Set date time variable in automation

Hi,

I’m struggling with time variables in an automation.

Configuration.yaml :

input_datetime:
# Stopcontact fietslader aan-uit tijd ingeven
  begintijd_stopcontact_fietslader:
    name: Fietslader_aan
    has_time: true
    has_date: false
    initial: "08:00"
  eindtijd_stopcontact_fietslader:
    name: Fietslader_uit
    has_time: true
    has_date: false
    initial: "20:00"

sensor:
#tijdssensoren stopcontact fietslader- aan- en uittijden
  - platform: template
    sensors:
      aantijd_stopcontact_fietslader:
        value_template: "{{ (state_attr('input_datetime.begintijd_stopcontact_fietslader', 'timestamp')) | timestamp_custom ('%H:%M', False) }}" 
  - platform: template
    sensors:
      uittijd_stopcontact_fietslader:
        value_template: "{{ (state_attr('input_datetime.eindtijd_stopcontact_fietslader', 'timestamp')) | timestamp_custom ('%H:%M', False) }}" 

Is OK, no errors.

automation:

- id: 'Fietsladers aan op gekozen tijd'
  alias: Fietsladers aan
  trigger:
  - at: 'sensor.aantijd_stopcontact_fietslader'
    platform: time
  condition:
  - condition: state
    entity_id: switch.home_control_metering_plug
    state: 'off'
  action:
  - entity_id: switch.home_control_metering_plug
    service: switch.turn_on

- id: 'Fietsladers uit op gekozen tijd'
  alias: Fietsladers uit
  trigger:
  - at: 'sensor.uittijd_stopcontact_fietslader'
    platform: time
  condition:
  - condition: state
    entity_id: switch.home_control_metering_plug
    state: 'on'
  action:
  - service: switch.turn_off
    entity_id: switch.home_control_metering_plug

Problem: nothing happens. The automation doesn’t work.
What is wrong?

Thx for the help.

I think you have no seconds in your hours and minutes custom_timestamp

If you create a time trigger manually with a normal fixed value, it expects seconds:-

mode: single
trigger:
  - platform: time
    at: "08:00:00"
condition: []
action: []

First, if you are just starting your template sensor journey, you should be using the current format instead of the legacy format.

Second, why are you using an intermediary sensor? You can just use the input datetime in your automation.

- id: 'Fietsladers aan op gekozen tijd'
  alias: Fietsladers aan
  trigger:
  - at: input_datetime.begintijd_stopcontact_fietslader
    platform: time
  condition:
  - condition: state
    entity_id: switch.home_control_metering_plug
    state: 'off'
  action:
  - entity_id: switch.home_control_metering_plug
    service: switch.turn_on

- id: 'Fietsladers uit op gekozen tijd'
  alias: Fietsladers uit
  trigger:
  - at: input_datetime.eindtijd_stopcontact_fietslader
    platform: time
  condition:
  - condition: state
    entity_id: switch.home_control_metering_plug
    state: 'on'
  action:
  - service: switch.turn_off
    entity_id: switch.home_control_metering_plug

If, for some reason, you just want to use the sensors you will need to add the configuration varaible device class: timestamp to each sensor in order for it to work in a time trigger.

@Didgeridrew

Can you elaborate on which bits are legacy.
I’m still learning my way through template sensors and am keen to understand what the current best practise is.

The current format, as well as the legacy format, are covered in the Template Sensor Documents

While this is likely not needed to solve OP’s original problem (and the templates have their own issues) in the current format they would be configured as follows:

template:
  - sensor:
      - name:  Aantijd Stopcontact Fietslader
        unique_id:  aantijd_stopcontact_fietslader
        state: >
          {{ state_attr('input_datetime.begintijd_stopcontact_fietslader', 'timestamp') 
          | timestamp_custom ('%H:%M', False) }}
        device_class: timestamp
      - name: Uittijd Stopcontact Fietslader
        unique_id: uittijd_stopcontact_fietslader
        state: >
          {{ state_attr('input_datetime.eindtijd_stopcontact_fietslader', 'timestamp') 
          | timestamp_custom ('%H:%M', False) }}
        device_class: timestamp

Thanks for that, super helpful. I have 4 or 5 legacy template sensors like this that I’m going to move over to the new format.

Hi Didgeridrew,

- id: 'Fietsladers aan op gekozen tijd'
  alias: Fietsladers aan
  trigger:
  - at: 'input_datetime.begintijd_stopcontact_fietslader'
    platform: time
  condition:
  - condition: state
    entity_id: switch.home_control_metering_plug
    state: 'off'
  action:
  - entity_id: switch.home_control_metering_plug
    service: switch.turn_on

- id: 'Fietsladers uit op gekozen tijd'
  alias: Fietsladers uit
  trigger:
  - at: 'input_datetime.eindtijd_stopcontact_fietslader'
    platform: time
  condition:
  - condition: state
    entity_id: switch.home_control_metering_plug
    state: 'on'
  action:
  - service: switch.turn_off
    entity_id: switch.home_control_metering_plug

…doesn’t work

- id: 'Fietsladers aan om 8u'
  alias: Fietsladers aan om 8u
  trigger:
  - at: '08:00'
    platform: time
  condition:
  - condition: state
    entity_id: switch.home_control_metering_plug
    state: 'off'
  action:
  - entity_id: switch.home_control_metering_plug
    service: switch.turn_on

…works fine …

I think a problem with " input_datetime.begintijd_stopcontact_fietslader " and " input_datetime.eindtijd_stopcontact_fietslader " but which problem ??

Configuration.yaml:

input_datetime:
# Stopcontact fietslader aan-uit tijd ingeven
  begintijd_stopcontact_fietslader:
    name: Fietslader_aan
    has_time: true
    has_date: false
    initial: "08:00"
  eindtijd_stopcontact_fietslader:
    name: Fietslader_uit
    has_time: true
    has_date: false
    initial: "20:00"

???

As long as those automations are properly set up under the automation heading, I don’t see anything wrong with your input number configurations or automations. Regarding the automations, what do the traces say?

Hi Drew,

Problem solved. Indeed, there was nothing wrong .
Very strange cause. A reboot of my Qnap NAS solved the problem (System software upgrade) !!! I had already given up but after the reboot of the NAS it suddenly worked.
it’s not the first time a discrepancy qnap-docker-HA causes trouble.