I used this initially:
but then I used this:
But the last time the sensor was tripped was 20:22, thus for me 2 hours ago…
I used this initially:
but then I used this:
But the last time the sensor was tripped was 20:22, thus for me 2 hours ago…
it doesn’t round.
so you mean in 4 minutes from now, at my time 22:22 it will say “2 hours ago”?
EDIT: yes it does:
yep, that’s what will happen.
Ok thank you for your help.
As a moderate user I must say that this is not very handy/understandable/user friendly/clear/whatever comes to that :-). I just want to see “my time” stuff in hass and not a UTC timezone that for me in this location make no real sense… I think this must be aware to the “awesome guys” that make hass?
I would really like to see events and tripped times to my timezone. That not a dumb question is it?
I understand where you’re coming from, but it’s only confusing because of the way that your device is implemented. Anyone who want’s a special time displayed in the interface from a device goes through this and there is 9000 different ways people want to view their time. Some people want AM PM, some people only want minutes, some people want it spelled out… see where this is going?
For example, my motion sensors do not have a special attribute called ‘last_tripped_time’. They just turn on and off. HA handles the times by using the last_updated and last_changed state object properties. (giving you the ability to use the last_changed secondary row). Your sensor is unique because it doesn’t do that. Apparently when your sensor trips, it doesn’t send an update to the main state, effectively making last_changed or last_updated useless.
Sorry, I don’t see where you are going :-). time is time, nothing fancy is it? I don’t care about AM/PM, written or sung, but I DO care about the correct ZONE. Nevertheless, thank you and I hope it will be picked up in the future.
Yes, but you seem to not understand. The more-info page is showing you unaltered attributes. It (home assistant) does not know it’s a time. So it keeps it unaltered. That’s up to the user to make use of the attribute.
If that is coming straight from your device, then your device needs to use the local timezone. And if thats something that you can’t set, then you can make a request to the integration to put that time in local timezone. Or do what everyone else does and convert the time. There’s a number of threads that cover how to do that. Here’s one:
Ok I see now that I don’t know what I don’t know. I’ll read on. thanks again!
Hi, another question regarding this topic…
what if I wanted this:
Tried this:
sensors:
car_last_tripped:
friendly_name: "Last Motion in BMW"
value_template: "{{ state_attr('switch.motion_sensor_5_1493', 'last_tripped_time') }}"
device_class: timestamp
hal_voorkant_afdak_last_tripped:
friendly_name: "Last Motion Voordeur"
value_template: "{{ state_attr('binary_sensor.sensor_hal_voorkant_beweging', 'last-changed') }}"
device_class: timestamp
But clearly I have not yaml knowledge
you must have an error there in the logs… use last_changed
instead, and use it like this:
{{ states.binary_sensor.sensor_hal_voorkant_beweging.last_changed }}
you cant template last_changed using the states() method
yes, seems to work now, thank you!
sure, welcome.
you should understand why though, so read up on this: https://www.home-assistant.io/docs/configuration/state_object/
last_changed
isn’t an attributes you can call using state_attr()
Hi, read it. but I do not understand what you mean with
last_changed
isn’t an attributes you can call using state_attr()
using state_attr() you can reference all attributes of the state.
in your case eg:
states.binary_sensor.sensor_hal_voorkant_beweging.attributes.name
states.binary_sensor.sensor_hal_voorkant_beweging.attributes.icon
which you can also write as
state_attr('binary_sensor.sensor_hal_voorkant_beweging','name')
this is also explained here: https://www.home-assistant.io/docs/configuration/templating/#states
be sure to read the yellow Warning bit, as it will help you write safer templates.
if you want to see which attributes are available for you entity, just throw this at the template editor:
{{states.binary_sensor.sensor_hal_voorkant_beweging.attributes}}
you’ll notice ‘last_changed’ isnt listed. because it is no ‘attribute’.
On a RaspPi 3, HassOS 3.13
{{ utcnow() }}
{{ now() }}
{{ utcnow().astimezone() }}
{{ now().astimezone() }}
{{ utcnow().tzinfo }}
{{ now().tzinfo }}
{{ now().astimezone().tzinfo }}
I get
2020-05-19 01:53:12.396476+00:00
2020-05-18 20:53:12.396624-05:00
2020-05-19 01:53:12.396790+00:00
2020-05-19 01:53:12.398530+00:00
UTC
America/Chicago
UTC
Any idea why the astimezone()
are all messed up?
check out this
Hello Everybody!
Looks like I have a similar issue with time settings. I think you are all running in circles not finding the correct issue.
I say this because:
I am running home assistant supervised in an esxi VM. Installed using 3.13 vmdk image.
Since I installed it a few days ago, I have had a lot of problems, by losing access to the server. I saw it was losing its ip address.
So after reading a lot of topics, I found that the timestamps in supervisor logs are of by 3 hours.
This time delay will F*** up the dhcp renewal from my router (pfsense vm) and after the minimum lease time of 2 hours, the home assistant machine loses its IP and I have to power cycle it. Simple reset will not solve the issue.
Now, I would like to ask you if there is any way to correct this issue. It is driving me crazy, and until now I did not manage to find a way to set the supervisor time/timezone.
Thank you,
And here is my original topic on this forum: Hassio on esxi losing IP address - HA supervised
And here is the issue on Github: https://github.com/home-assistant/operating-system/issues/684
Similar problem here??
{{ now() }}
{{ now().astimezone() }}
{{ utcnow().astimezone() }}
{{ now().now() }}
{{ now().today() }}
{{ now().utcnow() }}
{{ utcnow() }}
{{ now().tzinfo }}
{{ now().astimezone().tzinfo }}
{{ utcnow().tzinfo }}
2022-11-12 15:12:40.501943+00:00
2022-11-12 09:12:40.501943-06:00
2022-11-12 09:12:40.501943-06:00
2022-11-12 09:12:40.501943
2022-11-12 09:12:40.502947
2022-11-12 15:12:40.502946
2022-11-12 15:12:40.502946+00:00
UTC
Central Standard Time
UTC
System Health
Version | core-2022.2.3 |
---|---|
Installation Type | Unknown |
Development | false |
Supervisor | false |
Docker | false |
Virtual Environment | false |
Python Version | 3.9.10 |
Operating System Family | Windows |
Operating System Version | 8.1 |
CPU Architecture | AMD64 |
Timezone | America/Chicago |
This automation is going off at 8AM UTC, not 8AM CDT:
seems like something isn’t correct?