Traccar Requests

[robshep]

Hi,

I've just loaded up the OwnTracks iOS app (great job) and pointed it to my Traccar server.

I'm looking at network level trace and the traccar app doesn't ever seem to send a { _type: location, ... } request.

Only {"_type":"dump","configuration":{ ...

These are responded with a 404 (as it doesn't contain _type: location )

Will the app need a positive response to the dump before it proceeds with location?

I've wandered round with it and it has a GPS fix OK.

Thanks

Rob

[jpmens]

You write

traccar app doesn't

I assume you mean "The OwnTracks app doesn't".

Tell us a bit more about how you've configured Traccar and the settings you've used on the OwnTracks app.

[robshep]

Whoops, sorry - yes of course, the OwnTracks app.

Thanks. Traccar is a default setup from the docker image. Brand new, staging to test this out.
I can push a fake OwnTracks message at the correct port to get it to update the screen.

curl -X POST -H "Content-Type: application/json" -d '{"_type":"location", "lat":53, "lon":-4, "tid":"1", "tst": 1613742255}' http://my.traccar.example.com:5144

So I know traccar is setup OK.

But looking at the output of tcpdump to see the requests incoming from the OwnTracks iOS app I only see {type: _dump} messages

Thanks

[jpmens]

What happens when you press on the "share" icon in OwnTracks? That should produce a _type: location. (You shouldn't really be seeing _dump at all ...)

[ckrey]

Yes, traccar does reject {"_type":"dump","configuration":{ .... Probably you asked the OwnTracks App to publish the configuration within the Settings menu.

And yes, you are correct, the app waits for a positive response before it continues to the next message.

You may either delete and reinstall the app, or change the mode from HTTP to MQTT and back. This will clear the message queue.

[robshep]

Thank you.

I'm certain I left the settings as default and only changed the connection type to HTTP from MQTT.

I turned off all the settings down at the bottom of the screen and ensured the URL was OK.
Then flipped to MQTT then Back to HTTP and it has worked fine.

I haven't ventured outside yet as the weather is dreadful but once I start moving will it continue to push to the HTTP endpoint automatically? or do I have to share each time?

Thanks again for your help, it is appreciated.

Rob

[jpmens]

OwnTracks will continue to publish as soon as it detects movement and can connect to your (Traccar)-endpoint. This is assuming you've got the app in Significant changes mode (switchable at the top of the map)

[robshep]

Thank you. Yes I've found the description of these modes in the excellent documentation.
I can't find what all the toggles down at the bottom of the setting page do.
I have them all off, but don't know if i'm missing out on something fantastical?
Thanks again
Rob

[jpmens]

Ah, the toggles at the bottom. Those are in the not so excellent documentation :-)

Toggle at will: they just flip the distinct map modes (satellite, hybrid, etc.) As soon as you get the hang of them, if you wish to improve our world, you might want to document them and submit a merge request to our Booket. Our eternal gratitude, and all that. :-)

[robshep]

Cheers,
Actually I should have explained better that I meant the expert setting screen.

These ones in the image below.

I recognise that some of these are MQTT specific but at least one of these was the “dump” thing that prohibited location updates. I don’t know which that was as I turned them all off. Just wondering if any others are useful.

Thanks

[jpmens]

That's black magic; don't touch.

Honestly, please don't unless you have something specific. You're right in as much as most of them affect MQTT. cmd should be documented (allows remote commands to be sent to OwnTracks on the device), locked will lock the settings, extendedData sends battery level, barometric pressure, etc. along in a location publish.

[robshep]

Understood.
One of them was responsible for the {_type: "dump", ... } issue - and by default some were toggled on and some toggled off.
I turned them all off. is this workable?
I need to try a few friends handsets and so would be useful to know which is responsible for emitting {_type: "dump", ... } and I can ensure that one is disabled.

Thanks

[jpmens]

{"_type":"dump" was produced by tapping on Publish Settings. None of these exports/publish features are available with Traccar. (IIRC we wanted to catch illegal payloads in the Traccar connector but the authors didn't like our doing so ...)

[jpmens]

And as an explanation: dump produces a JSON object with all settings (except password), all configured regions, etc. This can be used by applications to obtain a "backup" of the OwnTracks settings, and our Recorder uses that.

[robshep]

Understood.

The traccar connector does just reject payloads it can't handle with a 400 - the sticking point for me was that the iOS app kept it queued and retried. On the whole almost all 4xx shouldn't be retried without modification, so you could just bin them?

The danger I have is if any of my group clicks "publish" by accident or from being curious, a dump message will be queued that won't get cleared without a non-trivial overhaul.

I'll just brief them for now.

Thank you for the support.

[jpmens]

@robshep this has been implemented on iOS and will be in our next release. Thank you for the suggestion.