[Feature request] fixed GPS coordinates based on wifi SSID

[leprechaun]

Hey folks,

I've searched online, and in the issues, and can't find a close enough match, so here goes. This may have been discussed, in slightly different terms and here sorry.

It would be nice if one could specify fixed GPS coordinates based on which Wifi SSID you're connected to. My GPS/Location happens to be really noisy, for reasons unknown; it can jump a few hundred meters while I've been plopped on the couch. My historical data is all over the place, and ultimately, I can't really rely on my reported location.

While the issue clearly has to do with my own circumstances, I wouldn't be surprised others find it useful as well. It would certainly clean up my data, enough to trust it for geo-fencing things, and might also save some battery at the same time.

Perhaps this could be tied to regions, where a region could be either the mapping of a location radius to a name, or mapping an SSID to a set of coordinates.

While no Android expert, seems like a permissions change might not be required, as getting the SSID requires location, which obviously users would have granted.

Anyway, just a thought.

[jpmens]

This is a very interesting idea, and I too imagine it would benefit a number of users. Thank you for proposing it.

[growse]

Agree, it's an interesting idea.

Couple of thoughts off the top of my head:

• SSIDs are not unique. I'd worry about the possiblity of coming across a duplicate network name and having Owntracks then assume that it's at one location when it's actually at another. Might the BSSID be a better selector for such a feature?
• I'd also be concerned about overloading the meaning of the "location" field in the Location message. Currently, it's sort-of assumed that this is a location that has come explicitly from the device. Overloading that field to mean "could be from the device, or it could be set by an app-specific override rule" might cause problems further down the line. I'd be more comfortable if we could explicitly indicate somehow that the value of the location has been derived from proximity to an SSID/BSSID rather than the location services of the device. Maybe a flag, or even a different message type?

[leprechaun]

SSIDs are not unique

Quite right, good point. I'm afraid it complicates matters indeed. While it's more work, supporting both SSID and BSSID in some fashion might be the winning move.

If I understood correctly, each VLAN has one SSID (name), but can have one BSSID for each of the radios of each access point. In a home setting, we're dealing with handful, at worst, but in an office setting, it could approach hundreds. The challenge would be to input all of them all.

UI wise, it could be relatively simple. Show the current connected SSID, the current GPS coordinates, and a checkbox, "restrict to the following BSSIDs", which enables a textbox where you could paste the list. I tried a BSSID logging app from Google play, but it didn't work as advertised. I'd still be happy to copy paste from my laptop, though. Perhaps obtaining the list of BSSIDs for the current SSID is possible and not an astronomical amount of work; I don't know.

If kept simplistic, one could map a different set of BSSIDs of the same SSID to different locations (eg, cafe chain branch X vs branch Y).

Overloading the meaning of "location"

I can imagine the concern. I haven't looked at the codebase, but I can imagine the location concept gets passed up and down quite a bit in every part, and tacking on the concept of "deduced location" (or something to that effect) wouldn't be trivial.

OTOH, as a starting point, using this feature would require configuration (and therefore opt-in). Users could be warned, and should be able to understand the distinction between reported location vs deduced location. Restricting the feature to the currently connected SSID/BSSID, vs those that are visible would also help in terms of noise/false-positives (eg, you're close enough to be connected, and bothered connecting so probably intentionally at that location).

$0.02

[Mondei1]

+1 for this idea. I was actually about to write an issue by myself.

My Pixel 6 experiences rapid battery drainage with OwnTracks, even when placed idle on my desk at home in "significant changes" mode. Like already discussed, a beneficial feature could be the ability to disable GPS when the phone is connected to a particular WiFi, significantly reducing battery consumption for users predominantly at home, while still allowing tracking when outside.

To address the SSID matching issue, a solution could involve verifying if the last reported location is within a designated radius. For example only activating the override if the phone's last location is within a 150m radius of my home and connected to its WiFi. This approach would prevent triggering the override in the presence of a similar SSID and BSSID elsewhere. It also is reducing the likelihood of someone setting up a fake WiFi network to alter the phone's location reporting (although this is highly improbable, it's a neat side-effect).

The override would be disabled as soon as the WiFi connection changes. However there needs to be a timeout because the connection could drop every time without any reason. So OwnTracks should check if the connection, if dropped, has been restored in 10secs or something.

[leprechaun]

3 years later ... It's me again!

I may have a different solution to this problem. I've recently started using macrodroid/automate to change reporting modes.

Instead of having owntracks care about wifi networks, I can get tasker/automate/macro droid to care about the networks, and do the heavy lifting.

I tried to use a FakeGPS app. One works great, but wants donations to enable automation. The other supports automation for free, but I found it was unreliable.

Then it occurred to me ... There could be an intent in Owntracks to fake the location.

Two options.

First, likely simpler, is to send a manual location update and pass coordinate parameters in the intent. This would work just fine, assuming you change to manual reporting mode before doing this.

Automation example:

On wifi network change,
If network == home
Send intent: change reporting mode to manual
Send intent: send manual with coordinates(lat, long)

No need for UI changes or options. No new concepts in Owntracks. And because it's a one off thing, even misuse by users who bother trying this out won't break everything.

This could be a new intent as well, specifically for this.

Option two, more complicated, is having a new LocationProvider that returns whatever you configure it with. This change would be persistent until you disable it, and might require some UI notification if we wanted to be nice to people who try it out.

Anyway. Food for thought.

I'm still not an Android developer, but this one seems feasible for a pleb like me ... Maybe.