[Released] Rule Machine 3.0

📐 Rule Machine® All things Rule Machine
387

Until one grasps the sort of inside out logic that happens in an event driven system, the documentation is not going to make much sense. So I agree that using the system to gain this understanding is important. A full semester discourse on event driven systems isn't quite within the purview of "documentation".

The documentation is not perfect by any means. We are scrambling as fast as possible to fill it in, while we move the platform ahead aggressively. There are dozens and dozens of examples of rules in this community. But, the best way to learn is to do. See what works, what doesn't work, ask questions, get help from others, until it becomes obvious how to go about creating automations. I wouldn't suggest this if I thought that grasping automation is easy or obvious, or could be learned from documents.

1 Like
388

I agree, for you it won't be play, it seems it will be hard work. Nevertheless, go work with the system, you will learn.

1 Like
389

That is the exact reason I left Vera, because to "learn" their equivalent to rule machine user created app "PLEG" you had to go through literally 28 pages of documentation just to "figure out" doing a basic automation. This "method" is completely unacceptable in my view. .

@bravenel's Rule Machine may be a bit of a learning curve for the completely non-experienced user, however it is FAR easier to figure out the basics just by simply clicking drop down menus, and trial and error, and you expand from there, and there is plenty of support given here to assist with anything.

There are many people brand new to automations who routinely post here asking how to do the basics, and no one is turned away.

2 Likes
390

I'm sorta bored, so want to chime in. Hopefully I'm helpful and not just confusing. And hopefully I don't say anything that is incorrect!

Here is my explanation of the difference...

A lot of times you can use triggers or rules... just one is more efficient than the other.

You create a trigger of "If the door opens then turn on the light." This will only happen when the event of the door opening occurs.

It will have the same result as a rule that says:

If the door is open then turn on the light (as a truth action). This rule will be evaluated anytime the door state changes - open or closed. The action of true will only happen once upon the door first being open (rule goes to true), unless the rule state changes to false (door closed), then back to true (door open), in which case the action will reoccur.

So the trigger is the better rule due to its simplicity.

But if you wanted the light to go off when the door closes, you would need to create a second trigger for the door closing... or alternatively you could just put in a false action on the existing rule. So in this case, the rule is more efficient as you only need 1 versus 2.

But now you have 5 doors, and anytime one of them opens you want to toggle the light, and you want this to happen whether or not the other doors are closed. With a single trigger you could put all 5 doors as trigger events to toggle the light. Every time a door opens, it would trigger the action to toggle the light. Door open, light toggles. Without closing that door open a second door, light toggles again. Etc. Only need one trigger.

Creating a single rule for this wouldn't be possible because it only will toggle the light on truth change, which would occur on the first door opening. So a door opens, it goes to true, toggles the light. A second door opens without the first door having been closed... the rule is still true so it does nothing... no truth change no action. So you would need 5 separate rules to create the same thing that the single trigger did.

A triggered rule would be: When button 1 is pressed, evaluate whether the light is on, if it is on send me a text message saying "light is on", if it is off send me a text message of "light is off". This way, the light changing on and off doesn't cause a text to be sent, the text is only sent when the button is pressed and after the button is pressed the rule would decide which text message is sent.

They are all quite similar, and sometimes can be interchanged. But not always...

3 Likes
391

“Rule Machine may be a bit of a learning curve for the completely non-experienced user”

I can’t decide if that’s a huge understatement or just completely inaccurate.

@bravenel has gotten the interface to Rule Machine to a point where it is quite useable. I also appreciate where he is coming from with RM and where the HE team is coming from with their focus on local control and hardware minimalization. That’s to say, focusing on events is key to the overall HE strategy.

It’s not helpful to the conversation to say, “work harder”. It’s also not helpful to say “until one grasp” because this infers another person is not already busting their butt to figure things out.

These well-intentioned attempts to help, make a person feel just like you did if you bought one of Steve Job’s iPhones with the bad antenna arrangement and Job’s response was, you’re holding it the wrong way.

Here’s one example of built-in confusion for a single device that can be applied to the confusion that still exist around Rule Machine.

A smart outlet is hardware device that only offers female access to smart electricity.

A smart plug offers for male access to dumb electricity while also providing for female access to smart electricity.

When a “system” continues to refer to both Smart Plugs and Smart Outlets as the exact same thing, you have created unnecessary confusion for users. “You’re holding it the wrong way” repeatedly as a response to this type of confusion will eventually result in a very small user base who know the super-secret way to hold it right.

Now on these issues @mikes is properly pointing out.

Are there just 2 types of Rules, Triggered Rules and Conditional Rules? If this is accurate there’s a starting point to cleaning up the confusion. If this is not accurate then add to this.

1 Like
392

The problem with your analogy is that everyone with the phones experienced the issues, not one person.

There is no such thing as smart electricity......the "Smart" part of the outlet/plug regardless of male/female is the ability to remotely activate on/off etc. without "a human" physically performing an action to make it function.

Their "functionality" IS the exact same thing.

This can be explained here. Rule Machine® Introduction

393

The continuing confusion about Rule Machine makes me think that it needs to be revamped into a form that is less confusing. The differences between Rules and Triggered Rules, concepts such as truth change, cancel on truth change, etc, are not obvious to most users.

The efforts made recently to flatten and simplify the UI, while adding scripted actions with conditional actions lays the foundation for making a substantive change to RM's structure and organization. I'm hopeful that most of the confusion can go away through restructuring the app. Time will tell. Stay tuned...

4 Likes
394

No, many people did not experience it the same way. Some "knew how to hold it the right way"

395

Back to my simple question first, Are there 2 types of rules, conditional and triggered?

396

No, one is fixed in a wall with screws and cannot be moved around, easily. The other is designed around ease of use and the ability to move it from one location to another.

397

There are 5 types: Rule, Trigger, Triggered Rule, Actions, Schedule.

398

You are referring to the aesthetic "appearance" and mobility of the device, it's irrelevant to the "functionality"

A cell phone and a landline BOTH have the exact same function regarding phone calls.

399

It wasn't one of those where you put the speaker at the top and the microphone at the bottom was it? :wink:
Sorry..........

1 Like
400

But they are referred to as cell phones and landlines in conversation. Also is true in any documentation because while they both allow you to talk to other people, a cell phone is more complex than the old school landline was on the consumer end of things.

Thanks for helping to make the point about why it is better to make a distinction between outlets and smart plugs.

401

As are "outlets" and "plugs" One is a "fixed" device and one is able to be easily relocated.

Not when referring to phone calls. They operate identically when making phone calls......Just as outlets and plugs do is relation to being operated by an "smart" platform.

Your welcome, there is no difference in the functionality between an outlet and a plug.

402

On a slightly different note...
I have discovered that the 'Delay this action' button doesn't do what I expected.
The documentation states that Actions execute subsequently but not when using this button. If my actions are:

Action a
Action b --> after a delay of 0:00:30
Action c --> after a delay of 0:00:30
Action d --> after a delay of 0:00:05

I would expect:

Action 'a' at rule start
Action 'b' at start + 30
Action 'c' at start + 60
Action 'd' at start + 65

but what I get is:

Action 'a' at rule start
Action 'd' at start + 05
Action 'b' and c' both at start + 30

If this the desired functionality, can you change the button from 'Delay this action?' to 'Delay this action from rule start?' or something?
I realize that I can use the inline delay instead and this does work great and I am busy making this change in all my 50 rules but users shouldn't have to learn this the hard way.
And lest I be misunderstood, thanks again for all the great work you have invested in Rules Machine. Especially release 3.

Trying to please a huge group of users can be a thankless and never ending task. I should know. :wink:

1 Like
403

But if I ask for your phone number, I don't care whether it's a cell or a landline. The use case of "call mpoole32" doesn't make a distinction. Similarly, the use case of "turn off the family room light" doesn't have a distinction between an outlet or plug. (or even a smartswitch or smartbulb. They all have capability of "Switch". They can be off or on.)

404

Virtually all smart home systems (including Hubitat) have converged on a similar set of ideas about what a "device" is to an end user. Generally, it can be looked at in 3 aspects:

  1. What "Capabilities" the device has
  2. What UI representation it is given
  3. How you name it

For example, I have a smartplug by my bedside, with a lamp plugged in. It has capability of "Switch". In various UIs, such as Hubitat dashboards or HomeKit, I can "represent" it as a switch or a lightbulb. I have given it the name "Nightstand Lamp". I have never found it useful to refer to it as the "Smart Plug in my bedroom" or to represent it as a small cylindrical device. UI Representation and Name can be different than capability, which is different than the physical form of this device that is hidden behind my nightstand.

Like any abstraction, these abstractions of capability, representation, and name aren't perfect. For example, a GE Fan Controller switch uses z-wave messages ("capability") as if it was a dimmer, with a percentage of full power. However, inside the physical switch, it uses its dimmer percentage to decide among 4 fixed speeds. That causes some "representations" to be confused on some systems. For example, Alexa refuses to understand "Alexa, set the fan to Medium". Alexa wants you to set it to 50%.

Additionally, some smarthome systems haven't allowed enough control over these 3 aspects. In SmartThings, "capability" and "representation" are tightly tied together. If you want a different representation for a device, you have to use a custom driver. Some systems don't even allow that.

Overall, I really like the balance Hubitat has. My device driver (combined with the physical device) determine the capabilities. Depending on the capabilities, I can then choose the UI representation I want (Tile type in dashboards. Or icon in HomeKit.). And I can name independently.

1 Like
405

Now that you've learned how it works, what good would changing the words do?

2 Likes
406

I assume you are saying this in jest??? :slight_smile:
But just in case, I'm suggesting this for all the users who AREN'T me as well as the future acceptance of Hubitat and Rules Machine as a platform.
Also, this might have been a bug.

2 Likes