Hub Statistics

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!



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

  • 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)

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.


hehehe... you can always release bad code, Dave, and see how long it takes for Staff to contact you. :smiley:

(this is of course, intended to be humorous... ) :smiley:


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.



Fundamentally, outside of the initial question raised in OP about load metrics, the suggestions around coding going awry boil down to a few things

  1. Custom code can lead to problems / be malicious
    Yes, it certainly can.

  2. Most support cases are due to bad custom code
    Seems totally obvious - I believe it when @bravenel he says it.

  3. Proposal to remove custom code as way to combat support load
    This would break everything Hubitat stands for.

  4. 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

  • Not being cloud based
  • Having the ability to run & write your own custom code (drivers, apps, etc)
  • The power that Rule Machine brings to the table as a function of the aforementioned

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.

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.


4 posts were split to a new topic: Prohibit Custom Apps being Published in Community

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.

3 posts were merged into an existing topic: Prohibit Custom Apps being Published in Community