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.
I can't add more to this thread either.
I stated my opinion if you guys disagree you are on your own right.
Time will tell.
Just a few final notes:
Nobody said that you guys don't work hard.
Nobody said that there isn't other priorities. Me for example said in some time.... some time is not the same as now, this week, this month, maybe not even this year...
If you need a business model for the app store more than glad to pitch in. Again as I refer several times I'm not a coder.
How do I defrag my hub?
7 Likes
With a headshot 
1 Like
rm -rf / works wonders. 
I kid... Lol
1 Like
...and yet, in Vera, we still used old-school timers to power-cycle once-per-day for those cases where it's health checks failed, and they failed regularly.
In Vera's case, their underlying *nix didn't have resource-management primitives (like cgroups .or the higher constructs like runc), and they had a single core, so it was easy to overwhelm it with user-code.
I had many hours on the phone with Aaron about that 
With a few more cores, and a clean separation of user-processes from system-processes, then something simple like cgroups can readily protect the core system, even on resource constrained devices.
... but single-process Java isn't going to do that, and you'd end up spending more system resources (and engineering resources) to bifurcate the runtime like that - might as well make it easier (seamless) to have multiple hubs, for those that want that level of separation.
1 Like
Regarding the "App Store" aka Hubitat Community Created Apps and Drivers Store...
It's clear that Users wish for one.. even clearer is that Developers are not motivated.
There are at least two categories of Developers.. 'accidental' and 'intentional.'
'Accidental' = Some people migrate some ST code and while it's a great addition to the Community, there's zero interest by them of maintaining the code. They donate it to the community, 'as is' and then walk away. I gotta love them because when I first arrived they supplied me with a lot of code I needed to get started.
'Intentional' those who want to contribute but have had to create their own mechanism for distributing code. Most have their own github and don't need another. Having a HubitatCommunity github doesn't benefit them, as far as I can tell. It's just more work.
Crickets, indeed.
7 Likes
format c: /u
2 Likes
OMG.....everything erase!!! Saw YouTube vid to put in microwave to restore files...BRB...
1 Like
Much of my code is accidental. 
I hear you, if I can't even bring myself to post to the nice community repo... I don't know where I'm going with this, but hobby hours fly by quick I guess is what I'm saying. 
I thought you will complain about been angry and old... you are not funny at all....
1 Like
LOL. Well, angry I'm not, but old I am. What can I say? Nothing much to complain about...
4 Likes
We really should have done this on a video conference . . . like the old ST developer video conferences.
2 Likes
Wait... You mean, this wasn't a Hubitat publicity photo, and it isn't you and @chuck.schwer???
2 Likes
