[Released] Rule 4.0


#801

And another question / issue... How do you make a condition that compares two local variables??? It doesn't seem to work.

Condition:

Variable values:
57%20AM

Notice the condition is "TRUE". It should be "FALSE".

@bravenel I guess I'm stuck at this point. I can't use Mode changed as a condition, and I can't manually compare CurrentMode and LastMode variables to detect mode change.


#802

@bravenel Hey Bruce, I just about have my Hello and Goodbye routines doing what I want. One exception - I believe. So if someone arrives, I want a 20 second delay then the garage door opens. Then three minutes after arrival I want the door to close. Seems to work. However, if someone arrives and the rule triggers THEN someone ELSE arrives during the 3 minute delay I don't want the garage door to close based on the first arrival, but shift to the second arrival. I believe I need to set the 3 minute delay with a (cancel) but then also believe I need a Cancel Delayed Actions - somewhere in there as well. Can you confirm?


#803

The * * changed* * for any device/mode is not really a condition. It just says that you want to trigger the rule independent of what the value is. You than have to make your conditions explicit, as in checking for the actual value that you want to test for, like Day, Night, etc. * * changed * * will always be true. Otherwise the rule wouldn’t have fired in the first place

Like this:


#804

Just add a Cancel Delayed Actions as the first action of the rule and enable that cancel on the delayed actions. That should accomplish what you want


#805

Funnily enough, I started testing local var comparisons as well as local to global. In both cases they fail... (in my simple tests)

Shown below is local var comparisons:
image

image


#806

That makes sense. I was just trying to do too much in one rule I think, as I needed to know which trigger kicked off the rule execution - or I would need a lot more logic.

Not big deal, split into 2 rules, works fine now.


#807

@bravenel,

This rule is doing my head in. I can't figure out how to do it. Initially, I thought the cancel delay 2 seconds was not being honored, but now I can see that it is, and the issue is something else. I have a rule that sends me a message when the garage door opens. Problem is that when the garage door opens, the sensor moves in and out of range of the magnet, and sends a few notifications. In rule 3, I had a rule that worked well, delaying the notification for 2 seconds, and I only received 1 message. But in Rule 4, I'm getting 3 or 4 notifications every time the garage door opens or shuts, all saying "Garage Door Open", despite the delay. I have another rule, whereby when the Global variable is set to true/false, I get sent a pushover message. That rule is being run 3-4 times, because THIS rule is setting the Globbal variable 3-4 times within 0.4 of a second.

This is the rule (the delay is so I dont get multiple messages, worked in Rule 3, not Rule 4, and also due to the wind).

Here is the contact sensor opening and closing. Just focus on the 1:16pm OPEN (where the garage door opened ONCE, but I received 4 notifications from the sensor). As you can see, HE received 4 messages in 0.4 of a second.

Here are the logs for the rule itself. (two images, start from bottom)


Now obviously, the rule is doing exactly as it should. Every time the Contact sensor "opens" (sic), the delay is triggered and then after 2 seconds, it sets the global variable, and it all happens so fast that there is no cancelling of the delay within the 2 seconds. Can you think of a way to do it in Rule 4?

(Other things: battery was recently replaced, at 100%; mesh is good, I have an XBee).

Edit: I attempted to make the set garagedoor to false (delayed 2 seconds), cancel) a conditional statement IF garagedoorshut is true, THEN set garagedoorshut to false.

But it evaluates the rule at beginning of delay, not when the delay is over.


#808

If you think this through, unless you are doing something in a rule to cause a mode location event, then pretty much mode changed will always be true. This is because each mode change is just that, a change.

More generally, changed doesn't really make sense in a condition. One could make a convincing argument it should not be a comparison choice for a condition. It makes sense in a trigger, where something happening to the selection is causing the trigger to fire.


#809

There is a bug wrt comparing two string variables, which will be fixed in the next release. However, there is a work-around available in the interim: If you have, or create, two number variables, make the condition first to compare them. This will offer the choice of comparing to another variable. Once you have set that up, edit it to change from the number variables to the string variables you want to compare, and ignore the field for entering a string value.


#810

Thanks Bruce. The workaround is fine for me for now.

Originally, I had a rule w/2 triggers - mode changed and motion changed on a device.

So sometimes the rule could be triggered by a mode change, but usually it would not be. I thought then I would use mode changed as a condition to tell when it was triggered by mode changed, versus motion changed.

But obviously that didn't work, because even when the rule was triggered by motion changed (and the mode hadn't changed in hours), mode changed as a condition was always true (which still seems odd to me).

Anyway, breaking it into 2 rules (one for mode changed one for motion changed) works fine.


#811

@bravenel

Did you see my rule issue [Released] Rule 4.0


#813

Thanks Thing is, it worked in rule 3. Is there no way to evaluate the condition after the delay, not before? I guess not.


#814

Sure there is, just delay before it.


#815

Then why move it to 4.0? If it isn't broken, don't fix it.


#816

@bravenel just got this

I believe i got it when i turned off logging from the rules and clicked done, any ideas what it means?

edit it happens on click done with this rule


#817

I'm getting that error fairly often as well.


#818

i have an exact same rule that the only difference is the light (Not a group light, like this one) and a different contact but no error on.


#819

another odd UI thing

spot the random FALSE?


#820

Yes, there is no way to delete it. You will have to recreate the rule if you want to get rid of it.


#821

Does the rule work?