From what I can tell by looking at the code of sensors that specify the timestamp device class, they all seem to be datetimes converted to ISO format in UTC. So you might try:
did the string test which confirmed the sensor didn’t output at date_time object but a string …
float would be needed indeed, because as you can see the string is not using decimals.
restarting as I write this, (not at location using the wonderful Ide add-on) and will report back with results.
which is not just there yet…
I still get the Invalid date, but clicking the sensor for more-info results in:
Ive made 2 sensors, 1 using device_class: timestamp, and 1 without:
as you can see the device_class translates the timestamp now into a relative time description as it is supposed to.
Only thing is, it isn’t correct
we are + 2 hours relative to timestamp_utc. Which shows 17:37:16. Adding 2 hours would make 19:37:17.
The timestamp sensor shows ‘2 hours ago’, while in fact it is currently 22:39:xx overhere. so the timestamp sensor should read 3 hours ago…
now how do I correct that.
First of all I’d like the regular timestamp sensor to be correct about the timezone, so not show utc but local timezone (which isn’t always +2, on changing the daylight savings times). Is there another |timestamp_ I should use for that?
Secondly the timestamp_ts sensor should calculate the relative time correctly…
forget the last remake on the timestamp_ts. Ive just hit the location push in the Owntracks app, and immediately the timestamp sensors were updated.
the second timestamp_ts sensor is correct now, must have been a restart or cache thing why it miscalculated the hour.
Still, would love to have the regular sensor show my local timezone.
in fact, since I now use 2 ( like the 2 representations for the the timestamp), I could also leave out the |replace(' ', 'T'), since that is only necessary for the device_class to do its job
why is this so undocumented… Can’t find this in the 2 links dev-template gives us for templating, nor in the python timestamp documentation? even googling |timestamp_local doesn’t yield an answer…
duh, I’ve completely overlooked that, read it about 10 times today, and use that as a reference many a time when configuring templates… but because I couldn’t find examples using the |timestamp_utc or _local, incorrectly skipped it in configuring this particular sensors. Talking about tunnel vision.
Having said that, a couple of simple |timestamp examples wouldn’t hurt on that page. just like is done with (all) the other filters…