How to get "Last update" dates right ("Last update" is not updated in HA if the value does not change)

Configuration
1

In short: there should be a way to have a state change its last update value and trigger an automation whan it happens.
That coulld be done by allowing a boolean attribute to be set on the state such as “always_update”.

Another issue is the rounding of the temperature values.

Other discussions

The last_update time has been at the core of several questions on this forum, mainly because automations are not triggered or “flowing” as expected.

If working as I would expect as a user, the last_update value would be close to the last_seen value for a zigbee device, but it isn’t.

Generally the discussion turns to “can’t you use a timer in the automation” 1. However that ignores the information if the value is actually recent or if the sensor has not been able to communicate its value.
In some cases it is important to know that the value is current.

My current use case

I am sending a remotely measured temperature to a Danfoss Ally TRV. The TRV then automatically adjusts its internal temperature offset in order to regulate the expected temperature at the remote temperature.

It requires the temperature to be sent at most every 30 minutes and at least every 180 minutes.

In practice, when the temperature is regulated, it will not change enough at the remote location to have a change in the “last_update” and “last_changed” values. I can see that the thermometer is reporting every 5 minutes, but the UI (and the state information) will show that it is 40 minutes old for instance (last_update value + last_changed value).

So the workaround that is proposed is to use a timer and then use the value that is observed. However, if the sensor is not communicating and this lasts for a very long time, then the temperature reported to the thermostatic valve is always the same.
Suppose that the temperature is lower than the setpoint, then the radiator would be constantly heating.
In the other case, it would become quite cold because the thermostat would be informed that the temperature is still ok.

Further, the temperature that is available in the state is rounded to tenths of a degree, while the sensor reports in 0.01°C. So in practice there is mostly at least a 0.01°C change, but it is not catched by the state because it has a rounded value.
Using the raw value could have some impact on improving regulation because the slight changes could help the PID, but that information is lost.
I did not check where it is lost. My sensor is a SONOF/TH01 under ZHA and it’s not using a quirk so it’s either a rounding in ZHA or HA.

Workarounds

  • In the case of ZHA it’s possible to write a quirk and then it’s probably possible to increase precision and the last_update timestamp - either through the existing state or a new one. Or, convert the temperature cluster in an “EventableCluster” so that updates to attributes are reported through events and then an automation could use that event instead.
  • It may become possible to use snarky-snark/home-assistant-variables to slightly change the state value so that (Z)HA detects a change when the nexst new value arrives. An official service to update a state value does not exist to my astonishment, so we have to go to an “external” component.
  • Use zha-toolkit to read the temperature on a regular basis and update a state. However the thermometer is a sleepy device and it requires often more than 50 unsuccessful request to communicate successfully.
  • See if there is some method to access the last_seen timestamp of a ZHA device and use that as a best guess for last_update.
  • If last_update would be a correct value, then this could be checked on a timed basis.

But I believe that there should not be any reason to have to implement workarounds for coping with the lack of updates to ‘last_update’. I understand that the question of limiting the number of triggers, but there should be a way to have it work through an attribute on the state such as “always_update”. When the attribute exists/is set to true, then HA should change last_update on every reception of a value. Further, in the case of the temperature, it would be nice to be able to get the higher precisiion.

Please share your thoughts, ideas, explain the rationale behind not updating “last_update”. Maybe this should be turned into one or two feature requests.

1 Like
2

The temperature is rounded in ZHA to one decimal digit because that is the default:

and it is not changed in the Temperature class - nor in the DeviceTemperature class:

3

There seems to be provisioning for triggering updates in the core, but I am not sure how to (persistantly) trigger a state update/how to set force_update (persistantly) to have HA generate a trigger every time the value is set (and not only when it changes):

4

As a workaround, I apply a small change to the sensor value once it updates.
As the automation (blueprint) is running in single mode, the update itself will not trigger the automation again.
It works essentially like this:

blueprint:
  domain: automation
  name: Update sensor value to get next update trigger.
  input:
    sensor_id:
      name: Sensor
      description: Sensor to apply fake update to in order to ensure future update event if the value is identical.
      selector:
        entity:
variables:
  sensor_id: !input sensor_id
trigger:
  - platform: state
    entity_id:
      - !input sensor_id
action:
  - alias: Fake small change so that the next sensor update triggers an update/change event
    service: zha_toolkit.ha_set_state
    data:
      state_id: '{{ sensor_id }}'
      attr_val: '{{ (states(sensor_id)|round(2)) + 0.001 }}'
mode: single
1 Like