I want to find out if the mqtt binding has device discovery
Since the MQTT binding is a “protocol” binding, meaning that it deals with messages on topics being published and subscribed, it is not the place to have an understanding of Things that would represent concrete, real-world objects. Therefore, it is not the place to discover what a device is.
By comparison, the MQTTitude binding is an example of a binding that uses MQTT as a transport to represent concrete things (like waypoints and mobile devices), so it would be a binding that could potentially be ported to OH2 for the purpose of discovering those concrete things. You or others could write a binding along those lines that used MQTT as a transport, but had in mind concrete Things that could be discovered.
I’ve been tinkering with OH2 mqtt binding, and indeed I would assume it should contain discovery in some way.
I’ve always disliked that you need to type/remember each mqtt topic, hence I would like discovery to find each new topic as a thing.
Unfortunately there is still quite some work to be done to get the binding running stable.
Anyway, what I have can be found here… mostly based on the work of marcus
I would also really appreciate a MQTT auto discover function. Sadly I am not in the position to help coding it , but I can certainly offer my system to test functions (A lot of topics, multiple messages per second).
I can send you a compiled version for testing.
Note that I’ve focused on receiving messages & discovery, not on other parts (like sending etc)
The forum does not let me attach it, so if you want that, send a pm with your emailaddress and I’ll mail it.
As AOL once stated: “you’ve got mail”
For others that want to give a try for this very alpha version
you can download it here.
To get going:
- Save it to the addons folder
- Go to paperUI configuration and click the plus and add a mqtt bridge
Then it will start automatically with discovering new things for each received topic.
(use commandline ’ smarthome discovery clear ’ to remove all discovered items in one go, when you’ve defined the ones you need)
The current version has a channel for each data type. Work in progress to make things that cover multiple mqtt topics. So currently each mqtt topic became a new thing. I plan to remove that and make each topic a channel of a thing.
e.g. if you have 2 topics \solar\power and \solar\volt it would become 1 topic ‘solar’ with 2 channels (power and volt)
This is kind of working (e.g. if you now make a manual thing with for a topic /solar/# it works like that) but unfortunately the paper UI and basic UI do not fully support dynamic channels yet, hence you can only enable the channels with smarthome console commands
For all interested ones, please find here the next alpha release for the OH2 mqtt binding
Main updates in this version
- Additional bridge configuration options
- Configurable topic for discovery
- Multiple mqtt topics per Thing
- Fixed the topic naming
- Online/offline updated based on broker connection
Note: As the UI’s don’t support dynamic channels very well, you will need to enable the new channels with the command line. In the messages the right command is displayed: e.g.
2016-01-14 00:18:43.125 [INFO ] [e.s.b.mqtt.handler.MqttHandler:460 ] - Dynamic channels are not visible in UI, use command line to enable : smarthome setup enableChannel mqtt:topic:SolarEnergy:SolarEnergyT
Next step is to have the dynamic channels allow you to configure the right datatype. (and more important… the UI to allow this)
for anyone trying this in the new karaf build:
you need to enable the mqtt io:
also, for the channel enable, it seems you don’t need to use the ‘smarhome’ command anymore, just setup enableChannel e.g.
openhab> setup enableChannel mqtt:topic:VcSensor1:VcSensor1Value The channel "mqtt:topic:VcSensor1:VcSensor1Value" was enabled. openhab>
Any progress with the Mqtt binding?
Unfortunately I bumped into few issues that I did not know how to resolve.
I’ve some ideas how to fix them now, but lack time. I May give it another shot
@marcel_verpaalen - does your latest message mean this no longer works?
I just came across a HomeAssistant article of them adding MQTT Discovery (https://home-assistant.io/docs/mqtt/discovery/). This would be a huge win IMO. I’ve been migrating all of my devices to MQTT/WIFI and the stability and responsiveness over z-wave and insteon is light years.
The discovery I build in the oh2 mqtt binding works remarkably similar.
You give the base topic, and it will discover any mqtt topic as a thing or thing channel
The unresolved issues are around handing the various data types in a nice way. (Meaning not creating a channel for each data type).
The second issue to resolve its around deleting dynamic channels
I invite everybody to participate in the related Eclipse Smarthome (ESH) Github issue:
Improved core Mqtt support
Mqtt is only a second class citizen in ESH until now. I made a big refactoring of the core mqtt transport bundle and on top of that, we can implement some Mqtt bindings to improve the way of configuring broker connections, and bind Mqtt broker topics to Things.
Configure broker connections in PaperUI
I’m working on a binding to configure broker connections in ESH via Things right now, which hopefully solves all problems people have at the moment with configuring a broker connection in the first place.
More to come hopefully
It’s would be awesome if there could be a joined effort to develop:
- A generic Mqtt Binding to bind a topic (state/command) to a Thing,
- specific bindings for Mqtt Homie, EasyESP (Openhab-Mqtt protocol),
- a Mqtt<–>Eventbus binding (for replication to other ESH instances for example).
I thing it’s a good idea to implement 1) and 3) in the ESH repository, and 2) in the Openhab repository.
Generic Mqtt Binding
The already mentioned https://github.com/marcelrv/smarthome/tree/mqtt/extensions/binding/org.eclipse.smarthome.binding.mqtt is a good start for 1) if slimmed down. The easiest way for the beginning would be that the user selects a Mqtt Broker connections (bridge) and manually the type of a Thing (String, Switch, Contact, Ranged-int, etc). A thing would have one channel only and needs the state/command topic to be configured. Auto discovery can still be added at a later state.
I would even say, that auto-discovery for the generic Mqtt Binding is not useful at all, and is more necessary and possible for vendor Mqtt IoT specifications (where a clear way of enumerating topics is provided and semantics are defined).