AHA, we caught you. I'll be promptly turning you in, as well as my expired Dad, he did the same thing. I despise people who take advantage of our gigantic, very nice, freedom loving, technical oligarchs. And don't you worry, on high priority matters like this, the FBI solves these cases in under 24 hours 
2 Likes
What is the path forward for the Rule Editor? I find it really laborious to create rules.
Is there an API that can be used to build rules? I've been showing my 8 year old daughter some coding in Scratch - she can create rules in that 100x faster than I can in Hubitat. How crazy would it be to try and use Scratch as a UI to the rule editor?
(for those that don't know Scratch - https://scratch.mit.edu/projects/editor/?tutorial=getStarted)
Update: I had previous said "It's crazy what a mess the UI is." for which I apologize. I very much appreciate what the rule engine does and those that helped build it. From my point of view though it still needs significant more work on the UI.
1 Like
Rule Machine is what it is. It’s not a programming language. There’s not an easy way that an external app could spit out rules for RM to use. Hubitat’s priorities are focused on other things. Some people find it easier to write apps in Groovy rather than use RM.
Bruce Ravenel, who wrote RM, has always said that anyone in the community is welcome to write a replacement as a community-contributed app.
2 Likes
You could always look at Event Engine and webCoRE to see if they work better for you - believe both are available through HPM. Nice thing about the HE platform is that we have options. (Also can run Node-Red from a Pi if you don't mind adding another piece of hardware.
4 Likes
Thanks @672southmain. I apologize if my post seemed offensive, I understand it's really hard to make a good UX for this sort of thing.
You answered my question though - this isn't a priority for Hubitat. Personally I find that really interesting, from my point of view, rules are really where Hubitat shines (once you get them working 
).
Alexa is already a decent hub, has rules, makes rule suggestions based on AI etc. but, to me, what it's really missing is the more complicated rules. With simple rules you can do stuff that works well 90% of the time, but 10% of the time it's a bad experience. With more complicated rules, you really can achieve experiences that work well 99% of the time.
Anyway, perhaps I'll try switching to Groovy. That actually sounds like a really good solution for me.
1 Like
No need for an apology, I wasn’t offended. Only reason I responded is because Bruce Ravenel has made the same response many times, just saving him time. I’m sure he is very busy.
If you read the Rule Machine thread in the SmartThings community forum, you can see what led up to Bruce giving up on SmartThings (that’s where RM was originally developed by him) and launching Hubitat. RM is much more complex than most of us can appreciate. At this point, it’s so large and complex, so many moving parts, that substantive changes are very difficult. The UI is constrained by the API for all apps. What we see in the UI is an abstract representation of the underlying rule.
I, for one, appreciate the things it can do. It’s just one tool. Because of my age and background in developing and maintaining Unix system internals, I prefer C rather than Groovy.
5 Likes
It did, and it was. Feel free to make your own rule engine app with an awesome UI any time you want. 
After all your hard work make sure and share it with the community for free, too, so others can comment on it.
When you start off a discussion in a combative manner, essentially "this sucks!", it doesn't lend itself as well to a constructive conversation. Starting with "I'm having issues with this" or "is there anything that can be done to improve this" tends to work better in my experience. Especially if the target for the discussion is the developer that spent hundreds, if not thousands, of hours on said product.
But do what you want. 
9 Likes
I’m not sure it’s fair to say it’s not a priority, more so that it would require some pretty fundamental structural changes to how rule machine was developed in order to really fix the underlying “clunkiness” of its UI (again, that’s according to what Bruce has said in this and other threads).
So it’s not a trivial task to accomplish.
3 Likes
Yup, they are definitely able to voice their concerns any way they want. I didn't say anything counter to that.
I did suggest, however, that if they are expecting constructive discourse on the issue that there are better and worse ways to approach the topic.
And I still maintain that position.
5 Likes
6 Likes
Hey, if people just want to vent/whine that's fine too. Sometimes that is healthy. And sometimes (but rarely) leads to a constructive outcome. It just isn't the most effective way to communicate and improve.
But enough. Everyone is free to do whatever they want.
4 Likes
I hate to say it, the majority of us who have switched off of RM onto other platforms like Node-Red have all noticed speed increases much more dramatic than 75ms. This may be true for the simplest of automations, but when you get into some of the more complex stuff or larger rules the time savings can be significant. An example was my goodnight routine which locked doors, armed the alarm, turned off tv's, lights, etc.. etc.. in RM it would take up to a minute to complete. In Node-Red it's down to mere seconds.
I've heard it many times, RM is slower because of the overhead needed to run it. And that makes sense, it's huge and can do almost anything you can think of. But to me this says putting more power under the hood of the hub would solve this issue of speed. If your truck can't haul your big trailer, the solution isn't to buy multiple trucks and multiple smaller trailers. The solution is to buy a bigger truck. But this thinking leads us down a whole different rabbit hole of a "pro" hub or software licensing for own hardware, which is waaay off topic 
I'd be very curious to see a rule that takes a minute to run. We have never seen anything like this. Logs showing this timing would be quite valuable to us.
12 Likes
I heard that.
1 Like
This is the route I went, and I’ve been thrilled with it. It gives me complete control, I can very easily make changes across multiple rules, and I can utilize source control for history and change tracking. If I ever get a new hub, I’ve already got all my rules backed up in GitHub, so I just have to import my code and I’m good to go.
I use Simple Automation, Notifications, and Rule Machine to prototype new ideas, but I very rarely keep them around for long before converting them to Groovy.
1 Like
I got rid of it months ago otherwise you could test it.
It essentially checked the state of every device in the house outside of the master bedroom and turned them all off if needed. In hindsight, it would have been a lot easier to setup a scene and just trigger the scene, potentially faster too. But it was incredibly slow executing. I wish I could say I was exagerating at the 1 minute mark but it was that long every single night.
It's not really an apples to apples comparisson though since I run node-red on a much more powerful NUC. It's like a ferrari racing a civic. If all things were even, I'd still suspect node red would be faster but I can't say that for certain.
Nope, you'd have to do some actual engineering with real measurements for that assertion to be meaningful.
It's at best anecdotal, and probably not even what you think it is. There are many factors that can make something like what you describe take many seconds, but RM's "overhead" is not likely to be to the actual cause. For example, checking a device means loading a driver, and then turning it off means loading the driver a second time, etc.
I had a simple app that turned off 30+ lights. It took 20 to 25 seconds, and it was a small app. Using RM to do it still would have taken the same amount of time, plus 100 ms, but the fact that it was RM makes it the fodder for misinformation about where time is actually spent, and why.
I don't mean to come across as defensive about RM, because I'm not -- it is what it is and I have no regrets about that. What bothers me is rank misinformation about it, or about anything else for that matter. The truth based on facts is so much better.
12 Likes
Not comming across as defensive at all, no worries there. You won't change my mind on RM, but the conversation is educational.
So a simple app that turns off 30+ lights taking 20-25s, makes my goodnight routine taking a minute seem even more normal. There were 40+ lights, a few plugs, 5 locks, 18 thermostats, alarm, blinds.... I implemented the check state beforehand to limit traffic to those only needing a state change because of the amount it was trying to do at 1 time.
So with that said, the speed increase I've seen in node-red on this same routine, do you think that would be because of the added processing power, or would it be because it's not using groovy and not needing to load all these drivers to access stored states? Or a little of each?
If you're controlling devices the drivers are having to load, so that's the same irrespective. It's impossible to know without actually having a side by side test. I'm from Missouri on this one... (Show Me State).
Think about it, you load RM once, and a rule runs -- it's not loading over and over. You hit some devices, that's the same no matter how you do it. There is no reason to believe (absent real evidence) that CPU speed has anything to do with it. All of this is I/O bound (radio speed), not CPU bound. That is to say, CPU usage is a tiny percentage of the time this takes.
4 Likes
As a simple test I just wrote a bare bones app that turns on or off a long list of lights. For the first test this is 14 lights. Time to turn all on based on logs is about 700 ms. Time to turn all off about 600 ms.
Made a rule in RM to do exactly the same thing. Time to turn on is about 650 ms, and time to turn off is about 700 ms.
OK, this doesn't mean very much. I could try loading it up with 50 devices, locks, thermostats, etc. Frankly, I don't expect the times to be wildly different. Why? Caching and the minimal impact of CPU processing time in automations.
Here is the rule:
And here is the app:
definition(
name: "Basic Lights on/off",
namespace: "hubitat",
author: "Bruce Ravenel",
description: "Basic Lights on/off App",
installOnOpen: true,
category: "Convenience",
iconUrl: "",
iconX2Url: ""
)
preferences {
page(name: "mainPage")
}
def mainPage() {
dynamicPage(name: "mainPage", title: "Basic App", uninstall: true, install: true) {
section {
input "switches", "capability.switch", title: "Select switches", submitOnChange: true, multiple: true
input "on", "button", title: "Turn On", width: 4
input "off", "button", title: "Turn Off", width: 4
}
}
}
def appButtonHandler(btn) {
log.debug "before"
if(btn == "on") switches.on()
else switches.off()
log.debug "after"
}
def updated() {
}
def installed() {
}
3 Likes
