One fix, found by a reporter running the previous release against a time-series log of their own device.
Gateway thermometer readings no longer step backwards once an hour
If you have a thermometer behind a Govee gateway — an H5310 or H5112 behind an H5044, say — its reading dipped to the previous hour's value for about five minutes of every hour, then corrected itself.
v2026.8.5 started reading temperature from the gateway's own MQTT frame, which arrives roughly 8 minutes before Govee's cloud has a copy of the same reading. Inside that window the 5-minute account poll still returns the previous hour's value, and the integration applied it unconditionally — overwriting a current reading with a stale one.
Measured by @Araknus13 on a pool thermometer (times UTC):
frame 08:56:35 19.9 °C MQTT, current
poll 09:00:42 19.1 °C account API, still the 07:56 reading
poll 09:05:43 19.8 °C account API, caught up
The size of the dip is simply one hour of temperature change — small on a swimming pool, larger on anything that moves faster. It also produced a burst of spurious history: 37 recorded state changes in ten hours against 20–24 per full day before, for a value that hadn't actually changed.
Both sides timestamp the reading device-side — the frame in its own bytes, the cloud as lastTime — so they're directly comparable. A cloud reading no newer than the frame already applied is now recognised as the cloud catching up rather than as new information.
Deliberately narrow: if there's no gateway frame for a device, or the payload carries no usable timestamp, the reading is applied exactly as before. Devices without a gateway are unaffected.
Thanks to @Araknus13 (#151), who also confirmed the frame decode itself on live hardware — byte 13 = 95 → 20.7 °C, matching the entity exactly, on an account other than the one the formula was derived from.
Full Changelog: v2026.8.5...v2026.8.6