Got the C-8 implemented and so far so good. The external antennas make a huge difference. I wanted to put an idea out there though. I would pay a lot more for a HE Max or HE Deluxe or some other name that came with a lot more processing power, and especially a lot more memory/storage. I still have to split the load for my rather large complex combination of devices and apps. This does make things more complicated to manage. If there was an HE Pro or something like that I'd be all over it. Give us more speed, more memory and more storage and I'll have my credit card out in a heartbeat.
Yeah I'd happily pay for something that primarily had more storage for logs. It shouldn't be necessary if all of your rules and devices are playing nicely. However every now and again something goes wrong and I need the logs to find the cause. Of course I'll have turned them off at some point for the problem device. I'd love logs like I have with other devices where I can choose between two dates and filter it to show devices x, y & z and rules a, b & c as a single time ordered report allowing an entire sequence of events to be viewed (rather than clicking between tabs). That bit should be possible on current hardware.
Also with all the talk of UPS and potential database corruption from abnormal shutdown (power cut/plug being pulled) a hub with small built in UPS/battery backup would be nice, with inbuilt setup for monitoring/graceful shutdown on low battery. I'd happily have a physically larger hub to accommodate that (I'm not obsessed with every device having to be so small). In the meantime (if I ever get around to it) I'll have to build the C-8 and a Talent Cell mini UPS into some custom enclosure to appear as a single device.
If things are consuming more memory over time, personally I would look into what and why that is happening. Ideally you want to have things that consume relatively stable amounts of resources on the whole. If they spike or, of more concern, if they increase over time, then more resources are only going to lengthen the time you can run the hub without rebooting. The key word here is ideally.... I'm not suggesting I have reached this state, or have some magic solution to achieve it, only to say that throwing more resources in the mix is unlikely to change things in the long-run, IMHO.
This from the guy running 4-5 HE's for similar reasons to what you are raising .... Granted more resources may make some things run faster, therefore reducing the bottlenecks that may occur, but the improvement may be hard to quantify on a user-by-user basis, it would depend quite heavily on what Apps / Devices you use, so justifying the expense would be hard to quantify, just because you have a "slow" system would not necessarily mean you would benefit from the rolls-royce version...
There are also various reasons why people may need or want multiple hubs, including splitting functions like I have between lighting control, general rules and cloud-related stuff. I like the ability to have my lighting not impacted by any outage to the rules or cloud HE hub, as much as that is a rare event. Separate to my own circumstances, other may have other reasons to run multiple hubs, so it feels like the complexities people experience in running this setup may be worth exploring and refining, rather than outlaying additional expense in developing and releasing another version of the hub. What kinds of things do you find complex to manage?
I'm not against a beefier hub or enhanced version with extra features, just want it to be something that can be easy as to explain to situations where users will benefit from outlaying the extra $$.
To be honest I feel like this should just be something that is part of the next version of the hub, rather than some extra that you have to pay for. Hopefully slightly more storage is something that is in the list of incremental improvements for the next revision.
Yeah, was about to say the same thing you did at the end there, again, not something I expect would be worth paying extra for, but just an improvement to the current firmware. As an alternative, you can port your logs to external systems for analysis using Community solutions. I know not the ideal situation in terms of a built-in solution, but something people may be interested in.
Exactly.... Again not something I would pay a lot more for personally, so probably not worth making an alternate model for, given that many, like me will have already invested in a UPS to cover the broad range of IT equipment I have accumulated, but as an incremental improvement to the hub, this would be a great addition.
Why not just run syslog and save all logs to an external drive?
Even with all my integrations and rules and 200+ devices, I barely hit 4 percent of cpu usage during peak. . My free memory hovers around 230-250k. As for onboard storage, I mean, very little is stored there except for maybe a few html files for apps. So not sure if I see a reason to upgrade the CPU and memory. Your bottle neck is still going to be the end devices being controlled. It's like people who want a gigabit port. The bandwidth that hubitat uses to communicate with anything else is minimal so it's really not needed.
It's something I've considered but from what I understand that would only cover device logs and I'd like to see a means to forward and manipulate rule machine and device logs. That would allow a user to find out what went wrong a lot easier. But as said, that in itself, should not require different hardware.
WHATEVER level of component quality, reliability, and extremes tolerance that went into the C5 ...keep striving for that.
We're into the third winter/summer (freeze/simmer) seasonal cycle of unit survival in dusty unconditioned outbuildings. Not everybody can put these in nice conditioned home/office spaces. With the exception of water I dare say they've performed to MILSPEC even with the dust.
This is exactly what I'm doing. I've moved Kasa, Ecobee, LifX and the "Precipitation and Weather Monitor for NWS Data" device over to my old C-7. Hoping this is enough to buy me more time between boots. If necessary I'll move Echo Speaks over too. It's just such a touchy beast, I'm not in a hurry to tempt fate.
You've been managing multiple hubs so long you forgot how much easier one is.
Don't have to "remember" where services and devices live
Manage updates on multiple hubs
Double the points of failure
I get what people say about CPU use. That was never a problem with my C-7 running everything. It ran out of memory and needed to reboot. Failing better tools to figure out which app was responsible, I've split the load. It is what it is. Just saying if I could spend $350 on a hub that has so much headroom so as not worry about resources, I would do it. I like the idea of a built in battery back up. But I have my network gear and (NOW TWO) HE's on UPSs so that's fine. We recently were without power for about an hour and a half and I never lost network access including HE. Of course she didn't have anything to control. Except my power failure notification solution which worked just fine.
I have found that typically Zwave Zigbee stuff is very resource efficient. It all generally goes down hill once LAN stuff starts to get involved. For some stuff that is inevitable, but It goes back to what i have heard over and over. Stick with Zwave/Zigbee devices when possible.
If I was going to break my setup out the very first thing I would do is break out the Lan/Wifi integration devices to their own hub.
As far as the conversation about more resources, I see both sides to it. Simply put when things are kept simple yea we don't need much, but once things start to add up and get complicated it doesn't take much to overwhelm that small system.
Having the ability to scale it with your personal environment isn't a bad idea. I would love to load Hubitat as a docker and just allocate resources to it as needed, but i understand why they don't allow it as well It is just another variable. Also being in IT i have seen how the saying "if you build it they will come" applies here. Making the machine bigger could likely not do anything for peoples usage issues. Maybe postpone it a little as some have said, but it could also promote bad habits as it just obfuscates them.
That thread is also about the subject of capturing extended logs with advanced filtering and such. It works great and the INfluxDB Syslog Device driver to load INfluxDB seems to work well with low system impact.
To some extent I agree, but there are legit reasons a app may take up more memory space. The Govee Integration is a good example. To enable scenes I am having to store the values for each scene command in the app to be used by the devices. This has added up considerably when you consider the quantity of devices. I have taken steps to reduce it as much as possible and am thinking about more ideas to further trim it down, but no mater how you look at it advanced features like that are more then a small on/off command attribute or something like that could benefit.
I also think the internal processes are getting to the point they may benefit from it as well. Most of the time I have noticed a hit in responsiveness has been accompanied by a sudden drop in memory related to DB access. Yes sometimes it has been something else behind the scenes, but it has also been related at times to the DB backup. I have seen my hub take a 80MB hit just by doing a backup.
I think something else to consider in this discussion is simply what are we talking about in actually price impact. I don't know what memory is actually in the unit, but when I look at Micron FBGA on Mouser the difference from 1GB to 2GB chips isn't that much money. They could probably quadruple the memory and only charge another $25 bucks. That doesn't account though for if the Processor in the unit can take that much more. If a upgrade is needed on it, that may make the difference bigger.
Ofcourse I say all of that but I am seeing mixed reports of weather the S905x in the more current HE's can support more then 2GB of ram. If they had to go to a new CPU, pricing could get more complicated. We also don't know how much ram is in the box and used for OS vs JVM functions. We know we see the JVM free memory is around 600MB after a restart but other than that we don't know.
That is not very surprising. It depends on your environment. I see 600MB + on my dev hub that has limited stuff. My Prod hub is similar to what you are showing there. you can kind of see that in the below image.
In regards to this suggestion (of a "SUPER HUB"), I must admit that I'm of two minds.
First of all, from my long history in IT, we all have used to the approach of "throwing improved/upgraded hardware at a problem". This was a very common technique, and it worked very well in many circumstances. The HW got much less expensive and much more powerful, and the cost of SW adjustments (programming/debugging) got much more expensive. However, some times this approach didn't work. In some cases, due to user error/poor programming/etc. no matter how much HW we would throw at a problem, it wasn't enough.
To be frank, this was a lazy man's approach.
The other approach was to spend the time necessary to uncover the root of the problem, and properly debug the issue. Sure, there was the very infrequent case of Operating System bug, or unusual confluence of circumstances. However, in general, many of the cases that we used to solve by throwing HW at the problem could have been solved by smarter/better programming.
This approach took MUCH greater time and effort, and may have cost more in various circumstances.
Theoretics aside, in this particular case, we all know that the Hubitat box is not an all powerful box able to handle all workloads thrown at it. However, we all know, that the box can (and does) handle 95%(? guess - maybe more) of all general Home Automation environments and situations. Furthermore, they made the box even extendable with the use of Hub Mesh so that you could easily leverage more than one box.
It's a compromise situation, and in my humble opinion, Hubitat has chosen the right balance.
.... Granted more resources may make some things run faster, therefore reducing the bottlenecks that may occur, but the improvement may be hard to quantify on a user-by-user basis, it would depend quite heavily on what Apps / Devices you use, so justifying the expense would be hard to quantify, just because you have a "slow" system would not necessarily mean you would benefit from the rolls-royce version...
