[RELEASE] OwnTracks Presence

⚙️ Custom Apps and Drivers Custom Drivers
284

From the discussion it suggests that you loses some stuff while gaining the no longer need to start the app. How has it been since you have swapped?

285

@brianwilson with this driver am I correct in saying I need multiple devices per person if I want to track different locations?

I would like to get rid of life 360 as the only reason I use that is to gain another location. I have my home as two geo fences. One is very close and the other is the whole town.

I use it so when we leave everything shuts down but if we leave the town and come back that starts the heating but leaves everything secured.

So in a ideal world I want present when we are home and region of "home". However when I'm in town it would be not present but region of "local" then the same for "work", "parents" etc. So I only need one present but multiple regions. Is this possible using the HTTP?

286

Yes.

287

Would it not be possible to have the region get updated depending on which one you within?

288

Probably, but not sure if the current code base easily supports it. I don’t currently use OwnTracks.

289

Hi

I have been playing around with OwnTracks (OT), and have managed to successfully set up Recorder and a FrontEnd using HTTP mode, using a Portainer stack (EVERYTHING works.
[Portainer stack at the END of my message if anybody wants to use it]

After installing the Google phone app (Pixel6Pro), I pointed it to http://my_internal_ip:8083/pub, and just like magic it stared recording my location! (Everything works!)

I then installed the Hubitat app + driver, did the OAUTH thing, got my Hubitat URL access token, created a location, and changed to phone app to point to the Hubitat URL. And just like magic I had a new presence device! (Everything works!)

Now (finally) for my question...

I have taken a look at @bptworld's app [Beta] OwnTracker - Map your location with OwnTracks!. I did NOT implement it. Right now, what puts me off it, is:

  • Bryan is no longer supporting/developing it (not an issue if something is rock solid)
  • But mostly because the Google maps API costs are apparently prohibitive (based on the comments in that app's post thread)
  • And to a lesser degree, I LIKE the front-end from my container!

THE MILLION DOLLAR QUESTION IS HOW DO I UPDATE BOTH ENDPOINTS AT THE SAME TIME???

Well, out of the box it is not doable with the phone client... BUT, BUT, but

  • this app, the Hubitat OwnTracks Presence app/device, already gets the exact same packet the native recorder would get, in other words, all the info is already available...

So, what would it take to do a POST request from the hub [read: this app], using the exact same packet received, back to http://my_internal_ip:8083/pub ?

  • There is a DISTINCT security advantage in doing so... I would NOT need to open any ports on my router, NOT do any forwarding, or have a need for something like a reverse proxy!! Everything is internal to my system, as the phone app already securely communicates with the hub, and the Hub and the Recorder are both behind my firewall [read: internal network]

Note: I am not a programmer. To me, Groovy is something that happened in the 70's. But I did look at the code, and eveything appears to be already there to make a POST happen. I just don't know the how-to's.

Any enterprising folks out there want to implement a change? I'll be the guinea-pig...

Thanks
J

Portainer Container:

---
version: '3'
services:
  #https://www.reddit.com/r/selfhosted/comments/raade4/quick_owntracksrecorderindocker_dummies_guide/
  owntracks-recorder:
    container_name: otrecorder
    image: owntracks/recorder
    #command: "--port 0"  # Seems to be needed to disable MQTT   # Old method, do not use.
    environment:
      - OTR_PORT=0  # disables MQTT
      - TZ=America/Edmonton
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /var/lib/docker/volumes/portainer_data/owntracks/config:/config
      - /var/lib/docker/volumes/portainer_data/owntracks/store:/store
    ports:
      - 8083:8083
    restart: unless-stopped

  #https://hub.docker.com/r/owntracks/frontend
  owntracks-ui:
    container_name: otui
    image: owntracks/frontend
    ports:
      - 89:80
    volumes:
      - /var/lib/docker/volumes/portainer_data/owntracks/config/config.js:/usr/share/nginx/html/config/config.js
    environment:
      - SERVER_HOST=otrecorder
      - SERVER_PORT=8083
    restart: unless-stopped
1 Like
290

Hey... Wondering if anyone using this integration has figured out the right balance between battery optimization and utility in owntracks? At least on Android, owntracks came with a default location interval at 900 seconds (15 minutes). Seems kinda useless for most of the use cases I'm thinking of... For example, "turn on the outside lights when I get home" means my radius for "home" needs to be a 15 minute drive! Feels like between all the other crap drawing down my battery and the frequency the twenty other location based services on the phone are requesting that data, that can probably go a LOT lower before I notice the dent in the battery life. Any thoughts on what the sweet spot is? Seems also like you can say "only update after I move a certain distance" which could probably be used to keep it the high frequency updates to essentially only when driving?

291

I would like to know this as well.

292

For what is worth... According to the battery tracking it's used only 1% of my battery in the last 6 hours since I switched it to 60 seconds with a 500m minimum displacement. radiuses are currently set to 1500m (should be mostly over a minute drive time always).. So 4-5% extra on the battery per day of I trust the Android estimates of which app is burning the battery

Edit: Maybe take that with a grain of salt... Just realized I was home for half an hour and the app never updated. Thinking maybe because the default is to ignore updates with accuracy worse than 0m (i.e. Anything that isn't perfect...). Increased that... We'll see if it acts more reliably. I read most of the posts on this thread and not sure if that one was reported or not since it's not an issue with the integration. It was said before, but really does feel like the Android version of owntracks is an after thought.

Edit 2: OK... Regions set to 1500m. Minimum displacement 500m. Location interval 60s... Didn't SEEM like a noticable battery hit. According to Android it's pretty far down the list of offenders on most days.

1 Like
293

Hey, did you figure out?

294

After playing around I found no magic combination that worked 100% of the time. OT was better than HE's and Life 360's but I've actually moved over to @jpage4500 's HD+ presence detection. That's been more reliable than any other so far, not perfect, but certainly the closest to 100% that I have come across. I'll maybe get one miss every couple/few weeks which is usually remedied by simply waking my phone up while I'm in the driveway.

295

I'm playing with this right now. After doing a bunch of digging in the code, the app and the Google API, basically the settings that you need to touch are:

  • ignoreInaccurateLocations: 500 (The phone won't send any locations if the accuracy is above this number -- I've seen spurious accuracies that come in high as 1799.99 which sounds like an error. If leave this at 0, and your defined regions are within 1800m of each other, then you will get an "inregion" event for a bunch of places, all at once. 500 works well to filter off this noise).
  • monitoring: 1 (Significant mode. This allows sending locations based on movement and time together. Move mode sends locations on periodic time intervals which is a battery killer.)
  • locatorPriority: 3 (High power. You need the GPS or you do not get good accuracy)

These need to be dialed in, and I'm still trying to figure out best balance:

  • locatorDisplacement: How many meters the phone needs to move before a location update is sent. Due to jitter on the location, I've found you shouldn't go less than 15m, or you get a bunch of location events even when the phone is stationary. 30m or 50m is probably best, and I'd say you should have this value less than the radius around your region if you want automations to trigger properly (still testing this though).
  • locatorInterval: Maximum reporting interval in seconds, requires locatorDisplacement meters to be moved. Go too high, and then your updates are laggy. Go too low and you burn battery with a lot of updates. NOTE: If locatorDisplacement is high (say 500m) then you can make locatorInterval low (5 seconds) since they work in conjunction with each other

For example, if you set:

  • locatorDisplacement = 5
  • locatorInterval = 50

And you move 20m in 10 seconds, you would only get a location update after the first 5m, and no more until 50 seconds later. You would not get 4 locations updates from the phone.

I am still trying to dial in those two parameters. Seems 30m or 50m and maybe 10s is a good balance, but still testing. :+1:

3 Likes
296

Ok, did more playing, and it seems for me (Pixel 7) these are the settings which have a nice balance of accuracy/battery usage (note, we are using Life 360 as well, and these settings seem to align with about the same battery consumption for both apps):

  • pegLocatorFastestIntervalToInterval: false
  • monitoring : significant
  • locatorPriority: 3
  • locatorDisplacement: 50
  • locatorInterval : 30
  • ignoreInaccurateLocations : 150
  • ignoreStaleLocations : 0.0
  • ping : 30

I did try locator displacement of 30 which allowed triggers further from the house (region radius 75m), but battery usage was higher. Increasing the radius on the regions will improve this. The recommended values from OwnTracks as locatorDisplacement=50m/locatorInterval =30s which does appear to be the sweet spot.

On my Pixel 7 (Android 14), locatorPriority "3" seems to have the same or less power usage than "2", but with better accuracy. Apparently how phones implement "Significant" mode is a bit up to the vendor, so your results may vary. Hope this helps! :+1:

3 Likes
297

Thanks for posting your findings, much appreciated. I haven't played w/my Owntracks settings in quite a while, and look forward to trying out yours on my phone (Samsung S21).

1 Like
298

Thanks for your reporting and suggestions! I have updated my settings and will see how it works on a Samsung Flip 4.

1 Like
299

Thanks +1
I have a P7 and still looking for the sweet spot.
I went downtown the other day and OT thought I was home all day :frowning:
I have a virtual presence in WebCore combining that with HE (but that's not very accurate) and sometimes an ST presence sensor (in my car) which work awesome every time..
My wife's phone, P5, is very spotty too sometimes. It's mostly the arrival that lags.
I usually mirror what's on my P7 in the P5 so we'll see if your testing helps.

1 Like
300

When you look at 'Preferences -> Configuration Management', is 'locatorPriority' '2' or '3'? By default it's '2' which only uses cellular/wifi for accuracy. I was trying '3' which uses GPS and was a lot better.

What about the "App battery usage" on the phone? If it's restricted, then other apps will get spotty locations since the app gets blocked. (Not sure how applicable since this does run foreground in the notifications....)

301

Found something interesting today. I have the app set to 50 m and 30 seconds. What I found was the phone needs move (or a noisy location) that is larger than 50 m and then it sends a location to Hubitat.

When I was driving, I was getting a location every 5-seconds. The distance between locations was relative to how fast I was going (300m@110kph, 120m@88kph, 90m@60kph, 100m@35kph)

Changing to 500m and 30 seconds then I got a location at 500m and around 17 seconds at 110kph. It's a bit unclear how the time setting is actually used, since it seems to do it's own thing behind the scenes based on how far apart locations are being sent.

If you set pegLocatorFastestIntervalToInterval to true, then it seems to send reports at the time interval you set (as long as the phone move the distance value). So 50 m and 30 seconds got me a location o 30-second intervals when moving.

1 Like
302

With the new settings OwnTracks is number 1 in my battery list, using about 12% of my battery since this morning full charge. How did it go for you?

303

Same here! 23% since last charge vs. 15% over last 7 days (which, of course, is affected by the recent increase). If I recall correctly, Owntracks was below 10% before changes.

I'm changing pegLocatorFastestIntervalToInterval to true and will see what happens.