Feature Request] Add support for the "consider_home" parameter present in other router based tracking integrations

[oblivioncth]

Thank you for this great integration, already it's way more useful than both the built-in and generic FreeBSD ones.

Many other device tracking centric integrations (particularly those that are router focused) feature a user configurable field that is usually called "consider_home", which acts to delay the state change of a device_tracker in HA by X number of seconds from the initial detection (usually via polling) in order to mitigate false positives. If the real device was found to have gone back to its original state after that period, the change is not reported.

See: https://www.home-assistant.io/integrations/device_tracker/#configuring-a-device_tracker-platform

I have no clue exactly what it would take to add this feature as I imagine its implementation is completely integration specific and likely consists of firing a timer for the specified time after a change occurs/is discovered and then checking the state again when it has elapsed before actually reporting it (or ignoring it if that is the case).

The existing "Device Tracker Scan Interval" setting does help facilitate this functionality partially, but ultimately is not the same thing. Setting it to a larger value does reduce the odds of polling the devices connection while it is temporarily marked as disconnected due to sleep, but does ultimately allow for poor luck to cause instant false positives. This alternative method ensures a fixed time grace period always occurs after a device is first believed to be disconnected, and if this time is tuned to be slightly longer than most of a user's devices tend to sleep then incorrect presence states can be eliminated almost entirely.

I know that this isn't exactly a high priority, but it is somewhat of a "standard feature" that I think is important to eventually have. Also I recognize that you may very well already be aware of this and just haven't bothered thus far, but I just wanted to have it down on paper haha.

[travisghansen]

Implemented here: f40b650

[travisghansen]

Please note, this works in conjunction with the scan interval. Some key points in this integration:

• the state of the device is only checked every scan interval
• each scan interval the arp entry is removed after the scan is complete
• the consider_home is only augmented by the above 2 point, does not replace either

For example, let's say you put the scan interval at 60 seconds, every 60 seconds the arp table is checked for the given mac address and if present the state is considered home. Additionally if the mac address is in the arp table it is removed which means the device MUST communicate with the router at least once after the integration has removed the mac from the arp table and before the subsequent scan interval to be considered still present.

With the newly added 'consider_home' setting what happens is every scan interval when the arp entry is checked if present the timestamp of when it was 'seen' is stored in hass (this is a new state value on the device last_known_connected_time). The value is always updated as appropriate. If during the course of a state check (ie: each scan interval) the arp entry is not found and the 'consider_home' setting is > 0 then the value from the state attribute is loaded up (assuming it's present, which is basically should always be as it's restored on startup) and used to compare against the current moment in time. If the elapsed time between those is < the 'consider home' value then we still return true/present/home/connected, otherwise return false/disconnected/away.

[alexdelprete]

@oblivioncth Christian, can you give Travis a feedback on this? It was implemented based on your request.

Thanks.

[oblivioncth]

Sorry,

I've been quite busy and haven't had a good chance to test this (didn't expect it to be implemented so soon either!) so I didn't want to give hollow feedback. At the moment I only have two WiFi devices that are being tracked an both of them have been very accurate with the scan interval I currently have set, though I absolutely suspect I have a few that will not, and regardless I would like to tighten my scan interval up a bit.

I appreciate the detailed documentation. The implementation seems perfectly reasonable and likely to be effective, though I can't comment on how it compares to other integrations that provide device trackers as I'm overall new to HA and this is the first integration I'm using for device tracking where sleeping, or any other cause of false positives, is a concern (from everything I was reading though I knew this would be a key feature for a number of people and not just myself). But as I said, this approach seems idiomatic and I expect it to produce intuitive behavior, obviously within the constraint of having a reasonable scan interval.

I would like clarification of one aspect though:
every scan interval when the arp entry is checked if present the timestamp of when it was 'seen' is stored in hass

Is this timestamp set directly at the time each scan occurs where the device is found to be present in the table by the integration itself (and then the first time the device is found away the timestamp from the last "positive" scan interval is used)? Or is this timestamp something managed by OPNsense and this integration simply requests said value during a poll?

In the former, having consider_home < scan_interval would essentially make consider_home irrelavent since the consider_home time would always expire before the next scan, obviously limiting the functionality of this feature considerably. If it's the latter, as long as OPNsense updates that timestamp fairly frequently then while overall accuracy is still ultimately gated by one's scan interval, this feature in particular wouldn't be completely at the mercy of its value.

I'm guessing it is the latter, but I just want to make sure. If it isn't and you have to track the last-seen state entirely on your own, then I completely understand, it's just obviously important that the limitations are clear either way.

[travisghansen]

It is the former. I’m not sure I understand the concern however. It’s sort of implicit with these trackers that consider home value is greater than the scan interval. Generally the value is some multiple of the scan interval…ie: scan every 60 seconds and consider home for 300 seconds (must be missing 5 consecutive scans before it’s considered away).

[oblivioncth]

I supposed I myself did just express I wanted to keep the scan interval short so you very clearly have a point.

I was overly focused on the technical details and which would be "superior" without considering the practically of its use. Thinking of it as ignoring 'n' scans before considering a device away is a good way to think about it.

That's what I get for responding to this in haste after just waking.

So it seems it should work well then, and I will be sure it test it out as soon as I can.

[travisghansen]

It’s not even ignoring n scans (technically). The scan happens regardless but each positive scan effectively ‘slides the window’ creating the sliding window pattern.

Note that the last seen value is stored in perpetuity effectively as it is restored on startup so you have an added bonus that you could hypothetically create a template sensor for the last seen date/time :)

[alexdelprete]

Thanks for the feedback Christian. Please close the issue when you feel comfortable to.

[oblivioncth]

I got some more devices added and was able to give this a real test.

By default the devices would, as expected, intermittently sleep and not report into to OPNsense often enough to be always marked as home. I let them go like this for a number of hours to get a good baseline and then looked at the history of each to get a sense of how long they tended to temporarily drop-off the network (or at least be marked as such by the router). On average it was one to two minutes, but there were occasional periods where it would be longer.

After a little bit of tweaking I settled with a scan interval of 60 seconds with a consider home time of 7 minutes. The latter is a bit longer than I'd prefer and could maybe be dropped down to 6 minutes (5 still wasn't quite long enough), but with these settings none of the three phones I tested with showed away anymore when they were actually home, as is hoped.

With this assigned to a person in tandem with GPS tracking I expect their presence to handled quite smoothly, and so far that has been the case.

Nice job!