Revisit DISTANCE_TIMEOUT for proxies that stop reporting adverts, and sudden departures.

[agittins]

Raised in particular consideration of Shelly's that might be dropping out or not reporting adverts for upwards of 30 seconds.

DEVTRACKER_TIMEOUT only applies to device_tracker entities, and since departure on those is typically less latency-sensitive, a simple timeout up to or beyond 180 seconds is typically adequate for dealing with advert gaps (and especially since we can get a perfectly valid Home indication from any proxy).

However, the simplistic Area detection is using the filtered rssi_distance, which currently uses the hard-coded default DISTANCE_TIMEOUT of 30 seconds to persist a "valid" measurement for 30 seconds after a proxy stops reporting that device.

Smoothing/filtering is still done over that time, so if the last report happened to be more distant than the one before, the smoothed value will approach that latest reading over the 30 seconds.

This works ok-ish when a proxy gets a weak advert as the device leaves the area, but can make the area "too sticky" if the device leaves quickly enough that the proxy doesn't hear any distant adverts - the stale "close" reading prevents another proxy from winning the device until it gets closer to that proxy than it was to the old one, at least for the next 30 seconds.

For users with misbehaving proxies that go offline for long periods, it would be helpful to be able to increase DISTANCE_TIMEOUT to compensate for longer reporting delays, although the core issue is probably with the proxy or its backhaul (wifi).

Revisit the logic, as it adds more latency than it should (when proxies are behaving well), but shortening it will make proxy drop-outs more annoying.

Perhaps have it assume the device left at peak velocity, and assume increasing distances on that basis, which might still give time for a slow/delayed/rebooting proxy to reclaim the device before it switches, but will also allow other proxies to "win" sooner if they are starting to see closer readings.

The above only applies to the simplistic area matching we do currently, for trilateration we should be able to weight the reading with decreasing confidence as the reading ages. I think.

[agittins]

This absolute mess, believe it or not, illustrates the issue of a working proxy not catching a distant measurement as I departed, so it caused the area to "stick" longer than it should have..

Two proxies in studio, camfront and prox-studio, at first camfront is closest (mustard, orange), but it detects me moving away, so its filtered distance (orange) starts rising gradually over time (probably too slowly).

However, prox-studio (lime) didn't see any of my retreat, so just left a fairly close reading, which sat there for 30 seconds. That reading "won" after camfront's filtered distance rose enough, and it then prevented the dining room from winning until it was very close. Not shown are the lounge and kitchen sensors which were along the way, but they never got close enough to beat out prox-studio, but would have shown up if it weren't hogging the stats.

The muddy-peach (?!) line at the bottom is from a different device, showing that prox-studio was still receiving and forwarding adverts during the timeout.