Setting a Timestamp device class

Hi All

We have scheduled rolling blackouts where I live. We have access to a nice app (with an API) that communicates the next scheduled blackout. Although the API communicates this as an attribute, I managed (as a noob) to extract this into its own sensor.

However, this sensor is not a time class sensor, so it cannot be use as a trigger in the classic time sense. For example, I would like to automate some tasks 1 hour before this scheduled blackout time.

My current yaml configuration to get the sensor is as follows:

# Create Loadshedding sensors
- platform: template

# Strip next loadshedding start time from Loadshedding Schedule - this returns hh:mm:ss dd:mm:yyy
      unique_id: "loadshedding_local_starttime"
      friendly_name: "Loadshedding Attribute: Next Start Time"
      value_template: "{{ state_attr('calendar.loadshedding_local_schedule','start_time') }}"

# Getting Time Only from next load shedding event - this returns hh:mm:ss
      unique_id: "loadshedding_local_starttime_next"
      friendly_name: "Loadshedding Attribute: Next Start Time (Time Only)"
      value_template: >-
        {% set time = states('sensor.loadshedding_local_starttime') %}
        {% set ftime = as_timestamp(time)|timestamp_custom('%H:%M:%S') %}
        {{ ftime }}

The above is successful and returns a state for example
sensor.loadshedding_local_starttime_next = 22:00:00

I am trying to make this sensor a timestamp device class.

Please help?

My current effort looks as follows:

- platform: template

# Create Loadshedding sensors in timestamp class
       device_class: timestamp
       unique_id: "loadshedding_next_timeformat"
       friendly_name: "Loadshedding Attribute: Next Start Time (Time Format)"
       value_template: "{{ states('sensor.loadshedding_local_starttime') }}"

But although the yaml compiles without problem, this returns an unkown value. I suspect that the template platform does not allow timestamp device class, but I have no idea how to change.


1 Like

If you create a Template Sensor whose device_class is timestamp, its state value must be a date and time in ISO format.

For example:

       value_template: "{{ today_at(states('sensor.loadshedding_local_starttime')).isoformat() }}"




value_template: "{{ today_at(states('sensor.loadshedding_local_starttime')).isoformat() }}"

In the template editor gives me the following error message

ValueError: could not convert str to datetime: ‘2023-04-29 12:00:00’

@daniemare I suspect I know which country you’re in. Based on the work of others, here is my complete package. I ran into some problems too with the datetimes.

  - platform: template
        friendly_name: Loadshedding Start Time
        device_class: timestamp
        value_template: >-
          {% if states('sensor.eskomsepush')
                and state_attr('sensor.eskomsepush', 'events') != []
                and 'start' in (state_attr('sensor.eskomsepush', 'events') | first) %}
            {{ (state_attr('sensor.eskomsepush', 'events') | first).start }}
          {% else %}
            {{ 0 | as_datetime }}
          {% endif %}

My mistake; I thought the sensor’s value was simply time but it’s actually date and time (which doesn’t work with today_at).

I suggest you use as_datetime, to convert the datetime string to a datetime object, then as_local, to provide the datetime object with your local timezone, and finally present the value in ISO format using the datetime object’s isoformat() method.

value_template: "{{ (states('sensor.loadshedding_local_starttime') | as_datetime | as_local).isoformat() }}"

How did you guys :wink:

Thanks, I will have a look

Thank you!

1 Like

It’s a bit ridiculous that | as_timestamp doesn’t result in a value that’s compatible with the timestamp template sensor device class.

1 Like
  • as_timestamp() existed before the concept of a timestamp device_class was introduced. It generates a UNIX timestamp (number of seconds since the Unix epoch). This can be useful for date and time calculations.

  • A sensor whose device_class is timestamp requires the sensor’s state to be presented as a timestamp in ISO 8601 format. This is easier for user’s to read and understand, for example in Developer Tools > States, than a Unix timestamp would be.

Basically, two definitions of the word timestamp, both equally valid for their intended purpose but not in the same format.

Fortunately, converting from one to the other is simple.

1 Like

Thank you for the helpful explanation!

That being said, in case anyone with decision-making power in this regard reads this: this is common in SW dev and the thing is, no end user cares about the historical reasons why terms are overloaded. The consequence is that it’s confusing, adds friction, and degrades the user experience.

My suggestion: one of them should be renamed, and/or they should be converted internally to the same format (after the typical deprecation period of course). I’m not saying it’s high-priority (not high enough for me to contribute a PR at the moment, maybe later), but something to keep in mind imo.