So...
Can anybody can tell me what is wrong with this logic?
Device Events:
A re-trigger cancels any wait, and I might assume that the power level of your device reports > 2000 at multiple times in a single run, not just once at the beginning. (On a related note, that value is higher than I'd expect if the units are watts and you're measuring a typical North American household outlet, but it looks like your device is, in fact reporting that.) From the event history you posted, that didn't happen in this case. However, what could have happened is that it did previously, and your "stillRunning" variable got stuck false, since the rule retriggered and the "Set to false" action never was reached. As you can see from the orange text in the screenshot, the variable was false at the time you took this screenshot, so nothing inside the IF would have run.
You may need to re-think your actions, unless this > 2000 event really does happen only once during a run. Logically, I'm not really sure you need that variable here at all: your actions will only run when a trigger event happens, and in your actions you're just waiting for it to stay 0 for a bit. That alone might be all you really want to do with this rule--the wait will get cancelled with a retrigger but then more or less immediately re-instated. I have a rule for my washing machine that does more or less exactly that:
It should also be noted that the "timeout" on your "Wait for condition" means that the wait will be over when either the condition is met or the time expires, not when the condition stays that way for that amount of time. This seems unlikely to be what you really want, but the way I wrote my rule above will make sure it stays that way for 1 minute (in my case). In Rule 5.0, you could also use "Wait for conditions" with the new "Use duration?" option--not a timeout.
Some of this is my best guess since you didn't really state what you wanted your logic to do. 
But hopefully it's of some help.
Hi,
You are correct, the isStillRunning is for the case when there are several hits for the condition, regarding the wait for condition, my intent was to wait 5 minutes for the power to be 0, is this incorrect? What should I use then? From the waiter menu?
If you're using Rule 4.x, you can do something like I did in my example. In Rule 5.0, you can also:
Either has the effect of waiting 5 minutes (or 1 in my example) either at the specified condition (in the Rule 5.x suggestion) or not at or above the triggering value (in my Rule 4.1 example).
Thank you 
, I do use the 5 version, though to give it a try. I'll make the modification and post the results. Need to have dirty dishes first though 
So,.. this didn't work either: I have set the local var to false before use.
It's been 20 minutes. Time now is 16:44
This is probably failing for the other reasons I mentioned: here, a >2000 event is indeed happening multiple times. So, the rule triggers once, then the variable gets set false, the wait starts...and soon the rule re-triggers (which cancels the waits), and now basically all your meaningful actions are skipped because the variable is set to true. Now, nothing will ever happen to set it back to false, nor will the wait get rescheduled (since the surrounding conditional evaluates to false now).
If your goal is just to wait until the power remains at 0 for 5 minutes after it's been >2000 at least once, you don't really need this variable at all. Take a look at the washing machine rule I posted above (though, again, with Rule 5.0 you could combine my two "Wait for event" actions into a single "Wait for condition" with a duration, which is a bit cleaner).
1 Like
Why would it cancel the wait? Isn't the whole idea of this wait, to wait the duration for the predicate to be true? This is how I understood it.
Your rule doesn't have any predicate conditions, at least not in the Rule 5.0 sense of that word (which is now the name of a specific feature).
Re-triggers cancel waits just due to how Rule Machine works. It doesn't have to be that way, but it is. In most cases, though, I'd say this is desirable--triggers make your actions run again, and it's unlikely you want to schedule another (additional) wait or really wait for the other one to finish, even if something else happened. (Again, keep in mind that any trigger event matching--at least while the predicate is true or you have no predicate, both in the Rule 5.0 sense--will make your actions run again from the beginning, even if they all haven't "finished" yet. This is also part of how Rule Machine works. Predicate conditions make this easier to avoid than in the past, but careful rule design has always been helpful.)
Delays are not cancelled on retrigger. Sometimes you can use this to your advantage (though in most cases, I'd say most people also want delays cancelled on retrigger, and a common mistake is to forget to do this). In your case, I'm not sure you need to; again, look at my washing machine rule for an example of how simple "Waits" make this (but again you can combine this into a single "Wait for condition" in Rule 5.0). Unless you're using this variable to display on a Dashboard or something, I don't think you really need it at all, and even then, I'm not sure you need it as a condition in your IF.
If you need the other behavior for some reason, the only thing I can think of is to use a "changed" trigger, an IF THEN/ELSE in the rule body (with one testing for high power usage and the other for low), and a delay instead of a wait for time. This seems a bit messier to me, and again, I'm not sure you'd really need to. If something like my washing machine rule (with different power values, different times, and optionally combining my two waits from Rule 4.x into a single Wait for Condition with a duration in Rule 5.0) doesn't work, a clear statement as to why would be helpful in suggesting alternative rules that may work for you.
Good luck!
1 Like
1 Like
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
