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.
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 ?
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
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.
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.
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.
There are two very good examples that I can use as a reference for implementing MQTT.
Home Assistant (native and component)
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 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.