Integration Solutions using MQTT

Devices & Integrations
, , , ,
1

I’d like to share some projects I’ve been working on that provide some nice integration options between SmartThings and other external applications. These use MQTT, which if you’re not familiar with, you can find plenty of information about on the internet. Put simply, you install what’s called an MQTT Broker application onto an always-on computer on your LAN (‘Mosquitto’ is one of the more popular free ones), and it provides a structured way to publish and subscribe to messages across devices and applications. This provides a nice solution to being able to get device information into, and out of SmartThings in a consistent and reliable way with little-to-no development expertise required.

MQTT solutions have existed for SmartThings on the ‘old’ Groovy-based platform. My new projects bring those capabilities onto the new Edge device and SmartApp execution platforms. I don’t profess to be the first to do this (@gol probably was!), but I’m offering these for general use.

UPDATED 11/16/22:
I’ve added an additional driver for creating SmartThings devices that have built-in MQTT support. Device types currently supported are acceleration sensor, alarm, battery, button, CO2 contact, dimmer, energy, fan, humidity, lock, motion, generic text or numeric, presence, robot, sound, switch, temperature, moisture, shade. It can also be used to publish any MQTT message to a given topic. The README file on github has all the details. Also see this post for latest info and this post for the initial announcement.

Simple MQTT message display device
To get started, this is a super-simple Edge driver that creates a device that can display MQTT messages for a given subscribed topic, and also echo those messages back out to another MQTT topic as a demonstration of the ability to also publish messages.

This is intended to be for simple testing and monitoring as you get your MQTT broker up and running, but it could also inspire you to imagine new ways to utilize this capability.

MQTT Handler/Discovery
This is also an Edge driver that can be considered a SmartThings implementation of Home Assistant’s ‘MQTT Discovery’ application. With this driver, you can literally create new SmartThings devices by publishing an MQTT message from anywhere on your LAN, and then update the states of those devices with additional MQTT messages. HA supposedly has many devices that support this framework, so this could provide a way to easily integrate HA devices into SmartThings.

MQTT SmartApp
This SmartApp provides a way to externalize any SmartThings device to MQTT. Use it to configure selected devices to send MQTT messages whenever their state changes. This provides a way to get device states to external applications without having to ‘poll’ the SmartThings RESTful API.

This SmartApp is designed to run on your own LAN - freeing yourself from Groovy or AWS-based SmartApps. The project is a demonstration on how to do that, and includes step-by-step setup instructions.

I offer these projects as starting points and am happy to revise/improve to meet community needs.

To install either of the Edge drivers, enroll your hub with my test channel and select these drivers to install to your hub.

                                      Driver Name
                                      --------------------
Simple MQTT message display           MQTT Test Driver 1
MQTT Handler/Discovery                MQTT Handler V1

Once available, you can use the mobile app to do an Add device / Scan for nearby devices and new MQTT devices will be created in your No Room Assigned room.

For the simple message display driver, all you need to do is go into device Settings and configure your broker address, optional authentication info, and a topic to subscribe to. It can be anything in the standard MQTT topic formats. Configure an optional publish topic if you also want received messages to be echoed out to another topic. After Settings are saved, tap the Refresh button on the Controls screen to connect to your broker, and messages received on the configured subscribe topic will be displayed.

For more information on the MQTT Handler/Discovery driver, please reference the README on github

For more information on the MQTT SmartApp, please reference the README on github

Thank you goes out to @jpeden @mwav3 and @fooktheta for providing early inspiration and feedback on these concepts.

18 Likes
2

Nice work! :sunglasses:

1 Like
3

Just wanted to mention that the Hubitat hub has a built-in feature to communicate with an MQTT broker.

https://docs.hubitat.com/index.php?title=MQTT_Interface

So if you’re willing to run 3 devices (SmartThings hub, Hubitat hub which offers a built-in interface to communicate with an MQTT broker, and a Raspberry Pi to host the smartapp discussed in this thread) you could, for example, run Webcore on hubitat, keep your zwave and Zigbee devices on SmartThings, and use the MQTT smartapp discussed in this thread to communicate between the two.

It would be a lot of complexity to get everything synchronized, but it should be doable. :sunglasses:

(It’s possible I got the details wrong on hosting the smartapp, if so please correct. But the main concept is using MQTT to communicate between SmartThings and Hubitat. :thinking:)

2 Likes
4

thanks for this! I ll try but the only thing, I only have a ST hub, so is it possible ton install webcore on a local pc, rasberry pî or something and then link it with the ST hub?

5

No. Now, if someone could get their hands on the source code, who knows!..

You can run smartapps written in JS on a local computer, and you can have local apps communicate directly with an Edge driver on the hub. MQTT is kind of a generic way to do the latter.

6

yes, actually, webcore is running on a server somewhere and those smartapps are just the link between the smart hub and the api. That would be cool to have webcore running independently with the same interface or so… then we just need to supply a devices list with their state so it could run the piston and then output the list of changed devices with their new state that the rules api could read from a driver and update those devices… Actually, all it takes is communication between rules api and webcore in both direction and it already exist using drivers and json… I m no expert so I could be wrong and probably are but the missing part is just the’ running webcore ’ thing.
If someone could create a tool to make it run without any ‘hub’ then we could make it communicate with what we want and run pistons, actually its a rule engine too…
What do you think about it? I very like to talk about it as personnal knowledge…

7

With a LOT of effort someone could certainly find a way to implement much of webcore’s function on a locally running computer - or even an AWS server for that matter. Unfortunately the setup and configuration would be far too much for most people to want to tackle. A big benefit of webcore was that someone was willing to stand up a server to run it and make it all very simple for the average user.

Just my opinion, but…

Some kind of turn-key Raspberry Pi software image could be created to implement an environment to keep it as simple as possible, but to be honest I’m not sure there are going to be enough people staying with the platform to make this worthwhile for anyone to want to try and build it. Sadly, I think we’re going to see a mass-exodus of the home automation hobbyists to other platforms and what will be left is what Samsung really intended all along for SmartThings - a platform primarily for their own appliance products and not really geared toward general home automation. That market has been taken over by Amazon, Google, and Apple. SmartThings is not a revenue-generating business for Samsung. They’ve done what they can to accommodate the legacy user base, but that’s coming to an end and their ongoing investments are going to be minimal.

I hope they prove me wrong :slight_smile:

1 Like
8

It’s not that simple. Webcore isn’t just a program written in groovy. It’s a program written to run in the environment of the Samsung-hosted groovy cloud, taking advantage of features and values not all of which were documented and not all of which will be available after the groovy cloud is shut down. The Rules API does not currently have feature parity with Webcore, so there are a lot of things you can do with Webcore that you just can’t yet do with the Rules API. So communicating the way you describe doesn’t give you Webcore again.

It took multiple people about 10 months to create the Webcore version for Hubitat. It’s debugged and working and has some added features because it’s had active development while the ST version has not.

I don’t know what your time is worth to you, but speaking just for myself, if I was personally very interested in continuing to use Webcore, I’d consider the cost of a Hubitat hub well worth the savings in time and trouble versus a DIY start from scratch version. But that’s just me. :wink:

9

yes! that what the logic suggest! To be honnest, I just find it…how to say, its a buisness decision that not taking care of clients… They should let run the groovy server and makes the rules api updating and when the API is all ready, then they could makes the shut down… I fell like I felt in a trap! The marketing aroung the ST hub was that sky is the limit and that exactly what I bought but now I realized that its not! They told me that they takes all suggestions…and they would try…etc but not sure they would do something nor when! They had already a very powerfull things with webcore and they decided to start from scratch!
I think I should migrate soon!
Thanks again!

10

yes! thanks! I was hoping for solution but I think I should migrate soon! When I decided to go with smart home devices, I was thinking of stability… If any time all those automations could stop what is the purpose? ST deceived me, I know that maybe in 10 years they probably want to be good with their new stuff but harsh transition!
Well thanks again!

1 Like
11

@TAustin, thanks for the MQTT Handler/Discovery driver. It took me a while to figure it out. But it is working really well. I am using it to send command from smartthings to mosquito to node-red. It gives me an alternative to your webrequestor. The only thing I am missing now for my transition to EDGE is a way to control my AC with a virtual thermostat. Would it be possible to add it a thermostat to the MQTT handler/discovery driver. I can currently use a MQTT switch, on-off to node-red to an AC node-red palette. thanks again.

12

I have added a moisture device to the MQTT Handler/Discovery driver. This new device type uses the relativeHumidityMeasurement stock capability to capture a moisture percentage (0-100) from an MQTT topic.

Complete list of device types now supported:

switch, level, momentary, light, plug, motion, contact, presence, alarm, valve, moisture

Please note that additional device types can be added. Just ask!

Driver Version: 2022-10-01T00:11:20.862986677

Updated README for more details on how to use.

2 Likes
13

I added the discovery driver, set the ip to my local mosquitto broker, and got a connected and subscribed. I changed the groovey mqtt broker so they would not interfere. I hit the refresh button, and see a ‘PUBLISH’ message on the broker logs. Should I not be seeing the messages coming from my devices now ( as I don’t see anything)?

14

What device type are you trying to use? Has it been created?

What is the MQTT topic string your device is sending?

15

When I create a device type “contact” there’s no way to set the topic like there is with a “switch”, how does it know what messages control the device?

16

Whatever is publishing the MQTT message needs to use a topic that follows this format:

smartthings/<type >/ [nodename /]<uniquename >**/state >

The driver parses the topic to determine what device to control. For example if you published this message:

mosquitto_pub -h localhost -t “smartthings/switch/myswitch/state” -m “on”

Then the driver looks for a device with a internal ID of ‘myswitch’ (specified when it was created) and updates the switch capability (‘type’) to ‘on’.

Be sure you have read through the documentation here. Let me know if anything is unclear so I can improve it.

1 Like
17

I misunderstood the process. I retrieved a ngrok account and tried to process that first. I took a bit to realise I had to set up a web server, and to add a port for the system to work. Now I think I need to add a folder for the smartthings developer app to go to, and to point the port to that folder, as the developer registration does not complete.

18

I’m confused now as to what you are doing! You don’t need ngrok for the MQTT drivers and I don’t know what you are referring to regarding “smartthings developer app” or “developer registration”.

19

I am using the smartthings for 2 ikea 5 button modules that mqtt to my node-red system to integrate with the rest of my automation. I haven’t spent any time on the smartthings system for the last 3 years, and with the emails explaining the groovey system is going away, I just want to switch over. When I did a search for mqtt solutions, this was one of very few topics. I thought by following your instructions, the system could be moved over.
I’m probably lost (well, not probably).

20

OK, so your two Ikea buttons publish MQTT messages and you want to get those states reflected in a SmartThings device?

If I have that right then the first question I would ask is, do you know what flexibility you have in configuring the MQTT topic that is used by the buttons when they publish messages? If you don’t know, or think it may be rather fixed, can you find out exactly what the topics are? As well as find out the format/contents of the message? With that information I can advise you on your best options.

1 Like