Node Red MQTT Discussion

I would argue the dragino sensors, and the like, are at consumer price levels and use complexity.

The hub prices are coming down, especially for inside-only use, but the real barrier to consumer use of LoRa of any flavor is the complexity. It takes more work to setup a gateway, setup a network sever and application server (even if using a cloud one), understanding how to activate devices, and getting the data out of the sensor and into where they want it than most consumers will put up with.

i integrate all my LoRaWAN with node-red and Hubitat with no issues, via mqtt of course. But I wouldn't say that solution would be acceptable to the average consumer.

2 Likes

Thanks for the pointer to Dragino, I’ll check them out. I’ll see if I can get a LoRa gateway for “testing” on a NFR basis from my Cisco rep. :wink:

And thanks also for reminding me that I need to learn more about MQTT as well. I think I’ll do that on my Home Assistant installation, rather than Hubitat, though. But if you happen to be familiar with both, I’d be interested in your thoughts on Node Red on HA vs HE.

I would never do mqtt inside of anything, home assistant or other.

I would setup a separate vm or rpi with mqtt, or run mqtt along side (but not inside of) something like home assistant or other apps on a multi-use rpi.

But that said, many people run mqtt inside of node-red or HA just fine. I have a visceral aversion to it though, for a few reasons.

I also run home assistant, just as a side comment. I mainly only use it for homekit capable devices though.

1 Like

To drag this a little further away from the OT...

POE lighting seems like it might be close to breaking into the consumer market too. And lights are more interesting than sensors IMO.

Agreed, but there isn't too much out there yet. PoE Cameras abound, but the Philips strategy is indicative of the current state of overhead LED lighting. Their Signify Interact IoT+LED Lighting platform is strictly commercial, meanwhile their Hue consumer brand is still limited to simplistic bulbs and strips--hardly cutting edge. The most I've seen for consumer-level PoE LED lighting is for exterior/outdoor soffit downlighting.

I have a friend building a new home, and would love to recommend a lot of things to him, but so much of what I do on a commercial basis is "just around the corner" for homeowners but not here quite yet. :frowning:

Like I said, lots to learn about MQTT--and Node Red, for that matter. Since HA is a fully containerized solution, putting Node Red alongside it is primarily a matter of available CPU & RAM resources. But for supportability purposes, I'm with you going old school and putting it into a separate VM.

At work that's a no-brainer to throw onto an existing multi-node VMware cluster, (I'm sure the resource consumption wouldn't be much more than a rounding error), but I'm not big enough of a nerd to have one of those at home. :nerd_face:

Somewhere, I got in on a PoE discussion.

Thing is, with a limit of 60W (or less) to stay as a <= Class 2 device, you can't really get much light per cable. So, you end up with a situation where you need to run a BUNCH of PoE cables to a lot of locations. And, you need to run the connection directly to each device (you can't tap mid-run into an ethernet cable nor can you string multiple bulbs together like you can a 14/2 electrical wire). Maybe, that works in a new installation--but far from ideal in an existing house. And, it certainly isn't flexible with current fixtures.

With 60W you could do a strip of MLV or ELV lights.. Just not sure if the vendors would be able to get the lighting strips cheap enough with PoE systems for commercial use.

Not entirely true, but you're right, this isn't a good case for retrofits, at least not unless you're going back to the studs. Not disagreeing with you at all on that point, but if anyone else is still following this thread that I've so ruthlessly hijacked, (sorry, folks!), hopefully the below is of interest.

In commercial environments, we deploy IEEE 802.3bt Type 4 POE and Cisco's enhanced version of that called UPOE+ at 90W on low-voltage CAT6 cabling. You can daisy-chain PoE LEDs or use PoE pass-through to extend the reach of single runs. For example, Igor's typical office ceiling luminaire is 20W, meaning you can easily power 3 of them daisy-chained together, plus additional lower-power devices like occupancy and temperature sensors, (typically 5V USB), door badge readers and locks, and so on with a single run. For home fixtures that only draw say, 5W, you could easily support 15 pot lights on a single run. Sadly, I have not seen pot lights with daisy-chaining capabilities emerge on the market yet. (Igor may have an applicable patent that holds that up due to licensing/royalties, but I'm not certain.)

You can even go beyond PoE with DC cabling for power distribution with solutions from companies like VoltServer. Their product is IEC 62368-1 LPS approved for sending 1kW over a single copper pair up to 2km. Using that, you can centralize power for entire PoE switches, remote UPS, and all sorts of applications.

Sure, it requires non-standard cabling rather than good ol' CAT6, (18 to 12 AWG pairs vs. 23 AWG in CAT6), but it's available from any Belden supplier or similar. I haven't had a project to work with this yet, but it's very cost-efficient, in terms of both installation and operations, since you don't need to run the cable in conduit and--like PoE--you don't really even need an electrician. AND it's safe to touch--power is cut off within 3ms of an abnormal condition. This may not fall under NEC Class 2, but it's been deployed in hotels, schools, and hospitals, so you know it's approved.

Check out this article from a few years ago when they were still considered a start-up: VoltServer Solution Provides Power That Is Safe To Touch.

I run it within Node-RED but only use it for internal Node-RED things like creating & handling certain kinds of "events". Truthfully that could probably be replaced with Link nodes but MQTT seems less spaghetti-like. I prefer the Mosquitto MQTT broker for the "real" comm stuff. My pie-in-the-sky goal would be MQTT as the backbone and everything else including NR and HE hanging off of that..

Me neither. My system is an MQTT centric system. It uses MQTT for the device central state reference and for control so I use a standalone Mosquitto broker.

The first thing I look at with any new device is does it support MQTT natively and if not do any of my controllers support the device such that I can enable it via MQTT and hence make it available to everything else. This is pretty much universally achievable now so all my controllers have access to every device in real time.

Very happy with my choice of MQTT and no specific controller centric dependence at the moment, .and I only see it getting better.

2 Likes

I also love NodeRED - my reticence with it is that typically people are tying their implementation to a specific controller which has custom nodes available in NodeRED. This makes you system controller specific and will cause hurdles later if you switch controller. Sticking with MQTT can , but doesn't always avoid that.

1 Like

The trouble is certain integrations like HE Nodes for NR are just so easy to incorporate vs going the MQTT route. I am weak and not yet worthy...

But I agree with you..

Using MQTT in NodeRED is more awkward as there is no 100% reliable way to keep NR state in synch with MQTT so an MQTT read is typically required before something like 'if xyz is on' to be confident. But it's do-able. There should be such a node using NR persistent storage but there isn't. The HE nodes provide a dependable state so are much easier to use.

1 Like

If only there was an MQTT client node in node-red with persistence.... :wink:

2 Likes

I know you have an itch to write one...

2 Likes

I've looked at it a few times. The MQTT nodes are on git and it would be doable. I seem to remember someone else made one at one point, but it must not have worked right because otherwise I'd be using it...

Might add that to my project list.

EDIT: This is the one I was thinking of. I know I didn't use it for one reason or another though.... I'll try it out again and see if I remember why.

2 Likes

You mentioned you would never put mqtt inside of anything in your home. I have always thought it was overly bloated even though people say it's very minimal.

Why do you think so many devices have mqtt inside? I also have other friends who program and think the same thing, so I'm just curious what your opinion is?

I think you misunderstood my comment. I use mqtt extensively.

I would never install an mqtt broker software inside another software such as home assistant. I would install the mqtt broker software on its own either directly or through a docker container. But not INSIDE OF another application.

2 Likes

Ah, okay. Thanks for clarifying.

I personally would never use mqtt as they're just always seems to be way too much overhead for me.

It is however used in the industry so I guess using something that is standard does make it a lot easier to port from project to project.