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.
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
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.
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.
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
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.
If this facility was removed, I’d throw my 5 hubs in the bin as they would be useless to me
I only use a couple of integrated apps
95% are custom
With the exception of @ogiewon’s excellent harmony integration and @srwhite’s excellent hubConnect, all apps etc are written by me.
Do my hubs crash? Nope!
Do I ever have problems with bad code I’ve written? Yes!
How do I fix things?
By looking at cpu/mem etc? Nope.
By adding lots & lots of logging at every stage of the running app to see where it stops/fails? Yes!
I'm not sure the entire context is considered. When you say a small number of people out of thousands, is that people installing our custom applications or people developing the custom applications? The later I can understand, the former, I'm skeptical. My guess is more than half your customers are installing at least one custom application or driver.
I believe it's those developers on platforms like these that drive adoption for your product. We're filling the gaps for your small team, is my point. Not trying to be contentious and I understand I could be totally wrong.
I'd love peer review. Java is not a strong language for me, and I could learn quite a lot from something like that.
Whether or not the statistics would be useful, I have no opinion, however.
Uh no! Lord help me I'd actually go back to ST if that were the case. Uhg.
ST actually worked well for me overall. That said I would go back to home assistant or home seer within the hour if HE took away custom code capability.
When a bad actor is discovered, does the Hubitat staff contact the developer when suspected so they can correct?
Is there a checklist or test procedure outline that developers can use to verify functionality?
If no checklist /outline currently, could someone develop the same?
I only have several apps; but I loose sleep worrying about impact to anyone who uses them. If I thought they caused problems, I would fix or delete. But if I fix, I do not know if the fix is effective.
Dave Gutheinz, (TP-Link Devices and Samsung Speaker Integrations)
@djgutheinz
I don’t know if it happens all the time but..
I released a driver once which was causing problems (rookie mistake with a logging loop)
I was contacted by @bobbyD when it caused an issue with a user’s hub and was able to immediately fix it.
I have also been contacted by staff members with advice on a future release when they knew it would directly affect something I had announced that I was working on.
Thanks. You are obviously someone know well to the staff (therefore "Ambassador"). For us peons with only one or two integrations - this may not be the case. But that said, the staff (developers and support alike) are great! Maybe I just do not have any such problems.
