MQTT Client

I wonder if there is a way to implement something along these lines?

Also thinks this is a really important feature and is actually the main thing stopping me from jumping on to HE now (waiting a bit, hoping it will be solved). I might be able to solve it myself as I am a developer, but not being sure about the overall model in HE, I am reluctant to just go and buy it and hoping I can fix it, and fail, and by that have two platforms in parallel, not being able to retire the old one...

One good use for MQTT that I have today on my current platform is that when some sensors are updated, it pushes the values (temperature, humidity and pressure) to my MQTT broker so that other programs/computers/devices can use it. And also the other way around, other devices can push data back to my automation platform and therefore extends its capabilities.

In my case the data is used by and sent from esp8266 devices and also pushed to influxdb using telegraf.

One possible extension of a MQTT client could also be to create virtual devices in HE that subscribes to topics on the broker and is directly updated when things changes ( would be a perfect fit for my upcoming build of the heating control, esp8266 and actuator on the valve for the radiator heating water )

MQTT really is a must have in any IoT/Automation system. So to have to use a bridge (which is code that was ported from SmartThings and not maintained) is a bit frustrating. It works...kinda... but too many points of failure. MQTT should be integrated into Hubitat, as that is its goal (i believe), stand alone, local execution.

2 Likes

I use MQTT to update live weather results from my Ambient WS. You don't have refresh the page or set a URL refresh in the header.

Another vote for an MQTT Client!

Though TBH as a user of just a handful of days I think improving the whole "idiot in a hurry" user experience is more of a priority!

1 Like

This I would like to learn more about. Ambient provides the REST API and a WS interface. How are you using MQTT?

weewx.com and the skin GitHub - poblabs/weewx-belchertown: A clean and modern weewx skin with real time streaming updates, forecast data and interactive charts. View it in action at BelchertownWeather.com

You need to install GitHub - morrowwm/weewxMQTT: A driver for weewx which receives data as MQTT topics containing key:value pairs.
And follow the directions at hostapd WiFi setup for Interceptor driver Ā· weewx/weewx Wiki Ā· GitHub to get all working.

Oh and read Google Groups this cause I went through a bang of a time getting hostapd working.

Ahh this is the part that is sniffing out the wifi traffic from the Display consoles from the various PWS's. There is a similar method of doing a router/sniffer for the Observer IP Module that is ethernet connected.

Couple of issues with this:

  1. Needs another external unit (rPi not a big deal)
  2. Only works for PWS with Wifi data transfer. I have 2 one with display and one with Observer IP module (won't work with OIP)
  3. The add-on sensor data is ONLY available via AmbientWeather.Net so this does not remove the need for the API connection as the add-on sensors also only work with the Observer IP module (currently, last I was working on the HomeSeer plugin)

Ask in the google forum -- Pat uses the Observer I think for his Davis.

Pat is the author of the skin I linked to.

+1 for a native MQTT client. MQTT is an essential component for integrating IoT and Home Automation systems.

1 Like

Is this coming soon?
I've just published a message from my HUB!
Please let it be so!

:+1: on MQTT integration.

This need not be anything fancy and should not require the adoption of complex topic structures like "homie" et al. At minimum, there should be an ability to send an arbitrary payload on an arbitrary topic to an arbitrary broker for any action in any rule similar to the ability to send HTTP requests. Also at minimum, it should be possible to subscribe to an arbitrary topic on an arbitrary broker as a trigger for a rule. Rules triggered in this way would need a way to pass the payload through to actions. Hopefully this could be achieved in a less constrained fashion than the manner in which the Maker API app handles incoming HTTP requests.

Of course, HE could ditch its custom rule engine in favor of an embedded Node-RED instance and then all of the above would be moot. :slight_smile:

Note that it doesn't make much sense to have a broker running in the HE itself unless that broker supports secure, encrypted access from outside the home (e.g. for using MQTT dashboard apps on mobile devices). That would require some sort of dynamic DNS or reverse proxy built in as well as a valid, unique certificate per hub.

My own approach is to use mosquitto running on a Raspberry Pi with TLS and password protection enabled. I use duckdns.org for dynamic DNS and a free letsencrypt.org certificate, automatically renewed as necessary using certbot. (Doesn't that sound easy? :stuck_out_tongue_winking_eye: )

There will likely never be an MQTT broker built into Hubitat. Nor do I think there should be, personally. Client will happen, but broker seems outside of the mission of what Hubitat is designed for.

1 Like

Hubitats MQTT client has already happened and works well. and I hope my existing MQTT alpha application handles most of Kirks needs.

Yes it uses a homie structure because then auto discovery works both in and out but you can just use homie as an ordinary topic structure too.

You donā€™t have to use more than the two standard state and command topics .. I donā€™t see the issue. I donā€™t validate homie topic structures and so if you just used a single state topic or added a command one it will work. However auto discovery wonā€™t.

Also the app can link to ANY existing topic structure for importing devices into HE. However it does not currently handle multiple brokers, but although I havenā€™t tested this, you could install multiple apps, one per broker.

Currently it also does publish to a ā€˜basicā€™ topic structure with a Hubitat/hubname/ root. This is marked to be deprecated though as essentially it just duplicates the homie functionality and is resource wasteful.

I assume this a reflection on the MQTT integration within RM ? if so my app is not readily available yet and I guess new support within RM might become more requested. If itā€™s something Iā€™m not catering for in my app let me know as the next release after the current alpha4 will be a public beta, essentially feature complete. You can already trigger any rule off an attribute (payload) change on any MQTT device.

You use NodeRED extensively so topic mapping is easy :wink:

Kevin

1 Like

@kevin, i composed that generic feature request before seeing your client. I agree yours is very close to everything i am looking for once it is fully complete and ready for release. I will send you a message separately in regards to what I mean by "very close" for your consideration as possible feature enhancements. :slight_smile:

Great - I have tried to make the app really simple on the surface with deep capabilities for power users. I hope it suits everyone. If thereā€™s something I can improve let me know by PM. I value your input here as a user with a MQTT centric architecture.

I do understand the request to be able to send an arbitrary topic/payload from RM although receiving anything back into RM would be very difficult as it would have to maintain subscriptions.

With my current app HE has very powerful capabilities in a MQTT system - dare I say better than Iā€™d ever expected. Just got to ensure itā€™s robust now. Hence the long alpha.

1 Like