A read only shell wonât cause any problems. âGrannyâsâ use computers and they still generally allow access. Average users wouldnât even dream of deep access. I can live without shell or FTP, but if it was there, Iâd poke at it.
Agreed...but....I do wish those that choose to use it understand that they are installing an engine designed for a Nissan into a Honda. I for one, want my Honda engineers working on making my Accord more fuel efficient and with additional stock features...not wasting time working with mechanics who insist that their Nissan engine worked fine a week ago.
I'm in love with my Honda and though the engine runs on different engineering priciples... I read the manual and have learned to use it for maximum performance and fuel efficiency. I refuse to do anything to jeopardize my warranty or the throw a wrench in a system fine tuned for Hondas only.
Excuse my horrible example above but I'm trying not to offend the Nissan die-hards....used to be one myself...but have since moved on.
4 Likes
WebCORE has nothing but issues in any platform. The reason is it is an abstraction from the core. Yes there isnât much delay in response time in layering BUT where it flops is on any changes. In ST this happened often requiring WebCORE to be constantly monitored for potential updates.
With HE if you are using WC and it is stable then you should choose to wait a while prior to upgrading HE or WebCORE until it is considered stable. The biggest benefit to HE is upgrade on your terms on your time. Unlike ST that would do an update fix to fix the update fix that would fix the .0.1 useless upgrade mandatory to your box. This was my biggest complaint and reason for stability issues with ST. Relying on WC to not stop working.
So I am with 99% of the folks here. HE is super stable, reliable and the developers respond quickly to ghosts in the machine. Getting rid of WC and asking for features in HE (which were delivered) gave me a robust, fast and stable system.
2 Likes
That's you...but others have had a different experience. Some of the most used automations I have rely on webCoRE to work. Nothing in the native architecture of Hubitat would be able to do it. Let me explain one....
I work from home...and when I have a conference call coming up in my Outlook 365 calendar, I get a webhook from IFTTT with the start and end times as well as the subject. That triggers a voice alert when the webhook is received and again 5 minutes before the meeting starts with the description of the meeting. In addition, LED strips I have throughout the house, flash red for 10 seconds and return to normal. Then, at the start of the meeting, all my audio alerts are shut down until the meeting is over. I have even gotten this worked out so that it accounts for a second webhook while i'm in the first meeting as well. It all runs through a few very complicated pistons that I have spent a year perfecting. Now, how could I get the same functionality through the base of Hubitat? I have adjusted my pistons to avoid the use of global variables as well as some other iffy spots I've seen in the logs but i have experienced zero issues with hub slow-downs or lockups. Plus, I don't know of any way to do those things since it involves parsing Json data and storing variables. Two functions not available in RM. Short of learning to code in Groovy, which I really don't have time to do, I don't know of any other way to get the functionality I've described in HE.
I agree, webCoRE should not be used when there is a native HE app that can do the same thing. That's why I've moved 95% of my pistons out of webCoRE and into RM. It was painful but I did it. But there is still those 5% of situations which are not available within RM yet, that's what I use webCoRE for. It's like a golf bag. When you're in the sand trap, you've gotta pull out your sand wedge. Everybody hates it and it's a pain in the ass but hey, it works, so you use it. The trick is using it right and only when you need to.
1 Like
Your example is my point. If you have a stable WC in HE running 2-3 pistons without any issues then you should run it but with reserve. Aka meaning when 2.1 ever comes out you hesitate until those who love to take risks and update resolve the WC potential code changes. Also this means to also hold off on WC upgrades until you are confident in the changes and the results wonât waste many hours attempting to solve an issue that ultimately is because of WC.
Lastly, if you are using IFTTT you could do what you are asking with multiple rules in RM. Your scenario may not be as complex as you think when you break it down. May need to use to use virtual switches or pause rules accordingly but I bet you could reproduce your scenario using HE and IFTTT. I would love to see your piston. The reason I am saying this is I used to think I could convert a VERY complex piston for auto starting vehicles dependent on if they were in the garage or not. I use a webcam to see vehicles in the garage and execute a garage door 1 or 2 open depending on the vehicle being started. I have this all running in RM with only 2 rules for each vehicle. What I thought was complex really wasnât.
Really? But how could I parse the data from IFTTT on the start and end times? They come as JSON data in the web hook and I don't think there's any way to parse that it RM. I will post the piston when I get home if you're really interested.
Hey Ryan,
I'm not an expert in WC but I had it and I love it but, I had to get rid of it when migrated to HE.
Is not there any options to install WC into a rpi or server locally that will work like ST cloud? I mean, to release the CPU of HE to do all the WC process? Unfortunately we can't expect the CPU of HE to handle everything we add, it's not very powerful or if it is, then it has limits for sure, maybe we are overloading and that's why shell access, or cpu stats right?
Just asking because I can try to test my self to add a rpi for this.
1 Like
You can overwhelm the CPU of the hub, if you don't know what you are doing in webCoRE or you try to implement something that causes a race condition. But this has also happened to developers of regular apps in HE, not just webCoRE. The point is, if used properly it is a wonderful tool. And those of us that were HEAVILY dependant on it in ST have to adjust our thinking and move things into native HE apps when possible. Not because webCoRE is bad but because it allows for things to be cross-connected causing the pistons to run away with all the hubs resources. But this is easily avoided with proper planning and implementation. As I've said, the elimination of Global Variables in your webCoRE pistons seems to be a HUGE help. Almost all of the scenarios I've seen of people having problems it's when there are global variables involved. And that is because any piston that uses one as a trigger is evaluated EVERY time ANY of the variables change.
Also, the RPi used for webCoRE has nothing to do with the execution of the pistons. That is all done on your hub. The RPi is only used to edit your pistons. Basically, that is where the web dashboard for webCoRE lives allowing you to use the webCoRE interface. None of the processing for the execution of the pistons is done on your RPi.
For those that are interested, here's the example I was talking about. Now, I have combined a bunch of pistons into one to avoid those global variables so it's kind of long but it works very well.
My sense with webcore is that there are some actions around piston creation that do something to the Hubitat "database" and whatever it does to the database is currently un-recoverable short of a restore of the db. My anecdotal experience is that adding new devices to hubitat, and then adding them to the webcore app is some kind of trigger.
Whatever happens, both hubitat and webcore still seem to work, but both get slower and slower and eventually start dropping events. This slowness is present across reboots, so this suggests to me some kind of corruption of the "database". I don't quite know what a restore does to the db, but doing one seems to reset the state and speed everything up again.
This could all be entirely wrong, but my hope is that now that I'm done adding devices, my current fast hubitat/webcore will be durable in its current state.
Webcore 99.5% works. It would be a shame to give up on it based on one or two bugs. I'm simply trying to make the case that if we in the community had a few more tools to help debug and extend it, I don't see how that isn't anything but a win for Hubitat.
Ok, but that processing power is not done at the ST hub neither, it's done in a cloud, is not a way to replicate that way but using HE? ST Cloud=rpi?
I totally understand your points and your needs, I'm interested in WC too, just trying to see options. I got a second hub, maybe installing WC in that hub and nothing else than hublink will compensate the lack of processing power if that is the main issue, who knows.
No, ST cloud = HE hub. RPi = webCoRE cloud (dashboard.webcore.co). That is where you go in ST to edit your pistons. A separate cloud environment. There is no way to offload the processing of your pistons from your HE hub to another device. It has to run in your hub, otherwise it won't work. That's kind of the whole point. In ST, it may process in the cloud, but it processes in your part of the cloud. Within your "hub in the sky" as it were. If you want to use a rules engine outside of your hub, try something like Stringify or Sharptools Rules Engine.
+1 for read only shell access.
from the various threads about unresponsive or slow hubs this week ⌠read only shell access would be great help for all. at a minimum if there is a way to view hub information like top output that would be a great start:
When I first came over to HE I had about 50 pistons in webcore. But webcore gave nothing but problems. It took me a while to learn groovy and adjust my thinking but eventually I got off of webcore and uninstalled it completely from the hub. It has been much faster and much more stable since.
I highly recommend looking at the built in apps and RM to do what you need. Learning groovy to write your own apps has opened up a whole new world of possibilities too.
3 Likes
Is the groovy stuff any faster? I was surprised to find that with the RM testing I did, when WebCoRE is running well at least, both were comparable in response time.
For me I use a lot of @globals in WebCoRE and I'd have to figure out how to recreate that in groovy.
Right now I once again have webcore running well. I guess I'll see if it stays that way.
With my tests I noticed significant difference.
For example, I would write an app that would pair a switch with an outlet. When I toggled the switch it would then toggle the outlet. In webcore it was noticeably slower and this was my deciding factor.
WebCore is an app written in groovy. Its just a bunch of extra overhead but does simplify creating automations with some power. But you sacrifice speed with it, especially when working with things that require the speed. It also puts a lot of extra strain on the hub as it does a lot of stuff in the background.
2 Likes
The sample groovy app I'm looking at seems to define methods for handling a lot of low level operations like tracking motion state and inactive time. I'd rather spend my time coding the behavior I want than figuring out how to implement my own low level triggers. Are there libraries of these sorts of things that you can include?
