Am I missing out on Node Red

The hub has a quad core processor. But, Hubitat is a Java Machine fundamentally. It's a Java Machine running a Java Database all on a Linux OS running on a quad core ARM processor. If I had to speculate, I'd be all 'squinty eye' on Java. :smiley:

But I'm not a Hubitat employee.. so my 'eye' doesn't contribute much, if anything. I think, again, it's the reason I've had multiple hubs for my entire Home Automation interest. And for this, I'm saying Node-Red is just another hub, as is HASS, et al.

3 Likes

Thanks, @csteele, for your insight on the internals of HE.

However, there is a little confusion (for me anyway) that I'd like to separate out. Let's use a simple motion lighting process for the example:

motion detected -> detector to HE via mesh -> HE processing -> HE to switch via mesh -> light on

If the processing is done external to HE then the block "HE processing" gets replaced with:

-> comms to external system (via Maker, MQTT, ???) -> processing -> comms from external system (via Maker, MQTT, ???)

Since everything outside of "HE processing" in the first case is a constant, or nearly so, for any given system the external processing time plus the comms time (twice) would be expected, by most people, to be longer than the "HE processing" time. But it's not, at least for most users.*

IMO, this points to inefficiency in HE's processing exclusively. Whatever other loads HE has (getting weather date, whatever) would only make it worse. I'll point out that I have only 30 devices, about 50/50 Z-wave and Zigbee, and my processing on HE is all with the canned apps, no RM, so it's a pretty clean comparison against NR with the equivalent simple flows.

I'm so interested in this timing thing (curse you, @april.brandt! :wink:) that I'll probably setup NR on an Rpi (using NR's bundled install) and test again...but not today. I regret that I did not save the Ethernet packet captures that showed the external, to HE, timing from my previous experiment but I'll do so next time.

*it seems I picked the worst possible "external system" because my response times with HE alone are less than half of what I got using NR. What I setup was NR in a Docker container (don't ask) on a box that I'll just call Server. Also on Server was the MQTT broker. So my external consisted of HE -> MQTT broker -> NR (in the Docker on the same box) -> MQTT broker -> HE. You'll have to take my word for it that Server was more than up to the task and much beefier than a Rpi.

1 Like

Dunno. I have always ran Node-RED in docker, and it has always been faster than when I had the rules in RM. :man_shrugging:

I can make very fast groovy apps, and am more than capable of programming in groovy... But I really don't want to manage a bunch of homemade apps long term, so that wasn't attractive to me.

3 Likes

I didn't expect this to blow up so much, I'm struggling to keep up. I'll enjoy catching up on everyone's views on NR

1 Like

If the Hubitat Hub had that ONE item to process then Offloading wouldn't bring much to the picnic. But the point of Offloading, to me, is to get more consistency, with the least possible long term effort.

As @JasonJoel indicates, maintaining a Groovy app next year, with zero minutes looking at it between, is an error waiting to happen. It might be true of Node-Red too.. upgrades over the next year might break a flow. But that's what backups are for, right? :smiley:

If I assume that the Z-Radio queue management is reasonably efficient, then it's best times, it's most responsiveness, is what I want to see all of the time. If there's variability in response, I want to find a way around that. The answer for Me, is to use more hubs. To Offload the things I can, so that my Hubitat Hubs are a) consistent and b) at the 'best' end of responsiveness.

Said yet another way... I've always thrown multiple solutions at my Home Automation problem set. Hubitat is at the core of my most recent iteration. I have multiple Hubitat hubs, as well as a set of NodeJS 'helper hubs' thrown at the current problem set. This is NOT final for me. New hubs, new solutions will present themselves. I'll keep whacking away at this until someone does come up with a full and complete solution to my problem set.

3 Likes

I think itā€™s important to understand where speed is critical and desirable. In the context of saving a couple of 100 mS and compared to other benefits.

You have a scheduled event for 6pm .. not important
You log or send a push message when an event happens ..not important.
You walk into a room and the PIR brings the lights on .. important
You approach your house and the door unlocks .. probably not important.
Temperature drops and you bring the heating on early ..not important
You approach your house and the the lighting, heating comes on, not important.

All my automations slow down from 500ms to 5 secs.. problematic
All my automations slow down from 500ms to 50 secs .. disastrous.
My automations fail,. disastrous.

Really the main speed need is is event driven/immediate reaction and typically these are Just motion >lights or switch/button press for lighting. These can be sped up many way, most effectively by direct wireless association sensor > light or using direct hardware. Agreed logic can then not be applied easily.

I venture to say that most people disappearing down the NodeRED Rabbit hole want reliability and repeatability*, not necessarily speed but thatā€™s a bonus. Things must complete in predictable sequence order too, If this is the reason for ā€˜burrowingā€™ , and it does appear substantiated , then Hubitat take note as this shouldnā€™t be the case and it indirectly provides a migration path elsewhere.

*Actually NodeRED offers many diverse and useful nodes and features that RM/HE donā€™t have which is a big draw too.

7 Likes

Someone emailed me with a valid comment that NodeRED is only a solution and of interest to a minor group of users, the techies, thatā€™s true. Hubitatā€™s market focus and volume is the other 90%.

Even more a reason for Hubitat ensuring RM is the engine of choice. The fastest, most reliable and easiest to use, and no installation hurdle.

1 Like

Well, I would point out that home automation as a whole is mostly in the realm of techie users... :man_shrugging:

4 Likes

I meant really within the existing users category (owners)

What % of existing purchasers could (or want to) set up a separate NodeRED server and learn to make flows. Every manufacturer of hubs is trying to widen the base of the pyramid making HA accessible to more and more users.

2 Likes

True / good point.

1 Like

What % of users know about node red prior to purchasing their hubs? I find that there is a lot of ignorance floating around the forums until one gets curious and asks. Or sees a post that sparks interest. I'm that person. I discover only by happenstance that someone mentioned it and it sparked my interest. There is a large number of users that follow the "norm" until they're led to a rabbit hole.

3 Likes

HA in the last couple of years has really evolved, moving from I wish I could do this or buy that productā€™ to so many things I can do now by so many different ways.. ā€˜ I wish I had more timeā€™ !

The confluence of things like IP capable controllers, NodeRED, IFTTT,Alexa, Google and cloud services, local APIā€™s , all separately very powerful but now combined,,, fantastic times ..(for techies)

One canā€™t but admire what IBM did with NodeRED

3 Likes

How would say an inbuilt Blockly version of RM serve peopleā€™s needs who think they are ā€˜missing outā€™ on NodeRED. It would help a large volume of users I feel.

@bravenel . Any merit at all ?

2 Likes

You supped that ā€˜Drink Meā€™ bottle.. :cup_with_straw:

1 Like

I think @bravenel hit the nail on the head years ago when he said WebCoRE should produce Groovy, not interpretive code. WebCoRE already has an online Editor, producing exchangeable code. It runs on the Cloud or via a local instance. If only it created a 'child app' that can be pasted into Hubitat, there'd be a great RM alternative for people that don't like the RM UI.

2 Likes

Just to clarify any misunderstanding with this, I assume you mean ONLY when defining/editing/deleting pistons as the pistons run on the HE hub locally not in the cloud. :+1:

2 Likes

@csteele.

I sort of avoided the WebCore comparison because it addresses some but (as you said) not all these issues. Plus itā€™s definitely not on Hubitatā€™s party invite list.

I was trying to promote RM as an existing asset to consider a new UI (via an already available code base upgrade inclusion) and with that clearer understanding and accessibility to more users.

But of course, I agree with everything you say.

Why don't they or are they not interested in doing that?

Why??

:smiley:
I was told long ago that ANY question beginning with "Why don't THEY..." has a single answer: Money. :smiley:

Hubitat is building little Hub gizmos.. There's no place for an external gizmo in that scenario. They don't want to Host the App, with GIGs of storage forever, so that people can 'recover/exchange' code for the tiny percentage interested.

I'm suggesting: for those of us that already are on the corner at the intersection of NodeJS server and Performance, we'd find an attractive alternative. No one else would. :smiley:

2 Likes

@Shaneb

Congrats on an interesting topic, Iā€™m slightly aware that I veered it off topic.

So to answer the topic title I would say ā€˜Yesā€™. If you are a power user and also feel technically happy with setting up NodeRED and learning how to use it .. go for it , It is truly eye opening in what it allows you to do and very rewarding once you tame it.

Learning to use these new ā€˜componentsā€™ is one of the great pleasures I get from HA. By learning, I only mean enough to use them for my purposes, not anything in depth at all.

3 Likes