I'd like to have an option to write a string to a MQTT topic. Similar to the HTTP get/post ability. I'd like to trigger some external to HE devices. You might want a default mqtt broker setup somewhere (Settings? ) so RM doesn't have to spin up a couple of sockets just for one message. Or a list of active Mqtt connections to pick from.
1 Like
Not something I would use but seems like a nice idea for those who rely heavily on MQTT. That said I think this may be a large change because currently apps (Rule Machine is an app) are not allowed to use MQTT, only drivers are.
1 Like
And I think you could already do this--using such a driver, just run a custom command on it that publishes whatever you want. I'm no longer using MQTT for anything so can't test this myself, but there are a coupe community solutions (a beta of a full-featured MQTT client that username kevin is working on, and a newer MQTT client intended for simple cases like HASS integration). Either of these looks like the driver component has custom commands that could do what you're looking for.
1 Like
In my MQTT app there is a client driver for MQTT and it has an exposed 'publishMsg' command that you can set topic and payload for. This is now a child device so not quite as easy to operate as the previous standalone driver. You could use that previous version though and interface to it via RM.
I also provide an MQTT Text device which if used with my current app / child driver will do what you want bidirectionally linking to an MQTT topic. It handles automatic post and pre pend of text and also html tags.
I do see the interest for a simpler device just for this focused purpose, maybe that newer client mentioned above would suit. The MQTT app would be a sledgehammer to crack a nut in this scenario
2 Likes
But, they can use HTTP. My suggestion would put MQTT publish on equal footing. Neither are device drivers. They a outbound communication methods. You still need drivers for both HTTP/MQTT to listen for incoming messages and create Events.
This proposal does not replace the need or usefulness of @kevin work or @tpc77 efforts. More structure for MQTT is good. But not everything MQTT is well structured or ever will be. If all I want to do is send an 'on' payload to a topic from RM and not care if it succeeds, then setting up an app and a driver is more work than really needed. If you do care if the message made it then you do need drivers and some sort of protocol and structure.
@dman2306 is correct about apps not having access to the built-in MQTT client. It is only accessible on the driver side. Implementing it in RM would definitely require the Hubitat dev team to add this functionality.
That said, if you'll accept an interim solution then MQTT Link will do what you're looking for. @kevin 's app / device combo may work as well but I don't know the intricacies of his work to say for sure. I'll provide some instructions for setting this up with my app and then Kevin can provide some for his if he likes.
I know that you don't want to install an app or driver but this method will require both.
- Install both the MQTT Link app and driver according to the readme in the repo
- Add a new, virtual device with the following:
2a. Device name. This will become a portion of the outbound MQTT topic so choose appropriately
2b. You mentioned wanted to send an 'on' and presumably an 'off' so choose Virtual Switch and then save the device - Open the MQTT Link app and pick the newly added virtual switch device on the first screen. Will assume that you've already set up the driver in step 1 so press Next after you've selected the device.
- On the next page find the newly selected virtual switch and choose the Switch capability from the dropdown then click Done.
At this point, MQTT Link will monitor the virtual switch for any change in Switch state and will publish a message with that new state to the generated topic.
Now, you can go into RM and and configure as desired but also add the following
- Add action via Set Actions to Run
- Select Set Mode or Variables, Run Custom Action from the dropdown
- Select Set Custom Action in the second dropdown
- Select Switch from the Capabilities dropdown
- Choose the new virtual switch that was added in the prior setup list
- Specify the custom command to perform. e.g. 'on' or 'off'
- Complete the rest of your rule setup and test.
Now, when the rule is fired and conditions are met according to your configuration, the action will change the state of the virtual switch and the MQTT Link app will be listening. Once it gets notification of the change, it'll forward that state change to the MQTT Link Driver which will publish the message.
I realize that this is a bit convoluted and much more complicated than simply picking 'Send MQTT Message' from a dropdown but it might be the easiest stop-gap solution for you.
Open to any feedback that you may have. Thanks!
1 Like
Yup, not saying g that makes it a bad idea. Was just saying itās more work than exposing additional functionality in RM. more work = more time 
I have working solutions for my problem. I just create yet another custom driver tailored for my particular setup. They are easy to write and test once you have boilerplate that works.
The Feature Request is to not have to do that or procedures like @tcp77 provided or move logic to Node-Red or.... I do see how the request could be architecturally undesirable or business strategy undesirable or just too hackish or time consuming for the dev team with not enough demand to support it. because more people use HTTP than MQTT so HTTP is special.. All perfectly acceptable answers. On the other hand, if the request is never made, it will never get in a queue, any queue, not even the 'nice idea for when we have nothing to do' queue
1 Like
Agreed. MQTT is also growing. Both AWS IoT and Azure IoT make use of MQTT and AMQP for their IoT integrations. Itās lightweight and I think as IoT grows we'll see it used more and more.
1 Like
