New binding for mqttitude / owntracks

Hi @Kai , hi @teichsta ,

Pinging you guys explicitly to get some architecture input before starting any unnecessary work :smiling_imp:

I spent some time today trying to get owntracks presence detection to work with OH2. The biggest hurdle was finding out why the mqttitude.jar was not included in the 2.0.0 addons package :smile:

Would you guys be o.k. with starting off new OH2 binding, maybe namespaced org.openhab.binding.owntracks ? Or should I work on the “old” OH1 binding and try to get that to run and play nicely with the current OH2 runtime?


Hi Hakan,

I wrote the original Mqttitude binding - so firstly thanks for taking on this job (which has been on my TODO list for months!). I would definitely re-name the binding to owntracks, the old Mqttitude name is very much old-news and not in use anywhere now.

Other than that it should be a pretty simple port - the binding itself is pretty basic. I think we should still support both modes of operation, and it might be nice if the binding also supported the new Location item type for parsing out the lat/lon coordinates from an Owntracks location publish.

I am going to be out of action for the next month, extended work trip with no access to my openHAB system, but feel free to ask any questions and I will answer them as best I can.


Hi Ben,

Sorry, I was half-asleep yesterday while writing this, else I could have found that you were the original author. I just went by the committers in the git repo :blush:

Thanks for your blessing, I will go ahead and set up my repo and branch, and hopefully understand how to write a mqtt / paho client fast enough.


You shouldn’t need to write any sort of MQTT client, there will hopefully
be an MQTT IO binding ready for you to use.

Yes, there is, right here:

Thank you both for your work!

Thinking about the proper modeling… What exactly would constitute a “Thing” in the OwnTracks context?

I seem to understand that a “Thing” is a device that is attached to the OH2 server. In that case, the MQTT server holding the messages could be considered a “Thing”. That server could then be queried for “Items” like the user holding a mobile device or the mobile device itself.

On the other hand, the mobile device could be considered the “Thing”, which then holds “Items” like the location of the device or the waypoints / geofence areas configured for it.

Hi Hakan,

I am not yet familiar with the details of OwnTracks, but in general a Thing is somehow an optional and configurable unit that can be added to your system. So the MQTT server should definitely be modelled as a Thing as you need to set it up with the right hostname, credentials etc. As there is not a fixed set of features (=channels) it provides, you would not be able to define them statically (which should be preferred). So possibly, you can use the server as a Bridge (a special kind of Thing) and discover further Things that are attached to your Bridge, which would then be the mobile devices - for which you probably can define a fixed set of channels like location, name, geofence, etc.

Just my 2 cents,

I don’t know much about the new OH2 world, but based on what Kai has said, and what I know about Owntracks/MQTT it sounds like you would define a broker thing which would include the hostname, username, password etc, and one extra property, the base topic. Once you have the base topic you can then do a simple wildcard subscription (e.g. /basetopic/+/+) to get a dynamic list of device things. And from there create your static channels per device.

So in theory to setup the Owntracks binding all you would have to do is define the broker thing and everything else would be auto-created.

NOTE: the binding would only be able to auto-detect the devices if they are publishing retained messages, otherwise it would have to wait until a device publishes a location AFTER the binding is subscribed to the base topic.

Hi Kai,

I am still trying to understand OSGI, so please allow me a few stupid questions :blush:

I believe that I should use the MqttService from that bundle. How do I obtain a reference to a service from another bundle? In spring based containers, I would use some kind of wiring (annotation or XML based), but with OSGI, I have no idea even where to start reading.

I tried “References -> Workspace” in Eclipse, but that did not find any references except the logger object inside the class itself :smile:


Hi Hakan,
When I started th WeMo binding, a good starting point fo me was to have a look into the hue binding.
You could also have a look into the OH2 Sonos Binding where you can find references to the io.transport.upnp bundle.


openHAB uses OSGi Declarative Services for this (it is a kind of Spring DM configuration). See e.g. this example.

A tutorial about OSGi DS can be found at


Did this go any further? Or has a replacement popped up for OH2? I can’t see anything in the extensions.

Nope, the project fell into a coma as I got sidetracked by some other things.

As my understanding of the OH2 architecture increased in the meantime, I will take it up again in the near future, though.

1 Like

I don’t suppose this has had any more action on it? I’m not capable of picking up the reigns and doing it myself i’m afraid, but will put my hand up to say that it would be appreciated.

If you’re not worried about the native OH2 build with auto discovery etc, you can use the 1.9 build in OH2 in the same way as we did for openHAB 1.8. I have been using it for some time without any issues.

1 Like

Ok, great. Thanks. I’ll have to have a hunt around for the 1.9 build.

You can find a snapshot in the OH1 addons section on Cloudbees -

Thanks. Which config settings do I need to put in the OH2 openhab.cfg file? Just the mqttitude stuff, or the mqtt stuff, too?

You don’t need anything in the openhab.cfg file unless you want to identify home/set up geofences etc - I don’t do these in Owntracks and do my processing within openHAB and so haven’t tried any of the config file entries. For simple receiving of location messages, it should work out of the box assuming your mqtt binding is working correctly.

Hi folks,
Anyone had luck with using 1.9 binding in OH2? Also, why 1.x version is not included in OH2 as legacy binding, are there any reasons for that?