Normally I like to run things "lean". In this case it would be with minimal user apps. Why? I think its a personality flaw.
However it certainly seems WebCoRE is much easier to edit (and perhaps create) than RM rules.
So I wish to dip my toes in the WebCoRE pond.
I understand I load two groovy files in Hubitat apps. And one of them will generate some ID number. Its here I start to wonder what is the goal of this number. I believe it is this number that allows me to log into the WebCoRE interface. So what does this number communicate about me and my system?
I believe the Web based editor is likely harmless however I don't know if it downloads directly to my hub (not good) or allows me to download to a file then load as an app.
Any thoughts would be appreciated. Also if anyone uses WebCoRE but would not have started again (I doubt any of these folks will respond to my post but I can ask).
The webcore editor edits a piston. The piston is stored in the webcore child app (that is the piston) which is seen under the HE console apps -> webcore -> child piston. (this also means when you take HE hub backups, you have backups of all your pistons.)
You can backup pistons to local files, but the browser editor is interacting with the HE hub.
It needs to to be able to run / debug / trace / stat the piston, as well as show you what devices, etc are available. The browser app is a IDE vs. just an editor.
The browser (or any browser) cannot get access until you grant it (this is the browser registration code). The browser / hub communication is thru the standard HE cloud endpoints (these exist whether using webcore or not), so webcore does not open up network ports or the hub in some 'different' way than it is already setup.
You can run the webserver for the IDE html/css files locally (ie no internet). This has the side effect that you can only edit pistons when you are on your home network, or have a VPN that both your browser, your html/css web server, and the HE hub are all accessible.
This is described in note 2 of the webcore updates thread. It is likely a good idea to read note 1 and 2 of this thread to understand how things work.
Current data for small piston execution on my hubs is 5 ms at this point.
Just a note; I have trouble with generically named files (i.e. Update A and Update B) because there is no reference if this update is valid or to which version it applies. I personally wish folks would use version numbers.
Well Webcore requires cloud operation I think? When I find RM isn't doing what I want without undue kerfuffle I write a Groovy app that lives locally on the hub. Have you already considered that?
Honestly, I find webcore easier to use than RM. But, I have been writing pistons for several years now and I only moved to HE about a year ago. I do use RM for a few things. I have written hundreds of pistons. I still have pistons running in the SmartThings environment. But I have all but abandon the ST platform because groovy will be closed down on that platform in the near future and that will kill webcore. So I moved everything to HE and I am quite happy with it. I have about 80-90 pistons running daily. I have about 5 rules in RM. I am not anti-RM. I just have far more experience and comfort in the webcore arena.
The appeal of WebCoRE for me is not just efficiency. My lone C3 with 80+ Zigbee & Z-Wave devices runs >100 pistons; last time I used RM it was version 3, and WebCoRE beat or matched it in every benchmark I devised then; it's been optimized considerably since. It has a true IDE with editor (copy, cut/paste, drag/drop are super handy for modifying complex automations as is the ability to comment them).
What really sets it apart is the ability to trace (and time) the execution of every conditional; debugging and optimizing automations is much easier. Local, global, and system variables are on dispay and you can see when timed events and delays are scheduled.
The only downside is that it's easy to create a piston that looks right flow-wise but doesn't execute the way you'd expect. It's critical to distinguish triggers and conditions; the 'lightning bolts' help considerably to highlight statements that cause the piston to execute as does the keyword segregation by conditions/triggers in the condition->comparison dropdown.
If you are looking for even greater efficiency the system RM apps are the way to go. If you want the absolute most efficient rules then roll your own via custom apps. Another option is offloading rules to another system connected via websocket or using the Maker api app - that can lighten the hub resource load and the speed is very comparable albeit a tiny fraction slower.
The other consideration is ease of use - As a programmer type person I found WebCoRE IDE to be super intuitive and the debugging excellent. Disclaimer: I have not run WC in a while but certainly appreciate it's strengths.
edit1: I would absolutely consider running the cloud stuff locally if you can. Who knows what will happen to WebCoRE in the future. The situation is complicated thanks to Samsung. Maybe things have changed since I last looked a few months ago.. dunno.
edit2: Some good stuff here.. things maybe okay so apologize for "chicken littling".
Agree with running the IDE locally; I like knowing my RPi is available in case of cloud issues... I still remember the trauma when my old CM15A /X10 ActiveHome Pro became dysfunctional when its cloud-based authentication scheme stopped working.
I do all my automations in webCoRE, everything from VERY simple stuff to VERY complicated stuff. I also try to keep everything together so I don't have to troubleshoot a million apps all trying to run stuff.
I would install it with the Hubitat Package Manager and try it out with the web-based dashboard. I haven't gotten to the point of running the dashboard locally, but I've also written hundreds of pistons over the years and everything has been just fine.
I don't think there is data to support RM is faster than webCoRE.
In the data on tests done (anecdotal) in the webcore thread, it was not true. I would be surprised if it is given my own testing and optimizations.
The hub is variable in its operations, given the db and asynchronous nature of events. I would love to see real data, but it is hard to get any performance data out of RM.
I was only going by comments Bruce has made in the past about WebCoRE... where he thought that if you could compile the pistons into groovy code it would be much more efficient. Certainly main RM app has some inefficiencies because it has to take into account a lot of different scenarios where the "lite" versions are much more focused.
EDIT: My knowledge in this area appears to be a little dated so please take this with the proper grain of salt!
I've found external calls to Maker API to be equally speedy as well.
Similarly, I started playing with WebCoRE before moving to HE. I dabbled with RM just long enough to break my first few rules. Then I learned that WebCoRE runs locally and never looked back.
Thanks for all the input. I've installed the groovy files and am looking for an example for me to familiarize myself with the IDE and structure of pistons.
My motivation is not speed (at least not at the msecond level), but ease in writing and editing automations. I've not been able to become even close to efficient with RM. Probably my own mindset.
I have been an ardent webcore user for roughly 4 years after I "accidentally" discovered it on a side conversation on a YouTube video. Its an incredibly powerful tool and definitely fits within your personal condition of wanting to run lean (I think I have the same affliction).
I not only came from ST on Webcore but also successfully automated my entire HE on it. I tried RM twice and I just don't think it was for me.
There were a few quirks in the HE version of webcore but the product owner has been very engaged in resolving issues very quickly recently. The issues have always been in the Webcore HE code, its just now enough of us have converted and used enough of the obscure functionality, and now somebody is applying fixes, those bugs are getting reported/fixed quickly. Nothing that's ever been a showstopper or impacted my functionality.
Even if you have minimal home automation experience, I HIGHLY recommend webcore. Its very approachable and I don't think I've ever discovered a limit of what it can't do. So much so, I finally got to a point where if I couldn't get a device into webcore, I wouldn't buy it. It made my entire automation experience much more streamlined.
My biggest pointer would be to create an automation control piston that keeps all your virtual switches for your various automations that one might use to stop automations by voice. It's very responsive, I can tell Alexa to turn off a rooms automations and walk right into the room. You have to make a separate piston to handle this so when you do the pausing/resuming of pistons the virtual switch automation isn't affected.
If you can think of something you want HE/Webcore to do, let us know. Chances are someone already has a piston they can share with you, and then you can mess around with it.
