Thanks for the info. I haven’t really looked at the code for most of those, but I have looked at the code for Google Maps Location Sharing. I’ll take a look at the others as well. Maybe I have missed something.
But one important point is, the device tracker component level code (i.e., the “higher level” code used for all device trackers) treats GPS-based platforms differently than network (aka router) and bluetooth platforms. The reason is that GPS-based platforms can report locations both in the home zone and out of it, whereas all the others can only report that the device is “home”. And more importantly for network and bluetooth platforms, the reverse is also true – i.e., they cannot report that a device is “not home.” Therefore, to make network & bluetooth platforms useful at all, the component level code implements a “consider home time” algorithm for them. I.e., if they haven’t reported for longer than that configured time period, then the component code makes them
'not_home'. If it didn’t do that then network and bluetooth platforms would be useless. And this algorithm is just a guess at best (and, BTW, is often wrong.) Also note that the component level code does not apply the same algorithm to GPS-based platforms.
So, for all your network (asuswrt, nmap, ping) and bluetooth trackers, they are actually not determining that the device is
'not_home'; that’s being done by the component level code based on the algorithm mentioned above when they stop reporting that the device is home.
Believe me, I hear you. It does seem as though the Life360 server can report that the device is “disconnected” (although it would seem it takes a long time before that happens – maybe several hours.) And the platform code could have some sort of timeout if the “last seen” timestamp hasn’t changed. But I think you keep missing the point – there’s no defined way for a platform to tell the component level code this, other than via the
see() method, and simply by calling that method it’s effectively telling the component level code that the device has been seen – that’s what calling it means. And even if if that is done with a “location” (aka state) of something like
'offline', and/or with an attribute that indications a lost connection, again, simply by calling the function that will mess up the component level’s algorithms. That’s why I keep saying, if you want this to change, don’t tell me. Tell the HA developers by opening an issue on the device tracker component.