Is there anyway at all to get a shell onto the device? It would be super useful for debugging when it gets slow... like its doing right now. As is its just impossible to tell whats happening. It just spins like a windows box.
1 Like
I’d like that just to poke around, even if it’s read only access.
See my thread on slowness, it might be relevant as I also have the same slow downs on the web UI.
Unfortunately there is no shell access. 
Well, I suppose I'm lobbying for it then. The box is linux under the hood right? There ought to be no technical limitation.
I completely agree that having shell access would be super helpful though.
Just guessing, but I’m betting this goes under the “will never happen” category.
“We’re building a Consumer Home Automation product, not a developer/hobbiest platform.”
“Granny” is the target audience, I’m thinking. I’m one that is hoping they succeed in making this that simple. It’s so far away at this point but I think we’re seeing the underpinnings today. Once a lot more building blocks are constructed, a higher level “app” (for lack of a better term) will hide forever the apps we use today. Some abstraction that sees what is needed and build a a Simple Light rule or a Motion Light rule, or a RM, so we don’t have to pick.
Awww darn, the crystal ball just ran out of batteries 
2 Likes
Well if granny is the target audience its going to have to get a whole lot more stable. I'm about 4 weeks in, and as much as I desperately want to believe this platform is more stable than ST, it just isn't. Its slower too. At least right now, under 2.0 it is.
A slow, unstable black box full of poltergeists, where I come home EVERY SINGLE DAY to find lights that were left on, locks that didn't lock, and other lights (and virtual switches) that never fired is not what I was hoping for, but that's exactly what i've got at the moment. I could have just stayed with ST for that.
There seems to especially be a problem with sending a command to a group of devices. Some get it, some don't. Some times the same event is quick, some times it takes several seconds. Other bugs I've seen are that several devices both zigbee and z-wave, don't show status in Hubitat that matches their real world status.
That I'm starting to get into the realm of voodoo where I have to put waits in all over the place to try to make sure too many things aren't happening at once and hubitat doesn't drop events on the floor, or I have ask for refreshes to ensure hubitat state is in sync with real world state before taking an action, is deeply troubling. Hubitat is lucky that Amazon is blocking me from reviewing, because at the moment I'd give it 2 stars.
The idea that this is a consumer home automation platform and not a developer/hobbyist platform is a false dichotomy. Developers and hobbyists are the people who make it stable and featureful enough for "granny" to use. My god when has freezing out developers ever been the path to platform success?
You're still running webCoRE?
hahaha.. that's a good one. Excellent hyperbole. 
When I first started reading I thought you were serious. You had me through the first couple of paragraphs, but then I started grinning. Poltergeists.. voodoo..
1 Like
I prefer the shell access NOT to be granted to owners/users.
Any problems and issues should be escalated to the Support team and resolution can be given and addressed privately......which is the normal procedure.
Your Hubitat hub is the gateway to your home automation......I don't like someone trying to hack our hub and toying with ....let's see......your own home.
Maybe asked the Hubitat team and see if you can be a Beta tester instead.
Google Kerckhoff's principal or Shannon's maxim-
"One ought to design systems under the assumption that the enemy will immediately gain full familiarity with them."
I am still running webcore. It's frustrating because its SOOO close. In fact sometimes it works great, and other times its slow AF. It's hard to figure out what's actually going on without being able to peak under the hood.
I just somehow completely pooched my webcore install but restred the whole hub from a backup and now its working flawlessly again. It sure seems like something somehow gets corrupted on the hubitat, which grinds the whole thing to a halt and a "database" restore seems to fix it.
I get that the official path is RE (or is it called RM?), but I'm just not that interested in another point and click interface where I can't save my code. As I've said elsewhere, the pseudo code of webCoRE is bad enough, but RE feels like a step backwards in terms of the type of complex and wholistic apps I can create. I suppose I'll have to look into writing straight groovy but frankly it isn't quite what I'm looking for either.
I just want a decent scripting language that I can save as text and reload at will! Something like xtend from openHAB maybe? Heh. I was going to say that even yaml would be ok like in HA... but no... no it wouldn't.
Not that I necessarily agree with him but I don't think he was talking about obscurity, you cannot hack something that is not available, he is talking about not including doors that can be potentially hacked...
That said, I doubt that is the reason they do not do it. Its most likely purely a business decision, the protection of their IP and the allocation of resources needed to properly implement and support something like this vs using those resources on advancing the platform by adding easy to use (dumb proof) features, support for more devices, etc.
I've taken to building little custom apps for my automations in groovy. Works really well. They all run locally and predictably. Which is something I could never even hope for in the other hub. You do have to be able to code a little though. Although for simpler things I do use RE.
have a good example app?
My experience with HE has been pretty great, in terms of both stability and speed. Much better than ST. Others have shared similar experiences.
Webcore usage seems to have a negative impact on both, from what others have described in the forum.
Yep, I agree. Issues with webcore have been well documented. If you want a stable platform, webcore needs to go. Can't blame Hubitat when a non-supported app causes problems. Frankly I wouldn't be surprised to see webcore blocked at some point, and I would support that because the staff is spending their time troubleshooting these types of problems instead of debugging and enhancing the official stuff.
4 Likes
I disagree. I have half a dozen pistons running in webCoRE for things nothing else in Hubitat can do without knowing how to program in Groovy. I am using it to make a webcall, parse the response and then take different actions depending on the response. Or, to use a parameter passed from Google Assistant through IFTTT to take actions after a set period of time (i.e. Hey google turn off X in 30 minutes.). I don't know how to do that in RM. And I don't know how to program in Groovy. So far I have had ZERO slow-downs or lockups in 6 weeks of running with webCoRE on. Now, I have eliminated all global variables, which I think was most people's problem. After looking at my logs I noticed that every time a global variable changed, ANY global variable, any piston that had a global variable as a trigger was re-evaluated. If you have 10-15 pistons with a couple variables each, you can see how it can quickly get out of control.
But just like every tool in the bag, I think webCoRE has its place and if you use it appropriately, it won't cause issues. Now, have most users taken this into account and adjusted their pistons accordingly, no. But that's no reason to ban it for the rest of us that are using it successfully with no issues.
3 Likes
Hope not ... webCoRE is working fine for me ... just well as on ST, but no lag due to ST scheduling issues.
3 Likes
Ok I retract my statement, blocking would be bad for community app development.
2 Likes
