Configuring mosquitto

Continuing the discussion from iPhone Locator Binding:

I put my mosquitto server listening on port 8883 (TLS) on the public Internet, but use authentication. openHAB connects to mosquitto locally on port 1883 (no TLS). With ddclient my server is at a constantly accessible FQDN, so OwnTracks can always connect and publish.

1 Like

When I was using MQTTitude I punched a hole through my firewall to allow connections to my Mosquitto server from the Internet and then set up Mosquitto to use SSL/TLS and require a username and password for incoming connections, very much like watou. It isn’t bulletproof but it is better than nothing.

I was only using MQTTitude to detect when I and my wife was home and it ended up being cleaner to just use the Network Health binding and writing a script based on this tutorial and a script I wrote for reporting door sensors (because my wife’s iPhone keeps dropping off the network) which works far more reliably than MQTTitude did.

I completely understand the desire for a native iPhone Locator binding because everything I’ve tried except for the Bluetooth detection has worked like a charm on Android but unreliably on the iPhone.

Rich

One of the alternative ways to have a secure mqtt with the internet is to use an additional mqtt server already on the internet.

There is cloudmqtt.com service which is free, you let your internet based devices connect to it.
Then you also setup your local, behind the firewall, mosquitto to connect to the cloudmqtt and subscribe it to the updates.

This way you don’t need to punch holes in your firewall and still have the benefit of connecting devices outside your firewall

2 Likes

Well, an Android users’ answer would be: you don’t need any iPhone locator binding, what you need is an Android phone :smile: preferrably a Cyanogenmod based one, to also keep Google’s greedy hands off your data.

I, too, run @watou’s setup, and it works pretty well. The only unreliable thing is when my phone is either being switched off, cut off from network, or does not have GPS coverage inside a building, it’s dropping out of the corresponding region. Maybe we can think of a better algorithm to implement in the mqttitude binding (and/or in OH rules) to handle these cases.

I’d like to encourage you to stick with owntracks and help improve its reliability because it works on both, iPhone AND Android, and it for sure enables you to do things beyond what the network-health/bluetooth/… methods of presence detection allow for, like say turn on your room’s heating already when you’re leaving work (and not just on arrival).

I am in the process of installing openhab but already have the OwnTracks app running on my Nexus 5, publishing to a mosquitto broker at home. (It doesn’t seem to do anything with my waypoints, but that’s another issue, sigh…) There is only one mosquitto listener bound to both external and internal IPs on my server, using TLS with username/password auth.

Does anyone know if the openhab MQTT binding supports TLS? Or will I need to configure a second mosquitto listener on the internal subnet, like @watou and @mstormi? I looked at the wiki but couldn’t really tell. It mentions “ssl://” URLs but I am unsophisticated enough that I don’t really understand if ssl/tls are interchangeable in this context.

I set up two listeners in mosquitto. One is bound to a port that is not exposed to the Internet and it is unencrypted. You can further restrict it if you want. This is the one openHAB uses to communicate through. The second listener is configured with TLS and is on a port exposed to the Internet for OwnTracks. Both listeners requires a username and password.

The openhab.cfg says it supports an ssl:// URL but I don’t see a place to enter the path to cert files so I doubt you can use it with self signed certs. But if you have mosquitto running with a certs signed by an official trusted CA it might work.

Rich

Actually mqttitude binding seems to be using TLS per default (for tcp:// URLs), so you don’t need another listener… just connect to the one you connect with your owntracks clients to from the outside, too.
You don’t need TLS at all here. Why would you want to encrypt that session if server (mosquitto) and client (mqttitude binding) run on the same box ? Use user based authentication (I’ve recently updated the owntracks booklet broker section to explain that, too). Or IP based ACL.

To complete, while you cannot use client certificate based authentication to authenticate the binding against mosquitto (because that indeed would require telling the binding about the client cert it would need to do for that, and I, too, haven’t seen an option to do that), you can still TLS-encrypt the session. Encrypting requires a server-side (i.e. mosquitto) cert only.

Yes, the question is academic in some sense, because as you point out there is no reason to use TLS on your local net. I do want TLS encryption (not authentication) between my phone and server. So it is just a question of whether you need to define a second listener, or not. I’ll try with TLS first and see how it goes. Right now I have bigger problems in that the Android app isn’t triggering waypoints. I guess most everyone here is using the iOS version of OwnTracks?

Err, no. I’d guess 50:50 or closer to the ratio seen on the market (80:20 Android:iphone, I just read somewhere).
Anyway, as already mentioned, I (on Android) do still have issues with waypoint publishing, too.
Just for a quick check:
Are you using the latest release (just released to play store some days ago), have you set the waypoints to ‘share’, do you use the region based definition, and have you read about the iPhone specifics in the owntracks booklet?
There’s an own owntracks forum and Github space, which is probably the better place to ask for help.

I’m currently discussing my issues with the creators of owntracks and the mqttitude binding there, too.

Hm, I guess I’m unusually unlucky then. I haven’t been able to get a single waypoint transition yet, and yes, I’ve checked all the obvious things. The owntracks Android expert, Alexander Rust, is also having issues (#175 on the owntracks/android repo on github).