I for one love rule machine. I've tried a lot of other simple to use polished UIs and still prefer RM.
It may be a bit confusing at first, but I find it very easy because it's just basic logic.
Also I find it easier to make multiple rules instead of one big rule.
Example water heater control. One Main rule, 4 Boolean Control rules.
Here's an example of the private Boolean to turn it on Monday through Friday. Ignore the times, I get up at 4:00AM during the week, and the dirty kids need to shower early in the afternoon.
For what it's worth I initially found RM really hard to use (and to be honest I occasionally still get frustrated by the awkwardness) but honestly once you have figured the UI out you can be pretty quick.
I still wish there was a way to just sort of 'type in' what you wanted (e.g. an alternate input method) but it works so well (once you get it entered) RM is well worth it.
I agree with overall sentiment - Rule Machine is powerful, but it would be nice if the interface was easier to use. I don't configure new rule often, so each time I come back to it, I feel like I have to relearn things.
Yes there is some subjectivity to my opinion, that's why its an opinion - that said with PLEG I 100% agree. PLEG has to be the worst automation system ever conceived and I tossed it after about 4 hours of trying to understand the gibberish manual and obtuse UI.
It's not at all, my criticism is entirely valid - it's a UX nightmare! I work for a software company (the leader in our field according to Gartner) and if our UI team came up with that kind of navigation complexity, our customers would get out the pitch-forks and flaming torches and march on our HQ!
Reactor is clean, simple, yet powerful, you can read it at a glance and know exactly what is going on. Yes, there is a learning curve, but it's not a steep one. RM isn't exactly "hard" either, however, its UI too complicated which makes life much harder than it needs to be.
It took me a little while to figure out RM, but I also find it difficult to edit existing rules. 50% of the time, I have to rewrite the rule from scratch because I messed it up or can't figure out how to edit it correctly. If Hubitat had an rules interface like Node-Red, that would be wonderful!
I only use RM for simple things. Complex rules are very challenging to maintain as you want to add new criteria. The UI is challenging, debugging is difficult (logging is on or off, I can’t customize), and the UI is often very slow to respond. I’ve moved towards building custom groovy apps for many of my more complicated things. Like I have one called Bathroom Manager that handles everything bathroom related.
RM Author here: There is nothing to defend about this. The UI is an artifact of the App UI Framework, which imposes significant constraints on Apps UIs. Is that an excuse? No, simply a historical explanation.
We have had many discussions over the years about replacing the App UI framework with one that would support a more appealing interface. We simply have not had the resources to devote to that -- it's one of those 'boil the ocean' type of projects.
It would be great if you or some other experienced software person were to implement a better UI within the framework that exists. I certainly want to encourage you and any other experienced software people to dive in to the app creation process, and create compelling app interfaces. In the meantime, RM serves its purpose. Writing your own app in Groovy is another way to do anything that RM does, without all of the UI overhead. Point designs... See the Hubitat Public repo for some simple examples.
Back in the Noughties I was a SysAdmin/Biz Analyst and designed Updated UI's for internal company apps being ported from legacy systems to Oracle AppEx - Customers pointing to workflows and UI elements and making disparaging remarks about them is par for the course and enables you to make them better.
Thanks for the background info - it's unfortunate when ones hands are tied by the platform and there isn't much you can do about it.
Unfortunately, my coding skills suck quite hard, however, I'd certainly be open to participating in a UI design/review process should one happen in the future for a new RM.
So what? I hadn't been employed as a software person for over 25 years when I learned Groovy and ended up writing RM (ha! and it shows, right?).
It's easy to criticize a UI you don't like. Not the same as having to come up with something that actually works, right? It's funny how there are all of these 'devs' around here, but no one has taken on this challenge. RM was a community app in ST, and its successor after I pulled it, webCoRE, was also a community app, What, no one wants to take on writing a really good rules engine?
It can also sometimes make you take a critical look at something. I once designed a piece of software that I was very proud of. I thought it was great and would have (at that time) listed it as the greatest software I had written. One day, unbeknownst to the user, I was at a customer running that software. She was having an issue with it and described the software as "the single biggest piece of junk I'd ever used. It's designed by idiots and I'd rather die than use it every day!" (yes, those were pretty much her exact words... I remember it well). Naturally I was surprised but I asked her why. She gave me a laundry list. She was 100% right in everything she said and I learned a lot from that experience and I redesigned that software from the ground up. The negativity she had and the frustration she expressed about how the software negatively affected her every day life was eye opening, even if hard to hear. If I had told her before she commented that I was the guy who built that system and I was very proud of it, and honestly thought of it like my child, I would have never gotten her candor and never gotten to hear that feedback, she would have likely done like most polite people and just told me it was "ok". I think I'm a better developer because of the things she said to me out of complete honesty ... and I learned a new perspective on the "voice of the user" in software UX...
But back on topic... I did try to accept @bravenel's challenge and build something better. I got a POC that I liked, but it basically required "throwing the baby out with the bathwater" so to speak. I didn't use any of the HE app framework. I basically embedded a React app within an HE app and did everything myself in Javascript. The problem wasn't a lack of ability, it's a lack of time. I got about 80-120 hours in (I was trying to learn React so I figured it was worth it) and realized I was maybe 5% of the way through recreating RM... just too much time and effort. So I completely agree with him, the time and effort it will take is significant. Is that really where HE should focus? Not to make me happy, as I said I already found a different solution, I use groovy. I'd rather them focus on other areas even though I agree, RM needs some UI help. Like all things in the world of software, much is possible, but you only have so many hours in the day and so much money in the bank so you do what you can to best use those hours to increase the money in the bank. Since the big competitors to HE don't have anything near as good as RM, there are probably other areas they can focus on to increase the bottom line.
This is the most articulate explanation of the reality we deal with that anyone has ever posted.
It's a hard nut to swallow that one doesn't have infinite time and infinite resources to make everything really perfect in every aspect. One ends up settling for what one can get that works and does the job well enough, for now. Always room to improve. We do truly appreciate the feedback we get, and hopefully we can go on improving this product for all of you...
RM is almost 5 years old. That's 5 years of continuous improvement. Pretty much every release has something to fix or make better. So yeah, it would be a large effort to recreate it. One interesting project I started on, but have put on the shelf for now, was to separate RM into its two halves: the frontend UI, and the backend rule executor. The latter is pretty tight, and has a fairly well defined interface (could be cleaned up some). So in theory one could slap a different front end on it that feeds that same data structure interface. Turned out that one of the crazy complexities is logging, where you want the logs to show things that actually come from the UI, but are happening when the rule runs.
BTW, your approach with React is along the same lines we've talked about: getting the UI into Javascript, and out of the damn Groovy page rendering nonsense.
Feel like I need to chime in here as well. As someone who has used both Rule Machine and Reactor, I must say that I find Reactor much easier to use. There is something about being able to drag rules around and place them where you want. Anyway, I love Hubitat, and Vera is in fact a dumpster fire, but Reactor made it somewhat usable.
One of the problems with webCoRE is that the back-end is 95% implemented. This means that every now and then you try do so something and it doesn't work, and when you finally give up and ask the experts, you find out that particular thing can't work because Adrian never finished it (and went to work for SmartThings, so all work is effectively frozen).
The other problem is the UI at first glance is awesome, but sometimes it's difficult to figure out how to enter or select something. You've often got to get help figuring out which gear you click to do something.
Coupling those with a lack of good documentation make the learning curve difficult.
Im going to stick with RM because I really dont want an externally hosted automation system. Im slowly getting used to RM and it's very functional, just very grindy to get things done.
Luckily HE has amazing logging so I use that to test my automation now and ensure they are behaving as they should.
