Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mqtt / http differences #774

Open
vinistoisr opened this issue Dec 31, 2019 · 5 comments
Open

mqtt / http differences #774

vinistoisr opened this issue Dec 31, 2019 · 5 comments

Comments

@vinistoisr
Copy link

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?

@jpmens jpmens transferred this issue from owntracks/talk Dec 31, 2019
@jpmens
Copy link
Member

jpmens commented Dec 31, 2019

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.

@vinistoisr
Copy link
Author

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?

@jpmens
Copy link
Member

jpmens commented Dec 31, 2019

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
Copy link
Member

jpmens commented Dec 31, 2019

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?

@vinistoisr
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants