Understanding rule machine and trigger events


I'm new here and received my HE a week ago. I'm trying to understand the rule machine and trigger events.

I have created a global variable (boolean) and used it for my motion sensors. It seems to work. It becomes true when there is motion and false after a delay.

To keep it simple i would like to use this to turn on and of a light. But I can't figure it out. I have made the following rule:
It does not work correct. I know it's the trigger events that's not working.
When 'Outdoor motion' changes to 'true' shouldn't it run the rule and turn on the lights? It doesn't do that, so I added the motion sensors. Now it turns on when the sensors go from active til inactive.

Is it possible to disable trigger events, so it runs the rule all the time?


Why use a variable and not just set the lights in the first rule? If your planning to use the variable for something else in the future you could still control the lights in that first rule and set the variable as you have it. However my guess on the issue with second rule is you should remove the OR Front or Back door any changed bit since that would take place at exactly the same time as the first rule and so the variable may not have been changed yet. Also you could enable logging for the second rule to see why it says it did or didn't do what your expecting.

I'm planning to use it in the future, so i thought it was a good exercise.
When i remove the OR front or back door nothing happens.
I will enable logging.

First, is there a reason you're creating the variable at all? In your second rule, you're using the sensors directly. The variable would be unnecessary in this case (if you ended up using them in the rule actions instead). Second, you might want to check out the built-in Zone Motion Controller app, which can (among other things) create an effectively virtual motion sensor that can change state based on multiple sensors you select. That being said, the first rule looks fine (except that I'd use "Cancel Delayed Actions" instead of "Cancel Rule Timers," which technically does a bit more but nothing that matters here).

Your second rule also looks mostly ok, but, again, the variable is testing for the same thing your sensors are, and you're not testing the sensors at all in the rule, so I don't see why you'd want them as triggers.

You can turn on logging for triggers (and actions if you want) to see what the rule thinks it's doing. To answer your questions, you can have no triggers, but then nothing will ever run unless you call the actions from another rule. That is probably not what you want here. And an app or rule can't run "all the time"--some event has to happen to call it and wale it up, whether that's an event from a sensor (or variable changing), a previously scheduled job (that's how delays and delayed actions work), or whatever subscriptions the rule creates for you based on how you configured it (your triggers). If you ever think about writing a rule that just constantly checks for some condition instead of subscribing to an event (in rules these are usually triggers) that would cause that condition to change, you're probably doing it wrong. :slight_smile:

Most of what you want could probably also be done with Motion Lighting if you haven't checked it out already, but this should work too.


Thank you for your thorough reply.

There was no reason for creating a variable. It was just for testing and learning the rule machine.
I could not get the rule to trigger, so I added the sensors in the second rule to see what would happen.

I used the log and could see that my variable never triggered the rule. I have added a connector to the variable and that did not work. So when i deleted the connector it works as I first thought.

I will go further and learn more about my HE :slight_smile:

Honestly, I'm not sure how long global variables as triggers have been around. I've never used one. It's possible there's a bug...

I'd probably use a virtual switch rather than a global variable.

My understanding of global variables is that they're part of the RM parent app, rather than a child rule. So every time a rule calls one, it has to open the parent app. That makes the rule just that much less efficient.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.