[RELEASE] MQTT Simple Switch Driver

⚙️ Custom Apps and Drivers
1

My first time sharing a driver here, hope I'm doing this right. :slight_smile:

My primary goal was to practice writing some drivers for Hubitat and learning Groovy, but I also wanted to solve for my use case.

The driver is in part based on MQTT Link Driver for Hubitat: [RELEASE] Hubitat MQTT Link (GitHub - mydevbox/hubitat-mqtt-link)

While a few MQTT drivers are available for Hubitat, I found some too complicated and others that won't fit my simple use case (it's possible there are other drivers that didn't come up in my search results, which could have worked). I needed a simple driver that would connect to an MQTT broker and subscribe to a topic, which I can then use to control a simple switch in Hubitat and use it in the Rule Machine to perform actions. My particular use case was for monitoring motion events from a Unifi camera that publishes to MQTT when smart motion (person detected) occurs, which would turn on my porch lights via Hubitat at night.

This driver can be used for just monitoring an MQTT topic and activating the virtual switch, without the ability to publish back. However, I've built in the ability for two-way communication -- it can also publish back to the same (or another) MQTT topic when the switch in Hubitat is toggled on or off. I also use this driver for controlling a few Tasmota devices via MQTT on my network.

When setting this up, I recommend using something like MQTT Explorer (https://mqtt-explorer.com/) to see which messages are passing through your broker.

Limitations
This driver can only monitor for or publish simple values/payloads (e.g. ON, OFF, 0, 1, etc.) to MQTT topics. There is no capability to parse JSON/XML (at least yet).

While the driver should survive and reconnect upon Hubitat Hub restart, I've not tested it for cases when the MQTT broker temporarily loses connection, in which case it may not work and may need to be re-initialized (or the Hub restarted to re-initialize multiple devices).

A virtual device would need to be created for each topic that you want to monitor, which in turn would create a separate connection from Hubitat Hub to the broker.

1 Like
2

Well done, just a couple of I hope constructive suggestions..

This is not good practice. Your ‘status’ and ‘control’ topics should always be separate and distinct topics. Otherwise it is not possible to tell which is which, you will get duplicate payload values and can perilously easily create loops particularly if some logic inverts the state like a ‘toggle’ action for example.

I appreciate this is an optional treatment in your app but it really shouldn’t be used. Use distinct topics for each and I actually recommend blocking the use of the same topic.

I do appreciate you can kludge using the same topic with a different status and control value like opened/open and closed/close but that is not good practice.

You should only need one connection to the broker shared by each virtual device. Just keep adding subscriptions for each new device.

3

Thanks for the feedback!

Regarding the "status" and "control" topics: I understand your point. I suppose I can enter a warning in the description that they should ideally be different to avoid any loops and racing events. I did want to keep some flexibility here for the "power user" :).

For the multiple connections: you're absolutely correct. Ideally, this should be set up as a parent-child device. Have the parent handle connection to the MQTT broker and subscriptions and children be the separate devices. I've not gotten into the complexities of coding for the child devices yet. Will play around with that as time permits.

4

Hi, I have been looking for something simple and I like your driver as I have had issues with installing other complex ones and getting them working, no doubt due to my limited understanding. but I have yours happily humming away. What I am looking to do is just use the Topic Payload value (which is a pool Filter water flow value in Litres/min) and put it into a Hubitat String or Number Variable so I can send this value to my Sharptools Dashboard.
Is this something that could be easily added to your App?

5

Should be possible. I can look into it in my spare time. But probably only after Jan 6th. Can you provide the full MQTT topic that you’re looking to monitor?