Xiaomi door/window sensor last opened time / Philips HUE motion sensor

Configuration
42

It does not show anything with that :confused:

Should that have tha attributes.last_update? No luck with that either :confused:

43

Well now it seems to work! I took away the split() from the sensor script so the timestamp was 2018-07-24T14:06:34 and I changed that to the value_template %Y-%m-%dT%H:%M:%S and now it works :slight_smile: (At least for now :smiley: )

Thank you very much, I hate timestamps and timezones in coding :confused:

1 Like
44

It’s the worse thing about home assistant. I hope we can band together and come up with a solution sometime in the future.

1 Like
45

Oh my, the timezone is wrong again even when there is the as_timestamp() :confused: Most likely was like that from the beginning but I did not notice it.

the as_timestamp does work but it translates it to 1532446334.0 which is UTC time…

46

A Unix timestamp, by definition, is UTC. It depends on how you display it. If you use the timestamp_local filter, it will be displayed in local time. If you use the timestamp_utc filter, it will be displayed in UTC. If you use the timestamp_custom filter, it depends on what you put for the second parameter: true (the default if you don’t specify it) gets you local, false gets you UTC.

The other thing to understand is how as_timestamp() interprets the datetime string. If it does not contain a timezone suffix it will assume local time. If it contains a timezone suffix, it will use that timezone. The result, though, will always be (possibly converted to) UTC.

1 Like
47

Yes I understand that and I tried to use timestamp_local but it shows the time still in UTC time. now() gives me the right time so the system is in right time.

Edit:
If I put the boolean false, it shows GMT time, true and it shows UTC

48

GMT == UTC.

I think your issue is not using the timestamp_xxx filters, but rather where you’re using as_timestamp() to interpret a datetime string into a Unix timestamp. If the datetime string is UTC, but does not contain the UTC timezone suffix (i.e., +00:00), then you need to add the UTC suffix. E.g., as_timestamp(my_utc_time_string+'+00:00'). Otherwise it will interpret it as local time.

1 Like
49

Oh, that is true. Any idea how to add it to

“{{ as_timestamp(strptime(states.sensor.kitchen_motion_sensor.attributes.last_updated, ‘%Y-%m-%dT%H:%M:%S’)) | timestamp_custom(’%d.%m %H:%M’) }}”

since when i put it here

“{{ as_timestamp(strptime(states.sensor.kitchen_motion_sensor.attributes.last_updated, ‘%Y-%m-%dT%H:%M:%S’)+’+00:00’) | timestamp_custom(’%d.%m %H:%M’) }}”

it shows nothing…

It works without the strptime()

50

I got it! I forgot to add the +00:00 to strptime :slight_smile:

“{{ as_timestamp(strptime(states.sensor.kitchen_motion_sensor.attributes.last_updated, ‘%Y-%m-%dT%H:%M:%S +00:00’)+‘+00:00’) | timestamp_custom(‘%d.%m %H:%M’) }}”

show the correct time finally!

Thanks again guys! Here is a related video :smiley:

51

Wait, why are you converting a date/time string into a Python datetime object, then into a Unix timestamp, then back into a string?

Assuming states.sensor.kitchen_motion_sensor.attributes.last_updated is a date/time string as_timestamp will accept, and it’s in UTC, but does not have the UTC timezone suffix, then:

"{{ as_timestamp(state_attr('sensor.kitchen_motion', 'last_updated') ~ '+00:00')
    |timestamp_custom('%d.%m %H:%M') }}"
1 Like
52

It is a string, not datetime object.

53

Yes, I understand that, but you can feed the string directly into as_timestamp without converting it to a Python datetime object first (which is what strptime does.)

EDIT: In fact, I can guarantee you your expression only works as a side effect. I.e., this part:

strptime(states.sensor.kitchen_motion_sensor.attributes.last_updated, '%Y-%m-%dT%H:%M:%S +00:00')+'+00:00'

is an invalid statement. You’re trying to take the output of strptime, which is a Python datetime object, and add a string to it. Also, the format string for strptime isn’t right either. The end result is, Jinja is being “nice” by passing the string straight through strptime (because it doesn’t match the format string), and then that original string is having ‘+00:00’ added to it. If you want to see this for yourself, try this in the template editor:

{{ strptime(states.sensor.kitchen_motion_sensor.attributes.last_updated, '%Y-%m-%dT%H:%M:%S +00:00')+'+00:00' }}
{{ strptime(states.sensor.kitchen_motion_sensor.attributes.last_updated, '%Y-%m-%dT%H:%M:%S')~'+00:00' }}

If you look close, the result of the first expression still has the ‘T’ in the middle of the string. This is because of what I explained. The second actually works (you’ll notice the ‘T’ is gone) because of two changes: 1) the + operator is changed to the ~ operator (the latter forces the operands to be converted to strings first), and 2) the format string is correct.

So, the result is the original string, with ‘+00:00’ added to it, is being passed to as_timestamp, which works because as_timestamp accepts that. Which is why what I suggested works.

1 Like
54

That seems to work too. Thank you and all the others that have helped :slight_smile:

55

I’m trying to get this work with my Ring doorbell.
I changed kitchen_motion_sensor with my entity ring_voordeur_motion.
The state shows unknown…

Can someone help?

56

@Jonde’s device is unique in the fact that he has the last_updated attribute, which is not to be confused with the home assistant datetime object last_updated. So, which one are you trying to use?

57

I fixxed it never mind!

58

What was wrong with it? The code is still working for me.

59

Well, that will only work with your sensor @Jonde because you have a last_updated attribute. Not many sensors have that attribute. Also, people confuse that with the last_updated property. Super confusing but the difference in code is this:

last_updated only on your device

states.domain.object_id.attributes.last_updated

vrs (state object’s last_updated, on all entities in home assistant)

states.domain.object_id.last_updated

I.E. Your code won’t work for everybody and it confuses people.

1 Like
60

I do not understand much of all the timezone discussion in this thread but I’m experiencing the wrong time zone with my door sensor as well. I’m in (GMT +1)

value_template: "{{ states.binary_sensor.ute.last_changed.strftime('%H:%M-%d/%m-%y') }}"

How can I easily add one hour to this?

61

Basically, last_changed is not expressed in local time, but rather in UTC. If you want to show it in local time, you have two ways to do so:

as_timestamp(states.binary_sensor.ute.last_changed)|timestamp_custom('%H:%M-%d/%m-%y')

or

states.binary_sensor.any_motion.last_changed.astimezone().strftime('%H:%M-%d/%m-%y')