Interesting concept. I take it that the discovery topic idea is something invented by HA, as I’ve never seen it referenced elsewhere.
Can you give me some real life examples of devices that would allow the needed MQTT topic configuration to work with this? Or are these more typically custom applications?
I think most widely used in HA, but OpenHab and others also support it. There’s also the Homie convention for IoT MQTT messaging. https://homieiot.github.io/
It is a lot of custom or semi-custom integrations that leverage this, but a few examples just from around my house:
Thanks. This should actually be pretty easy to implement, so I’ll give it a shot!
Question for you: are these integrations one-way only? From what I can gather from the HA documentation, that appears to be the case. I don’t see any reference to messages going from HA to the device, only messages from the device going to HA.
Control is definitely possible. You’ll see that the pattern is that for things like switches, there is both a “state_topic” and a “command_topic”. State comes from device to the MQTT broker and any apps/controllers to show the current state. Commands go from one or more controllers, through the broker, to the device. Commands when processed then get reflected back to the state topic.
I have a driver that reproduces the HA MQTT Discovery mechanism. It was fairly easy to reproduce; hopefully I won’t get a cease and desist letter for replicating it on SmartThings 
This driver is modeled after a Home Assistant solution, and as @jpeden explained above, is a general-purpose way to create and update basic SmartThings devices via MQTT messages. These messages can be initiated through configurable MQTT-enabled applications, or custom applications or scripts running on your home network. It’s quite easy to set up, and requires no programming expertise to implement.
I’ve stayed true to the HA-defined format for discover and state update topics and included the ability to have SmartThings capability commands sent back to the device at a configured topic.
Topic format for device creation and state updates:
smartthings/<type>/[nodename/]<uniquename>/<config | state>
where:
More device types can easily be added, but is dictated by SmartThings capabilities, rather than the HA list of supported types.
For device discovery, I have a couple different ways it could be implemented. One is to only create new MQTT devices at the request of a SmartThings Add device / Scan nearby devices. The second approach is to create them any time a config topic message is received.
At the moment, I’ve gone with the latter approach. I’m not sure how well the SmartThings platform - especially the mobile app - will handle this latter approach. The devices do appear spontaneously, but their functionality suffers from initial delays and the typical SmartThings app hiccups that occur while it’s still trying to update all the devices. The other interesting aspect is that it is awfully easy now to rapidly create a proliferation of SmartThings devices programmatically from any LAN-connected thing that can publish MQTT messages!
I invite anyone to try this out and give me your thoughts.
Instructions
Pre-requisite: Must have an operating MQTT broker on your LAN (e.g. Mosquitto)
Driver is available on my test channel; from the available drivers list, install MQTT Handler V1
Once available on hub, from mobile app, do an Add Device / Scan nearby devices, and a new device called MQTT Discovery will be created in the ‘No room assigned’ room.
Open the MQTT Discovery device and go into Settings and configure the MQTT broker IP address (IP only, no port; secure connections or authorization not yet supported). This has only been tested with Mosquitto as broker.
After saving the broker IP address, return to the device Controls screen and tap the Refresh button. The driver will now connect to broker and subscribe to topics ‘smartthings/#’
Using an app like mosquitto_pub, create a new device (e.g. switch)
mosquitto_pub -h localhost -t “smartthings/switch/myswitch/config” -m “create it!”
Note that the message content is unimportant, and Retain option is optional (unlike HA)
Update the state of the switch:
mosquitto_pub -h localhost -t “smartthings/switch/myswitch/state” -m “on”
mosquitto_pub -h localhost -t “smartthings/switch/myswitch/state” -m “off”
Created SmartThings MQTT devices can be configured to publish capability commands to a chosen topic. This is configured in device Settings. Note that this is implemented only for the devices containing switches (switch, plug, light) at the moment.
First time I tried to connect to the broker it said connection failed. I deleted the device and scanned again. Now I can’t set IP for the broker. It just returns to the default and nothing happens when I hit refresh. I managed to create few mqtt devices so there should be something to subscribe for.
Its open source, so you shouldn’t
This looks very interesting - zigbee2mqtt makes heavy use of MQTT discovery. I would definitely check it out for ideas (also open source) - https://www.zigbee2mqtt.io/ It supports 2245 zigbee devices and each one has an MQTT discovery topic so the device can easily be discovered by Home Assistant. Instead of creating the discovery topic manually for each device, it relies on coding (except for some more specialized/advanced devices) to create the discovery topic. This file drives most of the creating of the “discovery” topic for each device - https://github.com/Koenkk/zigbee2mqtt/blob/3c5854fa9f749dde071477f700c1c2461bc20e17/lib/extension/homeassistant.ts .
It probably wouldn’t make sense to connect a zwave or zigbee device by MQTT since you would connect that device directly to Smarthings, but I’m not sure if you can use their ideas to somehow build discovery topics for other MQTT devices to use in Smartthings.
I’ll see if I can try to test it out - I haven’t used Smartthings lately and don’t have really any experience with edge, but I have about 21 MQTT devices running through the broker right now.
Thanks for the pointers; I’ll check those out.
Yes, it would make more sense to connect zigbee devices directly rather than through MQTT in a SmartThings environment, but maybe there are devices that currently have no SmartThings drivers and at least this could be an alternative integration method.
I’d welcome any feedback you can provide if you can test it out. The limiting factor right now is just going to be the device types, since I’ve only implemented a handful until I know this is even a useful driver for folks.
Definitely, MQTT has many uses outside of zigbee/zwave
Here’s a non-zigbee/zwave mqtt example I use. I can start/lock/unlock my car with MQTT using this onstar2mqtt program
There’s a ton more. MQTT can be kind of like a “Rosetta stone” to bring many different kinds of devices together.
After just an initial look at zigbee2mqtt, I think the biggest inhibitor to implementing something like that for SmartThings is that in SmartThings Edge, there’s no concept of dynamically creating devices. All devices have to have a pre-defined profile, which defines its capabilities. I don’t know HA, but it looks like this feature can dynamically create devices based on the capabilities defined for the zigbee device.
In a SmartThings Edge driver, you’d have to define a canned set of device types with certain capabilities and try to best-fit match them to the discovered zigbee device. You might be able to support some simpler zigbee devices, but definitely not the expansive list that zigbee2mqtt supports. At least not without a lot of pre-building the associated SmartThings device profiles.
One might have more flexibility using a SmartApp, but then you’re dependent on a cloud-based solution.
That’s just my initial take, anyway…
Cool example! Yes, the sky is the limit. Any SmartThings Edge driver can be developed to use MQTT so all of this is possible. Some solutions will require custom drivers to be developed. Others might be able to take advantage of the generic MQTT Discovery driver, but I suspect those will be more customized on the device end of things.
I’m not sure if you’ve already reviewed the ST MQTT bridge project…it’s super old and hasn’t been touched in years so idk how relevant it would be but there may be some helpful information to be gleaned from it. I still use it to this day, and have been dreading the demise of Groovy because there hasn’t been anything that I’ve seen that could be a replacement for it. There have been a few attempts to get the MQTT bridge modernized but those were still Groovy based, so this is the first time I actually have some hope that I’ll still be able to use MQTT with the next phase of ST.
That project had something like 50+ device types that you could select from to send/receive status changes to. It was a little clunky, but what I did was choose which (real or in some cases virtual) devices in ST to expose to the MQTT bridge so I could get the data out of ST. A perfect example of this was when I was able to expose the status of all of the ST/ADT motion, door/window, flood, smoke, etc sensors that everyone said couldn’t be used outside of ST. Well, the MQTT bridge made that a piece of cake. Until Samsung pulled the rug out from the ADT users, but I digress…
Once the devices are publishing to MQTT, the sky is the limit. Plus, it’s two way communication so I could then use MQTT to send a command to toggle a switch or set a dimmer from node-red or home assistant in complex automations instead of using webcore. I also used it as a way to get some unsupported devices into ST…just create a virtual device in ST, expose it to MQTT and then allow the real (unsupported) device to feed data to that virtual device via MQTT.
There is a native ST integration for HA that would make doing this via MQTT somewhat redundant but I would much prefer to keep the device communication at the edge instead of having the HA cloud talk to the ST cloud every time I want to toggle a device. Plus that integration is part of their paid service which I support but realize not everyone is signed up for.
As you mentioned earlier, if you follow the HA native MQTT discovery structure, those exposed devices would then automagically become available in home assistant and that would be totally awesome. Honestly that seems like a cherry on top pipe dream at this point so needless to say I’m super excited to give your work a spin. I could have sworn Samsung said they were going to natively support MQTT at the dev conference a few years back, but kudos to you for moving that ball forward. It is very much appreciated. Now I just need to figure out how to get my Aeotec hub into edge mode!
They did, but like the “local processing” they promised for the V2 hub, what they delivered turned out to be very different than the expectations raised by the early discussions.
Last year a community member was hoping to use mqtt to create an integration with a green energy device and I was the one who posted the link to the dev conference presentation. Which turned out to be useless for the purpose. 
@TAustin, great work with mqtt. Thank you for spending the time and coming up with solutions.
If you plan to share your MQTT solution, I would love to build on it for specific device running on Zigbee2MQTT. The device discovery is nice to have but not critical. As an example, I run mix of Zigbee platform (ST, Z2M and Hubitat, each of them are Zigbee capable). It would be nice to be able to bring a some of the device that just happen to be in Z2M into ST. I personally would not mind manually configure broker ip address, topic and etc for each device that I am interested on. There are cases where I just want to bring one or two devices from Z2M. I don’t think in this case device discovery is important.
Just to give a context why I am running some devices in Z2M. Z2M has some backup capability where one can replace a broken Zigbee stick with a new one without re-pairing all the devices . I exploits this capability to set up multiple identical Z2M servers at different location where a device can join to a Z2M server that is in range without needing to be re-pair at each location. This device that I am talking about is my Arrival Sensor. When I have Zigbee mesh at Home and Office, the Arrival Sensor can be detected when they arrived at home or office. Here is a configuration that I did on my Hubitat. I hope it explain it better. It is not my intention to open a discussion hubitat vs ST. But, I have already some information there. I just do not want to duplicate it here. With your MQTT solution, I can probably do this in ST as well.
Thanks for your post! A couple thoughts I had:
Hi - I’d encourage you to try out the MQTT Discovery driver I posted earlier. The ‘discovery’ part of it just allows an easy way to get a device created in SmartThings to represent your actual (this case, zigbee) device. After that, you just need to configure your device to publish to a certain topic. My driver already supports a presence type device, so you might be able to get that working fairly quickly.
I’m still in the stage of understand requirements, so any other feedback or ideas you have is welcome!
@TAustin, I am happy to help.
I apologize if I may sound confused. I am more excited to see the capability to subscribing to a topic in mqtt. My arrival sensor is paired in z2m. The data is in z2m. It would be nice to be able to synchronize the sensor attribute from z2m to ST. Z2M is purely ZigBee manager. We could use ST as the automation and gui for the sensor. Combining the best of both world.
For those of us running home assistant and node red and all of the other smart home docker containers, one more smart app wouldn’t be any issue at all. I’ll hopefully have some time tonight to test things out and will report back with any feedback.
Again, I cannot thank you enough for doing what you’re doing!!!
Let me see if I understand correctly:
In your case, you don’t already have a SmartThings device, but you’d like to have one that gets its state updates from your arrival sensor via MQTT. Correct? You already have that arrival sensor set up to send message to MQTT. Are you able to configure additional topics for that device to send status to? This is the part I’m still pretty fuzzy on, and that is what flexibility you have to configure an MQTT-enabled device. Does my Edge driver/device have to recognize whatever topic structure your device sends out? Or if I defined a specific topic structure I needed, would your device be able to also send out messages to it?