Ahhh! I asked you to do a "reset to defaults" and it turns the slider in "enable thumbnails" back off. I'll add better indication that thumbnails are disabled instead of a instant off.
1 Like
Bingo! Get the man a cash prize...
Thanks! 
No more 'null':
- triggerSource : Timer
2 Likes
So I posted this over on the github of owntracks, but I believe the hubitat app has to expose the options for us since were are pushing the configuration from hubitat to owntracks.
.
.
.
jpmens commented 8 hours ago
Me: Something I miss was the notifications from friends (Family) leaving or entering regions
You don't need to miss them. If you are permitted to see friends (think MQTT ACL for instance), and you're also permitted to see their "_type": "transition" publishes, you will receive a notification whenever a friend enter or leaves a particular region.
More on this in our Booklet, search for _type=transition.
BTW this applies likewise to your own transitions in/out of geofences.
.
.
.
Is this something you can add in for us to configure and use?
Recorder all set up for me, if I can pry my wife's phone from here I hope to get Owntracks set up on it today or tomorrow.
This is so cool...
The next time my kids visit I'll try to talk them into putting it on their phones!
Me: "It's so cool, I can track you everywhere you go!!"
Them: "Dad, put my phone down and step away...are you off your meds again?!"
Yeah, maybe not. 
Thanks again and again, @lpakula.
3 Likes
Thanks for your integration. Thanks, Thanks and Thanks again!
You actually implemented something that I requested way back in May '23 with @brianwilson's implementation (See: [RELEASE] OwnTracks Presence - #289 by GatVlieg)
Said request being to update Recorder from Hubitat.
I am getting the dreaded 408 error when Hubitat OwnTracks tries to update Recorder.
My Recorder runs in Docker on Open Media Vault (OMV).
I can ping OMV successfully from Hubitat.
I use the standard Play Store version of the OwnTracks app on Android Pixel 6 Pro.
The Recorder URL used in Hubitat OwnTracks works 100% when I use that in my phone in the OwnTracks app; in fact I have been using Recorder since March of '23 in this capacity without any issues.
Is there any better logging you can implement in an attempt to solve the 408 error?
BTW... I liked CowTown better snow free, even when it was a deep freeze!
1 Like
It technically already does that. But I realize the next location message squashes it. If you check the logs, you will see the "Bob left home" type messages, but then in 60-seconds later an location update will change that.
I'll be reworking the driver attributes tonight and see how I can better retain this.
2 Likes
As for logging, that is the only thing the HTTP POST call returns, so its not super helpful.
What is your actual HE SW version? This might be something in the hub side. I'll check if there is HTTP parameter I can pass if it's a network in/out of Hubitat delay issues.
HE SW Version: 2.3.7.145
OwnTracks Version 1.6.14
driverVersion : 1.6.5
To be fair, the 408 error has persisted across the various HE OwnTracks versions you have released.
Your several versions behind, current is 1.6.18...is there a reason you haven't updated to the current version of the Owntracks app/driver? I'd do that first and then report if you're having issues so at least you and the dev are troubleshooting on the same version. Even if the issue has persisted, I'd update.
I will update, but like I said, the error has persisted regardless of the HE Owntracks version in use.
Yup, just always best practice to work from the current version unless the dev tells you to not update...removes variables between versions that can cause unintended confusion. I'm sure that @lpakula will get you sorted.
1 Like
I ran into the same issues several times i didnt really do anthing other than re entering the http adress in the owntracks app in Hubitat follwing the example exact and it solved itself. Might have been a type o my first time dont know but when i manual put in the ip its started to work with no errors.
Updated to the latest version 1.6.18 + driver 1.6.7
IP address is correct; there are no hidden spaces
I am HAPPY to stand corrected...
I no longer have the 408 error!!!!
I have to admit I don't really know what I did right/wrong ... I don't care! It works!!
The post above with the many 408 errors was immediately after I updated to the latest version.
I did not mess with the URL at all.
When I just glanced at the logs an hour later I saw it was OK.
Happiness is... a working URL.
1 Like
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!
