RM and all the applications that we publish are written in groovy, and they are written the exact same way as applications written by users, sure there are one or two internal shortcut methods that for security reasons only work with system applications, but that's a very very short list.
RM is big, given the options that it presents, it's going to be big, there's no getting around that, with flexibility comes complexity.
Personally I only have two custom apps that I run (one to manage dimmer levels, the other connects my hubs (pre HubConnect)), having said that my rules are simple and seldom exceed one if/else block.
So the point here is if you have a significantly sized Rule and it's correctly written and you aren't happy with the execution speed, sure, creating a dedicated application to replace it is going to run faster.
In almost every case a well written specific dedicated app is always going to perform faster than a larger more complex swiss army multipurpose app...
Having said that not everyone wants to write or needs to write code, but with Hubitat you have the option to create exactly what you want if so desired...
My intent was in no way meant to put any negativity on RM.. I am seriously impressed with RM and it's capabilities.. And for a non-programmer it is absolutely the way to go.. And I still use it for my simple rules.. But the power and speed behind locally executed groovy code is amazing for more complex actions..
Writing an app for every simple rule I have would be ridiculous..
Yea.. I probably have 15 RM rules that would all have to be separate apps.. I start writing an app when it start requiring variables and has more than one if/then else .. There is one app I wrote that was a simple RM .. but I really wanted to squeeze a few extra milliseconds out of the response on that one.. (my door chime), which incidentally was my first groovy app..
This is why it blows my mind with the reports of slow response times.. I'm sitting here talking about improving milliseconds of time differences.. I have done driver revisions to squeeze a few more milliseconds responsiveness (and fewer packets)
You know there could be RM issues for larger rules due to the complexity and maybe funky interactions. Since you are only using simple rules and custom apps that may be partly a reason why you haven't experienced the issues some of us have.
The way I see it.. RM is high level.. groovy is as close to the metal as we can get on the platform.. Again.. Please don’t take this as me dissuading people from using RM
Me either!! I'm just someone who is interested in tinkering with this stuff and kinda knows how/likes to code. For people who just want things to work should consider using RM before anything else.
I did a demo video that showed how crazy fast the platform really is.. It involved 2 of my drivers and the built-in mirror app in HE... The output of a device through my driver to the mirror app and back out to another of my drivers to 3 different devices.. It was imperceptible delay.. It was almost as fast as if it were a dumb switch controlling a load..
RM is definitely useful. I still use RM for all button controllers for example. Why re-write that? It just works. It is just a lot easier to use the RM options for that. The real motivation for writing my own apps was for lighting control to speed things up. My RM rules were very, VERY complex. So, writing them into custom apps got the response time down so much that friends even noticed when they came over. I was also frequently getting "pop" errors in RM due to rules triggering twice.
The other thing I wrote a custom app for was overall general house control (mode management, HSM control and thermostat control). Since they are all kind of linked but the linking within Hubitat's built-in apps wasn't quite what I wanted, I wrote my own app that does EXACTLY what I want. I wanted modes to be based on Luminescence level and thermostat control to tied to that and HSM to sometimes drive mode and sometimes follow mode. It took a while to nail everything down and work out all the kinks but it was also a learning exercise. I learned so much writing that app about how apps work. Rather than try and make a square peg fit into a round hole, I simply cut a square hole. But that isn't the fault of Hubitat, that's me being very particular about what I want the system to do. I quickly learned that if I want the system to do what I want, then I had to do it myself. Hubitat is going to make the system do what they want to make it do. If that doesn't line up with what you want and Hubitat doesn't want to change it, then you have to do it yourself.
There are other things I would never write an app for. HSM for example. Since it is critical it work right and I would never want to put an app through the level of testing that HSM has gone through, I would never consider re-writing the basics of HSM for myself.
And I also am not meaning to disparage any of the built-in apps. RM is EXTREMELY powerful. I can't even begin to imagine how I would get RM to do what it does. You don't really understand how complicated it is until you write your own apps. None of the custom apps that I have written would do anyone else any good. All of the actions are hard-coded into the app and the only options are for device selection and things like light levels. Everything else is hard-coded. So, I will have to re-write them if I ever move. And I've had to re-write them when I've reconfigured devices. But I knew that going in and the speed and customization was the trade-off I was willing to make.
So, if RM isn't doing what you want, then write your own app. You shouldn't expect RM to change just for you, IMHO. And RM is always going to be slower. You aren't going to get that level of flexibility and that level of universal applicability without trading away speed. The fact that it works as fast as it does considering what it is capable of doing is absolutely amazing.
I am also looking at possibly coding custom rule apps for some "home" clients I have if I can convince them to go HE. For that use-case it's nice to be in control of what's going on since I'd most likely be the first line of support anyway also, hey - billable support agreements...
When I first wrote Rule Machine I didn't think I needed it, as my approach was to write a small Groovy app for each automation I needed. When I discovered that I was using one app more than once, I'd poke at it a bit to get what I needed for multiple uses. This is how Motion Lighting came into being.
Since then a few things happened. Rule Machine grew from about 2700 lines of code to over 7000 lines of code. Motion Lighting grew a lot also, adding options for every variation people came up with. There's a real tradeoff here: RM can do pretty much anything, but it's big and bulky. Personally I only use a small fraction of it. A streamlined Motion Lighting still makes sense.
When I was a computer science grad student (decades ago!) I worked on language translation, software portability and abstract machines. I don't have the time now to do the sort of projects I did then. But what would make the most sense to me would be to create a "compiler" that would translate an automation definition into a simple Groovy app. For example, the "piston" definition for webCoRE, or the inferred "language" of a Rule as summarized on the Rule main page could be translated into a Groovy app. I can easily do this by hand, taking just a few minutes to do it. To create a compiler to do this would be a challenging project, but doable. The first step would be to define the automation language. Then, from that, write the compiler that generates Groovy. It wouldn't really matter how efficient the compiler would be, because the generated Groovy app would be tiny and super efficient when it runs.
I heartily endorse the idea of writing your own small apps to do automations if you have the skill to do so. This approach yields the fastest possible automations, each perfectly optimized to its use case with no extra complexity.
Hmmm.... maybe it's time to go back to grad school.
