^ I'm with this guy.
I agree. Everyone has said everything they're going to say at this point. As with many forum topics nothing was solved, and no agreements were reached. 
Hubitat committed nothing, including that there is even a problem to solve.
I didn't get mad and stomp off and buy a new hub.
Life goes on. 
Definitely a Brexit meeting. 
5 Likes
Oh wait, I mean +1,000,000
8 Likes
Did you write your own user code to get that number?
Yes, but when I write it, it's considered system code.
9 Likes
Show off lol
Is there anything worse (in the Developer universe) than a Certified developer program?
What a completely useless trend. I've never been more fearful of an applicant than when they touted their Certifications. 
2 Likes
++1000
so, 1001? I also like how you incremented before instead of after. A lot of people don't know the difference between ++x and x++
1 Like
coder humor 
1 Like
Not to beat a dead horse, but the way you quoted Mike was really out of context and seems unfair to me.
I read his response as, you would be asked to removed code that generates errors. Sounds reasonable to me. No one has ever said to me, disable all your Xiaomi devices or we're not going to help you.
Free support for a hub that only cost $100 is amazing. I have no expectation that HE is going to help me with any custom code I load on my hub. ST staff never chimed in to help like they do here. Support over there is almost 100% community driven.
If I add something unsupported to my hub, that is completely on me. I also cannot expect them to not change their policy as they go. We're all learning what works and what doesn't. I can't imagine anyone here wants Hubitat to fail, so lets make sure we remember how small their team is. Resources are limited and lines must be drawn. At the same time, because they're lean, they are also efficient. Once you get to SmartThings/Samsung size, no one gets to maintain this level of flexibility, and the people that make the product what it is often leave or are forced out. The product stagnates.
If they had more time to code and had to spend less time figuring out why hubs loaded with custom code are not performing as expected, just imagine how much further along the platform would be.
I would like to propose that the Hubitat team continue to build a great platform, keep listening to suggestions and keep improving the platform. The community should CYA. If its your code, make sure it works. If it is someone else's code you loaded on HE, and it's throwing errors, talk to the person that wrote it. I can run Microsoft code on a Mac, but I sure wouldn't call Apple for help with it, or blame the MacOS for problems with the Microsoft app I'm using.
2 Likes
We reached out to some of our most prolific developers encouraging them to help set up a marketplace for apps and drivers. So far, the response is crickets. So, other than you, I can't find anyone who takes this very seriously. Hubitat is certainly willing to support such an activity. Are you interested in leading such an effort, by and for developers?
As for us doing it ourselves, it's on our list behind many other things that we know are more needed.
This is laughable. How do you think we troubleshoot issues? We do all of the app and driver development on the platform itself. It's not very difficult to troubleshoot major code development. Granted, we have more experience in doing it, but we aren't using any secret internal tools that aren't available to users.
How else would you suggest isolating a problem? This is a standard debugging practice. We added that ability to the platform precisely to enable isolation of an offending app or driver. Once isolated, if the problem isn't obvious at that point, then one goes to the next similar step with the code of the offending app or driver. And thus it goes...
We don't actually expect you to turn off all user code. We want you to isolate the problem so it can be dealt with. If you come to support without isolating the problem, what realistically do you expect us to do? We don't charge for support, it isn't without cost, and we can't as a practical matter dig into your setup to find where you've gone astray.
You should realize that only a tiny fraction of users do what you do, and use custom drivers and apps to any great extent. Perhaps our support stance will limit growth with hard core developers, all 20 of them.
I actually think your point about Xiaomi is pretty well taken, that is, it does represent a very large volume of popular devices. If only it wasn't so damn difficult to deal with...
And that goes for us too!
NOTE: I know you think I'm being cranky and probably sound that way. This post is just a fun response to all of the seriousness about these topics. Don't get all excited about it!
13 Likes
Great post. I thin many of us lose track of the fact that most of us around here are in a very unique group of power users that do not represent the majority of Hubitat customers.
I believe the term used was “angry”, but I can’t recall who said it. 
1 Like
I accept everything you said Bruce.
But I will still suggest that you're arguing that everything's okay the way it is, so it shouldn't improve. I'm suggesting that the team look harder at figuring out a supported way to implement some code isolation, which would be better for everyone.
You said many times the hub isn't CPU or memory limited, so the extra overhead from some isolation should be fine. Right?
Nice to know that Multi Hub Users will soon exceed Hard Core Developers
If Only @srwhite would close his eyes and push the Button.
3 Likes
Good grief! We devoted quite some time not too long ago providing a mechanism in the platform and UI to allow any app or driver to be disabled. And this was in response to requests just like this one. So there is an existence proof that we are not arguing that everything's ok the way it is. That's actually a fairly ridiculous assertion to make considering the pace at which we continue to crank out improvements in the platform and apps and drivers. And (b) "team look harder"? You've got to be kidding, right?
2 Likes
I had a much longer response typed out, but what's the point. You seem to get very defensive if anyone insinuates the team can work harder on certain elements.
I'm not here to argue. I accept that area is viewed as not being a priority right now over other more valuable development work.
Enough said.
They make their money off the enterprise. I'm sure I've funded a few of their bonuses. When we have to engage them for support it's a hourly fee as well.
Luckily it doesn't happen often. But when it does it's expensive. 
Somewhat fun thread for a contentious topic.
I'll chime in, as I must, and state I believe the Hubitat staff has provided quite a bit of support toward custom apps and drivers from my perspective. Putting a standard policy out that states this is a fail safe, like the Pirate Code, it seems to be more a guideline really. 
Disabling apps is certainly a good way to find a problem child. And I suspect the sandbox will get better with time. That said, I'm still advocating for better diagnostic tooling on the user side.
2 Likes
