Hub Statistics

[sptrr99]

I've got some more thoughts on this, I'll have to get back into it later.

[Cobra]

@ogiewon

But please don’t suggest removing that capability for the rest of us.

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

[doug]

@bravenel

Please understand that when you say "some users", you are talking about a very small number of people, out of thousands of users.

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.

@bravenel

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

@sptrr99

If it's that much of an issue, perhaps that function should be removed

Uh no! Lord help me I'd actually go back to ST if that were the case. Uhg.

[JasonJoel]

@doug

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.

[djgutheinz]

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)

[Cobra]

@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

[djgutheinz]

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

[csteele]

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

[Cobra]

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

[grodik]

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:

@bravenel

All I can say is if you write or use custom code, its on you to be sure it behaves.

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.

[aaiyar]

@homeauto2112

The first time was due to a Z-Wave device that buried my hub during a bad join process. This caused my job queue to fill up and the lights in my house were blinking so quickly and randomly that even the cat looked at me with a WTF expression.

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.