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
Yarr matey! 
6 Likes
More good grief!!
I'm not being defensive, I'm laughing at the preposterous nature of the suggestions and comments. It is truly funny that you could possibly think we aren't working our a$$es off, and that somehow we need to get more serious about these "important" issues. I'm laughing and you're taking it seriously. You missed my suggestion above:
Not enough said by a long shot....
1 Like
Suggesting that someone could look harder at a topic, which is what I said, is not the same as saying they are not working hard.
However calling someone's comments or ideas preposterous, or other belittling language, is a personal attack - not a constructive opinion or suggestion.
As such I'm 100% done posting on this thread. Have a great rest of your day.
1 Like
Dammit Jim, I'm a coder not a technical writer!
3 Likes
Pretty interesting and lively discussion ...... I wonder if anybody can actually name a hub / bridge in this price bracket that while providing an open and extensible platform also fully isolates user code? Even removing the price bracket restriction I'd bet you'd struggle.
Personally I've been into home automation for around 20 years and have worked in the sector for just on 7 years ..... I have tested a huge array of hubs / bridges in that time and I can't recall any that are completely bullet proof and impervious to issues in user code.
IMO you can't have an open and extensible platform and that level of control & resilience at the same time.
That said, I do think some of the things that have been mentioned previously would go a long way to help:
- Better documentation (yes, resources are scarce, everybody hates doing docs, but even just a doxygen type thing would help point people in the right direction). I do acknowledge that there's been some additions to the docs lately too, so that's definitely moving in the right direction
- Release source of some of the built in drivers / apps to allow people to derive new code from them. I know there's a few examples from a while ago but perhaps some of the generic drivers would be an idea? If people have a better starting point to build from other than copied from ST or cobbled together from bits in forums then that would surely produce a better end result.
- Consider a watchdog process (not sure if there is one). In Vera for example there are various watchdog checks and if something hangs up the core process then the watchdog takes action to varying degrees from raising warnings, to restarting the process to even rebooting entirely.
#2 there are drivers in their github, and one app. Even today, I found the answer to a problem was there but I had overlooked.
#3, tried and removed. I have no idea what the details are, but it was implemented and WebCoRE blew up, massively. The resolution was a hot fix to disable it. Been there, done that.. probably should return to it, but then again, since I was not involved, I can only guess that the research done at the time proved it shouldn't be tried again.
