That line is how you get the data out of the template sensor again.
You can use it where you want, but if course that place needs to allow template sensors
What I meant; Do I need to put the line below the rest? like this
or do I need to create a seperate sensor, like this:
- sensor:
- name: "test"
state: "{{ state_attr('sensor.nominal_change_history', 'changes')['input_boolean.test'] | as_datetime }}"
and when I have multiple entities, I need to put it here twice right?
It’s not part of the template to store the data, so you should not put it in that template sensor.
You should put it where you want to use the stored datetime, which can be anywhere where usage of templates is allowed
Hm do you have an example? I’ve tried this one but the sensor is telling me unknown.
- platform: template
sensors:
lastchangedsomfybadkamer:
friendly_name: "Last changed SomfyBadkamer"
value_template: >-
state: "{{ state_attr('sensor.nominal_change_history', 'changes')['cover.somfybadkamer'] | as_datetime }}"
or is an input number (helper) a better way?
Not related and looks like a gpt answer?
I’ve seen a few spam bots on here recently, if it’s obviously not helpful it’s best just press report as spam on the post.
Can I give this topic another nudge? I have a suggestion that maybe makes this more likely to be implemented:
Add two fields to the states
table in the database:
-
last_communicated_state
:- This will normally just reflect the same value that is in
state
. However:- It can only be
unknown
upon sensor creation if the sensor has a state ofunknown
orunavailable
. - Once the sensor has any state besides
unknown
orunavailable
, this value will reflect that state. - If the sensor state ever reverts to
unknown
orunavailable
this value will not reflect that. It will not be changed and therefore retain the previous value.
- It can only be
- This will normally just reflect the same value that is in
-
last_communicated_state_change_ts
- This will be a timestamp which changes any time the
last_communicated_state
has its value changed.
- This will be a timestamp which changes any time the
Having the last communicated state in the database prevents having to do lookups when a sensor gets a new state and needs to determine whether this is a “real” change or not. It is also useful in scenarios where users want to ignore unknown/unavailable and just use the last known “real” value. Also it makes it clear that there is no request to change the functionality of the existing last_changed_ts
and last_updated_ts
fields.
The downside is that I have no idea how much extra storage this would require adding to the database.
Also, in regards to naming of these two fields, I don’t think it matters what it is called. Here’s some other ideas for people to chew on:
last_known_state
last_monitored_state
last_confirmed_state
last_nominal_state
last_measured_state
last_state_that_is_neither_unavailable_nor_unknown
any_parameter_name_that_the_people_who_create_and_approve_the_PR_agree_on
...
Is WTH running again this year?
It might be coming around that time to get this yearly widely requested feature raised again!
Ah that’s a shame, thanks for confirming though!
I can’t believe it, my prayers have been answered and I can finally get rid of my DIY solution! Great news!
Got my hopes up, I should have checked the link! I’m still hoping this is implemented at some point - I still have the same stance that it’s the expected behaviour from your standard HA users view.
an event is always fired when an integration sets the state of an entity, regardless of any change to the state or a state attribute.
Not really a solution. last_reported
is always going to be the last time the state was written to. Not the last time it actually changed. You can check the PRs listed on the docs site. This does not change the behavior for last_changed
.
So now you will have two state attributes that will be set to when Home Assistant started since last_reported
will fire when the integration starts up (assuming it checks the current values when it starts) and it will also have last_changed
set because last_changed
is still set to the same value on load as before.
Oops, wrong topic. Sorry about that. I meant this topic
FYI it’s 3 properties on the state object. last_changed, last_updated, and last_reported.