I't can be frustrating I know a minor thing can be the issue. Glad it all worked out.
My +follow changes its coordinates. Is that expected? It now has them to where I am now.
Sorry, I am also confused by the whole +follow thing.
What do you mean by "location is arbitrary"? Can I point it to anywhere on the map? If so, I still don't understand how it works, why we need and if the answer is "that's how iPhones work" why it's not something built-in in the app 
Hey @JustinL ,
Thanks for diving into this discussion! Your insight is greatly appreciated and provides food for thought. Kudos!
Allow me to share some background: I initially migrated from Wink (using Stringify) to SmartThings (using Webcore) to Hubitat (using Webcore), all while using the free version of Life360. Originally, I had limited access to a basic presence status: present or not present. So, I don’t have a great perspective on Life360 functionality; thanks for providing the information about it. With OwnTracks on Hubitat, I've found a treasure trove of information. Therefore, I'm trying to leverage OwnTracks in Webcore automations to the best benefit.
Regarding the "current region" field, just to clarify, I wasn't proposing its addition. My reference was to the Current States, [location]. As of my last check (unless there have been recent updates), it currently reports when a user is in a Region. When the user leaves that Region, it switches to reporting distance from home. I was curious about the necessity of duplicating this information, given that distance from home is already reported in Current States, [distanceFromHome]. Since [location] seems geared toward Regions, I thought about asking to expand its reporting capabilities around Regions and removing distance from home. For example, when transitioning from "home" to "work," it could display "Home" to "Left home" to "Work," all tied to Regions.
On the topic of displaying the "resolved address" when the user is not at a named location (Region?), I might be missing something, as I'm not entirely clear on what a "resolved address" entails. I'm not quite sure I see the value of having it also appear in the Current States, [location]. While having a separate Current State for the current address could be interesting, determining rules for capturing it and deciding on display length might pose challenges, I would think. Feel free to elaborate if I've misunderstood your point.
Your perspective is greatly appreciated, and ultimately, the decision lies with @lpakula as it's eir project. I was just making a suggestion. I'm open to whatever is decided, and I'll adapt accordingly. Thanks again for the perspectives!
Cheers,
David
1 Like
Ah, I see. That's certainly different from Life360, but an interesting idea. I'd probably favor having the "location" actually reflect the current location rather than what the last location was (and no indication of what the current location actually is). Life360 did have a previousAddress state, so having a "lastLocation" state might accomplish what you're wanting to do while still accomodating all the previous life360 users. So, the "lastLocation" could be "Home" while the "location" is either a different named region or the address obtained from a reverse geocode lookup of the coordinates.
Like you, though, I'll make whatever work. @lpakula is doing a great job with this!
Victory is sweet indeed.
Hi all - I've been using Owntracks & Brian's version of this to power my "clock that tells place rather than time":
And it's working pretty well, though not perfectly - it's driven by a bunch of locations (replicated for each person) and then some webcore code to control the servos
This new fork looks AMAZING, and I think it makes sense for me to migrate to it, as it should give me central admin, and reduced complexity.
Can anyone see any obvious "gotchas"? Owntracks is running on a mixture of versions of Android and iOS.
The only quirk I can see is that there's a "friend" category, which means different things for different people, but I can deal with that in the webcore piston....
It looks exciting!!
9 Likes
Damn! Just... damn!
1 Like
IT 101... outwait the customer, and they will solve their own problems. 
If you see that again, can you check the memory on the hub? I've never gotten the 408 errors, but have seen slow downs when memory was low (which might be causing this?)
2 Likes
That's AWESOME! No real gotchas, it will work in a mixed mobile environment. A "friend" apparently is someone you'd share your hub link with.
Exactly...I've offered to move in w/his family if it means I can use the clock. 
Ok, from @JJsLegacy comment it makes sense now. The OwnTracks iOS app goes into more of a sleep mode that impacts the update of locations.
The the iOS app as a region named "+follow", with a radius>0, then it will assign the phone's current location to that region. That forces the phone to wake up more often and check if you left that region (which can never happen, since it keeps updating your current location to the region coordinates).
The time/distance is how the Android locator service works. Of course the million dollar question is why the iOS OT app devs just didn't put a slider for that would just do that instead of requiring this fake region!
1 Like
@JJsLegacy if you check your Hub logs for the OwnTracks device name that you were seeing the location move on, do you see a "OwnTracks - has arrived at +follow" (or left +follow?)
Just wondering if I need to filter that from the regions message.
One key takeaway from that being that the +follow region can simply be ignored by Android users, correct?
Yes that is correct. Unfortunate spam in your regions so that those "inferior iPhone" users can play nice with the OwnTracks HE app. 
3 Likes
Oooooo...Android smack down on iOS, love it.
3 Likes
I got it, thanks! Seems like horrible UX for me and absolutely not user-friendly, but I think I got the jist.
If I understand correctly, were you so kind as to automatically create the region for us? So, there is nothing else for us to do? It should just work?
Ok, maybe inferior was harsh.
2 Likes
As long as you created a "home" location and saved that in the HE app, that is all you'd need to do.
The iOS mobile app is "odd" from my perspective. Most iOS stuff is really easy to understand/follow which ends up in minimal support calls. That app has WAY MORE configurations than the Android one (which is odd), and super not intuitive.
The HE app I'm still trying to work through how to make it easier while dealing with the limitations of Groovy.
1 Like
When starting the docker container I get the following
- version 0.9.6 starting with STORAGEDIR=/store
- gcache_open: mdb_env_open: Out of memory
- storage_init(): gc is NULL
- gcache_open: mdb_env_open: Out of memory
- gcache_open: mdb_env_open: Out of memory
- gcache_open: mdb_env_open: Out of memory
- gcache_open: mdb_env_open: Out of memory
- gcache_open: mdb_env_open: Out of memory
- Not using MQTT: disabled by port=0
- HTTP listener started on 0.0.0.0:8083, without browser-apikey
- HTTP prefix is unset
- Using storage at /store with precision 7
And I get nothing going to IP:8083
