Rule machine 4.0 is too hard to use (Part I)

I'm trying to wrap my head around how to leverage Rule Machine. It's well designed, provides elegant control structures, and is hamstrung by a terrible user interface. It could be amazing, but instead every time I try to create or edit rules I find myself on the edge of rampaging around my house breaking things.

First, the programming environment is cluttered, stateful, full of context switches, and challenging mental mappings. The visual display of the code is needlessly confusing:

IF (Treadmill (off) is on FALSE) Delay 0:20:00 
    Off: Treadmill 

instead of

IF (Treadmill is ON)      [off => FALSE] 
   Delay 0:20:00
   Off: Treadmill

The editing environment adds additional befuddlement - we get drop-downs below the code asking us to mutate the environment ("insert action before: [one thing] [another thing] [a third thing]"). In a modern browser, that's unnecessary - it could even be done with nothing more than better HTML/CSS, it wouldn't even require additional javascript. (But the underlying visual elements aren't well structured; many of the text elements aren't wrapped in their own <div> or <span> tags, so I can't even define my own CSS and attempt to clean it up myself).

Consider the below representation instead, where clicking a "+" adds an element in place, and clicking the "x" removes an existing one. (I'm using text, so my ability to format is a bit limited, please use your imagination - I'd probably try making these tiny "add" and "remove", or graphical elements, to reduce visual clutter):

IF (                           [false]   x
   Treadmill is ON             [off]     x +
   Delay 0:20:00                         x +
   Off: Treadmill                        x +

I believe this would be significantly more usable. With a little javascript, the changes could be defined in place. (BTW it's easy enough to always display an "else" clause, and then under the table ignore it if there's no code in the code block. This makes adding a conditional both easier and less confusing.)


People have, in the past, made similar (and different) suggestions for RM UI enhancements. There is no doubt that on the HTML, CSS, and JS side, one could do better, but the issue is that Hubitat has an underlying app UI framework that was largely inheritied/reverse-engineered from SmartThings--basically, it allows you to define inputs (dropdowns, text boxes, etc.), links to other pages, paragraphs, and (new to Hubitat, though ST had limited automatic capability for doing the same) buttons, etc., which the Hubitat admin UI (or SmartThings mobile app--which this was originally designed for) renders for you. In Hubitat, that happens to be a webpage, so HTML/CSS/JS is the output. On ST, it was likely native app UI elements, though it's possible they were doing something similar under the hood. Regardless, if you ever used RM or CoRE on SmartThings, these limitations will be apparent. This is probably one of the reasons webCoRE was created--editing is done outside of this framework (but not without other disadvantages). RM on Hubitat is pretty similar, though recent versions have both improved its power and push the limited app UI framework far enough to show its limits.

Staff have indicated in the past that they are open to reworking the app UI model, but hinted that RM would probably not be the first place this happens (there are many "regular" apps, in my opinion, that could also benefit). However, there is no timeline or even any certainty at all as to if or when this would happen.

In the meantime, I have seen occasional posts from people who either don't like or who are confused by the "(T)" or "FALSE" or "(on)", etc. indiciations of current device states or epxression evaluations. Some can also add quite a bit of text to the UI. Perhaps they could make some people happy by adding it as an option to enable/disable the display of this "helpful" text. Without making each action into its own input/href/button, the "X" and "+" icons next to each action would not be possible to create under the current UI framework, and with none of us having access to the RM code, it's difficult to say how difficult the former would be. I would not hold my breath on this based on other responses I've heard. :slight_smile:

If you're at all interested in development and are curious how app UIs work on Hubitat, I suggest reading the classic ST docs for SmartApps (Groovy, not their new web-service model) and Hubitat's developer documentation, along with some forum posts that can help explain some of the differences between these otherwise similar environments. If not, I guess the above is a summary--the apps are not "underlyingly" written in HTML/CSS/JS but rather an abstract framework, originally intended for mobile devices, that happens to convert them to such on Hubitat.


Now in an ideal world, you would not have to use Rule Machine to do this. Hopefully Simple Automations will get the ability to do this delay off in a future update. I keep forgetting to ask Bruce if he plans to add this feature in a future release, but they implied this was not the final version of Simple Automation in a recent chat.

The code in Rule Machine (on, off, true, false) is there so you can diagnose, and see the state of things. It does add clutter, but it is there for a reason, and differently colored for a reason. If you can ignore the colors, it may help while building your rule.

As far as the workflow in Rule Machine, I do agree that it is not intuitive. It isn't graphical. But you get used to it after a while. And when you become more familiar with it, you will understand how to build a rule and what buttons to press and how to navigate. I am far from an expert with RM, but it mostly makes sense after a while.


Agree with what you say.

I’m used to it and I find the state in parenthesis to be helpful, what gets me is it’s so sloooow and tedious.

If it would either be faster or let me type in a editor box and try and convert I’d be way happier.

As a dev I can guess how the code is stored. Taking the final code of the rule and storing it in lines in the dB one row per line. But it’s easy enough to split a string on new lines and parse it so that you could just edit text.

I also a think a nice improvement could be to get rid of the state in the text and instead show icons and state in a column on the right.

Either way there is entirely too much clicking to create a rule.

1 Like

That's interesting history, thanks. I hadn't realized. That's a really unfortunate limitation.

If I had a ton more time, I'd invest in development here, but I can't really afford it. Automating my house is about as much as I can afford. :slight_smile: