Well, we are halfway there, when your hub crashes, mine keeps going fine. 
5 Likes
I think the Title of this thread is inflammatory because there's an assumption the statement is true everytime/always and there are so many examples of it not being true.
Jason, you and I were just in a conversation(Notification) in which 3rd party code was being debugged on the fly. Both Bruce and Chuck participated and in a short while the answer was found. Resulting in fixes to BOTH Hubitat code and the third party's code.
3 Likes
Thats on me, I split the messages and wrote the title, I did not mean to inflame anyone 
To me, that seems like a tall order for something like the HE hub though. I know Java has the Isolated class that could be used to isolate code from the system core (which would come at a cost to the JVM), but how would drivers work in an isolated space? How would you code something that allowed for user written code as flexible as HE allows and not end up being dangerous to the system? Drivers by their very nature would have to be accessible by the system for things like automations and other apps.
This was the problem with SmartThings as well. When the ST hub came out it was fast, svelte and ran really well for what it did. Then everyone wanted the hub to do more and more and more until it became a huge, bloated mess.
1 Like
Again, I'm not really upset or especially unhappy right now.
It's my opinion that they need to figure out a way to compartmentalize user drivers and code better, whether it's in a separate hub (that can fully share drivers and attributes with another hub - not the existing limited functionality hub link app) a separate java heap a jail or other.
In the end they can do what they want. If it gets to the point where the product is unsupportable for my needs, I'll switch to something else. Until that point I will keep using the product because I like it.
I'm not really losing sleep about this either way, just trying to help and providing opinion.
1 Like
Hubitat never marketed this as including an IDE. They simply say you can use your own code, which is true.
Microsoft does not include a free IDE in it's operating systems either, so I think the reference to Microsoft is a little weak.
1 Like
I just want to say thanks for keeping this conversation open. Sometimes it is to easy to censor dissent. As long as everyone is respectful, I find the discussion interesting.
3 Likes
I wasn't going to respond to this in fear of derailing things further, but I can't help myself.
While what you say is absolutely true, I will say that in the years I used smart things user code crashed my hub exactly 0.0 times.... I can't say that for hubitat.
ST has plenty of other drawbacks though, and if I left hubitat it would not be to return to smart things.
2 Likes
Arguable and subjective. Powershell is a much more powerful scriped development environment than we have in hubitat. And powershell is most certainly fully supported, in box, and free.
None of that really matters, though. The goal and desire is to have a way to create and use user code without it crashing the system and without the first answer from support being turned it all off.
1 Like
Well, it isn't derailing as that's really the point here. ST never crashed on user code because it was cloud based and abstracted. Everything that was user created never actually hit our hubs locally. Even turning on or off a light through the app required internet access.
With HE, that's a different story as there really isn't a "cloud" for us to rely on in terms of a safety net.
1 Like
I just wish we had access to more of the built-in drivers, maybe even some of the built-in apps. They would be excellent examples to springboard from. Plus, seems like it would be a win-win if the community extended some of the generic drivers and the Hubitat folks (OK, I know limited resources!) could review and possibly include as stock. Right now it seems like many of the community created drivers and apps are cobbled together from either SmartThings code or other community created code, and I can see where that can create a lot of issues.
7 Likes
+1000. Although that doesn't help with user apps taking down the system.
There are multiple times where I could have simply extended the built-in driver to add one or two features I needed as opposed to rewriting an entire driver from scratch. At least in theory that should have been much lower risk from a user code standpoint.
But that is not an option available to us.
1 Like
I have to say I have received the "we do not support custom code" response early in my Hubitat endeavor. I also know that the HE team did eventually go far above and beyond anything I ever experienced with SmartThings in terms of support.
There have to be limits. At the end of the day Hubitat is a consumer product with some developer capabilities. I would say that if someone is looking for containers, VM's, protected processes as a requirement for home automation (not sure why), then perhaps Hubitat is too small for your needs.
Quite right. I definitely don't want to see responsiveness bogged down by unnecessary bloat.
1 Like
Sure you do. It is the core of a lot of the discussion in this thread. If user code couldn't take down the core system, this thread wouldn't even exist.
I'm not sure how you amassed so many votes?
Never said that.. I have advocated for more tools to be made available for troubleshooting however.
This is a very important distinction. It's why WebCoRE is problematic. It's why it's easy to crash a hub with a bad driver or app. I know, it happened during development of HubConnect. My fault entirely. There are no guardrails, no resource limits, no annoying 20 second app execution limit.
And no cloud to fail...
I will support the release of built in drivers. I do believe apps should be kept closed source for the same reasons ST does not release SmartLighting or Smart Home Monitor. Those would likely find their way ported to ST, with no benefit to the HE team that took time to create them.
1 Like
I borrowed them from others.
3 Likes
That thread was EPIC. It was probably the one biggest thing that got me talking in the forums after seeing all the support you got from the HE staff.
Exactly. There are literally three things I want my hub to do; Control devices, process automations and rules, and report back what happened and when. I purposely keep my apps to a minimum because I know this is a single board computer and trying to force it to do things that would require more resources is the wrong direction to go, in my opinion.
2 Likes
Exactly. And they've continued to stand by me and my very unique system ever since. Even despite @bravenel being an angrier (and probably older) old man than myself. 
I share the same goals... Although I diversified my hubs to spread the load of rules and reduce the footprint of a potential failure. I look at it this way... Simplicity is easy to troubleshoot at 3am on the rare occasion when something doesn't work.
3 Likes
Someone had to say it 
6 Likes
