I do not know about possibility to update relative_time() more frequently than once a minute (although you may press F5 more frequently which is not a solution).
That is why I am avoiding using relative_time() for showing last-changed/updated (means - template-entity-row) when I need to see constantly updating last-changed/updated.
As for “last-reported” - I missed a moment when this attribute became exposed.
It was added first to “states” but was not exposed for some period.
What is your use-case, why do you want this attribute to be shown?
Please advice any other approach so I can see the values updated (and localized).
I see my sensor value with comment “updated 3 hours ago”.
Is value the same for 3 hours?
Or is my sensor broken (connection lost)?
With “last-reported” shown near “last-changed” I do have an answer.
A standard entity row.
Actually, the only thing about “relative_time” is that it is updated once a minute.
Imho it is not a big deal - just press F5 to update it.
If last-updated is “3 hours ago” - then probably the last record in DB is from this moment of time.
Open a DB by something like DB browser for SQLite.
Also check logs; may be you also need to enable debug messages for this integration in Logger.
There seems to be a little missunderstanding.
If I do have problems with integration, I have plenty of ways to see what is happening.
Speaking about normal day. I look on my dashboard and see:
My temperature sensor value, changed 5 minutes ago - OK, everything works fine.
My CO2 sensor value, changed 18 hours ago - ALSO OK, I am sure something is wrong and need to investigate (normally the value changes a little every several minutes).
My PM2.5 sensor value, changed 6 hours ago - NOT OK.
May be the value is really constant for several hours.
May be there is a problem with integration - I do not know.
I want to see if there is a problem with integration without checking DB and logs every time I doubt.
One of the ways to see this: display last_reported value. May be, there is some better approach?
In general: if you doubt in something and trying to investigate - logs are first place to check. Next step - enabling debug messages for this integration and probably checking DB.
I assume all these sensors you are talking about are not template, they are provided by some integration (AirVisual?)?
Also, you may create a FR to allow displaying last-reported in Entities card and other places in UI (tiles, glance etc)
Last reported updates at a frequency that is different than last_changed. Both of those templates will update when the state (or any attribute in the state object) changes.
The template engine only listens to state changes and attribute changes. Properties on the state object do not cause the templates to update. last_changed, last_reported, etc are all properties, they are not attributes or the main state.
The only reason last_changed updates with a state update is because they come together at the same time.
If there is an entity’s state is accessed in a template, it will update when attributes or the state updates.
{{ states.sensor.abc }}
{{ states('sensor.abc') }}
{{ state_attr(...) }}
# etc any other function that access a entity_id or it's attributes.
If a domain is accessed, the template will update when all of the domains state’s and attributes update. However it will update at most once per second.
{{ states.sensor }} # no entity_id provided, only this object is used
If all states are accessed, the template will update when all states or attributes chage. However it will update at most once per minute.
{{ states }} # no domain provided, only this object is used
If now(), relative_time(), or today_at() are used in the template, the template will also update on the minute mark.
I always doubt.
Yes, I am an engineer, and I can read database and debug logs.
But why not having this information on dashboard instead, so one can immediately see the sensor value and if the value can be trusted?
For example, display relative_time(last_reported).
Or more complex: check last_reported with some script and display alert if the state was not reported for more than an hour.
There is one already: Add last-reported to secondary_info. May be it will be implemented some day, but I need to do something now, not after several months or years.
Great thanks for the explanation how it works.
From user point of view I definitely call this a bug: template contains value (last_reported), the value is updated, the template is not updated.
Even if this behavior is the one expected and hard to change.
The value is updated though. It’s a moment in time. It’s static, it does not change. The frontend does this nifty thing where it calculates the difference between the timestamp (that hasn’t changed) and the current time.
When you use a template, the frontend loses that context and you’re held to updates provided by the template. Those were described above.
If that was an entity instead of a template, you’d see a correct relative time in the UI. You’d have to make this into a trigger based template sensor, with an update frequency that matches your reported at frequency (or less than that).
Standard row secondary_info does not support last_reported. There is a FR for this support.
Template with last_reported is not updated when last_reported changes. That is how templates work. Only sensor state change or F5 updates the value on screen. From my point of view this behavior is strange, but it is how it works.
relative_time() is used in jinja-supporting cards like template-entity-row, is it possible to support higher frequency? For instance, if an optional “every_15_seconds” argument is defined - then a frequency is 15 sec (with no choice to select other frequencies).
When relative_time() is used only in UI to show a last-changed/updated - creating a trigger-based templates could be a bit overkill. Actually, rare updating of relative_time() is not a big problem, a user can press F5, just curious about a possibility to alternate a frequency of relative_time().
