[–] 3 points 1 week ago

It works but I wouldn't call it the cleanest solution, more a workaround. As far as I know only apps targeting SDK 37 are affected, older apps still get the permission implicitly. So the proper way would be to just grant "Nearby devices" to the apps that need it e.g. Immich or Jellyfin and if an app doesn't ask for it that's actually a bug and worth reporting, because it should request the permission as soon as the server resolves to a local IP. I also find the "Nearby Devices" title a bit misleading for apps that only need it to reach your own server, but on the other side it gives a somehow proper hint what the permission actually allows.

  • source
  • [–] 3 points 3 weeks ago (1 child)

    Tunnel is fine security wise. Keep the reverse proxy anyway and let the tunnel point at it. Routing, logs, etc. stay in one place this way.

    Zero Trust with Google etc. is the way for family. Tailscale or Wireguard means installing a VPN client and making sure it keeps running, that's too much for most people who just want to click a link.

  • source
  • [–] 2 points 1 month ago* (last edited 1 month ago)

    A profile with "speed above 10 km/h" will kick in when the last 5 points average speed is above 10 km/h. The notification banner and dashboard will tell you if the profile is actually active.

    If your interval for that profile is 5s, a new point will be requested every 5 seconds and with a 10m movement threshold every point closer than 10m to the last recorded point gets discarded.

    So to get smoother tracks you can decrease the movement threshold. Personally I use a movement threshold of 2m with a tracking interval of 6 seconds which works very well for me.

    Logging points every 10m without a time interval is not possible, because the app needs a location to determine you moved 10m and Android needs an interval. A workaround would be to decrease the interval to something like 3 sec and set the movement threshold to 10m. Then the app will request a new location every 3 seconds and checks if it is at least 10m apart from the last point. If it is it will be recorded, otherwise it will be discarded. That will use a lot more battery though.

    You can read more about the tracking profiles in the docs: https://colota.app/docs/guides/tracking-profiles

    For places where you stay frequently (home, work, etc.) geofences work better. The stationary profile is good for situations where you are somewhere temporarily for longer (restaurant, friends, etc.)

    Edit: Small correction after doing the math and reformatting after writing that on the phone 😂

    Lowering the movement threshold will not smooth out a driving track. 10m at a 5s interval works out to 7.2 km/h, so above that speed every fix is already more than 10m from the last one and the threshold throws nothing away. So the tracking interval is your lever here. 5s at 50 km/h is a point roughly every 70m and even at a realistic average of 30 km/h it is still one every 40m, which is what cuts the corners.

  • source
  • parent
  • context
  • [–] 2 points 1 month ago (5 children)

    Out of the box Colota records every fix it gets by the device. So in case you haven't already I would suggest to enable the accuracy filter and set it e.g. to 25m. This way all points with accuracy worse than 25m get filtered out. Also the movement threshold helps with the stationary drift

  • source
  • parent
  • context
  • [–] 2 points 1 month ago* (last edited 1 month ago) (2 children)

    Colota dev here 👋 What do you want the profiles to do?

    Profiles are an optional thing to finetune your tracking settings based on certain conditions, e.g. speed above or below x km/h, phone charging, Android Auto connected or being stationary. So you could raise the interval while charging, since that usually means you are not moving. To start with you could also make a pause zone at home and at work and turn on the WiFi pause. GPS stops completely while you are there and the app will consume much less battery. Tracking resumes when the WiFi drops.

    I would add one at a time and see if it behaves like you want. When you create like 10 different tracking profiles with different priorities they can interfere with each other, so less is often more.

    Edit: Also the accuracy filter is off by default so you probably want to enable it to reduce the noise

  • source
  • parent
  • context
  • [–] 5 points 3 months ago (2 children)

    Owntracks can do that but it has a limit of how much locations can be stored locally. I think it was 100k, so depending on your tracking interval during the month you may hit the limit. Also it still tries to sync every few minutes even though the server is down. Colota (https://github.com/dietrichmax/colota) supports the same without a limit and you can use it in a offline mode and then export e.g. a geojson and import it into Dawarich or you set it to only sync it on a imaginary SSID like "abc " and then change it to the correct one when you actually want to sync. So it never even tries to sync until you really want it to. Disclosure: I'm the dev of Colota.

  • source
  • parent
  • context
  • [–] [S] 1 point 5 months ago* (last edited 5 months ago)

    Thank you, really appreciate it! Glad to hear Colota is working well with Dawarich for you so far. Feedback and criticism are always welcome. Most of it has led to real improvements in the app. I think a casual forum thread is probably just not the best setting for deep technical discussions, where context shifts quickly, everyone has a different background and nuance gets lost.

  • source
  • parent
  • context
  •  

    Hi there,

    recently there has been a post here about Colota and thought you might be interested in a short summary about Colota.

    I am tracking my position since several years now mainly with Owntracks (and now Colota) and a simple postgres DB/table.

    I am a fan of the indieweb and eat what you cook and with already some million location points collected I recognized some pattern in existing GPS trackers I wasn't happy about:

    1. Battery consumption
    2. Duplicate points while staying in the same location for a long time

    So I decided to build my own GPS tracker and called it Custom Location Tracker.

    Improved battery consumption should come from disabling GPS entirely in so called "geofences" which are basically circles you draw on a map in the app. With GPS disabled in these you also won't get duplicate points while staying at e.g. home or work.

    The app is still quite new (actively developed since early 2026) but has already quite a lot of features which basically all came from user feedback. E.g.:

    • Automatic Tracking profiles which apply different tracking settings while e.g. being connected to Android Auto, moving slower than 6km/h or while the phone is currently charging.
    • The app works fully offline (map will not be visible then) but you can predownload map tiles from a tile server I selfhost or use your own tile server.
    • You can define how locations are synced to your backend. E.g. only for a specific Wi-Fi SSID every 15min, once a day or with every location update.

    Overall the app's focus should move to be a mobile location history app. So basically Google Timeline in a mobile app which also supports selfhosted backends (as backup).

    The app is fully open-source AGPL-3.0, has no ads, analytics or telemetry and only sends data to your own server (if you want to).

    You can download two versions.

    1. Google Play store which uses Fused Location Provider and therefore uses Google APIs. Also works with the sandboxed version by GrapheneOS and microG.
    2. FOSS version which uses Android's native GPS provider with a network location fallback. Available on IzzyOnDroid and hopefully someday on F-droid.

    Both can be also downloaded directly from the repo.

    view more: next ›