Pinging you guys explicitly to get some architecture input before starting any unnecessary work
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
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?
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.
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
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.
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.
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.
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.
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
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.
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.
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?
