GPSTracker with Life360, OwnTracks and GPSLogger integration

Add-ons Bindings
, ,
142

I am trying to use the binding with owntracks
It works from an android phone with a direct IP on LAN but I can’t connect via myopenhab.

I use the following parameters:
Host: https://home.myopenhab.org/gpstracker/owntracks
Username: As in myopenhab.org
Paswword: As in myopenhab.org

In the owntracks status report I get: Status: HTTP code 401

Thanks

143

That should be enough, first I did not add the home prefix and it also returned a 401, after adding the home to the url it worked, but only after restart of owntracks app.

are you sure you have the latest binding and latest openhab release.

144

Yes, I am on snapshot
Do you use the full user name as in myname@email.com or just myname?

145

Yes full username so user full email.
Then I also have “phone” as device ID and just K my first letter as tracker.

Then all just be OK. Be sure to double check the url it is maybe case sensitive so all lower caps
https://home.myopenhab.org/gpstracker/owntracks

146

I’m using the “Distance from Home” example from the documentation and am having trouble with location accuracy. I started with accuraryThreshold=30 as per the example but got this in the logs:

Location accuracy is below required threshold: 20<30.0

So I changed it to 20 and now I get:

Skip update as location accuracy is above required threshold: 20>=20.0

It won’t update if it’s above and it won’t update if it’s below, so I’m confused!

147

It’s good if it’s below. The first message is just a debug information. The update is only skipped if it equals or it’s above. Leave it on 30 and it’ll work.

1 Like
148

Thanks Gabor.

I’m in the process of upgrading from 2.3 to 2.4 by doing a clean install of 2.4 and I’m trying to avoid using old 1.x bindings. I use Zanzito on my phone for location and was using the Owntracks/Mqttitude binding. I’d almost given up on being able to use this new binding but found an easy way to continue using MQTT via this “gateway” rule:

rule "Owntracks"
when
    Item Mobile_Owntracks changed
then
    val String gpsLoggerUrl = 'http://127.0.0.1:8080/gpstracker/owntracks'
    val String json = (Mobile_Owntracks.state as StringType).toString
    sendHttpPostRequest(gpsLoggerUrl, "application/json", json)
end

The Mobile_Owntracks item is bound to the MQTT topic my phone sends its location data to.

Could be useful for anyone wanting to continue using Owntracks via MQTT with this binding.

149

Just tried to create a pull request on Github to add this information to the README.md of this binding. Maybe this is helpful to other users…

kind regards,

Christoph

1 Like
150

Thanks for improving the documentation but you need to sign the commit.

151

Hi Gabor,

wow, this is a rather high barrier for just changing two lines in a documentation file… the “Edit this page on GitHub” link at the end of the documentation page made me think “hey, improving this page is easy, just a click away”… but now i had to link my Github account to pullapprove.com, upload my public gpg key and at last need to learn how to sign commits on Github. Is there a kind of How-To which explains in detail how to sign a commit?

kind regards,

Christoph

1 Like
152

You need to change your last commit message to include your sign. Here is a link how to do that. I’ve never tried the other way…

153

Hi Guys,

i don’t get this to work. Can somebody help me to figure out, whats wrong?
I’m using openhabian 2.4.0 on a RPi3 and the app “GPSLogger” on my mobile device (tid “XY” for testing).

I’m gone through the GPSTracker-Addon-site over and over and think i’ve done everything right.
If i got it right, i can log to the following URL:
[https://“myopenhabusername”:“password”@home.myopenhab.org/gpstracker/gpslogger]
where “myopenhabusername” and “password” wre my credentials for myopenhab.org

Unfortunately i get an error “unauthorized” everytime.

Unexpected code Response{protocol=http/1.1, code=401, message=Unauthorized, url=https://"myopenhabusername":"password"@home.myopenhab.org/gpstracker/gpslogger}

Unauthorized

Because of this, i can’t see something in the logging except for:

openhab> log:display org.openhab.binding.gpstracker
18:05:18.213 [DEBUG] [acker.internal.handler.TrackerHandler] - Tracker handler created: XY
18:05:18.284 [TRACE] [acker.internal.handler.TrackerHandler] - Existing distance channel for system. No change.

What’s wrong?

Thank you in advance,
Minfred

154

Sorry, but i’m out of this - this is way too much effort for changing just two lines of documentation… you may delete or ignore my pull request.

kind regards,

Christoph

155

@gbicskei first I wanted to thank you for the contribution. Really love this new binding and in general it works very well, much better than previously with the mqtt stuff!

I posted a related issue on the owntracks issue tracker on the potential ability to retry on errors when hitting the http endpoint. I think it would be useful, would be great to add your thoughts to that issue if you have an opinion.

For me at least, it happens often enough that I glance and see a 500 error when owntracks is calling myopenhab which I think retries would fix/help the issue since manually clicking on the “report” button typically clears the error.

156

Hi,
I’m glad you like the binding. In connection with the issue you’ve created I would first check the logs as error 500 means internal server error most probably on your OH instance side. With this retry feature you only mask the problem without examining the root cause.
Cheers

157

I think you may be assuming i didnt try to look into the root cause or know what a 500 means :-)… There were no errors in the logs on my local openhab instance. These errors are hard to debug given I DO NOT have access to the logs on the myopenhab side… 500 is just one of many possible errors that could occur, retry makes sense to me to improve the reliability of the owntracks integration.

I think for home automation to gain momentum it needs to be reliable. There are many other reasons why the myopenhab server may not be reachable or temporarily unavailable. In my opinion having retry logic would improve the overall reliability of the end to end solution resulting in a better user experience.

158

I agree that reliability is very important but if you continuously need to check your phone for the communication status and you need to press a retry button in OT app to make it work in my opinion it doesn’t make the solution reliable…
I still think that re-sending the request is only masking the problem. If I were you I would check this error with the community first. What if you install an another binding tomorrow that also uses HTTP based communication through myopenhab and you get a similar 500 error? With this approach you’ll need another retry button there too…

159

I also see/saw the 500 Error the last days, now it’s clear again.
I checked my local install and there where no errors in the log.
It’s solved by itself without a restart from my side, either on the app or on my openhab install.

This makes me think the issue is in the MyOpenhab site. I don’t know how the internal parts work of MyOpenHab and how it’s forwarded to my local instance and how I need to debug it.
So I’m interested in like you said how to identify these errors correctly, for future HTTP connected services.
(FYI IFTTT had no issues at all, it kept working even when OT was down(i think) ).

160

hi @gbicskei . I agree, clicking on a retry button doesn’t make it reliable. That’s why my recommendation was the client software owntracks should retry on error in my opinion. I noticed something today that I think might be the crux of the issue. For me, I live in a high rise condo, so when I come home I park in the underground. I have been monitoring and believe I notice that when I am underground (with no real cell signal) and owntracks tries to send the request, I get the 500. As soon as i’m back in my condo, hit “report” and the 500 error goes away. I also tried going into the elevator where there is also no signal and hitting the “report” button and then the 500 error will return.

I still feel the same way, there can be numerous other situations. Let’s say there’s a 5 minute network outage, someone restarts the openhab servers, etc. When using owntracks for part of your presence detection, it sucks to lose those region transition events.

Also, just cross posting this comment from the owntracks issue I created as I feel it’s quite important. When a 5xx error occurs, the transition messages are discarded

When an error occurs (5xx,4xx) the message is discarded. This is also true for transition messages.

When there is no connection and the endpoint cannot be reached, delivery is retried until it can be delivered or a 4xx,5xx error is returned

161

Owntracks question - does anyone else use bluetooth BLE beacons for presence? It is very solid / reliable with the exception I need some help figuring out the exact string for the BLE broadcast so I don’t have to broadcast from multiple pi’s in my apartment. With just one pi broadcasting sometimes it will miss intervals and owntracks would send a leave and enter just a minute later.I believe there is something sub optimal with my broadcast settings- likely the frequency or power? but I can’t really find any good documentation on how to adjust that. I swapped out my uuid with xx, major with ‘MM’ and minor with ‘mm’

Adding my other pi’s around the house to the broadcast with the same string solved the problem 100% but I feel it should be sufficient to just use one as I live in an apartment? what type of range can we expect to get out of BLE beacons?

Thanks!

hciconfig hci0 up
hcitool -i hci0 cmd 0x08 0x0008 1E 02 01 1A 1A FF 4C 00 02 15 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx MM MM mm mm 00 00
hcitool -i hci0 cmd 0x08 0x0006 A0 00 A0 00 03 00 00 00 00 00 00 00 00 07 00  
hcitool -i hci0 cmd 0x08 0x000a 01