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.
I've got some more thoughts on this, I'll have to get back into it later.
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!
Andy
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.
I agree with @bravenel. Questions
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.
Andy
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.
Dave
hehehe... you can always release bad code, Dave, and see how long it takes for Staff to contact you. 
(this is of course, intended to be humorous... )
Dave
I don’t think you have a problem
I think if any user was told one of your apps or drivers was causing them a problem then I’m sure they would let you know.
Andy
Fundamentally, outside of the initial question raised in OP about load metrics, the suggestions around coding going awry boil down to a few things
Custom code can lead to problems / be malicious
Yes, it certainly can.
Most support cases are due to bad custom code
Seems totally obvious - I believe it when @bravenel he says it.
Proposal to remove custom code as way to combat support load
This would break everything Hubitat stands for.
Hubitat blessed, community-driven code review / plugin acceptance platform
This is a great idea, but one that requires time investment in the form of, if nothing else, organization (actual code review, policy writing, rule preparation, platform development, etc etc not withstanding).
Fundamentally, the Hubitat platform has three massive legs up over the competition
I applaud Bruce's stance (and presumably the company's official stance) on custom code:
Users need, and should be forced to, take responsibility for their own actions (you know, be an adult). It's absolutely on you, the user, to understand and acknowledge that running code you didn't write, and have no idea what it actually does, could potentially be harmful. And more importantly, to own that mistake when support says "This code is causing issues".
The community here is quite vibrant and active - when someone writes code that's got a bug, it's quickly squashed (see: @Cobra's anecdotes). Similarly, I would expect to see a very quick reaction by the community at large should code be identified as malicious - that's the beauty of a thriving open-source community.
If living inside of a walled garden is more attractive to you than having the full power and potential that freedom brings, I would encourage you to look at other Home Automation solutions (@sptrr99). Don't ask the rest of us to live inside that walled garden with you though - we value the choices that Hubitat lets us make ourselves.
tl;dr:
If you're concerned about custom code, don't run it. If you choose to run custom code, take responsibility for your actions.
=====================
The Community platform for apps and drivers is a great idea, and I think Hubitat officially blessing it is awesome - but it's a huge time sink. Which is precisely why it doesn't exist today. On top of that, there simply aren't (right this moment), enough people developing third-party code to really warrant the investment. For now, the forums seem to be working (see: vibrant and active FOSS community). A first stab at something like this might be as simple as a github repository, where all PR's are audited and commented on, documentation exists as wiki pages, discussions exist in the form of bug, etc etc.
This has happened to me twice (maybe a month or so ago). Both times were during z-wave inclusion of a Fibaro Motion/Temp/Lux sensor with older firmware (2.6). It hasn't happened with devices included since then. And both times, it cleared itself after a minute or so.
Download the Hubitat app
