I’m not sure I can answer that with the information you’ve provided.
How do you plan on using the newly rendered time format?
I have simple sensor cards for my frontend to display the time.
Then you likely will want to use it in the value_template section.
I think this should work:
value_template: >
{% if value_json.device == "1P7U5" %}
{% set datetime = value_json.time %}
{{ as_timestamp(strptime(datetime, '%Y-%m-%d %H:%M:%S')) | timestamp_custom('%I:%M %p') }}
{% else %}
{{ states("sensor.justin_east_window") }}
{% endif %}
1 Like
Thank you so much for this thread. I have just spent an hour trying to drop the leading “0” from a time format, and found the oh-so-simple answer here. Most of the other threads have awful kludges in them.
1 Like
really baffled now, but using this:
daylight_remaining_hm:
friendly_name: 'Daylight remaining hh:mm'
value_template: >
{% set nw = now().replace(microsecond=0) %}
{% set sr = state_attr('sensor.astral_sunrise', 'today') %}
{% set ss = state_attr('sensor.astral_sunset', 'today') %}
{% if nw < sr %}
{{ ss - sr }}
{% elif nw < ss %}
{{ ss - nw }}
{% else %}
0:00:00
{% endif %}
I see the time left to be 7:11:02.028393 … obviously I want to see HH:MM. checking one of the conversions mentioned atop of this thread, I want to use strptime:
{% set nw = now().replace(microsecond=0) %}
{% set sr = state_attr('sensor.astral_sunrise', 'today') %}
{% set ss = state_attr('sensor.astral_sunset', 'today') %}
{% if nw < sr %}
{% set tl = ss - sr %}
{{ strptime(tl,'%H:%M') }}
{% elif nw < ss %}
{% set tl = ss - nw %}
{{ strptime(tl,'%H:%M') }}
{% else %}
0:00:00
{% endif %}
which doesn’t do anything, still outputs 7:09:02.028393. Missing the obvious here, sp please have a look if you have a spare minute please? thanks
Because it’s not a datetime object it’s a timedelta object. strptime does not work on time deltas. Also strptime takes a string and turns it into a datetime object. strftime takes a datetime object and turns it into a string. If I recall correctly, strftime works on timedelta. I recalled wrong, strftime doesn’t work on timedelta either.
hmm, so where does this all leave us now. This has worked up to the time change in recent HA update.
Ive fallen back to
{{(as_timestamp(state_attr('sun.sun','next_setting')) - now().timestamp())
|timestamp_custom('%H:%M',false)}}
for now, but really need to understand (and use) the change in the template with Phils astral Sun2 component … heck, why does this subject stay so challenging.
btw, these are just strings aren’t they?
what has worked up to this timechange? strptime on timedeltas, that’s not true. You’re mixing up functionality. Strfttime, and strptime has never worked on timedeltas, only datetimes.
just think of it this way:
What’s tuesday - monday? 1 day. Ok, what day of the week is that? Don’t have an answer? That’s because there is no answer, hence why strftime and striptime do not work on timedeltas. Because timedeltas are a change in time. Stftime and strptime include formats that would not be possible on a time delta, like %A which is the day of the week as a word.
sorry, should have been more specific… I meant to say, the first template here worked fine up to the time change in HA. It showed the time in HH:MM m and now shows the microseconds output.
so I need to manipulate that back in to HH:MM
Na, you’re still miss remembering. Timedetla’s string repr has not changed in 20 years. It has always been d:hh:mm.ssssss.
it’s possible that the datetimes didn’t track microseconds which didn’t translate to the timedelta, but you would have still gotten a day and zero all the way out.
anyways…
or if you want the days, remove the microsecond
daylight_remaining_hm:
friendly_name: 'Daylight remaining hh:mm'
value_template: >
{% set nw = now().replace(microsecond=0) %}
{% set sr = state_attr('sensor.astral_sunrise', 'today').replace(microsecond=0) %}
{% set ss = state_attr('sensor.astral_sunset', 'today').replace(microsecond=0) %}
{% if nw < sr %}
{{ ss - sr }}
{% elif nw < ss %}
{{ ss - nw }}
{% else %}
0:00:00
{% endif %}
thanks!
btw it was this change I referred to, that causes the issue: Release Handle new time zone type in HA core · pnbruckner/ha-sun2 · GitHub
Home Assistant changed the details of its time zone implementation, starting w/ 2021.6.x. Specifically, it switched from the pytz package to Python’s new native zoneinfo library.
as you can see here, I did try the microsecond removal myself, but thought it hacky… though at the time I thought it showed only HH:MM and not :SS too… maybe not.
got another one, new to me so please have a look if I do this correctly:
mqtt topic returns 2021-08-02T20:34:03Z which is Zulu time, as I’ve been explained by Tinkerer, and is also touched atop in this thread.
Now of course I want local time so I can use device_class timestamp, and created this value_template
- platform: mqtt
state_topic: watermeter/smart_gateways/startup_time
name: Watermeter Startup time
value_template: >
{{value.split('Z')[0]}}
device_class: timestamp
and yes, that returns alright. I was wondering though if I shouldn’t be doing an official time manipulation instead if this string manipulation.
thanks for having a look
{{ as_datetime(value)|as_local }}
should work, nowadays, doesn’t it?
thanks!, but no it doesnt. this is what I had:
and this is what your suggestion renders without it being set as timestamp:
with timestamp:
Indeed. I’m always confused about what device_class: timestamp actually expects.
I redid the test, and the UTC time correctly display in my local TZ w/o transformation.
Are you saying that the UTC time returned by MQTT is not actually UTC but local?
Then, it’s just wrong, and you have to “correct” it manually, indeed, no magic here.
OTOH, there might be a setting on whatever sends the message to set the correct TZ…
no the Z time is Utc alright, and local is +2
if I simply take the value and use timestamp I get this:
confuses me even more, because that seems to be correct…
ill reboot the device and see what happens…
right:
so Ive got to go back to the original then
