[piomar123]

Problem

minute_data carries the newest history value forward to "now" (the gap fill from the last sample) using newest_state, picked with if minutes < newest_age. Since timestamps are truncated to the minute, the last two changes of a sensor that fall in the same minute have the same age, and the strict < keeps the older one. It is then used for every minute up to now, until the sensor changes again.

Seen live: a heat pump room sensor (1C resolution) flickers 22/23 every few seconds overnight and settled on 23 (22 at 02:15:46, 23 at 02:15:48). Predheat's internal_temperature read 22 for the next 10 hours, so it planned heating all day. The transition minute itself held 23, so the series even disagreed with itself.

Fix

On a tie in backwards history, the later item wins (minutes < newest_age or (backwards and minutes == newest_age)). Every backwards=True source passes history oldest first (HA API client sorts it, the DB query is ORDER BY datetime, GE Cloud data is time ordered), and minute_data_state already got the same change in #2896.

Impact review

• newest_state is only used by the "fill from last sample until now" step, i.e. calls without to_key. Rate, carbon and tariff calls (to_key) are untouched.
• Backwards history (load, import/export, SoC, battery power, Predheat inputs, cost/carbon today, load_ml, yesterday adjustment): changes only when the two newest items share a minute, and then the value carried to now is the newest one, matching the transition minute.
• Incrementing sensors: no change in output. clean_incrementing_reverse already ignored the small backwards step the stale value caused (checked, including a same-minute reset).
• Forward data without to_key (load forecasts, Solcast, Predheat weather): unchanged. A plain <= would have changed it: with smoothing=True each item starts at the previous item's time, so the first two items always tie, and <= moved the value that fills the tail past the last forecast point from item 1's to item 2's (on a cumulative load forecast, 0.0 became 0.25 for every minute after the data). The tie rule is therefore limited to backwards=True.

Tests

Tests 27-30 in test_minute_data: same-minute changes with and without smoothing (fail before, pass after), a same-minute counter update that must stay unchanged, and a forward smoothed load forecast whose tail fill must stay unchanged (fails with a plain <=). ./run_all --quick passes, and pre-commit is clean.

🤖 Generated with Claude Code