[Released] Rule Machine 3.0

📐 Rule Machine® All things Rule Machine
376

No, this isn't correct.

Everything is driven by events.

In the case of a Rule, any event that touches any of its Conditions causes it to be evaluated. If, upon evaluation, it finds that its truth state has changed, it runs the actions for that new truth state.

In the case of a Triggered Rule, the events selected as Trigger Events cause the rule to be evaluated. It then runs the True or False actions depending on the outcome, irrespective of prior state.

Think of a Rule as a big IF-THEN-ELSE, with the additional caveat that it only does something when truth changes. Think of a Triggered Rule as forcing an IF-THEN-ELSE analysis that does something irrespective of truth change.

The important observation to make is that Rules are about state, while Triggers and Triggered Rules are run by an event. However, state only changes from events, so the two are quite similar, confusingly so.

377

Clear as mud.

Hubitat needs clear and concise documentation, including examples.

2 Likes
378

I didn't use Trigger Rules because it don't have " Cancel on Truth change ". But I need : Motion becomes to, change to ...active\inactive and the rule can reset. Please give more examples.

379

Hi @TranDzung I've got a few minutes and can help you write a rule if you want. It appears there might be a bit of a language barrier, so be patient!
Can you explain a little more what you are trying to do?
If the motion sensor is active, do what?
Better yet - please message me if I can help so we don't fill up this thread.

380

https://docs.hubitat.com/index.php?title=Rule_Machine

and

https://docs.hubitat.com/index.php?title=Rule-3.0

381

Our understanding of "clear and concise, with examples" obviously differs, especially since Hubitat seems to want to create their own unique logical system apart from other long-term, well defined ones.

Really, what you point to says "A Trigger is a simple mechanism through which some event in your system causes a selected action to take place.

Then goes on to say "A Triggered Rule adds a rule to be evaluated for a trigger event. When any of its trigger events fire, it evaluates the conditions under the rule"

"the door opening is an event and results in the condition of the door being open. Both rules and triggers rely on events to cause their actions. Rules examine the conditions, and act on truth change. Triggers act on events."

Like I said, clear as mud. Sorry, but after 40+ years in tech dealing with much more complex systems, that documentation simply isn't fit, even more so for non-tech consumers.. Sure sounds like edge/level logic, but you said it wasn't. What's the difference between "If a door is open, turn on the light" and "When a door is opened, turn on a light" unless there's also built-in, automatic logic to turn the light off when the door is closed?

Clear and concise, no. Rule/Action/Trigger/Event/Condition. Maybe it's some form of self-consistent logic, but it's definitively separate from any commonly used system.

Is there any difference between an Event and a Trigger? Or just that a trigger is caused by an event, in which case why does the difference matter?

"For triggers we select events. Conditions and events are closely related because each event results in a condition"

That sounds like the long and well established edge/level which I already mentioned, but you said was wrong.

It behooves Hubitat to follow long established and well understood logical systems. Expecting users to follow a unique logical system, well, that's simply placing too much of the work on users.

1 Like
382

Ha ha ha, sorry. I think you are in the minority on this one. It makes sense to me. Go play with the system and you will learn. Its really not that hard. My humble suggestion is to stop taking your lack of knowledge so seriously. Enjoy the journey like the rest of us.

2 Likes
383

Something has to make an app look to see if the door is open or not. So what makes "if a door is open" happen? It could be the event of the door opening. But it also could be some other event related to some other Condition.

384

So, some other event/condition can close the door? That simply raises the question (again) of what's the difference between an event and a condition, if it's not edge/state (level). In traditional logic systems, an event is the cause of a condition. I can understand an event (use door actuator to close door) causing a change in condition (door is now closed).

But I've been told that's wrong. If (as mentioned earlier) I have a rule with a condition of "increment light level by 1 while (a condition) the switch is on", and it doesn't continuously increment while the switch is on, how is that different than "increment by 1 when (an event) the switch is turned on?"

1 Like
385

You're doing it wrong. The documentation should be defining - users shouldn't have to "play" to figure it out.

1 Like
386

This is correct. You misinterpreted my comment about what you had wrong above. All states are the result of events. So one does not need to 'monitor' a state, and Rule Machine does not do this. It only looks at events that could change the state. So, yes, in that sense it is edge logic,

In order to continuously do something while some state persists, it would need something to provoke it into action. It doesn't monitor or poll anything, so how is this to occur? One way is to use a 'while loop', which is based on a timer. The timer is then what would provoke it to evaluate the state -- not the state of the timer, but the state of the door (which may be unchanged, and hence not the source of any events).

Everything in Hubitat is event driven.

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?