Yes, there is, right here: https://github.com/eclipse/smarthome/tree/master/bundles/io/org.eclipse.smarthome.io.transport.mqtt
Thank you both for your work!
Kai
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,
Kai
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 
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 
Regards,
Hakan
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.
Best
Hans-Jörg
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 OSGi Modularity and Services - Tutorial.
Regards,
Kai
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 - https://openhab.ci.cloudbees.com/job/openHAB1-Addons/ws/bundles/binding/org.openhab.binding.mqttitude/target/org.openhab.binding.mqttitude-1.9.0-SNAPSHOT.jar
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?
Yes, it works fine in OH2. I guess the reason it is not (yet) included into the OH2 distro is that no-one has got around to adding the small changes so that it gets included (http://docs.openhab.org/developers/development/compatibilitylayer.html#how-to-add-a-successfully-tested-1x-add-on-to-the-distribution).
All,
I have problems gettting my owntracks again (it used to run one week ago).
I just upgraded to the latest snapshot and obviously there is no connection from my mosquitto to OH2 any more.
Please see also:
I have installed:
binding-mqttitude1
binding-mqtt
action.mqtt
Mosquitto is running fine and my smartphone is connected to it
No one?
You will need to go through a process of elimination to find out what the issue is. Certainly the binding seems to work for myself and others I know using the latest snapshot.
Some things to look at:
-
Subscribe to the
owntracks/#(remember to use the-vargument as well to see a more verbose response) the topic on your mqtt broker and make sure that you are seeing actual messages -
If all is coming through as expected, check your bindings on openHAB using the Karaf console. Use
list | grep -i mqttand make sure that you are seeing only the bindings you expect (i.e. openHAB has not loaded multiple versions of a binding). On my system, it is showing:openhab> list | grep -i mqtt 201 | Active | 80 | 1.9.0.201612240210 | openHAB MQTT Binding 202 | Active | 80 | 1.9.0.201612240210 | openHAB Mqttitude Binding 209 | Active | 80 | 1.9.0.201612240210 | openHAB MQTT Transport Bundle -
If the bindings are ok, then use an item that receives ALL the owntracks related mqtt messages (and not just the ones for your individual phone/entry/exit etc). E.g. your item could be defined as:
String Owntracks_Location_Raw "Owntracks Location raw location" (Owntracks) { mqtt="<[mosquitto:owntracks/#:state:default"}
I hope the above helps.