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
sensors:
# Strip next loadshedding start time from Loadshedding Schedule - this returns hh:mm:ss dd:mm:yyy
loadshedding_local_starttime:
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
loadshedding_local_starttime_next:
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
sensors:
# Create Loadshedding sensors in timestamp class
loadshedding_next_timeformat:
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.
@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
sensors:
loadshedding_start_time:
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.
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.
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.
