New state timestamp State.last_reported
The State object is now always updated and 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. This is implemented by adding a new timestamp, State.last_reported and a new event state_reported.
The state_reported event is fired in large volume, and must be used with care to avoid detrimental effects on system load:
- Event listeners which subscribe to all events are not called when state_reportedis fired.
- It's not allowed to listen to state_reportedevents for all entities.
- When listening to state_reported, anevent_filtermust be used to screen out events for other entities.
- When listening to state_reported, therun_immediatelyflag must be set.
Background
Home Assistant previously discarded state writes where neither the state nor the state attributes were changed, unless the integration set the force_update flag. This behavior made it very difficult for integrations to correctly do time series analysis of numerical sensor state. It also meant the user didn't know if an integration is updating a sensor or not.
The new timestamp and associated event were discussed in architecure discussion #1062.
Custom integration impact
The following APIs have breaking changes:
- The time_firedargument forhass.bus.async_firenow accepts afloattimestamp instead of adatetimeobject.
- The signature of event filters which can be passed to hass.bus.async_listenhas changed.
- The time_fired: datetime | Noneargument forEvent()has been replaced withtime_fired_timestamp: float | None.
- A new argument last_reported: datetimehas been added toState()in the middle of the argument list.
For more details, see core PR #113511 and core PR #113798.