android icon indicating copy to clipboard operation
android copied to clipboard

mqtt / http differences

Open vinistoisr opened this issue 5 years ago • 5 comments

I configured two android devices in mqtt over wss mode using an mqtt broker with a basic-auth http frontend, served behind traefik w/ lets encrypt certs. This worked at first, and we could instantly see each other on the apps, and get notifications when we enter/leave zones.

But then the instability came. It started when I used the webapp to set cards to the users. Suddenly the mqtt connection goes haywire and the mqtt server is flooded with last will messages, and the client goes into a reconnect loop. Once in awhile it will have time to transmit something useful.

So, this ends up killing our batteries really quickly.

Switching to http seems to be the answer, so I setup recorder also behind traefik for ssl, pointing to 8083. traefik handles the basic auth and passes the user to recorder. This also works well on both phones, no reconnects anymore.

But the issue on the http side is that we didn't show up on each other's friends list like on the mqtt side without editing the LMDB database. Once we got that figured out, and the json-formatted cards into the store, we are almost there!

Except we can only see each other's cards in the android app, not our own. also, the waypoints seem to trigger notifications for the friends. Why would that be?

All this makes it significantly more difficult to get things working reliably. Is there a way we could have it behave the same on HTTP mode as it does on MQTT mode?

vinistoisr avatar Dec 31 '19 08:12 vinistoisr

There are some subtle differences between MQTT and HTTP modes; we are aware of those, but haven't had an incentive to change that.

Is there a reason you haven't used plain MQTT (by which I mean not WSS)? That is the method with which we've most experience I would say, and thus the most stable.

jpmens avatar Dec 31 '19 10:12 jpmens

plain mqtt isn't secure is the most obvious reason. Also I'd like to use owntracks in a wider project which really requires deployment behind weird NAT situations and from corporate networks. For that I really need ssl on 443.

I built w/ lua (any reason this can't be default?) and got the http:mqtt script in place, so that helps compatibility on the internal network.

The only major issue left is the device see each others cards but not their own card. Any hints on that one?

vinistoisr avatar Dec 31 '19 10:12 vinistoisr

By plain MQTT I mean MQTT over TCP (not websockets), of course TLS protected, which the apps can do.

Own cards are possible, IIRC, by adding yourself to the LMDB datastore.

jpmens avatar Dec 31 '19 10:12 jpmens

I'd like to use owntracks in a wider project

Maybe you tell us about this, and tell us how you can help us help you?

jpmens avatar Dec 31 '19 10:12 jpmens

Regarding mqtt over tls, yes in theory if I listen on port 443, that should work. In practice, I couldn't get it working with my proxy. I also took note of the section in the docs recommending http mode for Android, and definitely it's much more reliable.

I'm interested in pushing more data in the http payload, like gpio or other phone sensor data (mute switch state), and attach it to the card.

I still can't figure out how to get my own card returned, even though I'm in the lmdb.

vinistoisr avatar Dec 31 '19 20:12 vinistoisr