I was always tempted to just select every device and be done with it, but I wasn't sure if that would create some overhead or slow things down. Maybe not, since Rule Machine has every device available to it already.
I have the same issue with Dashboards, I go to add a device and it is not selected yet, and I have to go add them to the dashboard and come back.
I haven't seen that. All my custom drivers have all the commands for my attributes available with the the word "custom" in front. I have seen an issue where a driver is shared already with Webcore, and then I add a new command to set a new attribute, and it is not there. I have to uncheck the device and re-add it so it picks up anything new added to the driver.
I had some issues with that too. I ended up with two instances. So I just deleted the user version. Then HPM still remembered Webcore was installed, and tried to update the build-in version once, which didn't go well. I was able to sort it out, but it was a pain.
That just about summarizes my experience. It was the sequence of prior familiarity with WC, early frustrations with the RM interface in Jan/2021 (are broken rules still a thing?), and no strong motivation to start yet another learning curve for Groovy or such.
If I was starting out today and without a catalog of WC pistons, then I might make different choices. Visual Rules Builder is something that I would play with. My first visual rule builder and dashboard was National Instruments' LabView in the 1990's, so it might be nostalgic.
Coming over from ST originally, webCoRE has been my default rule engine, but to be truthful it's largely been a create and forget -> 95%+ of the pistons were adapted from my ST instance on the first migration over and have only been tweeked since. I do have a few Rules in RM, but use it more to prototype routines or to verify that my groovy code is producing consistent results with an HE standard.
Yes, I use both as well. Although, the RM has come a long way! For me, more straightforward configurations use RM and much more complex rules (Changin timing of when and in what order) that trigger many different things. I still use WebCoRE. I, too, came from the original ST.
You just answered your own question. Many people don't program, don't like code, and don't think that way.
Maybe, but it isn't coding, it is dropdown and selection. If, then, else are not hard to understand and read easier than Rule Machine. I certainly do not think in the ways Rule Machine requires people to learn how to think. If you can learn Rule Machine, there is nothing limiting learning Webcore, which I think reads much clearer than RM rules.
I agree, it can be used like a sandbox for testing things out you want to do with Groovy.
Again, for many people it is. Just look at any of the bazillion posts asking for help making rules.
I'm not arguing that RM is better, as I don't really use it much myself. But having helped many people set up rules, some of your assumptions as someone comfortable with programming don't apply to a large portion of consumer users.
HE defines commands armAway() and disarm() for the "SecurityKeypad" capability. My driver for the Qolsys IQ alarm systems also defines those commands, However, my driver does not declare the "SecurityKeypad" capability. Therefore there is no naming conflict and there's no problem calling those commands in my driver from RM.
However, Webcore treats every command in every capability as "built-in" (and therefore immutable) without regard to context or the fact that the target device does not implement that capability.
So in WC, I cannot invoke for example the armAway() command in my driver (which requires arguments) because the "built-in" armAway() command (in the SecurityKeypad capability) takes zero arguments.
Not sure why WC has to do this when RM doesn't, other than perhaps WC is a user app whereas RM is built-in and might have more information available to it. WC in effect requires every driver developer to avoid using the name of any command that appears in any HE-defined capability, if you want to be able to invoke your driver's command in WC.
Maybe it doesn't come up all that often, so it's not worth it for the WC devs to fix. It's definitely a problem when you run up against it, and not at all intuitatuve as to why. AFAIK, this idea of WC's "built-in" commands is not documented anywhere either.
Good observation. I didn't code a lot, but enough so that webCoRE feels better and more comfortable to me.
There is a way around this, I'll have to go back through some old pistons to see if I can find out how I did it.
I am an early adopter of ST and an 'ex-programmer'. When they got all Sammy I ran and discovered this glorious platform.
I love being able to code almost anything I wanted in WC without the constraints of an app.
Adding conditions and variables, tweaking, creating subroutines, passing args and testing with Trace/Logs is just wonderful.
My 100 pistons from pool control to blinds that follow the sun to presence/tags control of our comings and goings is too complicated for rules apps and, at 66, I'm not going to learn Groovy; done with learning. 
Yes, this dark horse lives out in the shadows and is rarely mentioned but I am positive I am not the real audience for HE. The ease of use end user if the 'money maker'.
I was on the self-installed version for a long time as I liked the staging server and the fact that @nh.schottfam and @ipaterson would fix faults found by us there, let us test, and then implement a fix for the mainstream build.
Essentially that fork is a beta test with 'almost' no bugs.
I'll happily start a WC web server if it ever come to that.
This is a decade old hobby for me that I enjoy.
Fantastic thread. I'm also a Smartthings/webCoRE refugee, but I have NO programming background, so Groovy isn't really something I'm interested in. (I mean, like a lot of things I wish I just knew it instead of putting in the work. 
)
Exporting my pistons there and bringing them here was what sold me on Hubitat. My transition was pretty seamless, although there were a couple pistons I had to rethink because they were firing too fast. Pistons that ran much slower on Smartthings became their own trigger or triggered more than once on Hubitat. Oops! lol
I connect with the logic in the webCoRE structure. I don't connect at all with Rule Machine. It's not even installed on my hub. Same with Simple Rules and Room Lighting. Simple or complex, I do it in webCoRE.
I have 64 active pistons and a bunch that are deprecated or paused. Most of them are made to have full and complete control of a situation or device. A very simple piston that turns a lamp on will also turn it off. This also goes for very complex scenarios that have a lot of time or other restrictions. I've recently ventured into arrays and loops, which has greatly simplified some things once I finally get it right (again, not a programmer).
The only pistons that get called similar to a subroutine are the two that open and close my garage door. The garage has too many triggers and conditions that they needed to be separated out for sanity. I'm assuming you do "subroutines" by calling a separate piston?
Only slightly off topic: I use RM almost exclusively, I have not yet learned WebCore or Groovy. However, can either WC or Groovy do this:
Goal: For each of over 40 dimmers, I want to be able to set, at different times of day, whether a top-paddle tap turns a light on low or high (initially). and whether subsequent top-paddle taps cycle through either low-medium-high or high-medium-low (in other words, turning my 0-100% variable dimmers into 3-level light switches).
I want to pass to a function a hub variable (number), a start time, an end time, and 4 or 5 boolean values (1 or 0, or "true"/"false") and return a revised hub variable with a new dimming level. For example, pass something like this "hvCurrentLevel, 1, 1, 0, 0, 22:30, %vSunset%]" (where %vSunset% is set in the calling routine) and get back a revised value for hvCurrentLevel based on logic I've already worked out in RM.
In RM, I could use hub variables for all values but that seems very cumbersome and leaves me with a HUGE number of hub variables. The new Rule Function feature in RM appears to only allow passing of one variable (I haven't actually played with it, just read the description).
TIA for any guidance or suggestions!
Yes. I have many pistons that don't subscribe to events.
I pass arguments to them essentially telling them "what to do" and who called it.
That helps in tracing the operation with the Logs.
Bingo. Feel the same way.
As I alluded to earlier I treat the self installed version as a very tiny beta version.
The solid version gets built into the HE release builds as I understand it.
I believe webcore could handle this. I don’t see why not. And as someone mentioned, real-time expression evaluation. BTW, you can also use pistons as subroutines to other pistons and pass arguments.
Download the Hubitat app
