Motivation
PR #173 adds a last_reading timestamp attribute to the outdoor-temperature sensor
because its value comes from a trendsummary report that updates on its own
independent cadence, separate from the coordinator's main poll — so the displayed
value can go stale relative to when it was actually read (the subject of the earlier
outdoor-temp staleness investigation, #152). The same staleness risk applies to
other sensors that don't come from the main context poll.
Sensors affected
The coordinator's 60s poll (UPDATE_INTERVAL) only calls get_user_context().
Everything below runs on an independent cadence and has no staleness signal today:
- Energy (
API_TELEMETRY_ENERGY, 30 min cadence): ATA energy; ATW
energy_consumed, energy_produced, cop
- Telemetry (
get_telemetry_actual, 60 min cadence — and notably only requests
a 4-hour lookback window and keeps the latest point in it, so a reading can
already be old on arrival): all 8 ATW flow/return temperature sensors, plus ATW
wifi_signal
Sensors reading straight from the main context payload (room/zone/tank temperature,
operation status, ATA/ATW rssi from context) are poll-fresh already and don't need
this — HA's built-in last_updated covers them.
Proposal
Once #173 merges, extract its last_reading/timestamp-parsing logic into a shared
helper or mixin rather than copy-pasting the attribute across four more sensor
groups, and apply it to the energy and telemetry sensors listed above.
Motivation
PR #173 adds a
last_readingtimestamp attribute to the outdoor-temperature sensorbecause its value comes from a
trendsummaryreport that updates on its ownindependent cadence, separate from the coordinator's main poll — so the displayed
value can go stale relative to when it was actually read (the subject of the earlier
outdoor-temp staleness investigation, #152). The same staleness risk applies to
other sensors that don't come from the main context poll.
Sensors affected
The coordinator's 60s poll (
UPDATE_INTERVAL) only callsget_user_context().Everything below runs on an independent cadence and has no staleness signal today:
API_TELEMETRY_ENERGY, 30 min cadence): ATAenergy; ATWenergy_consumed,energy_produced,copget_telemetry_actual, 60 min cadence — and notably only requestsa 4-hour lookback window and keeps the latest point in it, so a reading can
already be old on arrival): all 8 ATW flow/return temperature sensors, plus ATW
wifi_signalSensors reading straight from the main context payload (room/zone/tank temperature,
operation status, ATA/ATW rssi from context) are poll-fresh already and don't need
this — HA's built-in
last_updatedcovers them.Proposal
Once #173 merges, extract its
last_reading/timestamp-parsing logic into a sharedhelper or mixin rather than copy-pasting the attribute across four more sensor
groups, and apply it to the energy and telemetry sensors listed above.