Gavin, Thanks for your story. I really relate to what you are saying, as this is the way I got into writing my own apps. Writing my own apps led to how most of the built-in apps on Hubitat came about. Rule Machine, Motion Lighting and Mode Lighting are apps that I've worked on for 3+ years. When someone reports a bug against one of the apps I wrote, I almost always know right where to look. There's a large enough body of code now that bugs are inevitable, but thankfully they are usually easily fixed. Adding features is often an exercise done in an hour, for the reasons you articulate well.
So my comments below are not really directed to you, but to the general audience who advocate for cpu % being displayed in the hub.
This is of almost no value in our system. You have multiple ways to know your hub has gone south. The vast majority of times that I've done it to myself, I've known right away what caused it -- that last change I made to the code I just installed! Oops, that recursion went off the rails, or whatever. I have enough experience as a developer to know what is risky (loops with logic for termination, recursion, etc.), so if I'm in a risk prone piece of new or modified code, and the hub starts acting wonky, I don't have time to worry about %cpu usage (which I can see if I want to). I want to kill that app asap before it crashes the hub.
I know from internal discussions that none of us ever look at cpu% as a useful diagnostic tool. Those of you who advocate for this are projecting from other environments where perhaps this was useful. Our hub is implemented in Java, running on the JVM. If you look at cpu% at the OS level you would see that java is running -- whoopee, I already knew that. You aren't going to have any visibility into the jvm and its threads. For whatever it's worth, what you would see is that java is consuming from 5% to 25% of cpu with occasional spikes higher, usually at less than 10%, where 400% would be max cpu utilization (quad core cpus). In short, it's not meaningful information.
You will just have to take our word for it that it is not useful in this environment (Groovy running on our hub). If we can't use it, and we spend 60+ hours a week developing and debugging in this environment, what makes you think it's going to be of use to you?
Similar remarks could be made about RAM utilization. In this environment apps and drivers are constantly being loaded and discarded from RAM, and there is caching taking place. There is no valuable information to be had, except for one piece: stack overflow. We now report that as an error. RAM exhaustion will typically occur well after other things have collapsed, for example, a run-away loop or recursion has brought the hub to its knees. The RAM footprint of these apps and drivers and hub platform are not great, not pushing the boundaries of the physical resources. UNTIL, the software goes off the rails. The whole way forward is for software to not go off the rails. When hubs fail, it's almost always from this cause.
As Gavin says,
