Hubitat vs Node-RED response time

đź’¬ Lounge
1

To answer my own question as far as responsiveness goes in another topic,

Question

Am I missing out on Node Red

I setup some simple, and not terribly scientific, response time testing. Since motion lighting is probably the most likely scenario most users will care about for response time I've used 2 different sensors (an Inovelli 4-in-1 (Z-Wave) on battery and an Iris 3326-L (Zigbee) battery only) to turn on a ST plug model IM6001-OTP01.

For each sensor I used @fblackburn's Node-RED nodes for hubitat and @kevin's MQTT app with the built-in MQTT nodes in NR as well as HE Motion Lighting without any conditions applied.

node-red-nodes-for-hubitat

Node-RED nodes for hubitat

mqtt-beta-3c

[Beta] MQTT beta 3c released

Results?:
In both test sets you can see that HE is faster than NR when using MQTT but significantly slower when using Node-RED nodes for hubitat and Maker API. This is different than my test some weeks back but that was with an earlier version of NR where I had to run it in Docker. It was also with an earlier version of the MQTT app.

It makes sense to me that MQTT is slower because there is a Mosquitto broker between HE and NR. But I find it surprising that ANY external system can effect the operation faster than HE can, and by a substantial margin. But this is consistent with what the consensus of HE & NR users has said.

It has also been said that HE would (likely) be faster if one writes an app in groovy for the operation but there are many downsides to that so it is not an attractive option, especially when the Motion Lighting App can deliver 1/3sec response as is.

I did do some less informal, analogous testing with another pair of devices in my home that use the Motion Lighting App with a conditional on lux from a 3rd device and got response times of 1 - 1.2sec. As that was not an appropriate comparison I did not pursue it for the purpose here.

Conclusion:
Responsiveness for "time-critical" automations favor Node-RED with Node-RED nodes for hubitat and Maker API in my environment. There are many variables in the hardware and software environment which I can not reasonably replicate so YMMV.

There are many reasons one may wish to use Node-RED along with Hubitat and here I have addressed but one of them.

The numbers

Inovelli

HE Motion Lighting App
avg(314, 331, 298, 302, 287) = 306.4ms

Node-RED with Node-RED nodes for hubitat using websocket via Maker API
avg(233, 248, 211, 209, 219) = 224.0ms
avg(162, 163, 131, 170, 147) = 154.6ms between Ethernet packets
avg(071, 085, 080, 039, 072) =  69.4ms processing time

Node-RED with the built-in MQTT nodes via @kevin's MQTT app
avg(638, 527, 503, 524, 650) = 568.4ms
avg(031, 088, 078, 068, 105) =  74.0ms between Ethernet packets
avg(607, 439, 425, 456, 545) = 494.4ms processing time

Iris

HE Motion Lighting App
avg(395, 318, 370, 361, 209) = 330.6ms

Node-RED with Node-RED nodes for hubitat using websocket via Maker API
avg(208, 209, 245, 198, 226) = 217.2ms
avg(161, 140, 172, 131, 161) = 153.0ms between Ethernet packets
avg(047, 069, 073, 067, 065) =  64.2ms processing time

Node-RED with the built-in MQTT nodes via @kevin's MQTT app
avg(519, 500, 598, 490, 467) = 514.8ms
avg(088, 077, 044, 078, 078) = 073.0ms between Ethernet packets
avg(431, 423, 554, 412, 389) = 441.8ms processing time
Test Notes

All device times were taken from the HE logs. All Ethernet packet times were taken from Wireshark. I ran each test 5 times and then averaged them.

Node-RED nodes for hubitat packet times are from "motion active" message comming out of HE to the ACK by HE of the "turn switch on" JSON packet..

MQTT packet times are from the "motion active" message coming out of HE to the ACK by HE of the "turn switch on" message. Therefore the processing time includes the time it takes for the Mosquitto broker, which is on the same box as NR, to receive/forward (twice) the messages.

Device Notes

The Inovelli sensor is not nearly as sensitive or quick to respond as the Iris (observed visually)

Edit: Oops, forgot to show the flows. Not that it matters much but just to show the simplicity...

Flows

Screenshot_2020-07-04_11-32-45
Screenshot_2020-07-04_11-46-07

7 Likes
3

Question - For the node-red nodes for hubitat, were you using webhook via Maker API or Hubitat websocket + writebacks via Maker API? Maybe another way of asking - did you have the "Use websocket" option selected, or not?

I may be being pedantic, but Maker API doesn't use websockets.

2 Likes
5

Oh, and thanks for posting this. Interesting to think about even if - to your point in the OP - others results may differ.

1 Like
6

I'm no expert here but evidently it does because I followed @fblackburn's advice and selected websockets because it is supposedly the faster and easier, though less flexible.

1 Like
7

Has anyone seen a simple vs motion lighting comparison? I never used motion, but am solidly inn the NR camp.

8

No, your mixing up two different things.

When "Use websocket" is selected he is just connecting to the unofficial Hubitat websocket. The incoming events come in through websocket and have nothing t o do with Maker API at all. You can prove this to yourself by not adding a device to Maker API and causing an event - it will still show up in Node-red if using websockets (because it isn't going through Maker API).

In all cases, the writes back to the hub use Maker API though. The only difference is how the events from Hubitat to Node-RED come in.

But in the end it doesn't matter much. I was just curious which you did, and you answered. :slight_smile: I've been meaning to do a websocket vs webhook speed comparison, but haven't found the time yet. Websocket should be faster.

The downside to websocket (and it can be a BIG DEAL in some cases) is that there is no deduplication of repeated events going on, so the end user must put more thought/effort into the Node-Red nodes to work around that.

4 Likes
9

:+1: Thanks for the education!

1 Like
10

It’s not just node red. Home assistant and Homeseer both deliver faster results too.

As for custom groovy apps, it made no real noticeable results in comparison to simple lighting.

I’ve spent a considerable amount of time re-writing rules, working with the motion lighting app, and simple lighting. Lastly, I created custom groovy apps with all the same results, slower.

At the end of the day, Homeseer is where all my logic sits.

1 Like
11

And there you go! :+1: I knew it wouldn't be long before users of systems I don't have would pipe up. :grinning:

Now, can I get you to do like testing and add it here? I'd love to see it.

2 Likes
12

Raspberry pi 4, 4gb, Ethernet wired, hassio, node red add-on and hubitat add-on and it’s “as fast”. My hubitat rules were almost instantaneous and are my node red ones. As far as just speed, I’ve noticed hardware matters a lot more. I’ve noticed my iris contact sensors to hue lights were way faster than my “I forgot the brand” contact sensor to my sylvania lights

13

That’s very possible.

I have Homeseer and tested NR off a dedicated full blown server.

14

This is what's been mind blowing to me and should be a big red flag. If anything, adding the step of sending the command over the LAN should be adding 20-30ms.

15

It likely does, but since the server is processing and sending the commands much faster it ends up being faster overall.

16

The Hubitat processing latency may be impacted by installed devices, applications, rules, etc. that are running in the Hubitat unit under test. That can change responsiveness within Hubitat (given the node-red server is dedicated to Hubitat). The cause may be the totality of the devices or it may be a high-use actor on the Hub.

Hubitat developers can't generally fix this since it is likely caused by a community developed element. You can determine if this is the issued with a full investigation. A full investigation would disable all apps and drivers in Hubitat except the test elements, try the test and if significantly different results it would indicate it is a resource loading in Hubitat. Further investigation (very time consuming) might identify a specific resource hog element.

But the bottom line is, if the loaded vs unloaded performance is significantly different, it may be time to invest in the second hub. I believe that many have done so and that what to install on primary vs secondary Hub may be discussed elsewhere in this forum.

1 Like
17

As a business geared towards selling hardware this is an excellent solution!

As a consumer, if I need to make further investments in hardware to handle the load, I'll make that investment in hardware that's capable of handling more than my current need. If I need 2, or 3 (or some people 5 or 6 lol) hubs to handle my needs, I'd invest that money into a single high powered system that can do it all from 1 unit. And is in fact exactly what I did and why I'm currently all the way down the NR rabbit hole :slight_smile:

5 Likes
18

Fully agree. But we are all extreme technolgists who enjoy expanding our knowledge. For the average Hubitat user, if it slows down buying the second hub is the easier fix.

I have node.js on my laptop. I will write an applet today to receive a message and then return to Hubitat an ack message using TCP (and maybe UDP and fawSocket). Then a simple device driver that when activated will log sending the message and the return message. That will define the communications latency with Hubitat overhead in my installation.

This is important to me since I have some high-use wifi devices that can use UDP or rawSocket for comms and I want the lowest load on the Hubitat Hub.

1 Like
19

Easy fix, I agree. Accepted fix, I'm not so sure. I would consider myself slightly more than an average user, and I did not buy a second hub out of principle. I want a hub that fits my needs. Even if that means I need to spend $299 instead of $99 (ahem pro model hehe). If you tell an average user that they need to get another hub, they might end up buying that second hub from another company. As a business geared towards selling hardware, this is worst-case scenario.

3 Likes
23

You should be sure... the #1 reason in this Community is to buy a second Hubitat Hub for backup. We've all come to rely on our hub and a failure would mean extensive shipping time. Much much better to have one sitting on the shelf in our own home, right?

What happens next is to wonder if a 2nd hub can help.. why not? it's just sitting there, why not power it on and see if it makes a difference? If it doesn't, put it back in the box to fill the original need for backup. But if it DOES help... :smiley:

1 Like
24

A backup may be the reason some started down the road of a second hub. Organization was the path for others so they could separate zwave and zigbee onto different hubs. But none of these are required.

What I'm saying is when people are experiencing slow downs, they're often told the fix is a second hub. And I'm sure it does help, but that shouldn't be the solution. As soon as it's given as a fix that puts it into the realm of a requirement, and that's where I disagree.

2 Likes
25

I wish to make it clear that I am very happy with HE. It's the only one (two? :wink:) to have as far as I'm concerned. I say this because some of the responses here have given me somewhat of a queasy feeling that maybe some were thinking I'm unhappy with HE. Not at all. I'm naturally curious about performance factors (and MANY other things) so I was wanting to gather some evidence that my perception of response time is reasonably accurate. As @kevin said so well (Am I missing out on Node Red) there are few automations where it really matters and I'm quite happy with my motion lighting response times with HE alone. Your Mileage WILL Vary

2 Likes