Awesome, I'll update now. Just for the record, when I fully rolled back to 220.127.116.11 yesterday using the :8081 interface, that did resolve my issue. Whats interesting is my rules were still triggering, but I couldn't make any changes to them. My guess is it was only impacting the UI and not the underlying scheduling/logic system.
Any chance of adding "with fade time" to the various "set color/temp and level / per mode" actions?
I must be a malfunction-magnet, haha. Update installed, but my hub powered off completely afterwards. Luckily I was home, otherwise that would have been a bit of a nightmare.
What's wrong with this rule? Been trying to fix it for a while now. The 5 second delay is so that the 4 minute turn off occurs and doesnt send redundant messages.
You are getting multiple simultaneous executions. That's not going to work. They are colliding with each other.
Mike, you might be able to use a private boolean to prevent multiple instances of this rule running. First line could stop the rule if PV false. I assume this would not impact the original rule that might still be running.
Does anyone know how much of the beginning of this rule is redundant? I'm trying to prevent the motion from triggering after someone turns the switch on manually -- at least for a few minutes.
Does private boolean preclude a rule from running in Rule 4, like it did in Rule 3? Or is it simply a like a virtual switch, that I can use in Rule machine to "exit rule" for example. I cant find any documentation as to what it does in the support docs.
Works like a local variable. In rm4 it doesn't do anything to action execution unless you explicitly use it that way.
Restrictions are gone. So only whatever logic you use for it will apply. It's like a simple Boolean variable, that starts out true. You can test it, set it, have other rules set it, and trigger off it. It's all up to you what you do with it. It can often be used instead of a virtual switch to remember some state.
So, I know I said I couldn't think of how you'd use an XOR....well, I did. Took me a while but it finally clicked. Thanks again for taking the time to explain it to me.
Every time I think I've wrapped my head around 4.0, I get surprised by something. I threw together a quick rule to wake me up at 6:43 AM on August 27th, and it got the job done. But it also turned on the light at 6:43 AM on August 28th. Why? I know as soon as someone points out my error, I will say "Doh!".
Your trigger runs at 6:43 everyday.
In your actions you have your dimmers that you set.
Although you have a condition defined you have not actually used it.
Leave your trigger.
In actions use an IF-THEN.
Date is Aug 27th. (The condition you have already defined)
Turn on dimmers.
Thank you. My head was erroneously thinking RM 3 Restriction and RM 4 Condition were the same, but they are not.
While I've done 30+ rules in RM 4 that are all working as intended, I haven't reached full understanding of the somewhat murky terminology. For example if you want to edit an If/Then construct, the UI to go through says you are editing an action.
I know it is easier said than done, but if would be nice if a future RM separated the notion of creating actions (things to do) and logic constructs (initially empty; into which actions are inserted).
How would you structure this rule to avoid mutliple instances. I tried private booleans, and it didnt work.
@bravenel, could you have a look at this please?
I'm sorry to add to this thread, I'm still trying to get the hang of RM4. What I want to accomplish, when my presence arrives, wait for porch motion to be active, then unlock Door. Cancel unlock if no motion is detected within 3 minutes. I've tried wait for event with timeout but as I understand it, timeout cancels the wait, but not the subsequent actions. Any help would be appreciated!
Something like this, maybe:
Trigger: Presence arrives Actions: Wait for events: porch motion --> timeout: 0:03:00 IF porch motion active then unlock door.
Hey, don't be sorry!
Let's work through this:
How about this:
Trigger Event: Presence arrives Actions: Set PB true Set PB false delayed 3:00 Wait for motion active, timeout 3:01 IF (PB true) Unlock door
You arrive, make sure PB is true (from previous time), then start 3 minute timer to set it false. Wait for motion, but only for 3 minutes. When there is motion (or time runs out), if PB is still true it must be within 3 minutes, so unlock the door. It it was longer than 3 minutes, PB is false. Bam!
Thank you both, both make sense to me now! Special thanks to you Bruce, I appreciate the level of community engagement, I have never seen such commitment from any other HA platform. Thanks!
This is why I keep coming back to this thread just to read. I love seeing problems and solutions, and this is the most clear-cut PB example I've seen yet.