Best practice for new Android setup

[grumpazoid]

Hi and thanks for what looks like an excellent project. I am up and running with my phone running Android 7 using MQTT.

Reading the docs, it says I should be using HTTP mode for anything greater than Android 6. If I am correct, this would mean the phone only receives data when it publishes it's own data and receives back some sort of HTTP response containing data of other users etc?

I already run MQTT and Node Red for my home automation, so the MQTT option makes sense to me. It would be great if someone could clarify the situation a bit further. I can set up a HTTP endpoint in node red but then I somehow have to publish data back to apps. Maybe I should just test with MQTT for phone reliability?

One other thing I am struggling to understand - What is are the pros and cons of using the MQTT websockets option as opposed to plain MQTT.

Thanks

[growse]

Hi! :wave:

Reading the docs, it says I should be using HTTP mode for anything greater than Android 6.

They do say this, but I think it's possibly worth revising as reality is more subtle and nuanced than this. The overall guidance is valid - recent versions of Android are getting more and more aggressive in restricting what can be done in the background and with long-running services. As you're likely aware, MQTT relies on a long-lived connection, which means that you need an active process keeping the socket alive.

What complicates this is that different device vendors often fiddle with Android's behaviour, meaning that the behaviour you see on a Pixel device might differ from what you see on (for example) a Samsung device. It seems like some vendors are much more aggressive about killing background tasks and services, presumably in an effort to make their battery marketing stats seem more impressive. Some vendors are very well-known for doing this (here's a whole website dedicated to this nonsense: https://dontkillmyapp.com/).

Personally, I've been using MQTT mode on the latest Pixel devices for years without any issues. The vanilla, default, not-fiddled-with Android framework is more than capable of keeping the service (and therefore the socket) alive. There's also mechanisms that will effectively jump-start the service every 15 minutes if it has been killed for whatever reason, so I've never really noticed an issue with dropped locations, or missing updates from the broker.

Ultimately, this is a thing to try with your device and see what happens. Your mileage may vary. Unfortunately I can't give more specific advice, simply because every single device / Android version may do something different, and the optimal combination of battery whitelisting / modes / settings may therefore be different. I only have my personal device and the emulators to test on, and this is the baseline I try to keep working reasonably.

You're right about HTTP mode only receiving updates from upstream in response to a location being posted.

One other thing I am struggling to understand - What is are the pros and cons of using the MQTT websockets option as opposed to plain MQTT.

In my experience, websockets may have some advantages under certain circumstances. Because it operates over HTTPS, it may be less restricted by the network - in other words if you're on a wifi or mobile network that blocks port 8883, you might find that a Websocket connection on port 443 is still allowed.

[grumpazoid]

@growse Many thanks for your fast and detailed response.

I have now installed on a second family phone and will continue down the MQTT path for now. It looks like I have no need for web sockets at the moment so that is one less complication.

At the moment, the app log on my (older) phone is currently being swamped by error messages so will search in the app section for a solution.

Maybe the next step is to try the recording server?

[growse]

You can use the recording server, as that'll help keep a log of what locations your devices send. If you just want to see the sorts of messages and frequency that locations are being published, mosquitto_sub is a simpler way of doing this.

[jpmens]

@grumpazoid any MQTT client will be able to show you what's going on, as @growse rightly points out. The Recorder is designed for long-term data storage and operates hand-in-hand with our Frontend which is a Web-based interface to the Recorder's REST API.

The format of the JSON payloads your phone will publish are documented in our Booklet.

[grumpazoid]

@growse @jpmens I use MQTT explorer on my windows PC to views the MQTT messages - All seems well. What I meant was the recorder seems like the next thing to test out now I have the app up and running. I look forward to some more testing!

[jpmens]

Closing as responded to.