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

From my personal experience, I would have to disagree with the following statement:

HE was my first home automation hub. I am old enough that when I took typing class in high school, pressing a key resulted in a bar flipping up and striking a piece of paper. I have no computer programming experience, but have found computers to be useful in my life, similar to the vast majority of the population. I like to do puzzles like Sudoku, but I don't think that makes me a geek or a technical person. I currently have 42 RM rules and I would consider some of them to be complex. Was there a learning curve, yep there was, but it wasn't that hard. Now that I am comfortable with RM, I took a look at Webcore and it looks like greek to me, makes no sense. I am sure I could learn it, but why, RM does what I need.

I think people that come from Webcore, experience the same thing. They like webcore they think it is easy and RM looks confusing and not for average tech users. But I wonder if this is just because webcore is what they are use to using, so therefore intuitively think it is easy and better.

5 Likes

This captures the issue pretty well.

A lot of how one views these apps has to do with one's background, including the obvious observation that an experience WebCore user will prefer WebCore and an experienced RM user will prefer RM. My guess is that people who have coding experience will find WebCore more intuitive and logical, because, it is laid out more like code than RM is. For people with no coding experience, either app is going to present a learning curve. When RM was very first developed, a well known ST user - forum member offered advice that it should be based on pull-down menus, not based on "code". My initial thoughts had been more along the lines of a small programming language (where WebCore sort of ended up). Now it's an odd mix of pull-down menus that result in a script of actions.

No matter how you go about it, and no matter what you are more comfortable with, it remains a fact that figuring out the logic of a complex automation is not just a trivial thing to do. The apps provide a means to express that logic, but one must have valid logic to express before an automation will do what you want.

8 Likes

I'm not a programmer, worse, I'm an engineer :slight_smile: The programming I've done was simple a means to an end. Because I've been doing this for a looong time I am most familiar with non object oriented languages. I recall the mindset problem when I needed to write my 1st Excel macro in VBA. I think what you are describing is similar.

That being said, I would be great if there was a "compiler" that would convert a text file to RM rule that could be imported. This would be ideal for me as the only way I've found to become friends with RM is to write the rule in a text editor then transfer it to the UI.

Such as:

Select Trigger Events
When time is 11:16 PM EDT
OR 
     Illuminance of Multisensor_6  < 350
OR
      Time is 1:00 AM EDT

Select Actions to Run:

IF (Illuminance of Multisensor_6 < 350
AND
    Time between 4:00 PM and 10:00 PM
 THEN
     Activate scenes: Accent_LIghts

ELSE-IF (Time = 11:16 PM 
AND
NOT Mode is PartyMode(T)
THEN
     Dim: Acc Lt (DR), Acc Lt (Foyer), Acc Lt (Console), Acc Lt (LR East  Wall), Acc Lt (FP Left), Acc Lt (FP Rt), RGBW Controller, Acc Lt (FP WW): 0

ELSE-IF  Time is 1:00 AM
 THEN
     Dim: Acc Lt (DR), Acc Lt (Foyer), Acc Lt (Console), Acc Lt (LR East  Wall), Acc Lt (FP Left), Acc Lt (FP Rt), RGBW Controller, Acc Lt (FP WW): 0

     Mode --> NormalMode

END-IF

Oh, well, nice idea -- should only take a Saturday afternoon's effort :rofl:

4 Likes

I never expected it to come to fruition and realize it (a compiler) might likely not be even the best approach if one actually were to consider something. Was just a thought.

You should also know that I came from many years of X-10. A little time with Vera.
I think your platform is awesome. Nit picking the entry method of RM is only a minor point. Overall I am extremely pleased with the platform hardware and usability. So kudos to you and the team.

1 Like

So I'm not sure why this thread suddenly reanimated after almost a year, but couple thoughts:

  • people who suggest "obvious" approaches should take a look at the SmartThings documentation. Among other minor impediments, as far as I can tell the environment doesn't allow code to lookup devices - the devices have to be selected from the UI. That means we can't create rules from code. (God, would I love to be wrong about that - please tell me how to do it, if so.) But it certainly won't allow basic coding primitives (e.g. creating classes) which make suggestions like this impossible.
  • I'm not sure I completely buy the argument that "webcore is too programmer like, and Rule Machine is more intuitive." My perspective is that RM is pretty programmer like... i mean, we have to add both "end if" statements, which is completely unnecessary in visual development environment.
  • My original complaints about RM were a mix of insight and ignorance. The UI could be better organized, the mix of delay primitives is confusing, and the interaction model between rules would be better modeled as message passing.

However, I decided to prove it by writing my own take on this, and holy crap is it more work than it seems. I hope to have something this weekend - I'm refactoring basically working code again again, because I coded myself into a corner again again - but if people are interested I'll try to push something out in the next couple weeks. [*] But all of this is basically to emphasize that we should not ignore how impressive Bruce's app is. It provides application-adjacent access to a very complicated programming environment, and provides a ton of very useful functionality. There are always more ways to do it, and I think the app could be improved, but what it provides is really impressive.

[*] my employer requires a process for releasing any code, so I have to go through review before I can publish the code.

1 Like

This is true for Hubitat also, at least wrt to user apps. System apps can get around this, but it would be a huge security hole to allow this in user apps.

Open to suggestions, as opposed to value statements. There are two delay primitives, one per action and one for all actions; again specific suggestions for improvement welcome.

The interaction model between rules is not the passing of messages, so why would it be modeled that way? It is actually the invocation of methods.

Rule Machine was originally implemented in one weekend. That was 6500+ lines of code ago, and perhaps ~100+ upgrades.

1 Like

Open to suggestions, as opposed to value statements. ... again specific suggestions for improvement welcome.

Heh. Well, remember, I'm OP on this thread. So I've made several, right? And you've rejected them. Which is your right! I'm implementing my own and we can hopefully debate specifics when I get there.

But to repeat a couple:

There's no reason not to inject the closing statements ("end if") when you create the opening statement ("if"). You suggested a while ago that you can't do so due to a limitation of the platform, but that's not entirely true. It's a limitation of how you've chosen to implement against that platform. (This one I'm confident in, but it'll be much easier to show than tell.)

There are two delay primitives, one per action and one for all actions

When I wrote my original post, I was definitely confused about how to use delays. But let's agree there are three: delay, pause, and wait. And some delays are cancellable. And they're organized into different collections in your UI. It's useable, but I think it's needlessly confusing.

The interaction model between rules is not the passing of messages, so why would it be modeled that way? It is actually the invocation of methods.

Yeah, but it completely breaks encapsulation, and means that users have multiple ways to interact. I would recommend you embrace message passing as the mechanism for invocation. It creates better encapsulation, making it clear how any action is invoked. I think it simplifies things for users; all we need to do is write methods that respond to events. If I want some other rule to do something, I send a message.

You can't do this now, of course; innovators dilemma, there's way too many rules using direct invocation. But this is how my system will work, and at least for the way my brain thinks about things, it's simpler.

this is not true at all. depending on where you place the if when you are editing an existing rule it is not at all clear where you want the en-if.. maybe in your mind in a very simple case but when you are modifying a complex rule with multi nested if's this is not true.

First of all, touching other rules from a rule is a fairly unusual thing to do for most users. And, yes, users have multiple ways to interact. This is both a strength and a weakness of RM. Weakness, because users can be confused by it -- as if that isn't easy enough already!

I don't recall saying that was the reason, but I agree there is no platform limitation to prevent doing it. But there is a reason not to do it, as doing so would create another issue -- the need to then insert subsequent actions before the END-IF rather than simply adding new actions at the end of the rule. Establishing the context of where a new action belongs becomes it's own problem set (hence action cut/paste).

At the end of the day, I did my best in creating Rule Machine, and I know better than probably anyone else how imperfect it is. It's worth bearing in mind the history of this app. At the time it was created it was the first and only home automation rules engine. At one point it was withdrawn from ST, and that event gave birth to Addy's webCore (Communities Own Rule Engine) development. RM has always been pushed along by user requests for capability, with a dose of my own insights into how to improve it over time. It's a work in progress, full of warts and shortcomings. It can certainly be outdone by someone seeking to do so, someone learning from its shortcomings, seeing the issues that must be faced, someone wanting to create something better.

I heartily encourage you to create something better! RM began as a community app. Go for it!!

And when you do, don't forget somebody is going to want the ability to stop a fade over time midstream... etc etc...

7 Likes

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!"

:slight_smile:

2 Likes

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.

4 Likes

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. :slight_smile: )

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.

1 Like

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:

  1. The UI is difficult to learn and use.
  2. RM has execution time overhead.

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.