Current state of MQTT on Smartthings- Hoping to be taught a bit on the subject (How to)

Wiki How-To
,
13

Ahh, I see, I never really thought about it the way you explained it. I follow you conceptually.

Yeah, that’s strange on the smartthings router, really strange.

Good deal, well I definitely know the exact format of each command, luckily the help guide shows an example of each one.

And I agree with you on @TAustin, he seems very talented and very helpful to many people.

I am going to see if I can find enough resources on the smartthings side to figure out how to create a virtual switch that can send one of these rest commands to the sign. Or even better would be a device that when I go into the device screen on the app would give me 5-6 buttons and each button would send a different command by rest to the sign. (Maybe like “on”, “off”, “next”, “previous”, “set playlist”, and “repeat”. If I can get those, I will be happy.

14

I don’t think I would call it a “virtual switch,“ but there is an edge Driver (from @TAustin , unsurprisingly :wink:) that should let you send the local commands one at a time. It’s a little glitchy right at the moment because of some changes smartthings made (all of the edge architecture is still in beta, so every edge Driver need to be assumed to be in beta at this time), but he’s working on it.

As far as the kind of multi tile UI you’re talking about, to be honest, I don’t know what’s possible, hopefully someone else will respond or you may be able to ask in that thread and see what people have done.

15

Ahhh, I have been looking at that just a bit the last few days. I honestly believe that will be enough to accomplish the simple on/off I am going for. Just to make sure I am understanding the integration properly though.

So If I install the driver and then set up a few buttons that can send those 2-3 discrete commands, the button presses will only talk to the device if I am connected to my network/ Wi-Fi?

If I setup an automation with the command in the automation (if that’s possible, I believe I read it was), will that function properly?— I would assume so as the hub is connected to my home network?

Thank you for any clarification you can help me with on this. I know I’m getting a little bit detailed.

Yeah, hopefully, we can get a few responses on that concept with regards to the UI, even if e we would’ve been able to “stay the course” with the original concept in terms of using mqtt, I would’ve liked the same UI concept/ automation abilities.

Thank you @JDRoberts and @TAustin again for the conversation.

1 Like
16

Quick update on the subject of MQTT-based device integrations: Although I’m helping @Wtstreetglow with a RESTful API-based solution for his immediate needs, I’ve started working on an MQTT solution for the Edge environment. I have found an all-Lua implementation of an MQTT client and am working on retro-fitting it to work in the Edge platform. I’ve already successfully published and subscribed to MQTT topic messages to/from an Edge test driver. However there’s much work to do to make this a robust solution.

I’d like to hear from anyone that has an MQTT device to better understand the various requirements there may be. I don’t know that there can ever be a “generic” MQTT driver per se, but rather with an enabling library of code, we will be able to build custom Edge drivers to support MQTT device integration.

2 Likes
17

I know @mwav3 is now primarily working with another platform, but he did a lot with MQTT in the past and might have some thoughts.

I think @Automated_House might have something more current.

Also, @KasperT00 was trying to get an MQTT/ST bridge working earlier this year, but I think ended up abandoning the project. He wanted to bring some enocean devices into smartthings, if I remember correctly.

18

I have an MQTT driver for anyone that wants to experiment a bit with MQTT on Edge.

This driver will create a device that will allow you to configure it with an MQTT broker address (IP only, no port), a topic to subscribe to, and optionally, a topic to publish back out whatever it receives. It’s enough to prove that things are working between Edge and an MQTT broker (like Mosquitto).

I’ve put it on my test channel, where you can install it: MQTT Test Driver 1, version 2022-06-07T23:08:13.079753516

Once you Scan nearby devices to get the device created, go into settings and configure the broker IP address and the MQTT topic to subscribe to. If you want the driver to echo messages it receives to another topic, you can enter a publish topic as well.

Then back on the device Controls screen, press the Refresh button and any received messages will be shown in the HTTP Response Data field (ignore the HTTP name, I’m borrowing this field from another device!).

Depending on the frequency of published messages, they can sometimes come fast and furious, so often you’ll only see the latest displayed. But sometimes you can open history and see more. If you have a very high frequency of received messages you could start exceeding SmartThing platform limits on state updates, so it’s possible some could get lost.

If you want to change the subscribe or publish topic in Settings, you’ll have to press Refresh after they are saved to re-establish things with the broker.

I’ve tested this with Mosquitto, but no other brokers. I’ve only tested the most basic functionality so far, no authentication or other optional MQTT parameters.

1 Like
19

I’ll give this a go. I will be using Mosquitto also.

Would this be the same concept as the http call driver?— if you want to publish/ subscribe to additional topics, duplicate the device. Or is that not possible just yet.— And when it gets a step further, will all of the additional subscribe/ publish topics happen under 1 device or will one create duplicate devices for additional topics.

EDIT: Or, this is proof of concept first, looking for bugs, and then extend functionality in the future?

Sorry for the weird questions, I am new to a good amount of these things.

1 Like
20

Not yet. I don’t know if it would be useful to have something like an MQTT version of Web Requestor… Maybe, if there are enough cases where a routine could be created to key off of a specific MQTT message.

Yes, this is mainly an initial proof of concept for now to spur exactly those kinds of questions and to get the creative juices flowing for those with devices spitting out MQTT messages.

1 Like
21

@TAustin are you familiar at all with the HA MQTT Discovery protocol? It would be amazingly cool to see an MQTT Edge Driver “controller” that subscribes to the discovery topic, and then, like the virtual device drivers, can auto discover and configure MQTT devices. Such a driver could unlock a ton of potential from a single driver (rather than a shared lib/reference pattern).

22

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?

23

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:

  • Ecowitt Weather Station
  • Aircon mini-split bridge
  • IDM/SCM meter readings for power/gas off of RTL-SDR radios and a pin zero 2 w
1 Like
24

Thanks. This should actually be pretty easy to implement, so I’ll give it a shot!

1 Like
25

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.

26

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.

27

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 :slight_smile:

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:

  • ‘smartthings’ is mandatory topic prefix
  • type is device type (currently: switch | light | plug | momentary | motion | presence)
  • nodename is an optional name identifying the source node [a-zA-Z0-9_]; no other special characters or spaces
  • uniquename is a unique identifying name for the device; [a-zA-Z0-9_]; no other special characters or spaces
  • ‘config’ indicates device creation, ‘state’ indicates device capability attribute update

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.

2 Likes
28

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.

29

Its open source, so you shouldn’t :slight_smile:

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 - zigbee2mqtt/homeassistant.ts at 3c5854fa9f749dde071477f700c1c2461bc20e17 · Koenkk/zigbee2mqtt · GitHub .

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.

2 Likes
30

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.

1 Like
31

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.

1 Like
32

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…