I was wondering if there is any view to build a performance edition of HE e.g. bigger CPU, memory etc? From my time on these forums it seems many people have more than 1 HE and sure some of this is to separate certain devices and or use for development but some are also spreading the load across more than a single hub due to hitting limits.
I'd imagine something like this would require interest from more than just a small group as no doubt a minimum order amount would be required to do this. So here we are with my post so maybe if this gets enough interest HE could consider it viable.
Btw, this post is not here to spark a huge debate or anything negative etc it was more of an interest on my end to understand future plans and to see what others thought about the idea.
You would need to define what you want in terms of performance. I think you would be unhappy if they sold you a box with more memory and a faster CPU and it wasn't any faster because the serial radios were the throttling factor. I think your request should be expressed in functional terms and then they should figure out how to deliver it. Just my $00.02.
My comment about wanting a pro model was not because of resource constraints.. But more in the idea that a more powerful system could support more advanced features, possibly more integrations that currently require you to use external software.. Etc...
And I’d be willing to pay the premium for these advanced features...
Good points, if CPU and Mem isn't what determines a "pro" edition then other factors may be it as you have mentioned. My post was merely out of interest to understand "what would a pro edition look like?" if any.
I had never seen discussions on mitigating performance issues using multiple hubs until researching Hubitat. What is the ST hardware doing differently to not have the same issues (or do they, and I just haven't seen such discussion)?
Well, people certainly report problems with Z-Wave and Zigbee devices on ST from time to time, likely the constraint on both platforms, but they're totally different implementations, so I'm sure each has its unique quirks. But most on ST doesn't really run on the hub: it gets processed in the cloud. Some things probably are intensive, and this ability to scale to meet that demand likely does help with heavy apps like WebCoRE or the numerous poorly written community SmartApps. (My preference is to write things well in the first place. ) Beyond that, in not sure any of us can really say other than what staff have told us.
My take is that the platforms are different therefore the issues are different.
First, everyone uses the same radios.. there are specific chips for Zigbee and ZWave and they are proprietary, even if they come from different foundries.
The Spec for the protocol is also the same for everyone. Everyone is 'stuck with' the nature of the mesh build by the chips + protocol stacks.
The limiting factor for Hubitat is Z-Radio. The speed of those protocols are so far below year 2020 capabilities, it's astonishing that they aren't trampled.
Hubitat also has finite CPU and Memory as mentioned that ST doesn't have in the same sense. ST can scale up the execution engine on demand. So giant apps can run in giant space. Not so with Hubitat.
The combo of Z-Device IO constraints and the exact same CPU running the App that is preventing the Z-Device from using the channel to it's fullest, is where the differences bloom.
ST runs the Rules (Apps) on a different CPU.. a cloud one.
the results are different places where the bottleneck occurs.
I've doubled the Z-Radios, I've tripled mem and CPU.
I have the Pro version -- or at least MY version of "Pro"
Here are some of the thing's I'd pay for in a "Pro" edition:
Hooks to allow external monitoring systems to check the status of the hub (snmp, maybe nrpe)
SMTP server enabled within HE, requiring end-user configuration to point to a valid SMTP gateway
More powerful hardware to support 3rd-party services on the Hub.
3rd-party software installed on the Hub (ie. Node Red, Nagios, Cacti, Pihole, etc.), eliminating the need for additional RPIs, etc to host these services. The HE software would remain unchanged. It would be up to the end-user to configure/use these services, via per-application or unified web interfaces (webmin, etc) -- still w/o shell access to the hub. Those applications would not be supported by HE.
Shell access (ssh) to the hub. As a 'pro' user, I'd accept that with an NDA or possibly even with a condition that shell access invalidates any support (ie., no user-serviceable parts inside). If I ssh to the hub & it breaks, I get to keep both pieces.
These seem at odds with each other. The previous discussion linked was that raw resources were not a limiting factor. If that's not the case - if adding additional resources to specifically handle rules would help (as an example) - then that sounds like it would satisfy OP's request.
The race to the bottom is great for adoption (and I think having an inexpensive, limited platform to run a handful of basic devices is also needed), but I am (and others are, it seems,) willing to drop additional money on a single, compact device for power users that can reasonably handle anything that I can throw at it in my home automation setup. Without having to forward-think about whether I'm going over some undefined threshold that would require me to rework into a multi-hub setup.
Not for the first time, @bertabcd1234 and I are saying the same thing.. at least that's my interpretation.
The CPU and Memory is adequate for greater than 90% of the Hubitat userbase, worldwide, I'm guessing. Certainly the subset of people joined to this community is a small subset of the total purchasers.. and the subset of people hitting limitations is also smaller than the worldwide total, I'm guessing. (My guessing is specifically: we don't know sales numbers, but it's perfectly clear sales are much larger than community involvement. 10X ?? oh for sure, 100X, Likely, 1000X?? I sure hope so. )
I think we mean the same thing, too. I didn't mean to steer back towards CPU and other resources with my WebCoRE example; that was just one thing I mentioned that might actually be resource intensive (basically an interpreter on top of something that is already an interpreter) and benefit from cloud scaling. The latest Hubitat fork works well for many and a second hub is probably good enough for those really concerned. My experience is that well written apps (or rules) and drivers are usually OK for people on both platforms and both are certainly limited by "Z" bandwidth, as mentioned above. But we can't see our own hubs to be sure, so I'm just trusting the people who developed the platform and didn't find this to be the case to also be the case for those of us simply using it.
Money tends to ultimately make up people's minds. So if you want more features and capabilities, then they would need a bigger team. The guys almost work round the clock as it is. How can they possibly do more?
Next big question. So you feel that the existing hub is limited? Why not buy another? OK, maybe not the same old answer you wanted, but consider the time, money and effort to get a pro hub out to the public and then the extra support for that special "pro" model. If only a small percentage of us hobbyists are buying it, that sounds like a lose-lose for Hubitat.
Now consider that since only a small number of people would buy it, that it would have to be priced significantly higher, for the aforementioned reasons and more. Would you pay more than double the cost for a single "pro" hub that likely couldn't do anything more than two of the current hubs? I think most people wouldn't. So Hubitat would lose again and their investors would not be happy.
If they build this, I hope they keep the "regular" version because I would not want to pay a dime for any of the things you have listed (except maybe syslog).
I agree with Eric. Always been a fan of distributive networks that share the load (in this case, the weakness seems to be restrictive radio traffic) Also keep critical functions separate, like Ring alarm system NOT linked to Hubitat. Maybe a false sense of security but that's how I have structured my home system(s?)
I'm sure there's lots of users here that would love a "Pro"system as I've seen lots of people asking for help for rules that look like a 3 page dissertation. My most complicated rule (that I created) is for the Lightify 4 function switch.
So far everything mostly works exactly as I want.
What if you could license HE to run on a Linux/Windows machine with whatever processor and memory you wanted to throw at it? Multiple hubs help a lot, but this would eliminate any of the concerns/needs that people want in a Pro version.
) Beyond that, in not sure any of us can really say other than what staff have told us.
