Is there a way we can get a page that shows us some stats on the hub?
CPU usage
Ram usage
Disk space
It would be a good way for us to see how the hub is performing.
This has been asked on many, many different threads and HE staff has said that they do not plan on implementing this because it is not a true estimation of how the hub is performing and could lead people down the wrong path.
I think they should revisit. If it's being requested so much, then obviously people believe there is a need to know more about how the hub is performing.
2 Likes
Not really. Many moons ago I would watch this sort of information, and you'll have to trust me that it reveals very little information -- certainly not anything useful. CPU usage can be characterized as sitting around waiting for little short bursts of activity. Even under relatively high load, the CPU is way undertaxed. RAM usage follows a similar pattern as apps and drivers come and go. As for disk usage, look at the size of your database backup. How much of 8GB does that represent?
This information, if presented, would be misleading and lead to all sorts of support questions for which there ultimately would be no good answers.
They would be wrong in thinking this would provide useful information.
5 Likes
If not CPU or Ram, there could be other stats that could be useful. Support does have access to metrics on the hubs I believe that we dont. I'd like to see some of that and possibly make changes to what I have deployed for better performance.
No, this is not true. There are no "metrics" on the hub.
There isn't anything available to look at that could provide any insight on how the hub is performing? When people load various apps and they lock up the hub, there's nothing to look at?
I would tend to agree with them that the information "can" be useful
For example a 4th of July rule I did which makes the porch light switch every 5 seconds from Red to White to Blue from Sunset to Sunrise, works perfectly fine on my "backup hub" that has literally nothing on it but that device and that rule.
The reason it's on the backup hub is because my main hub with everything else on it completely locked up running that rule and I would assume a CPU monitor would have provided me with the information showing that the CPU would be maxing out with everything running and that rule trying to run simultaneously.
Sure, we can look at what they have installed when they share that with us. There is a very high correlation to custom apps/drivers to hub lockups. But, there is no magic bullet that points at the culprit unless it's doing something like spamming the logs. How can you spot an infinite loop? Or a infinite recursion that leads to stack overflow?
Actually, you'd be very unlikely to see this in CPU activity. More likely is that your mesh o.d'd. You have to bear in mind that the hub is i/o limited, and the slowest aspect are the mesh networks.
The mesh worked fine for about 3-4 hours, then the processor eventually slowed to a halt and stop processing until a reboot.
This does not implicate the CPU, but more likely i/o queues. Remember Z-Wave is like 40kbps, so it's possible to overwhelm it, and fill queues. It is very unlikely that the CPU was maxed out.
I've had my hub lock up and seen reports of others having the same. A lot of times a reboot with help. Could it be a memory leak, CPU busy? Idk, hard to know.
I read the thread you linked. I disagree, I see plenty of usages for knowing more information. The hub is geared to be a local system. If that's the case, I'd like to know what's happening locally on my hub. I'd also like to see network information too.
If it could be i/o queues, let's have that information. Put the CPU info there too so we can see what might be causing issues. I can disable, remove, or change apps/devices in my system.
I'm not dogging the systems, just trying to make a case why some users would find that information useful.
This isn't high on our priority list at all. Not much more to say than that we don't see anything that would be of help, and there are other higher priorities. There are very few users who experience hub lockups, and they tend to be very vocal. Every single one we've dug into has been due to custom code. That leads to requests like yours.
At the same time, all of the built-in apps and drivers you have access to do not lead to hub lockups, and have been developed on the hub with the very same tools you and other app/driver authors have access to. We aren't in the business to support a development platform. Our support statistics are very telling. Not including brand new user issues, like login and registration, the vast majority of problems come from custom code. All I can say is if you write or use custom code, its on you to be sure it behaves. Do not expect us to invest our resources in supporting it, or in developing tools to diagnose it. That's not going to be a priority for us compared to doing things to help novice and new users.
Please understand that when you say "some users", you are talking about a very small number of people, out of thousands of users. Also, you will have to take my word for it that there is no low-hanging fruit in this area that we are denying you. People say, "but what about TOP". Fact is, top reveals nothing of use. What about X Y Z. Same answer.
Fair enough. I think a lot of users probably dont contact support on a lock up, they just reboot and move on.
I dont like how you say your not responsible for problems with custom code and aren't developing diagnostic tools for it. But you all do allow for its use. If it's that much of an issue, perhaps that function should be removed
1 Like
It's only an issue for a small number of users with a small number of bad-actor apps/drivers. Most custom apps and drivers are good, and wouldn't exist without this tool. Sorry to disappoint you, but we have been very clear about this all along.
3 Likes
The rest of us prefer a platform that development is permitted on. If you’re creating problems running custom code, then you can choose to stop running custom code. But please don’t suggest removing that capability for the rest of us.
13 Likes
I'm just going off what was told to me. He told me majority of their support calls are for custom code issues. Ways to address that would be to remove that functionality, or possibly adding ways for the users that have those issues to troubleshoot what the problem might be.
Custom code is permitted on the system and is regularly posted in these forums. Perhaps there could be a way to make certain ones that have Hubitat's seal of approval. Are certain "apps" removed from the forums if found they cause issues?
Exposing metrics like CPU load (which as Bruce mentioned is indicative at best, down right misleading most of the time) doesn't have anything to do with quality code review and testing. So yes, it may be neat to one day see third-party "seal of approved" apps, but that's got nothing to do with exposing meaningless metrics.
Purely conjecture here, and having worked support in the past, they know their pain points and what to look for when someone complains. Step 1: are you running custom code? What changed recently? This doesn't require "stats" to narrow down.
Edit: To suggest that the removal of one of the crowning features that Hubitat provides as a solution to some support cases, is counter to the culture and platform that they're trying to foster. The Hubitat team is doing the world a favor and have actually built a platform where hobbiests, coders, and other tinkerers can come together and build really cool things. Removing their ability to hack on the system and leverage the power that the hub actually provides, would surely cause a mass extinction of the buzz around the platform.
With great power there must also come -- great responsibility
1 Like
We won't go there. We have encouraged some of the strong app developers to come up with a community system with peer review, and told them that we'd support it. No takers.
1 Like
