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.
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
Well, an Android usersā answer would be: you donāt need any iPhone locator binding, what you need is an Android phone 
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).