I have set up a rule but wonder if this is a good/preferred (or stupid) way of doing this and seek advice. (It ain't working, so clearly it's leaning towards stupid I suspect...
I have a couple doors that are used at night for a dog poop run. One most of the time and another under a porch roof used when it's raining (TMI maybe, but maybe not) For testing I'm just using one door.
Each door has a outside light, and each has a switch associated. I don't want to mirror the switches for other reasons, but ideally I'd like to create the rule so if either door opens, conditioned on between sunset and sunrise, turn on the dimmers.... So far, so what... But I also want to have the lights turn off when we are done "smelling the flowers", so I'm thinking when either door is re-opened, So the second opening, hence the topic title.
I've created this rule:
The obvious problem is the second opening is also the next first opening.... so coming back in causes the rule to turn the lights on again rather than off. (don't even see the off in the logs)
I cant just do a delayed action, cause it's a dog... who knows how long its gonna take. Ideas greatly appreciated!
I think it could be done but with 2 rules 1st rule would turn it on flip the private Boolean of this rule and the other. Then the other would exit if the PB was false and if true turn off light and flip the other rules PB.
So essentially only one could run at a time and each time it runs, it disables it's rule for the next run and enables the other. Then visa versa, this way door open would turn on light then door open would turn off light. Hopefully you get it from that but If you need a example your have to wait until tomorrow as in bed .
What will happen is a classic race condition, with uncertain results. Both event subscriptions, the trigger and the wait, will cause activation of the rule. The trigger will cancel the wait, but it's most likely too late for that (indeterminate). Then the trigger will activate the scene. Meanwhile, the wait event will have turned off the outside lights. It's not possible to predict the relative order of these things happening. If activating the Scene and turning off the lights are unrelated, it would probably work. If they overlap, one turning on and the other off, probably not. You could put a delay on the Off if you want it to prevail, and it probably would work. Is this recommended? Heck no.
I actually have a similar rule, with a similar race condition -- quite knowingly. In my personal experience, both instances do run. The trigger doesn't do anything of consequence, and then hits the same wait. The action after the wait is unrelated to the trigger, and from observation, happens with close to 100% reliability (thus proving that both run, and that the trigger doesn't succeed in cancelling the wait before it has started to run). Do I recommend doing this? Heck no.
Not exactly your setup but I think you could use the same idea for what you are wanting using a Global Variable. You first check to see if the variable is True and then you can act on it if it is. If it is Not true, this is your first run through your logic. Your starting If statement will be to turn off the lights if it is true. This is skipped when opening the door the first time but sets it to true. Then when you open the door the second time, the variable is true so you turn off the lights and set the variable back to false.
In my example, the Variable name is "Front Door Motion". Hopefully you can follow my logic. In my case, I only want to hear that someone is at the front door once within a 5 minute period. You would just use the Variable logic out of my example.
I like the process(s) of both @chipworkz and @BorrisTheCat. Done similar in Vera many times before I switched to HE a few years ago. I also like having fewer rules... around here they seem to be made with rabbit DNA, for every one I want to make I end up making like 3... mostly because I didn't realize HE supported any sort of simple local variables! (manual... what manual??)
Thanks all, I'll post back what I end up with in case it helps others still wearing their water wings like me!
PS I really wish there was a way to hide the current device state from various programming screens... I see where it could be helpful at times, but most of the time my pea-brain flames out when it has to decipher sh*t like Motion(false)=true(F)[FALSE])
@bikesquid as alway @bravenel was right it wasn't easy as i thought and it did create a race condition that the 2nd rule fired straight away which i wasn't expecting. But i do i have it (was determined too), see below rules.
This last example @BorrisTheCat is what I thought you were getting to in your first post! See, sometimes a failure to communicate is a good thing?!
I'm hoping to put it in the box tomorrow and give it a whirl. Still haven't gone too deep in RM4, but its starting to feel like some real capability I've been Jonesing for have been hiding from me... time to set the IF/THEN hounds loose!
.
