[RELEASE] Hubitat MQTT Link


This is a conversion of the terrific MQTT Bridge project that removes the requirement for the nodejs application and replaces it with a native Hubitat MQTT client.


I would call myself a Hubitat enthusiast as it is not my primary hub. I purchased the hub a few years back after hearing Patrick promote it on a podcast. He touted the non-cloud focus of the platform and that appealed to me. But, after purchasing my hub, I soon discovered that Zigbee and Z-Wave devices aren't cheap and ended up purchasing only a few devices to connect to my hub.

My primary hub of choice is Home Assistant so I began my quest to find a way to integrate Hubitat with Home Assistant to gain access to those devices that I'd purchased. MQTT seemed like the logical choice and after browsing this forum I learned about MQTT Bridge for Hubitat that someone from the community had ported from an implementation made for SmartThings.

I was reluctant at first because it required a middle-man nodejs server to convert MQTT messages to REST calls. After searching for a better option and coming up empty, I relented and installed the nodejs server on a Raspberry Pi Zero. I was happy because it worked...for awhile.

I started having trouble with the nodejs server and often found that my devices stopped reporting / responding due to this. I suspect that running that server on a Pi Zero may not have been the best idea however, I had had enough and retired MQTT Bridge even though it meant losing integration with Home Assistant.

Sometime later, while browsing the forums, I heard about the Hubitat team adding an MQTT client to the platform. At first I was under the impression that it was a Built-in app that I could quickly install and be on my way. I soon discovered that the team had added the client library but had not provided an app to support it.

I waited, and waited for someone to implement a decent MQTT app using the built in client but none materialized to my liking. That got me thinking about the old MQTT Bridge app and the possibility of replacing that nodejs server with the native MQTT client. I started looking through the code even though knew nothing about building SmartThings / Hubitat apps and very little about coding in Groovy.

After a few months of reading through documentation, reviewing features of other Hubitat apps and a lot of trial and error, I've finally put together a solution that I am happy with.

MQTT Link is a bare bones app and driver set that simply sends and receives msgs to / from an MQTT broker. It knows nothing about the downstream subscribers of message that are sent out but it does utilize the message formatting established in the original application. This means that downstream clients can control devices simply by publishing a properly formatted message to the appropriate topic.

I've decided to make my implementation public just in case any others out there waiting, like me, for someone to built it.

I am open to maintaining this if bugs are reported and will even consider new features however, I will strive to maintain the simplistic design to ensure that it continues to be just a boring MQTT client reporting and receiving device events.

For more details, see the readme in the repo. I am looking forward to receiving feedback from the community. Enjoy!

Hubitat MQTT Link


I just came across another project in the forum for a Hubitat Package Manager which is a great idea. I added the required file needed for installing MQTT Link thru this tool.

Here's the url to the manifest file:



I added functionality to ping each of the selected devices every minute and push their status to subscribed mqtt topics so that those devices that don't often send updates will show up to the minute state values.


I added some instructions on how to use MQTT Link in conjunction with Rule Machine for sending MQTT messages when a rule is triggered.

Setup a virtual switch to send on or off MQTT message

1 Like

Some of the supported devices and capabilities needed to be cleaned up. The app should handle all of the device capabilities that Hubitat supports and will work with all virtual device types though Hubitat doesn't appear to expose / broadcast all events for virtual devices.

1 Like

I just released a minor update to the code that contains a breaking change.

If the hub name contained spaces those spaces would appear in the MQTT topic. This is 100% acceptable according to MQTT spec however, it did not follow the pattern established with device and attribute topic naming used throughout which replaces spaces with dashes.

All hub names containing spaces will now have those spaces converted to dashes.


/hubitat/this is my hub-1234/my-device-1234/its-attribute

Will become this


I really like where this is going. Thanks for taking the time and effort to make this.

I'm a Hubitat novice and I'm a bit puzzled on how to subscribe to a specific MQTT topic and process that further into Hubitat. For example; I have a digital and temperature input module publishing to MQTT, it publishes as: [Modulename/MAC/DI1 On/Off) or [Modulename/MAC/TI1 23.5 ℃] (without [ ]). I can't change the Modulename or MAC of this device, is there a way to get the data into Hubitat?

As you may have noticed, Hubitat MQTT Link is opinionated about the way that it handles MQTT topics. I took this approach to reduce the complexity and variability of getting HE devices to report to the broker. As is often the case, there is a trade-off for ease of use, and in this case that trade off is full customization.

You are the second person since I've shared this tool to ask for a simple way to get external data into HE via MQTT. I have a few thoughts on that and may be able to put together another tool that'd allow you to do what you're asking in the simplest way possible.

I will see what I can put together and share it with you when it's ready.


Thanks! Would be great to see a more transparant two-way approach. I like what is there now and I know you wanted to keep it small and simple, but may I throw in some suggestions? :wink:

It would be great to see a MQTT broker/server scan option, so you could see in Hubitat which topics are available. It would also be great if you then could select a topic and attach that to a Hubitat (virtual?) device. This would be an ideal solution, but this is not based on much Hubitat knowledge (yet).

IMHO MQTT is great to use as a base for your home automation because it makes your system completely independent from any device/manufacturer/software. It also offers an easy way to hook up and share your devices/data to several home automation platforms/software.

I do like the approach of Hubitat, but what is missing is a way to attach wired devices, with MQTT in the middle and, for example, a Modbus <-> MQTT gateway. This opens up a lot more wired opportunities. I know this all has not much to do with MQTT link, but I just wanted to share my two cents.

1 Like

Thanks for the input.

What you're looking for will require the target topic to be mapped to a device and its capabilities.

It may be a challenge to get a full list of topics from the broker because those change depending on the last time a message was published to the topic. There are some better options for this.

I've got this working partially, all my device data and actions etc. are sent from HE to MQTT, but if try and publish to a topic e.g.:


Then HE isn't receiving that back, nothing in the debug logs for MQTT Link or for the HE MQTT Client.

I can see if I sub another client to that topic, that my client is sending to the topic and the MQTT broker is sending that out to subscribed clients.

Any tips for debugging it?



Hey, I'm having issues getting subscriptions working. I just have 2 devices defined in the MQTT App and the MAKER API app. When i hit done in Specify Exposed Capabilities per Device page in the MQTT app. I only see 1 device(closegate) gets [deviceSubscribe] & [subscribe] updated as shown in the log. closegate intern works fine. opengate does not. remove closegate for mqttlink app and opengate works fine. Any help would greatly be appreciated Thanx! Michael


Verify that you are using the exact topic that is listed in the app config because it tacks on the device id to the end of device name to ensure uniqueness. Here is an example of a switch that I have set up on my hub.


Also verify that you have switch selected in the app for this device to ensure that it knows to listen for that event.

Does it publish a message to your mqtt broker if you go into the opengate device and turn it on/off there?

I would recommend using a tool like MQTT Explorer to connect to your broker and check what events are being published.

Yep. I'm already using MQTT Explorer. So I see when a light gets turned off etc. Just publishing from there doesn't get back to HE - but I can see from another MQTT client that's subscribed to that topic that it sees that MQTT Explorer has published.

Can you take a screenshot of how you are publishing from MQTT Explorer?

Here is what works for me. Take a look at the topic and payload to see if it matches the way you're doing it.



To confirm that this device is connected correctly, do you see events appear in the tree when you turn the switch on / off from within HE?

When I click the command buttons on the device page I will see the state change in the list.


Do you have any other devices in HE that are responding to commands from MQTT?

It was, but now it isn't and is only updating when it does the 60s refresh.

@tpc77 Trying to communicate with a Shelly 2 through MQTT but cant get it to work. I think it has to do with that messages is hard coded with the hub name and location. That assumption might be totally wrong though. :slight_smile:
I can control my Shell 2 through MQTT Explorer using shellies/shelly2/relay/1/command (I use shelly2 as custom MQTT prefix) and send ON or OFF.

If you got the time and energy I would very much appreciate if you can have a look at the Shelly documentation and wright a "For dummies" how I should set up MQTT Link to communicate with Shelly. Fully understand if you dont want to.