Node-RED running inside Hubitat

[eduardo]

I know this suggestion will most likely be declined or postponed for years, but I have to try

It would be great to have Node-RED running inside the hub, for reliability, speed and to save money. Better yet if it could be a Built-In app just like webCoRE.

I know it is not simple, since the hub software runs on a JVM and Node-RED runs on Node.JS, but there are some technologies that make it possible to run a Node.JS app on a JVM, like Javet, GraalVM and some others (BTW, GraalVM, if suitable, could boost considerably the speed of the hub itself).

Currently to use Node-RED you have to invest on a separate hardware, often more expensive than the hub itself. But that is not my main concern, running on a different hardware also means you have a new point of failure, that can potentially bring down all of your home automations.
Running on the same hardware brings lots of benefits, like single point of failure, local communication, easier maintenance, and for most people, using very little extra CPU power.

[aaiyar]

While I appreciate the desire to see this happen, I don't think this is a good idea for several reasons, including:

1. Some nodes that can be added to the Node-RED palette are computationally intensive, and not suited for the power offered by a hardware platform that has less computational power than an RPi 4.
2. It is very easy to misconfigure flows that bring the entire system to a crawl. And I speak from personal experience here. When this happens, there are real advantages to keeping the platform that runs automations distinct from the platform that controls hardware.
3. It is likely to become a support nightmare for Hubitat.

P.S. Since this thread isn't about a current built-in app, I am moving it to the Lounge.

[csteele]

I think a straight port of Node-Red to Hubitat would not be as advantageous as it would at first blush. I actually typed up a "Consider this, please" type of message to Hubitat, 5-6 months ago but could not click send because during the act of typing it out, I decided it would be a bad idea. Node-Red is too granular for logic-challenged people. It's ubiquitous that messages (msg) in Node-Red might be used for it's content, or for just existing. Some nodes look inside the msg, while in other situations, blocking or allowing the message to flow is all it takes. Many/most operate as both. if a msg contains a specific argument, that overrides whatever occurs if that was empty. I came to feel that despite acres of YouTube videos and How-To documents, it would rapidly get too hard to explain.

A visual mechanism is certainly desirable but at least two levels of granularity must be removed for Node-Red to be usable within this Community, in my opinion. I don't need a built in Visual tool because for me, being too logical at times, can use Node-Red with ease AND since I already have multiple hubs and multiple NodeJS 'helpers' connected to all those hubs, modularity appeals to me.

[aaiyar]

@csteele

A visual mechanism is certainly desirable

With this I agree completely. There is something attractive about the interface Homey has for automations. And the Stringify interface built by @klinquist.

But, as you point out, the variety of message handling schemes in Node-RED add to complexity. And with that comes two of the three issues that concern me about this proposal.

[csteele]

Homey's Cards are decidedly NOT granular and that's why it gets generally good reviews. By the time someone finds out it's got no granularity, and needs it, it's too late

Pete has a video for Advanced control of a pair of lights. Initially the "flow" (to use Node-red terminology) was enticing, but by the time he added in 3 different time segments and all the interactions, it looked like a bowl of spaghetti fell on the page.

[jtmpush18]

I agree on the Node-Red suggestion.
However, what do think about Blockly:

[eduardo]

@aaiyar

• Some nodes that can be added to the Node-RED palette are computationally intensive, and not suited for the power offered by a hardware platform that has less computational power than an RPi 4.

That's true, but how often are those nodes actually running in the course of a day?
The app could also be restricted to more powerful models, like C8 Pro and future models.
Of course it could become a problem, but so does every other rule mechanism if you misuse them.
A faulty community driver or app could use too much CPU. A single chatty device can also be a big problem.

@aaiyar

• It is very easy to misconfigure flows that bring the entire system to a crawl. And I speak from personal experience here. When this happens, there are real advantages to keeping the platform that runs automations distinct from the platform that controls hardware.

I don't agree on "very easy", since I'm using Node-RED for all my automations for almost 2 years and I didn't experience any problem. Again, albeit more unlikely, you could also misuse Rule Machine and have the same issue.
I do agree though on the benefits of running on a different platform, if you have a less powerful hub, if you have lots of CPU intensive automations, or if you just prefer it that way.
But it could be an option, the user could decide it, my suggestion is not that if you use Node-RED it should be mandatory to run it inside the hub.

@aaiyar

• It is likely to become a support nightmare for Hubitat.

Being a professional software developer/architect for over 30 years, I really understand that concern, and I thought about it while writing my suggestion.
But there are solutions. The support in my opinion should be restricted to the installation/upgrade of the app, which would probably be very little or non-existent.
It doesn't make sense for Hubitat staff to support flows, nodes, and anything the users do inside the tool. The tool is not developed by them.
I think it is even the same on Rule Machine, if you found a bug, great, you'll have support, but if you wrote a poor rule that is causing you trouble, it is your problem. They can't just hold users' hands and help them writing their automations/rules.

Likewise, webCoRE is not written by Hubitat developers and is available as a built-in app. I don't think Hubitat staff is (or should be) helping users with their pistons.

TL;DR
I do understand your points and concerns, I just think the option should be there, you are not obligated to use it, and Hubitat team is not obligated to support automations/problems that users created. Node-RED is not for everyone.

[rocketwiz]

@eduardo

running on a different hardware also means you have a new point of failure

Or additional redundancy . I might also mention that my NR setup has been ultra reliable - has not required a restart other than when updating nodes.

It hasn't been mentioned that there would also need to be a file storage system. I use NR to store camera snapshots for example, where would these be stored in Hubitat?

[eduardo]

@eduardo

I do agree though on the benefits of running on a different platform, if you have a less powerful hub, if you have lots of CPU intensive automations, or if you just prefer it that way.
But it could be an option, the user could decide it, my suggestion is not that if you use Node-RED it should be mandatory to run it inside the hub.

I didn't have any reliability issues with Node-RED either. What I'm most concerned about is a hardware failure.

[Alan_F]

Having two separate hardware setups means one can monitor the other and if one fails, the other can notify you. Separate hardware may fail more often (since for failure interval x you now have two pieces of hardware that may fail after x), but your reliability (defined as the system working when you expect it to work) may also be higher, since you'll know immediately when something fails, not some time later when you notice the lights didn't turn on as expected.

I have a rather complicated setup now with two Pi4's, two Hubitat hubs, and two instances of Node Red all doing various tasks. I'm running two instances of Uptime Kuma to monitor everything, and every important device or process is pinged or queried or has a heartbeat signal running so I know if anything goes offline.

Which is to say, even if my setup was just 1 Hubitat and 1 Node Red and the Hubitat could host Node Red, I'd choose to run it on separate hardware.

[nwmclean]

"Currently to use Node-RED you have to invest on a separate hardware, often more expensive than the hub itself. But that is not my main concern, ..."

Not the case for everyone. A lot of people here run Homebridge on a separate server. Me personally, I have a Mac mini as a home media server amongst other things. "Other things" included Homebridge until recently.

It was simple to install a node red service on the mini too. Now I have migrated ALL automations out of Hubitat (was using rule machine) to Node Red. Also migrated ALL Homebridge modules across to Node Red too.

• Have disabled rule machine in the Hubitat, will delete it all some day.
• Have decommissioned the Homebridge setup too.
• And disabled the MakerAPI instance that was talking to Homebridge.

Happy to be free of the above...

"...running on a different hardware also means you have a new point of failure,"

On the bright side you gain a level of redundancy and lose a serious SPOF.

[eduardo]

@nwmclean

On the bright side you gain a level of redundancy and lose a serious SPOF.

There is no redundancy in having Node-RED running on a different hardware.
It allows you to have redundancy, but you'd need to have 2 instances of Node-RED running on 2 separate machines. If you have just one, and the hardware fails, where is the redundancy?

Possible failure scenarios:

• Hubitat hub failed: Nothing will work, obviously.

  • NR is running inside the hub
    Doesn't make any difference, even if it is a software problem on the hub part only and NR kept running, there is no point in having NR running well while your hub is not responding.

  • NR is running on a different hardware
    It will not save you from catastrophe. Even if you have 10 redundant NR instances.

• Node-RED hardware failed

  • NR is running inside the hub
    Your hub has failed. Nothing will work.

  • NR is running on a different hardware
    All your automations are gone, unless you have real redundancy. Otherwise you have to setup a new hardware and recover your NR instance. For different people the time to have it all working again will vary a lot. I believe I don't need to stress how important it is to have your NR flows backed-up.

---

I also have a number of other services running on a different hardwares, and I'd still keep them running even if there is the option to run NR inside the hub. I'm not afraid of more complex setups, they just need to make sense.

I particularly trust the Hubitat hardware more than I trust my mini-pc.
Although my mini-pc is very new, I already had a problem with its cooler and had to wait ~20 days to receive a new one of the same model. Luckily the load on it is so low that I was able to keep it running without the cooler by keeping the pc open (without the plastic case) with an improvised USB fan.
I don't live in a country where you can get almost anything at your door next day like in the US (yes, my problem, but not very easy to fix ).

---

Another advantage I see is the fact that running on the same hardware makes it possible to have local communication, improving the speed, which might be negligible most of the time, but at times where your LAN is loaded, it could be significant.

Having said all that, and being redundant (pun intended), for me it makes sense to run inside the hub, for some people it might not. All I want is to have the freedom to do it. The option to run on a different hardware would still be available.
There could be a hundred people posting here about how much better other setups are (and they likely are, for them, different people, different needs), but in the end:

This suggestion is not taking any options off the table, it is just adding one.

[vitaliy_kh]

@nwmclean

It was simple to install a node red service on the mini too. Now I have migrated ALL automations out of Hubitat (was using rule machine) to Node Red. Also migrated ALL Homebridge modules across to Node Red too.

What is the reason/advantage to use Node-Red from Rule Machine?
All my automations are running on C8 in RM (in addition I have C7 and HA as a complementary hardware just to bring all Devices to C8 via HADB). Yes, RM is not perfect and has few problems but otherwise I am very happy with RM.
So, why I should even think about NR or anything other then RM?

[harold.min]

@vitaliy_kh

So, why I should even think about NR or anything other then RM?

If you have no need, you shouldn't. Options exist for those that can't execute their vision within the confines of RM.

[nwmclean]

If RM does all you want, stick with it. No reason to change. For me it was not an exercise to get away from RM for automation rules.

I wanted to:

• break away from the "unsupported" 3rd party Broadlink drivers I was using in Hubitat to drive a couple of Broadlink IR blasters used to control some dumb appliances
• move away from using Hubitat Safety Monitor (HSM) for my security system and logic
• unwind my dependence on Homebridge for exposing non-Home kit devices to HomeKit
• stop using the Hubitat app as part of presence logic (was so glad to turn off geolocation in that iPhone app on all family phones!)

(above not necessarily comprehensive. And not likely the end of what I will do in future)

I found support for all the above in Node Red, It was just a natural move from there to migrate all automation/rules onto Node Red too.

[ogiewon]

@nwmclean

stop using the Hubitat app as part of presence logic (was so glad to turn off geolocation in that iPhone app on all family phones!)

@nwmclean

I found support for all the above in Node Red,

Would you please briefly explaining how you're using Node-RED for Geolocation based presence? Is anything running on the phones? Just curious...

[aaiyar]

@ogiewon

Would you please briefly explaining how you're using Node-RED for Geolocation based presence? Is anything running on the phones?

Obviously, I'm mot @nwmclean, but I used Node-RED for geolocation. I used OwnTracks on my phone, and the following nodes in NR:

node-red-contrib-owntracks to decrypt messages from OwnTracks ...
and
node-red-node-geofence to interpret lat/lon and set geofence regions.

The neat thing about node-red-node-geofence is that regions can be arbitrarily shaped - for example to match the route I would take while driving home or to work .....

[eduardo]

I agree 100% with @nwmclean's statement:

@nwmclean

If RM does all you want, stick with it. No reason to change.

But just to elaborate a bit more, there can be many different reasons to use Node-RED instead of Rule Machine.
For me these are the 2 main ones:

1) Readability/maintainability

Theses concepts are interconnected, but just to illustrate it:

You don't need to have a super high IQ to understand what this flow does. Exclamation mark is a symbol of negation on most programming languages.

• At sunrise time, from April to August, if I'm not traveling, shades 4, 5 and 6 will move to shade mode (they also have a semi-blind mode).

If I want to change the months, I double click the BigTimer node (the first one), select the months I want, change the label of the node (to keep it readable), click Done and then save/deploy. That is it. In 15 seconds or less I could make this change.

What about getting it to execute even when I'm traveling? click in the !Traveling node, delete it, connect directly the output of the first node to the input of the shade node. Save/deploy. Done. Less than 10 seconds.

Important: Like with programming languages, there can be almost infinite ways to reach the same result. You can create the same automation shown above in a way that it is completely unreadable, resulting in the need to open every node in it to understand what it is doing.
Having said that, readability is much more easily achievable in NR than in RM, in my opinion.

2) Node-RED ecosystem

Node-RED is open source, with lots of people contributing with improvements and fixes, it is also widely used, even beyond home automation. This results in a very stable/reliable tool.

Apart from the core Node-RED and default set of nodes, anyone can create nodes and make them public.
This opens up a lot more possibilities of automations. For instance, recently I started using node-red-node-google to connect NR to my calendar and run some automations when some specific calendar events are triggered. How would I do that in RM? I have no idea.

---

The downside to me was the beginning, the learning curve is a bit steep, but once you understand the tool, it is amazing.

[harold.min]

@eduardo

This opens up a lot more possibilities of automations. For instance, recently I started using node-red-node-google to connect NR to my calendar and run some automations when some specific calendar events are triggered. How would I do that in RM? I have no idea.

The functionality there is awesome (if you utilize those services). I have a flow that reminds me of an event an hour beforehand and then calculates the travel time so I know when to leave. This triggers a cast on my Google homes that announces all that information. It also utilizes the Tessie HA integration (could use @kahn-hubitat's Hubitat app as well) to warm up/cool down my car if the temps are within specified ranges.

[ritchierich]

@eduardo

This opens up a lot more possibilities of automations. For instance, recently I started using node-red-node-google to connect NR to my calendar and run some automations when some specific calendar events are triggered. How would I do that in RM? I have no idea.

You can with my community integration:

[RELEASE] Google Calendar, Task, and Gmail Search and Gmail Notification Device

Google Calendar, Task, and Gmail Search integrates Hubitat Elevation with your Google Calendar, Tasks, Reminders, and Gmail to automate triggers based on items found matching your search criteria: Optionally toggle a child virtual switch Send Push, SMS, and TTS Notifications Run Rule Machine rule actions Gmail email notification devices can also be created with this application which will allow you to send email notifications directly from your Hubitat Elevation hub using the Google APIs with…