Ok I understand what MQTT is and what it does. I totally get the pub/sub model. Given HE providers the MakerAPI I assume the only value to MQTT is coordinating with devices that don't have HE support
Am I missing anything?
That and hooking up other systems. For example, I have a simple motion detection application on a system that is fed all my camera streams. I wanted to have control of the process (start/stop via systemd) from a Hubitat dashboard. So I created a virtual switch and added it to the dashboard and MQTT is how the video system gets told when the switch is tapped.
You can also use the MQTT broker for pretty much anything your heart desires AND you can set the "retain" flag on topics so that anything that subscribes to it will get the last message when it connects, like on startup.
Wow, the IoT is so much bigger than HE and what it supports, very much so.
MQTT is a generic protocol to let so many different things communicate, it really has nothing to do with Hubitat, on the surface anyways (as some custom apps/drivers may use MQTT under the hood to communicate instead of REST, websocket, etc etc)
@morningz I TOTALLY get the big picture value of MQTT I was questioning the where it plays specifically with HE.
I have used more Message Queuing systems in my career (Kafka , IBMs MQ etc) then I care to think about and written a few as well and I understand how MQTT is optimized for the IOT space.
hope this clear things up
I don't think MQTT does queuing but that is not really relevant to your question. For HE, it's just another way to integrate.
The value is on the other side of the broker, MQTT provides slight more structure than HTTP. If I create a device then I have to chose how or who I want to connect it to. HE and Maker API ? Custom websocket or REST? Which ones? Anything that can do MQTT? Of course it's not quite that simple in MQTT.
1 Like
Decision time, I’m going to choose the basis for how all my devices and controllers communicate... for maximum future compatibility...hmm, bit of research . IP and MQTT fit the bill.
Now let me choose devices and controllers... almost all controllers and an increasing number of devices support MQTT. So I’m not tied to one specific controller I can use several all at the same time or swap from one to another quite easily.
What about the radio linked devices ? I’ll connect them to one of my controllers that speaks MQTT then everything can talk to each other. Same with any specific integration one controller offers, I can expose that to everyone via MQTT.
Very flexible and open.
But I’ve got HE why should I use MQTT ? That’s not such an easy sell, but it will become increasingly attractive over time I believe as more direct MQTT devices appear, people swap controllers or their system grows in complexity.
3 Likes
This is my ultimate goal as well..
Currently NR is at the "center" of such communications but I would prefer MQTT with NR as a "rule+event manager/coordinator". The trouble is @fblackburn's HE nodes are extremely handy so for now HE<->NR<-MQTT<->others (pws etc).
Your app looks really cool too though and hope to explore it at some point as it seems to provide what I am looking for.
edit: is "homey" the standard to use going forward for these kinds of messages?
MQTT is really a state storage database supporting commands to control devices as well. NodeRED is a lot of things but primarily a logic engine with an amazing number of feature and device nodes. They work really well together to trigger off events, e.g. an update to MQTT.
One awkward thing about MQTT is it's not so easy to find the state of a device. You can't just ask but it will tell you if it changes. That is why it's awkward to do something like the following in NodeRED
If the motion sensor trips and the light is on then 'do this' because you can't do the 'light is on' test easily. It's not impossible to get state from MQTT - just a bit convoluted, (you have to subscribe to the topic again).
Node-RED has much the same issue and so the workaround is to cache the states within NodeRED for MQTT (but there aren't reliable nodes for this .. yet) . Why the HE nodes work really well is they have an inbuilt caching feature and so state is available. That makes it very usable for the 'and device xxx is in state yy' tests.
My only caution with direct nodes to controllers is that your flows (rules) are tied to that controller and the architecture of that node e.g. having that state cache. This makes it much harder to adapt your flows later to a new different brand controller... but of course far better than having the rules within the controller itself !
1 Like
TL;DR There is no requirement at all to understand or implement homie to use my MQTT app
There is no real standard. There are two popular emerging 'discovery' protocols homie and HA. The HA one just provides pointers to where the topics are that contain the payloads which could be within homie (as they are in my app). I support both.
homie , is an attempt to create a standard to recognise devices across platforms (and MQTT critically needs this) but it is not yet up to the task, particularly at the higher levels of identifying device types like say a washing machine. It is good for exposing capabilities/attributes of a device though.
I had to choose something or make my own up which would not have assisted MQTT adoption at all. The fact that it is homie compliant will help for controllers that support that like OpenHAB, and Homey. BUT - you can totally disregard the homie protocol if you wish and just publish the key payloads for the state information and a command topic to control it. homie publishes extra information like friendly name, type of device, type of payload and the allowable range e.g. integer 0-255 and whether it is controllable. This makes a single homie node tree quite large but turning off 'complete homie' (an option in the app) reduces it back to the more typical 1-3 payloads and less intimidating.
The nice thing is that if you use the simple MQTT approach but later want to use homie (hopefully it becomes more prevalent) then you can just turn it on. But your simple structure won't change or break, you'll just have more information included on MQTT.
1 Like
Ha!!!! I meant "homie"... sorry.
keep thinking of this.
Okay thanks for the explanation!!
It's unfortunate there's a homie protocol and a home automation controller called Homey manufactured by Athom (that in itself also supports homie)
1 Like
There is another aspect of MQTT of interest. It is not tied to it's clients and won't lock up if they come and go. Indeed MQTT can be configured to deliver any messages the client missed if it went absent for an hour if needed.
What this creates is a way to link many controllers and devices together without getting into the lockup situation when one goes down, or a 'deadly embrace' situation. So you can have multiple devices and controllers all talking to each other and not getting locked up. Very powerful.
In theory you can create a failover controller operation where another device steps in if one fails. There are many other associated things to work through using such an architecture though and Z-radio devices attached to a controller wouldn't transfer but you could adopt a Z-Wave to MQTT or ZigBee to MQTT solution. HA's just announced ZigBee implementation for example uses MQTT as it's underlying mechanism.
1 Like
The Z-radio to MQTT solutions are potentially interesting as they provide a way of not tying (pairing) these devices to just one controller. Instead all controllers can use all Z-devices. No more re-pairing. The primary/secondary controller implementation is really not viable.
HE has very helpfully announced a controller-controller transfer service for such Z devices.
1 Like
