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. 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.
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.
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
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.
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.
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
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.
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.
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...
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.
I wish to make it clear that I am very happy with HE. It's the only one (two? ) 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
Fully understand and agree with the general premise. However, if a person has a LOT of devices or runs a LOT of apps and automations at high frequency, the second hub may be necessary. The Hubitat Hub is designed/built for the anticipated 90% (guess) household usage. I agree that a professional Hub should be considered as a future offering with more Lan, Zigbee and Z-wave I/O and processing capability. But that is a business-based decision for the Hubitat staff.
I my Hubitat, the Hubit Staff, and the User Community.
I've been overall happy as well. While I use HA and Node-Red for my logic, control and dashboard, HE does still have good radios and all-around support. I have found the z-wave radio a little weak on it's own (ie having only 1 or 2 devices at a far distance), but with a properly built mesh it's a complete non-issue. And I think with the new c7 hub and the 700-series chip that should be much better. It actually gives the hub a leg-up on most of its competition.
My worry is, if the second hub is presented as a solution and the slowdowns continue, it's going to push those 10% away. And those 10% that are "power users" are usually the ones pushing the platform forward and developing new drivers and apps. I've seen a lot of them start to jump ship. When they're all gone, what's left is the "average" users who have already bought a hub and will never touch it again. They won't continue to buy hardware and then what? With diminishing revenues it's hard to stay operational and offer support, and it's just a downward spiral.
I'd love a "pro" hub, I'd even love the option to buy a software license and run on my own hardware. But that could quickly become a support nightmare.
I'd like to comment on this, as it comes up regularly.
We have tested this, as I would hope would be obvious. We learned two things: (1) For most automations it makes no difference what the power of the hub is; the hub's overall performance is ultimately limited by devices and mesh network performance, things that have nothing to do with the hub itself. There is no such thing as improved "Zigbee and Z-Wave I/O capability" other than breaking these networks down into multiple networks running on separate hubs. (2) We were sufficiently disappointed with the lack of improvement overall, that we were fairly convinced that anyone paying more for a more powerful hub would not be happy about the purchase.
The business case for a more powerful hub is very weak. The number of users who would benefit from it is small, a small percentage of customers. The cost to produce and market such a product would not yield desired financial returns to justify doing it. The opportunity cost to our business would be high, when we are pressed on other fronts. All in, it's a loser for us. That coupled with our experience of the actual level of improvement in performance argues pretty strongly against pursuing this.
Having said that, we do intend to pursue steps to improve hub performance. Some of these are already done, and will show up in the next release.
Thanks much, @bravenel, for the candor and insight! As I'm sure you're aware there has been a great deal of speculation and questioning around this in many topics. Here's hoping you've laid most of that to rest.
It's a perennial request. I certainly understand the thought process that leads to this desire.
There is another desire that is evident in the power user group: Being able to make Hubitat be an end-all home processor, running everything that one would want to run that controls your home. This is a very understandable desire; it's just not one that makes sense economically for a business to offer. Small audience, high investment, high support costs... If this were a great business opportunity, surely by now someone would be doing it, don't you think?
Our Hubitat Elevation product is not intended to be such a beast home processor -- it's intended to support mainstream home automation needs. Bear in mind that home automation itself is pretty much bleeding edge technology, not really suitable in its current form for mass market adoption. We've got voice controllers from two of the mega tech companies, but no home automation solution from any of them. Why is that?
I've been meaning to do a websocket vs webhook speed comparison, but haven't found the time yet. Websocket should be faster.
Thanks for the education!
I knew it wouldn't be long before users of systems I don't have would pipe up. 
) 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 
As I'm sure you're aware there has been a great deal of speculation and questioning around this in many topics. Here's hoping you've laid most of that to rest. 
