Fixed in 3.1.1: sensors frozen for hours
The bug is real, I reproduced it on my own system, found the cause, and
3.1.1 fixes it. Thanks to everyone who reported it “the values just stop”
was exactly the right clue.
What was happening
The integration doesn’t poll. It holds real-time listeners that push a
fresh snapshot every few minutes. All of those listeners share one
authentication object, and the token behind it is rotated every 55 minutes.
That rotation was reported in a way only one listener could observe. The
others never learned their credentials had been replaced, kept listening on
a token that expired 5 minutes later, and went silently dead no error, no
warning, no entity marked unavailable. Your readings simply stopped moving.
A dead listener only came back at a later rotation it happened to win.
Each missed rotation cost exactly 50 minutes, and consecutive misses
compounded. Over 48 hours on my own system I measured 8 stretches longer
than an hour, the worst at 6 hours 57 minutes.
Affected versions: 3.0.0 and 3.1.0. Still on 2.x? You’re not affected,
whatever number of pools you have before 3.0.0 each pool had its own
config entry with its own authentication, so there was nothing to race for.
The hub pattern in 3.0.0 consolidated everything onto one shared object,
which is what made a long-dormant flaw reachable. Accounts with several
pools were hit harder, since more listeners compete each time.
What to do
Update to 3.1.1 via HACS and restart. No configuration change needed.
How to confirm it’s working
Enable debug logging under Settings > Devices & services > Aquarite, and
look for Resubscribing lines around each token rotation. Before 3.1.1 only
one appeared per rotation; from 3.1.1 every subscription gets one.
If you want to check for stalls in general, look for
Manually updated Aquarite Pool data one per snapshot. On my system
these land every 11 minutes; yours may differ. A gap of an hour or more is
the symptom this release fixes.