Are there any plans for a premium, more powerful hub. My C7 is starting to show the strain a bit and so have invested in a second hub but this complicates things considerably. Some things just don't work through hubconnect. It would be much better to have a single hub that is powerful enough to cope with higher demands.
I'm sure there are plenty of people like me that would jump at the opportunity to buy a more powerful version.
1 Like
I can't recall when exactly the last time a request like this was made, but in the past the answer has been "no," with no indication they have reconsidered since then.
Thats a shame because it's a superb solution but the hardware is a bit under powered for some user cases.
I am not denying that your point is valid, however, I've seen customers who have hundreds of devices and running literally hundreds of apps, including many pistons, and their hubs don't show signs of slowing down. Are you sure that something on your main hub isn't misbehaving?
4 Likes
Everything is working ok for now but sometimes things take a second or two longer than normal. Hub Watchdog indicates this too. For the time being everything happens within a very reasonable time but my worry is that this can only get worse as more things are added in the future.
I have no factual evidence that says the hub needs more resources. However if you feel you need more "processing power" you could choose to move some of the automation processing off the hub. I choose to implement Node-Red to control the automation routines, and not bother my hub with it. For example we have some outdoor lighting that changes color every 3 seconds (rainbow effect). Rather than bog my hub down with all the "processing" of the rule I have my NR machine doing it. The commands are still sent to, and issued by the hub, but the timing and process is controlled by NR. The NR machine is a headless iMac i5@2.5Ghz, 16GB RAM, 500GB SSD, so plenty of power there.
That being said I would also purchase a "Pro" hub if one were available (not that it is needed I just like my machines/devices to have more than they will ever need/use, personal choice).
2 Likes
How about a high availability solution in an n+1 or 2n clustered configuration? Not sure how that would work with Zigbee and zWave pairing though. Might be considered overkill 
The fact that many of us find it beneficial to move some/most/all rule processing off the hub in order to have timely completion of things like motion lighting proves the OP has a very valid point. Frankly the response that the existing hub is quick enough and not processor locked is patently not the case for all use cases. My Pi running Node-Red just failed and I've been forced to reactivate my motion lighting rules on the hub. They are running like treacle as usual. I will be reactivating Node-Red as quickly as I possibly can.
1 Like
I remain unconvinced that a faster cpu / more RAM hub would improve things. I know there are some I/O hardware bottlenecks but I think the solutions to current issues are better software / stacks including maybe RM refinements.
4 Likes
I just wanted to add that I remain sceptical on both ZWave and Zigbee as device connectivity solutions and believe they both can contribute significantly to the slowdown issues people experience. On the C7 ZWave I particularly feel there’s work to do still, but it’s leading edge and bound to create hurdles initially.
IDK about that one, at least for me, I did not transition to Node-RED for speed reasons. I transitioned for ease of use, quick prototyping, and additional cross platform functionality including ease of sharing and github backup. I still use my Motion Lighting on hub because it does everything I want it to do already and is easy to modify since I use the built in app.
Now if this "pro" version of the hub was able to support a local host of Node-RED, that would be 10/10.
1 Like
Why ? ...because it’s tidier ?
Same could be attractive for MQTT and others but it’s an advanced user user feature and also utilised by other clients
so no reason to be paired to HE hub is there ?
I do appreciate the fewer boxes ‘ fewer points of failure’ reasoning... oh and backup if that worked....
Yes for one, easier to modify, easier to share, easier to backup, and also allows for additional integrations that are potentially shared with other smart home platforms.
Yeah I agree, not necessity per se, but imo I trust the reliability of my hubitat hub more than than the Rpi, so that's one reason for it to stay on hub. Both devices are required for the house to stay fully operational, so I rather just have one thing that can fail rather than 2.
My point with that was more about decentralized code development that multiple platforms use, therefore making it more "future-proof" imo.
Are you talking about HE or NR backup? I haven't had issues with either, albeit I've never had to use the HE one, but they seem to generate and download properly. I backup all of my NR using their projects feature and post it to my github.
This thread seems to overlook the additional support, testing, and code base complexity as different product models are added. Hubitat is a tiny company, and has to focus its product development efforts on the needs of 80% of its customer base / market. It can’t afford to spread itself too thin for the 5% high-end cases.
7 Likes
I think that maybe a compromise would be in order. Make just one model but make it a bit more powerful. surely this could be done without increasing the cost of the unit by too much?
Completely agree. As someone who has built both software and hardware for a living for 15+ years, "throwing hardware at a problem" is the lazy way out that buys you time, but doesn't fix the underlying problem. If you don't actually fix the underlying problem, adding 2x RAM, for example, likely just means it will take 2x as long before the hardware slows down, but it inevitably will still happen. A memory leak is a memory leak and eventually it will eat whatever resources you give it! Same story with CPU. Even worse, if the problem really is an IO issue, not CPU or memory, then it won't have any impact at all! You need to figure out WHAT the resource constraint is, and what the cause of the resource constraint is. Just saying "give me a more powerful hub!" will likely lead these same people to come back a year from now and say "those con artists at Hubitat! They sold me a more powerful hub telling me it'd fix my issues and it didn't! Now I've got two slow hubs!"
4 Likes
Not to mention stocking two SKUs has it's own challenges. Which one will be more popular? How many do you stock of each? Can the manufacturer accommodate two production lines at a reasonable cost? Etc. It sounds so simple from the outside looking in, to just say "add another model!" but the logistics of actually doing that and being successful aren't so easy.
2 Likes
And yet another Z-Wave, UL, CE, etc. certification process.
2 Likes
Unfortunately I don’t think there’s much to compromise on here. Between everything the staff have ever said publicly, and multiple reasons others have mentioned why it’s much easier said than done, it’s probably not gonna happen.
2 Likes
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
