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

📐 Rule Machine®
12

I agree with OP and obviously RM has morphed over time. I presume some things were left in for backwards compatibility which is completely understandable. However maybe re-thinking this from scratch isn't a terrible idea either. At some point you need to let go of old ideas. I actually miss some of the old days of RM3.0 where some things were infinitely easier to do. Lately I've been forcing myself to write my own apps to eliminate RM rules that were just getting too complicated. However now starting to have all these individual apps isn't very organized either. Then I wrote a Parent app to organize all my smaller apps under to organize things a bit better. But yes... I'm sure I'll get slammed for ... but I still miss webcore... it was so much easier to use and the interface was really great, the rules (pistons) could be shared between users, etc, etc.

Again though...that platform was running on hosted servers with little concern for overhead vs our now local platform. So everything is relative.

I think it's good people giving ideas for how to improve the platform.

3 Likes
13

How do you define a local variable? I've looked through the documentation and must be missing it.

14

You should have this option at the bottom of every rule:

image
image761×644 26.8 KB

This screenshot is from the latest release of Rule 4.0. If you happen to be on really old firmware for some reason, the feature was added last summer with hub firmware 2.1.3.

2 Likes
15

Thanks for the ideas, @dondo.

This all reminds me of the genesis of CoRE:
Phase 1: Adrian - "I've got a cool idea to replace RM"
Phase 2: Community - "You're in way over your head, boy"
Phase 3: Adrian - "Gonna do it anyway, even if just for myself"
Phase 4: Community - "Adrian, you are a god !"

3 Likes
16

If people think webcore is so great, they can do that today in Hubitat...

So that seems like an odd comparison, as if that is what "good looks like" to you, it is already an option to use. Right now. :man_shrugging:

No need to make rule machine into webcore.... Just use webcore.

5 Likes
17

Sorry for the long delay; busy week. I've been playing around with pause/wait/delay. I've discovered that the eventing model is not at all what I expected.

Inspired by the thread @bertabcd1234 referred to above, I tried to come up with a concurrent approach for hysteresis (that is, "run once and then hold off for a while.") In this case, the intent is to run once in a particular time period. I'm using a pretty short period (couple minutes or less) for testing.

Here's the baseline rule, using time variables. This works, but it's ugly. It's also going to be vulnerable to the midnight boundary (across which a time a few minutes in the future becomes 24 hours in the past) and run twice, which isn't ideal. [ed: this is why most programming languages provide timestamps, which aren't vulnerable to those oddities.]

image
image714×348 32.6 KB

I've tested it and sure enough, it basically works. But it's icky, so I decided to try to use the RM pause/wait/delay primitives directly.

This experiment was pretty informative, showing that things don't work at all as I expected.

image

Here I'm setting a boolean with a delay. My expectation was that everything would stop until that delay completed (since the rule is sitting on its hands, waiting for the timer to fire). But that's not what happened at all. The logs show a very interesting interaction (remember, read from bottom to top):

07:46:55.447 pm info Delay Over:     Set ready to true --> delayed: 0:00:45
    [ten seconds later!]
07:46:45.859 pm info Action: END-IF
07:46:45.856 pm info Action:     [stuff skipped here]
07:46:45.841 pm info Action: IF (Variable ready(false) = true(F) [FALSE]) THEN (skipping)
07:46:45.734 pm info ActOnce Triggered
07:46:45.522 pm info Office Motion Sensor is active

07:46:34.506 pm info Office Motion Sensor is inactive
07:46:11.063 pm info Deskside lights is on [digital]
07:46:10.274 pm info Action: END-IF
07:46:10.224 pm info Action:     Set ready to true --> delayed: 0:00:45
07:46:10.184 pm info Action:     On: Deskside lights
07:46:10.153 pm info Action:     Set ready to false
07:46:10.147 pm info Action: IF (Variable ready(true) = true(T) [TRUE]) THEN
07:46:09.950 pm info ActOnce Triggered
07:46:09.702 pm info Office Motion Sensor is active

So that's pretty fascinating. Each event gets its own distinct instance of the rule. So all of the wait/delay/pause primitives will operate on a unique chunk of running code - there's no underlying thread with which we can interact! So this does works, but not at all in the way I expected. I thought I could just wait; instead, I have to set the guard, and then remove it after the delay.

Still, a useful approach, so I thought I'd share.

18

Last time I checked that wasn't officially supported...and obviously a pretty big resource hog (yep, there is a tradeoff). Plus separate servers and stuff.

Honestly though...if you really want to start writing rules that are getting complicated...just start writing groovy...in some ways...it's actually easier/faster than RM4.0. It's also editable so there aren't all these clicks and drops downs and stuff.

leave RM4.0 for the rules that fit it. Plus once you start writing your own apps, it's copy paste quick to take code from a previous project. It's not that hard. In fact...A thread or spot with some good basic apps to get people started would't be a half bad idea. The staff at HE show examples all the time...like this one:

I used to start an MQTT driver for my garage door...sometimes it just takes a little help to get started.

1 Like
19

I've only followed some of what is being explained. It's 8am I've been up since 5 and only had one coffee. However it seems to make sense and I think it may bridge the gap for users going from the built simple automation and motion apps to rule Machine, which I feel isn't quite there for the average user.

There is merit on opening a dialogue with the powers that be. Maybe someone with more clout can tag them in, or point them into this post.

20

webCoRE makes more sense overall.
Got used to it from the first day and always managed to get any automation I needed to.
I tried to start using Rule Machine (being native to Hubitat, after I migrated from ST), but I couldn't make sense to it.
Although you can say webCoRE is closer to a developer mind and non-technical people might find it difficult to use, you cannot say that Rule Machine is for non-geeks. It just doesn't make any sense for beginners or average tech skilled users.
And honestly, if it takes you more than half an hour to understand such feature, it just proves that it is poorly designed.

2 Likes
21

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
22

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
23

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
24

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

4 Likes
25

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
26

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
27

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
28

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.

29

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.

30

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
31

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