Is my weather station, by reporting changes in both illuminance and temperature at the same time, causing this rule to run twice? If so, how do I stop it? I have the rule set to ignore trigger events while running.
C8 v 2.3.9.163
Scroll down just a tiny bit in the rule editing UI (assuming you are running a recent platform version)
Yes.
Now that I'm looking at your rule, you might want to tackle what seems to be the root cause of your issue: triggering on changed and then having conditional blocks in the actions. Look into embedding the condition (attribute value > 35 etc) within the trigger itself. You can probably even use a conditional trigger to replace that first IF. You might need to / benefit from splitting this rule into two rules, which looks like it should be easy in your case, since you are already running actions of another rule for the bulk of the work.
Perhaps I've misunderstood, but I thought using specific conditions in triggers was potentially problematic and using "changed" was the preferred method.
Not what experience has taught me.
The âmultiple executionâ error you get in the logs I believe happens in the specific case of a rule retriggering while an instance is already inside of a conditional block. Think of ways to avoid that happening. Triggering on changed practically guarantees the rule will trigger more often.
That being said, the âignore triggers while runningâ switch will probably work for you.
1 Like
There is no reason this should not work; in fact, my suggestion would be to do so when possible. (If you have sources or experience to suggest otherwise, please provide the relevant data.)
While either way should work, triggering on a specific event or range of values often simplifies actions, avoiding the need to check for things you could have just triggered on in the first place. Coupled with a "Wait for events" or "Wait for expression" in your actions, this can address the use case you may otherwise be tempted to use "changed" for.
That being said, I also agree with the above that if you already have a rule that is more or less working as you want, the simple change using the new option above might also take care of the problem. 
Thank you all. I'll give those suggestions a try.
Didnât OP say that he WAS using the ignore trigger events while running option?
Maybe his âBLIND ACTIONSâ routine is being called from somewhere else?
I did and I was. I assume the ignore trigger events while running is not evaluated by RM during the first run of the triggers.
Add a required condition of Private Boolean False
First action set private boolean true, last action, set private boolean false.
1 Like
How is your Weather Station reporting ne values?
I am using Ecowitt and its driver reports an updated values every fixed interval (this interval is set somewhere in the app). In this case the best SINGLE trigger will be when the entire set of data is updated:
Another words, there is no need to check for the individual value changes, anyway all they are will be updated exactly at the same time. But yours case could be different.
I missed that, but yeah...nevermind, then. However, the other approach might help (or one of the other ideas above).
That is a valid point! I had not thought of that. I think it updates every 15 mins.
I tried that, but could not get the rule to reliably reset the private boolean. That is part of the reason I've started cleaning up my apps to be more efficient and run only when needed.
You didn't show enough of the logs above, in particular the left side of the logs where it shows the appId or devId. It doesn't look as though those logs are from the rule posted (different actions). Your rule is blowing up because of an embedded delay in a Conditional action block -- Can't tell from the logs if this is some other rule or not.
A *changed* trigger followed with a Conditional Action to test what happened is the worst thing you can do. You're taking the valuable information in the triggering event and discarding it, just to examine the same devices again to find out what just happened. Then, putting a delay in the IF-THEN block pretty much guarantees a problem. This approach, while it reduces the number of rules, reduces it to the point that it fails.
2 Likes
I'm learning that more simple rules are better than fewer complex ones! That log was filtered for just that rule. That's why I didn't include it in the copy, but I should have made that clear in the post.
This can't be true, because there is no action in that rule of Delay 0:00:05, etc.
Fortunately, I didn't refresh the past logs tab. It's too long to copy in one frame. Here it is in its entirety.
OK, app 585 is not the one you posted above.
