From MQTT control and status to Hubitat Device

⚙️ Custom Apps and Drivers
1

I have a hard time understanding the Hubitat integration with MQTT.

If I have a device like the RatGdo that can be controlled by MQTT and which status can be obtained the same way, do I have to write a custom virtual device for it or is it more direct?


door/open - opens the door.
door/close - closes the door.
light/on - turns the light on.
light/off - turns the light off.
lock/lock - locks out the wiresss remotes.
lock/unlock - unlocks the use of wireless remotes.
Examples

If:

Device Name = “MyGarageDoor”
mqtt Prefix = “home/garage”
Then:

mqtt.topic = “home/garage/MyGarageDoor/command/door”; mqtt.payload = “open”; - opens the door
mqtt.topic = “home/garage/MyGarageDoor/command/door”; mqtt.payload = “close”; - closes the door
Statuses

The following statuses are broadcast over MQTT:

prefix/status/availability
online - once ratgdo connects to the MQTT broker.
offline - the mqtt last will message which is broadcast by the broker when the ratgdo client loses its connection.
prefix/status/obstruction
obstructed - when an object breaks the obstruction sensor beam.
clear - when an obstruction is cleared.
prefix/status/door
opening - when the door is opening.
open - when the door is fully open.
closing - when the door is closing.
closed - when the door is fully closed.
prefix/status/light
on - when the light is on
off - when the light is off
prefix/status/lock
locked - when the door opener is locked
unlocked - when unlocked```
2

You don't have to write your own. I use GitHub - parasaurolophus/hubitat-mqtt-connection: Extremely basic drivers for Hubitat Elevation that expose its hidden MQTT support for compatiblity with its built-in Rule Machine. I mainly use it to subscribe to MQTT messages, but it can also publish. Each topic you subscribe to creates a child device with a Custom Attribute of "payload". You can use that attribute in rule machine triggers and conditions.

It's a pretty basic driver, but it gets the job done.

Here is a rule I set up to test how the publish syntax works:

I created a handler in the MQTT device called "mqtt-test" that is subscribed to the topic "test". Whenever the payload changes, the rule publishes the message "test payload" under the topic "test1".

1000005326
10000053261080×1948 243 KB

I name all my child devices "mqtt-*" so they are easy to find in the list of devices when using rule machine.

1 Like
3

Note also that you will need an MQTT broker (unless this device has something built-in; this is not common). The hub itself is not an MQTT broker--it just has the ability to be an MQTT client, which your device also is, and both would connect to the broker (essentially a server) to communicate.

I am not familiar with that particular device. If there is a regular HTTP interface availabe (often called a REST API if it works like many do), that may be easier to use to work directly with your hub unless the above is not a problem or something you have already considered.

1 Like
4

Thank you, I do have a broker running for HA and Teslamate.

No, it doesn’t offer a REST api (which wouldn’t be practical because you’re have to poll it for status changes or use web sockets).

It can be set up for ESP Home, MQTT and in a few weeks HomeBridge. MQTT seems the most appropriate for integration with Hubitat, given the Hubitat built in library for MQTT.

I think I’ll use the above as an inspiration for a custom virtual driver.

5

If you have HA setup, then you can just install Home Assistant Device Bridge on HE to get status from, and control devices that are on HA.

1 Like
6

This.

I always recommend doing as many LAN integrations as you can outside of Hubitat, even if you bring the sensor data into Hubitat to use in RM, dashboards, etc. For me that has proven to be the path of least resistance and frustration.

That said, if you really want to do it directly in Hubitat, search on here for the many different MQTT apps/clients made in the user community. There are AT LEAST 5 different ones.

2 Likes