[PORT] Hubitat MQTT Bridge

Original project: GitHub - stjohnjohnson/smartthings-mqtt-bridge: Bridge between SmartThings and MQTT

Hubitat MQTT Bridge is a MQTT driver and app combo that sends events from Hubitat to an MQTT Server and can receive commands back from the MQTT Server.

Release Page: GitHub - jeubanks/hubitat-mqtt-bridge

Driver: hubitat-mqtt-bridge/hubitat-mqtt-bridge-driver.groovy at master · jeubanks/hubitat-mqtt-bridge · GitHub

App: hubitat-mqtt-bridge/hubitat-mqtt-bridge-app.groovy at master · jeubanks/hubitat-mqtt-bridge · GitHub

Docker Image: jeubanks/hubitat-mqtt-bridge

The main page has decent install instructions and a lot of original information from the SmartThings use. I’ve updated instructions for Hubitat.

Consider this a pre-release and not final.

9 Likes

Thank you - I was able to get this up and running extremely quickly and have it running side by side w/ my ST instance.

1 Like

Thanks for the port. Ive got it up and running on my Hubitat hub. I am using this to forward events from Hubitat to HomeAssistant.

I’m looking at the app code, and the driver code for a few aquara buttons ([Release] Xiaomi device drivers)

How much work is it to allow this app to capture the capability "PushableButton" events from the driver? As is, i can see the proper 1/2/3/4 click events being decoded by the driver for the button, but i am not sure of how to get this app to pick those events up and forward them to the rest->mqtt service.

Is it really as simple as adding another object to the CAPABILITY_MAP ?

Additionally, what’s the capability that needs to be added for airpressure measurements: xiaomi-hubitat/xiaomi-temperature-humidity-sensor-hubitat.groovy at master · veeceeoh/xiaomi-hubitat · GitHub

I’ve opened a PR; not hoping for a merge right away, but just keeping track of my changes. I’ve updated the button support to use the Hubitat button model: Hubitat’s button implementation

and i’ve also hacked in support for air-pressure reports from this driver: [Release] Xiaomi device drivers

I have no experience with MQTT. Can you advise if and how it might be possible to get from A to B for control of a Sonoff IFAN02 module from Hubitat? If all I have to do is setup an MQTT server on a RPi for local control, that'll be what I do instead of relying in a cloud connection.

Hubitat itself doesn't have any MQTT apps/drivers so in a generic use it's not possible with Hubitat. I have requested many times for a native MQTT app/driver for Hubitat but nothing yet.

1 Like

Confused by this. What does the driver and app you mentioned here do, if it cannot link devices to Hubitat? Are you saying that even via virtual switches, this or other devices are not controllable? I’m clearly missing the intended message in your last post.

This is an old project and is very specific to SmartThings and Hubitat. There is a driver that is used by Hubitat to understand what the MQTT messages are. This is specific to SmartThings and the middle layer that is written in node.js to "bridge" the app running in SmartThings and the App running in Hubitat.

To work in a "generic" sense of using any device there needs to be a native MQTT "app" for Hubitat that allows the configuration of what the message pattern would be and what device (virtual device) that should be linked to.

1 Like

The SmartThings MQTT implementation was a bit of a workaround, both in terms of features, functionality and to circumvent the issues with local interaction. An updated/inbuilt Hubitat version would (could) be so much better.

Absolutely correct. The ST -> MQTT -> Hubitat was a workaround.... not a solution. I have asked several times for a real built in solution from Hubitat for MQTT and I don't think it's going to happen anytime soon.

Actually thinking about this I am not sure a built in app would be good.

The needs of MQTT users are such that the ability to tweak the operation is very likely. As Hubitat apps are closed source this wouldn’t be useful.

Actually this applies to all Hubitat apps where any form of customisation might be desired.

1 Like

It all depends on how it's implemented.

There are two very good examples that I can use as a reference for implementing MQTT.

  1. Home Assistant (native and component)
  2. HomeSeer (plugins)

Both actually have multiple examples, but they follow the same "generic" pattern or rule for the plugin/component/app.

The core of the system should be a native app. Whether it be Hubitat developed or not, really doesn't matter. The advantage of it being Hubitat provided would be the support and functionality through Hubitat updates.

The basis of the "app" should be a generic MQTT client that allows easy mapping of a MQTT message to a Hubitat Virtual Device and then vice versa of being able to easily map a real device and properties to a message format.

The client would then be able to perform all of the normal sub/pub functions of an MQTT client and the actual broker would be somewhere else (raspberry pi is common).

The "client" Hubitat app needs to be generic so the user can specify the sub/pub message formats to match any device they may encounter or develop themselves.

I would really like to see a proper MQTT client available.

Like paho-mqtt · PyPI

Or JAVA version GitHub - eclipse/paho.mqtt.java: paho.mqtt.java

Currently I don't have the time to work on a native mqtt client. However here's a groovy client out on github someone could implement.

1 Like

I haven't got my hubitat hub yet, I just ordered it recently.

I'm assuming I can't import 3rd party stuff like import org.eclipse.paho.client.mqttv3.* this?

I've not done any direct development with Hubitat as of yet, only remote integrations so I don't know. You should ask @ogiewon or some of the others

That would probably be a better question for the Hubitat team, like @bravenel, @mike.maxwell. @patrick.

Correct, that package can't be imported.

1 Like

Just can't do anything fun.....

1 Like

I can't seem to finish configuring the app to install it. When i enter the bridge it select it but for some reason it doesn't store it there, It makes another entry in the list of devices so it says that an option that is required isn't filled in but it is.