Node-Red MQTT Integration

Something I've been doing for a while now is passing Hubitat devices to MQTT via Node-Red. I may abandon this path after the full Hubitat native MQTT app is complete, but haven't really decided. I've been slowly working towards making it generic, and pushing it to the public distro, but am not quite there yet.

How I do it, is I use MakerAPI and the event websocket. That is where I could use some opinions from others.

Q: For devices to pass to MQTT, I have 2 different sets of code.

a. On one code set, I simply pass ALL devices in the designated MakerAPI connection to MQTT. The thought here is that users would install a dedicated MakerAPI app instance for MQTT devices in Hubitat. Then, anything in that MakerAPI app instance automatically gets passed to MQTT. Node-red periodically looks for devices/added and removed from the MakerAPI instance and automatically updates its list - no user intervention needed other than adding/removing devices from MakerAPI. This is very simple, and works (more or less) perfectly.

b. On another code set, I've been experimenting with using Node-Red dashboards to allow dynamic selection of devices to MQTT. The PRO is that you wouldn't have to pass every device in the MakerAPI instance to MQTT if you didn't want to. The CONs are that now you have to do 2 steps (add device to MakerAPI, then enable device in Node-Red dashboard). Another CON is that Node-Red dashboards/checkboxes are a little goofy. I've spent a LOT of time to try and make it work flawlessly 100% of the time, but there are still graphical issues. I'm not really sure it is worth the added complexity versus option 1a.

Thoughts on path a vs path b?

1 Like

What was your motivation to develop path B? I don't see the benefit of having the Node-Red dashboard but it might just be me

1 Like

Well... Very good question. :slight_smile:

Originally I just wanted to see what I could do in Node-Red dashboards. I don't really think there is a good technical need for that level of device selection/de-selection. In fact, I think it really just adds complexity.

The code is MUCH simpler just using all devices listed in the Maker API instance.

I guess my thought process was that before I ripped out the 90% working node-red dashboard version, I would see if anyone things that the REALLY need that capability.

I would go with that. Having two places to make the same selection makes no real sense to me and could lead to possible confusion...

2 Likes

Are you finding the current feature set in the app suitable for your needs in this regard ?

Is it working OK ?

Having MQTT as a bidirectional path for status and control would seem more logical for your application and also any other controller device you might want to include later so I'd like to address any issues that you might currently have.

Yes, I think so. I'm not doing anything in my node-red implementation that the app can't already do today.

Mostly, but not fully. BUT I'm still on alpha 3b. :slight_smile: I need to upgrade. On 3b I see recurring times when the connection to the broker drops and doesn't reconnect without manually hitting initialize on the MQTT client device. But I reboot my broker often, so that might be somewhat self-induced.

It is, and my node-red implementation is bi-directional to/from Hubitat. The read-only part is seamless, and injects homie compliant topics to the broker. That part was very easy. The control/write to Hubitat part is kludgy the way I did it, but it does work. That is mostly why I haven't published the flow(s) - the writing back to Hubitat part.

I don't think most people (or maybe anyone?) would want to use my node-red implementation over your native app. I don't see that there is really any good reason to... Unless the user just doesn't want any/wants to reduce user code on their Hubitat hub, as the node-red implementation route requires zero code on the hub.

I will say, though, that the way I did the mapping back to homie structure makes more sense to me, though - unless that changed in alpha 4 (again, I'm still on 3b). While mine is VERY similar to yours, there are some differences. For instance for a switch instead of onoff as a property, I use the native hubitat vernacular of switch, and use "set" on the switch to do commands - which is technically more homie vernacular compliant.

This was the biggest overhaul in alpha4 - you'll be impressed I think and I would recommend you upgrade. In alpha3 it was also quite easy to get multiple versions of my app running simultaneously and so one when logging on would kick another off which then might attempt another reconnect (duplicate clientID's on MQTT).

It's also much faster ..

I'm interested in whether I could improve here. The issue is really that I find the homie spec poorly defined and deficient (or deliberately evasive) in certain aspects - like for example the $type topic. There's nothing really to test the structure against either.

In alpha4 I had started to make provision for people to use their own choice for defaults for things like onoff dim /set true|false etc. rather than enforce the homie recommendation but I'm a bit loathe to persue this as it will make the end implementation less compatible, and MQTT certainly could do with some agreed compatibility across devices.

I'm also interested in whether we could create a better top level device (or capability) topic in homie such that we know for example when a device is a thermostat or keypad. homie doesn't address this much at all but it would be useful in instances like yours where you're trying to choose and create a device from the MQTT topic structure but not sure what the device actually should be.

I don't want to veer your thread off topic but you're exploring the same issues that I am and so any input is appreciated and getting a consistent approach would pay dividends I think.

I agree Node-RED Dashboard could do with a bit of a graphic design overhaul ... but it's functional.

a

.. and if you do decide to use the MQTT app you'll get a lot of the b functionality included.

1 Like

I would say A as well.

I decided to move a lot of my logic away from NodeRed and into a dedicated node app as it performs a bit better than NodeRed does (no overhead). I have the script parse a dedicated Maker API instance and then subscribes to both the Event and Log websockets and it then updates my MQTT server from there. I capture both so that I can do both logging and MQTT updates from the same code base.

I'm curious. How did you setup your node server with HE?