Yeah, I get it. And honestly, coding on this platform is a bit like swimming in jello. I understand the security considerations so I'm not criticizing - but I definitely tip my hat to what you created.
I have a much easier problem to solve, of course. I get to say, "Yeah, I can't support that. Just go use RM!"
For all practical purposes, this is the same as classic ST for apps. We've made a number of improvements that help do a better job with the UI, but the framework is pretty unwieldy.
When I was a grad student in Computer Science, my speciality was in the area of compiler construction, abstract machines, and software portability. With that orientation, I've thought that one way to address this problem set, that would go directly to @JohnRob's vision above, is that a decent "programming" front end -- WebCoRE would be a good example, that drove a compiler to spit out a Groovy app, would be very powerful and worthwhile.
A user would create a rule in an editing environment, and hit the Compile button. What comes out is a fully formed Groovy app that implements the rule. These would be tight, carry little UI overhead, and themselves be editable. The UI of the app would allow for device selection (similar to, but better than what is done when you import or clone a rule) -- thus overcoming the security issue about device selection.
I have played around with this using WebCoRE as the "language". Most of what has to be compiled into Groovy is very straight forward to do. This would be a much smaller project than creating a rule engine, and the result would be more powerful than even Rule Machine.
I understand that the limitations are the same as SmartThings. And that's a pretty elegant solution.
...but given what we have access to in a user app, I shudder at the idea of building a real compiler. (You debate YACC vs. ANTLR? I laugh at your use of tools! I will write a compiler in a single, monolithic groovy file without using classes! ...uh, no thanks. )
The project I describe could be done as a 'cross compiler', that runs wherever it would run best. It's going to spit out Groovy text. That can be imported into Apps Code on the hub.
Ah, ok. Sure, that's much more reasonable. Seems like a fair amount of work for perhaps limited benefit, though. After writing a rule, users would have to import, establish the device settings, test... Maybe I'm misunderstanding (I don't claim to fully understand the constraints) but it seems like we'd have to re-establish the device settings each time. If so, I'm dubious simpler specification would really be worth it.
Each time you do what?
When I work on one of the built-in apps, I can change the source code and not touch the device selections -- they stay in place. Only if I make a fundamental change, like going from a single device to multiple, or changing from a motion sensor to a contact sensor, do I have to reselect anything. So, 99% of the time it's just work on the code and then test. That's how regression testing works also for app changes.
There are two things about RM that people complain about, one legitimate and one less so:
Both are fully addressed by this idea. The UI moves into a nice editing environment that can use Maker API to get full information about devices in the hub for presentation in the editor; and the 'language' is now whatever dream language one wants for defining an automation. The app execution time is optimized to its theoretical minimum, because the app only implements the rule, nothing else.
Or, use Node Red. It's providing an editing environment, and just hooks into the hub via Maker API. A similar approach could be done with any editing environment, where 'compiling' is an optional final step, if even needed at all.
If you happen to think this is better than RM:
I would rather have this than a new RM!
I personally think that Addy missed the boat on this one. WebCoRE spits out this huge hairy JSON structure, that then runs on an interpreter when the piston runs. It would not have been more effort to spit out Groovy instead.
Yeah, you're definitely right. I was misunderstanding your suggestion. That seems like a great solution, especially for complex rules.
I personally think that Addy missed the boat on this one. WebCoRE spits out this huge hairy JSON structure, that then runs on an interpreter when the piston runs. It would not have been more effort to spit out Groovy instead.
Maybe. If I understand the intent, he was focused on cross-platform. The JSON can be ported to any implementation of the interpreter on any platform.
At the time, no, he wan't. He was purely focused on ST. WebCoRE grew out of its predecessor CoRE. That created a certain mindset and orientation. It wasn't until years later that I realized both what he'd done and that there was this alternative. I have huge respect for Addy, and what he created, so in no way am I criticizing what he accomplished. More like, after a lot of reflection, "I should have had a V8".
A very strong JS engineer with the right language chops could rework WebCoRE editor to do this. I looked at it, but I'm JS novice.
Be ready by Monday then?
That Node Red sequence is very scary and complicated looking especially when taken out of context. Would be cool to see the equivalent RM rule / WC piston for comparison.
These rules/sequences etc can be as simple or as complex or ugly as we make them..with great power comes great responsibility. 
edit: I think RM is awesome too - for my use-case NR works better but I am always open to possibilities.
Agree, this sequence replaced 3 simple automations with restrictions and a couple rules.
I have used all three examples talked about, rm, nr, and webcore as my backbone. I could do all of my crazy automation with all three. Webcore’s interface is easier than rm by a long shot, rm will always be supported, nr is the easiest for a visual programmer. Each has its place for users.
For the new HE owner (who was not actively using WC in ST) I think that getting into RM and RM-Lite apps is the way to go. It just makes sense from a platform standpoint and has far more support available. With the others the user assumes more of the responsibility and risk.
With the apps I think you can do a lot of cool stuff just not necessarily in one huge single rule. That's what I like about those and most of my HE rules are with the apps now. RM is and maybe always will be for the advanced hard core users, so I wouldn't necessary say it needs to be pretty because even a great GUI would still make it complex to the average user
Apps are probably the best way to optimize your setup if you have the desire and ability to do so. There will always be trade-offs and the issue will still be one of resource management and reducing overhead. In using NR I've traded the pure optimization for greater flexibility, control and reduced overhead - and I would argue ease of maintenance. On the downside I've also added a potential failure point and additional complexity to the system that I must support myself.
As you've found NR is not for everyone. Building a home system using the powerful tools that come "stock" with the hub seem like the best solution for most HE users wanting to automate their homes. apologies on the reiteration from the prior post.. kind of boring really. 
I love node Red it's not so straight forward but I change my mind so much about rules that it's easy for me to just delete and add as I see fit
Kinda late to this discussion, but I have a question. I have been a webcore user for many years. I abandoned ST at the beginning of this year and switched to HE. I am learning RM but it does have a different mindset from webcore. I have transitioned all of my pistons from ST to HE. Should I be writing new routines in RM, or do we expect webcore to be around for a while on the HE environment?
I was the same as yourself with regards to WC. Just imported all my pistons from ST.
I then gradually converted them to RM. Simple ones first then the more complicated ones. I now only have a handful of pistons running.
My thinking is to try and use 'in-house' apps as they are supported by the HE staff and should always be updated etc. when bugs etc. are found.
As for WC not being around, it is supported by a couple of users here who are very active in keeping it up to date and resolving any issues that crop up. It does run locally on the HE hub so in theory there is no need to move away from it. The only issue that may arise is if the WC server is closed down which will mean you will not be able to define/edit any pistons. You can get round this though by using a local WC server, an RPi for example.
Download the Hubitat app
