Rule machine - as per the app developer, this app is no longer available for new installs, distribution, or support

(Paul) #4709

The difference is when the “thing” (rule or trigger) gets evaluated.

A trigger only gets evaluated when the trigger event happens:
(Door Contact Opens) (while Light Switch is On) (then do something…)

A rule gets evaluated every time the state changes from true to false or false to true so:
(Door Contact Opens AND Light Switch is On) (then do something…)

The trigger would only get evaluated when the door contact opens. Ever.

The Rule would get evaluated when the Door Contact Opens while the Light Switch is On and also when the Light Switch turns on while the Door Contact is Open.

( I hate Mondays) #4710

@jnschemm I am looking for constructive comments. My point is, there is no need for both rules and triggers. You can do with a rule that says “if door opens do this”. Simpler, user-friendlier approach.

(Mike Maxwell) #4711

incorrect, though I guess in your setup you have no need for them, I however do, 30% of my rules are conditional triggers

( I hate Mondays) #4712

I said triggers. Not conditional triggers. Triggers were first. Then rules “improved” them. As a new user of RM, I found the existence of both as confusing at best. I do programming for a living. In many languages and ecosystems.

(Mike Maxwell) #4713

well cool, we’ll all actively interested in your clean slate implementation!

( I hate Mondays) #4714

Can you please give me an example of a conditional trigger so I can understand what you mean?

Again, my point is, there is no need to decide what to use before you set it up. This implies high-level understanding of the complexity of a software, leading to that software being hard to grasp for most users. I am trying to imply that with a little bit of planning, we can figure out something that can incorporate the functionality of all three entities (triggers, rules, conditional triggers) into one single entity that will no longer confuse the user as to which one to start with…

[RELEASE CANDIDATE] CoRE (Community's own Rule Engine)
CoRE and Piston Rules Engine, first design steps
(Andreas A.) #4715

Consider the following:

Do something every time that a temperature sensor reads > 0

With a rule (T > 0), this would only happen when the temperature goes from less than or equal to zero to greater than zero (i.e., once). With a trigger, it would happen every time the sensor gets a reading greater than zero.


Historically, if I recall correctly, rule machine came first, then there was a separate app for triggers, then things got combined. Just sayin’.

As for designing your own rules engine smartapp, sounds great, please use the following new thread for that to keep people from getting confused.


( I hate Mondays) #4717

I have modified my copy of RM to incorporate other features, among which:

  • the ability to rate limit a trigger, so that it won’t execute if it just did in the last x minutes - had to do with presence
  • the ability to send the device name in the push notification text (dynamic messages) - again, presence. I want a notification that John got home, not someone got home.

There are many ways RM can be improved, but it takes a lot of us to figure out the core concept before we can start implementing it. Analysis, that is. And I am asking for help and coordinated efforts so we can get something working, in case RM never comes back. By all means, RM is a genius piece of code, not talking trash about it.

( I hate Mondays) #4718

How do you do hysteresis? Can you make something happen if and only when the temperature exceeds a certain temperature? i.e. goes over 100F, do something, then do it again only when it went over 100F again, after it has gone below 100F… this is an example of something that can be “factored in” into the analysis of an “entity” that can do it all.

(nicholas) #4719

What would it take to do such a thing?

( I hate Mondays) #4720

@JDRoberts I wasn’t aware of that thread, I’ll move there. I am only trying to help, so far I only find opposition… :slight_smile:

(Andreas A.) #4721

That would be a simple rule: T > 100. Rules gets evaluated only once on truth change

(Jason "The Enabler" as deemed so by @Smart) #4722

I think he wanted that in English!

( I hate Mondays) #4723

Wrong. An event is generated usually when temperature changes. Let’s assume temperature goes up 1 degree every 5 minutes, so you’ll have 5 events like this:

98 99 100 101 102

I only want the action to occur when T reaches 100, it should not run again when T is 101 or 102.

However, if T varies like this:

98 99 100 101 100 99 98 97 98 99 100 101 102

then the action should run twice.

Can you do that with RM?

(Jason "The Enabler" as deemed so by @Smart) #4724


I want my alarm to doing at 8am every single day, and only at 8am.

A trigger makes this happen.

A rule would have the alarm sound between 7:59 and 8:01.

Trigger means once.
Rule means over a period of time.

( I hate Mondays) #4725

But internally, the rule runs based on events as well - it doesn’t just run continuously or every 1 minute, unless you ask it to - which is time triggered then.

(Jason "The Enabler" as deemed so by @Smart) #4726

Actually, we could do away with rules and triggers.

Conditional triggers can do everything.

( I hate Mondays) #4727

If you are right, then my logic is not “flawed” and I was right, there is no point in having to get the user to decide which path to take. Instead, the app should “guide” him through towards the goal. Easy and simplistic, but versatile - I know these are two opposing things, balance must be found :slight_smile:


That’s only sort of true. If you omit Conditions and save it, when you go back it will be a Trigger. If you omit Trigger Events, and save it, when you go back it will be a Rule. Once it’s a Trigger or a Rule, that’s it. But that’s just the UI interpreting your selections.

Trigger and Rule are completely different anyway.