Owntracks mqtt timestamp invalid date?

Third party integrations
,
1

HI,

using the Owntracks mqtt sensors for ages, Ive today tried to add the device_class: timestamp to the timestamp sensor:

  - platform: mqtt
    state_topic: !secret owntracks_mqtt_topic
    name: 'Ot Timestamp'
    icon: mdi:clock
    value_template: >
      {{value_json.tst}}
    device_class: timestamp

which renders an unknown, and hence ‘Invalid date’ in the frontend.

This is remarkable since without it, it shows a valid timestamp.

48

Anyone got a clue why this would be unknown? Ive of course tried to update the sensors, which was successful, judging by all the other sensors I use.

Using the device_class: battery on the battery sensor works just fine, so it can’t be an mqtt / device_class incompatibility.

  - platform: mqtt
    state_topic: !secret owntracks_mqtt_topic
    name: 'Ot Battery'
    value_template: >
      {{value_json.batt}}
    unit_of_measurement: '%'
    device_class: battery
2

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:

    value_template: >
      {{value_json.tst|timestamp_utc}}

And you may need:

    value_template: >
      {{value_json.tst|float|timestamp_utc}}
3

Thanks Phil.

did the string test which confirmed the sensor didn’t output at date_time object but a string …:wink:
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:

15 so it does create a valid time.

4

Yeah, isoformat usually has a ‘T’ between the date & time instead of a space. This might be the problem. Try:

    value_template: >
      {{value_json.tst|float|timestamp_utc|replace(' ', 'T')}}
5

yes! that’s getting there.

Ive made 2 sensors, 1 using device_class: timestamp, and 1 without:

03

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 :wink:

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.

25

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.

6

How is the first one defined?

EDIT: Never mind. I think you meant they used the same value_template.

So change the first one to use |timestamp_local instead of timestamp_utc.

7 
  - platform: mqtt
    state_topic: !secret owntracks_mqtt_topic
    name: 'Ot Timestamp'
    icon: mdi:clock
    value_template: >
      {{value_json.tst|float|timestamp_utc|replace(' ', 'T')}}

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

8

Agreed. So:

  - platform: mqtt
    state_topic: !secret owntracks_mqtt_topic
    name: 'Ot Timestamp'
    icon: mdi:clock
    value_template: >
      {{value_json.tst|float|timestamp_local}}
9

quite. restarting.

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…

and bingo:

13

thanks Phil, appreciated, as always!

1 Like
10

It’s documented here.

11

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…