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?
Could I ask if I have the correct interpretation of those words?
Are you stating that if we have two hubs for example, running a zwave network on one, and a zigbee network on the other, would likely produce significant performance gains over one hub running both networks?
Fantastic! Bruce, I don't recall this level of assurance about Hubitat's future in any topic and I'm sure I'm not the only one to derive a lot of comfort from your words today.
No, I'm not saying that. I'm simply pointing out that the performance of a mesh network is independent of the hub. Some people have found advantages to splitting portions of a Zigbee network off to a separate hub. Zigbee bulbs make horrible repeaters, for example. So a unified Zigbee network can have performance issues, issues that depend on the actual devices used and the mesh topology.
I'm still confused given the discussion above how I can get faster motion lighting using NR than with RM if hub cpu performance is not capping performance and it's really mostly about the mesh. I'm using the exact same mesh (eg. Motion sensors on HE -> NR -> HE -> Hue) and it's noticeably quicker (with a level playing field in terms of everything else going on on the hub of course). It feels like RM needs a significant optimisation or a faster processor driving it. But what do I know
Either way, I love my HE (despite the various issues I've had) and in combination with NR it's now dynamite
I've given up trying to figure out that part. I can't see the app source code, I can't see the OS, and I can't get in the java vm so any guessing as to why it is a little slower than doing it w/Maker API + Node-RED would be exactly that - guessing. Which doesn't help me improve anything.
That said, I am 100% comfortable in using external logic engines, and I have no issues continuing to do so. I am going to have my docker swarm and NAS+VMs anyway for other uses, so it isn't like I had to 'stand up' any extra infrastructure to do it that way.
I understand that and agree with your approach. I for one don’t use ZigBee or Z-Wave much by deliberate choice and lack of need. But I do use HE a lot as it is very easy to code integrations for which, for me, are utilities or IP based I/O typically. Aside from the deficient UDP support it’s very capable.
So for my usage I’m not I/O bound and processing and memory are desirable. But I’m a very small minority % base of your users
Lol this was me. When I got my HE I quickly managed to get everything running on it locally. I quickly bounced off of the performance issues many have seen and was quite dissapointed. It wasn't till I started offloading everything back to my pi that my HE settled in and became reliable again.
I was annoyed for quite awhile then realized I just needed to adjust my expectations. HE is a awesome little hub. Just not the one hub to rule them all that I was hoping for.
) 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. 
