I understand that the existing hubs are more than adequate for the vast majority of people and that a large number of people are absolutely and totally focused on the "price" of product.
However--there is also a market for people who have "edge" cases or otherwise just like to spend money on something they feel is "better". This market is far less price-sensitive, so it could be sold at a notably higher profit margin.
To reduce the support and development costs, it would ideally be architecturally very similar--only differing in areas such as faster CPU with more cores, more/faster memory/storage. And,
possibly, with an external antenna that was a bit more powerful (a nod to those that find that worthy of an unsanctioned mod).
With some forethought in the design, it could possibly even share all the major infrastructure components (especially the custom designed ones--same box, main circuit board, sockets, etc.) with a few slots and 'knockouts' left unused on the standard version.
By positioning this as "only needed for people with complex and special needs", it could target businesses, value-added-resellers, and the select people who will readily pay more for the potential benefits.
This takes nothing away from the standard device and the spec details could enumerate some information about how many devices/rules/extra apps, etc. are easily supported on the standard hub while highlighting edge cases that could benefit from, say, an external antenna.
It just seems like it would open up an entryway into a market with significantly higher profit margins and establish an offering that could be made attractive to value-added-resellers who would incorporate it into a "bundle" for their customers, businesses, and other premier clients.
I'm not sure what more cores, faster memory is going to do. Storage is generally adequate. Speed comes from 2 things. The speed of signal between the hub and the device. Now an external high DB antenna is likely to do more good.
Now, you also have to remember that any change in hardware has to be re certified by both the FCC and the Z-Wave alliance. That isn't cheap Then there is coding. Making platform changes that are backwards compatible is no easy feat.
I'd also be curious about whether a commercial setting would need much more "grunt" than a home, where, I would have thought, much more activity would be occurring.
I am the resident naysayer, but if you look at hub stats, for the most part the hardware doesn't seem to be strained. My Device stats for my C7 are 4%, and App stats are 2%. My C5 is pretty similar at 2% use for both Device and App stats.
I think there is some merit to the external antenna idea. The best place physically (120V and ethernet available) for my hub is not the best place for RX/TX. Although I don't have any apparent issues from the sub-optimal placement, there are a few devices with barely any RSSI. If I could have an antenna that I could place in a different spot from the hub, it would strengthen my network and probably require less repeaters.
There are a couple things I would like to see different if I were putting together a wish list.
I would go to a barrel jack that has less issues in my opinion than the USB. Or at least USB-C
I would also add a normal full size USB port that could be used for a Wifi dongle or other future expansion without the weird Y-cables that you have to do now.
Last, I would add at least a supercapacitor, if not a CMOS battery. Either would be sufficient for those 1-2 second power blips that seem to cause on occasion database corruption. And I think it could be used to keep the clock in synch (RTC), and do a controlled shutdown upon power interruption. It seems like that would be a fairly inexpensive revision to hardware that I would hope wouldn't require a recertification. Note: I am not intending to have the UI or any radios running off this battery/capacitor long term, just for the couple purposes noted. So not a full battery backup.
Depending on how things are coded, keeping a similar architecture would reduce the coding work. I suspect it's a Linux base--so just adding more memory and/or cores and/or a faster CPU might be almost invisible to their code.
I guess I was thinking that having more cores built in and a faster CPU might allow "RM" apps to run faster, allow faster/more logging (something a business might want for security), allow it to have more user-apps running frequently, etc.
IOW, I was thinking of something that was largely compatible with the other version--much like I can build a PC at home with a motherboard, but choose from a variety of CPUs, memory, and disk storage. Nothing running really cares that much about those sorts of details--things are easily compatible and physically, it's the same footprint.
Certainly, a better antenna would be helpful--if what I see elsewhere is a clue.
The "z-wave" part would likely be the same--as that's pretty much a standard "chip" from what I can tell.
About the %usage stats--Supporting enterprise backups, I went around with our networking team on that sort of thing. Like any stat, there are crucial underlying details. that make a huge difference.
And, for usage stats, the key issue that's often overlooked relates to "peak" demand.
Your "%busy" time over an hour might only be 10%. However, if you have a 2 minute period where it's pegged out at 100%, you'll experience sluggishness.
My enterprise backups were super "bursty" like that. The Networking folks kept telling me the network wasn't busy--only xx% used. I could see when my backups got super chatty, they were totally slamming the network, but only for spurts. And, when they averaged the entire day, it was worse--because my backups were totally consuming the network for hours at a time in the evening, making it hard to get things done in a timely manner. But, averaged across the entire work day, the network looked fine.
That's why I'm thinking the option of a faster CPU with more cores could, potentially, help in some situations. Even when the overall system isn't loaded on an average basis, this could make it snappier in "high use" situations (e,g., when a complex app is running, etc.). It could also better handle asynchronous events (but, yeah, "4 more cores" doesn't yield "4x better" since there's some coordination involved between all of them).
I'm gonna argue that a boatload of the supportive ideas that get added to this thread could and should be in the future for the platform... and that having variants of any degree would be detrimental to a small lean team.
Raise the price, keep making rock solid hardware, add optional capability that is built-in but for which you have to pay for the accessory (e.g. a compatible external antenna, a mini UPS)....
...but don't bifurcate the platform even if it could be argued that one level could be a supportable subset or step-child of the other.
If anything, institute a trade-in program where we could just keep on the best hardware track and if someone didn't want the latest & greatest HE they could purchase from a legacy pool with legacy harnessed software.
You make some great points. Obviously Hubitat isn't going to discuss its business model, and they aren't public so it's not like we can pop in on the earnings calls. But I'm guessing they're making this all work on a fairly small staff.
Would be interesting to understand the price elasticity of a home automation hub. Given the amount I've spent overall, the cost of the three HEs I have is not even a blip on the radar. But not everyone may be in the same house.
That is an interesting idea. Not sure how it would play out in reality. It might help to keep sales up, and to have a supply of inexpensive hubs for new users if they don't want the newest. I would say it would have to be C5 and newer, and maybe limit to one trade-up every 2 years or something to prevent abuse to the program.
I am beginning to believe that elasticity in this case is VERY MUCH dependent on the targeted HA consumer....and that the typical HE consumer is not the typical/potential HA consumer of the immediate future.
It would be interesting to postulate how many folk have 2-3 HE's not for logistics reasons but because "just one" isn't safe enough, robust enough, or antenna-ed enough. So, take the cost of two and presto...if the next generation robust "C8 or C9" had that same cost would you pay it !?
I'd also buy a couple, I prefer to have my features spread across multiple hubs, just so that if one part of my setup is compromised in some way, another does not necessarily need to suffer or be affected as much as it could have been if I ran one hub.
