Your description suggests that the garage door status is oscillating, as it might if there’s a mercury tilt switch or similar device used for door position–these have a tendancy to “bounce” with the movement of the door (mercury moving around) and then stabilize once the door is still.
A look at a logic summary generated after opening the door would confirm this. But, if you think my assertion is plausible, try adding a “sustained for” of a few seconds on the door state test–that would tend to “debounce” that sensor a bit.
Ah great point, I’d forgotten that I had an 8 seconds sustained condition on my standard open/close notification logic - that should do the trick for this too.
The second has a different title. It looks like that may be the default Vera notification when an armed sensor is tripped. It is not the Reactor Sensor
Does it make sense to use a timer in this situation if I want the interval to start only once the door has been open for 15 min and then every 15 minutes after that? I know I can use the Sustained For condition to keep the group False until the first 15 minutes are up but then I want it to continue to notify every subsequent 15 min. The way I read the solution in this thread is that the “Notification Interval” group would reset on its own predetermined schedule so the first notification could come at say 23 minutes (Group 1 is true after door open for 15 + Group 2 happens to become true 8 minutes later).
Since the original post here, an additional feature was added to the “Interval” condition type to allow its timing basis to be the true edge of another condition. So all that would be needed in this prior example, for example (), is to set the “relative to condition is TRUE” and choose the garage door state condition.
My apologies. I saw that post but glossed over the OP’s intent for his Sensor and it didn’t click that it was the same “repeat when device has been tripped for x minutes” scenario I was looking for.
No worries at all! It started with a different topic and drifted into that as a solution, so I’m not surprised you didn’t pick it up. I was really just pointing it out because I posted screen shots that show the added feature in configuration.
Edit: By the way, as of 3.5, the “pulse” output mode option for conditions will allow repeats, so it will basically make a single condition work like the condition+Interval pair–a shortcut, if you will.
So here’s my logic summary. The problem I am seeing is that the activity is immediately firing when the door opens. I do see something about inserting missed interval so I’m wondering what that is and if it’s the cause of the group going true prematurely.
Version 19082.20 12/14/19 21:03:45
Message/status: Not tripped
Condition group "Reactor Sensor 5" (NUL) false as of 12-12.21:30:57 <root>
Z-T-group "Garage Open" (AND) TRUE as of 17:07:36 <grpll5pwog>
| &-T-service Garage Door Sensor (178) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped = 1 [0 => 1 at 17:07:36; T/T as of 17:07:36/17:07:36] <condll5q4tm>
Z-F-group "Garage Left Open" (AND) false as of 17:07:37 <grpll5qpz6>
| &-T-grpstate (self) (-1) Garage Open (grpll5pwog) istrue [true at 17:07:36; T/T as of 17:07:36/17:07:36] <condll5qteo>
| &-F-interval { "relto": "condtrue", "type": "interval", "mins": 15, "id": "condlmkil7q", "hours": 0, "days": 0, "relcond": "grpll5pwog" } [1576375372 => 1576447656 at 17:07:36; F/F as of 17:07:37/17:07:37] <condlmkil7q>
Z-F-group "Garage Open During Work" (AND) false as of 12-13.21:23:46 <grpll5vsxp>
| &-T-grpstate (self) (-1) Garage Open (grpll5pwog) istrue [true at 17:07:36; T/T as of 17:07:36/17:07:36] <condll5w5so>
| &-F-weekday { "id": "condll5wmxm", "type": "weekday", "value": "2,3,4,5,6", "operator": "" } [7 => 1 at 09:40:48; F/F as of 12-14.09:43:49/12-14.09:43:49] <condll5wmxm>
| &-F-trange bet ,,,8,0,,,,15,0 [1576447656 => 1576447657 at 17:07:37; F/F as of 17:01:48/17:01:48] <condll5wva7>
Z-F-group "Garage Opened at Night" (AND) false as of 12-13.21:23:46 <grpll5xj2y>
| &-T-grpstate (self) (-1) Garage Open (grpll5pwog) istrue [true at 17:07:36; T/T as of 17:07:36/17:07:36] <condll5xul6>
| &-F-trange bet ,,,22,0,,,,6,0 [1576447656 => 1576447657 at 17:07:37; F/F as of 12-14.09:43:49/12-14.09:43:49] <condll5y61q>
Activity grpll5qpz6.true
Notify nid 3: sid 33 users 1914511 message "Garage Left Open"
Notify nid 4: users message "Garage Left Open"
Activity grpll5xj2y.true
Notify nid 7: sid 35 users 1914511 message "Garage Opened at Night"
Notify nid 8: users message "Garage Open During Workday"
Activity grpll5vsxp.true
Notify nid 5: sid 34 users 1914511 message "Garage Open During Workday"
Notify nid 6: users message "Garage Open During Workday"
Events
2019-12-15 17:01:46: Reactor startup (Luup reload)
2019-12-15 17:01:47: Starting (Luup Startup/Reload)
2019-12-15 17:01:48: Condition condll5wva7 test state changed from true to false
2019-12-15 17:01:48: Condition condll5wva7 evaluation state changed from true to false
2019-12-15 17:02:35: Device Garage Door Sensor (#178) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped changed from "0" to "0"
2019-12-15 17:07:36: Device Garage Door Sensor (#178) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped changed from "0" to "1"
2019-12-15 17:07:36: Condition condll5q4tm test state changed from false to true
2019-12-15 17:07:36: Condition condll5q4tm evaluation state changed from false to true
2019-12-15 17:07:36: Group Garage Open test state changed from false to true
2019-12-15 17:07:36: Group Garage Open evaluation state changed from false to true
2019-12-15 17:07:36: Condition condll5qteo test state changed from false to true
2019-12-15 17:07:36: Condition condll5qteo evaluation state changed from false to true
2019-12-15 17:07:36: Condition condlmkil7q inserting missed interval (late 72000)
2019-12-15 17:07:36: Condition condlmkil7q test state changed from false to true
2019-12-15 17:07:36: Condition condlmkil7q evaluation state changed from false to true
2019-12-15 17:07:36: Group Garage Left Open test state changed from false to true
2019-12-15 17:07:36: Group Garage Left Open evaluation state changed from false to true
2019-12-15 17:07:36: Condition condll5w5so test state changed from false to true
2019-12-15 17:07:36: Condition condll5w5so evaluation state changed from false to true
2019-12-15 17:07:36: Condition condll5xul6 test state changed from false to true
2019-12-15 17:07:36: Condition condll5xul6 evaluation state changed from false to true
2019-12-15 17:07:36: Device Garage (#343) urn:toggledbits-com:serviceId:ReactorGroup/GroupStatus_grpll5pwog changed from "0" to "1"
2019-12-15 17:07:36: Launching Garage Left Open.true activity
2019-12-15 17:07:36: Launching scene/activity grpll5qpz6.true
2019-12-15 17:07:36: Starting "grpll5qpz6.true" group 1
2019-12-15 17:07:36: Activity "grpll5qpz6.true" finished
2019-12-15 17:07:37: Condition condlmkil7q test state changed from true to false
2019-12-15 17:07:37: Condition condlmkil7q evaluation state changed from true to false
2019-12-15 17:07:37: Group Garage Left Open test state changed from true to false
2019-12-15 17:07:37: Group Garage Left Open evaluation state changed from true to false
Devices
Garage Door Sensor (178) urn:schemas-micasaverde-com:device:MotionSensor:1 (4/3); parent 1; plugin -; mfg Ecolink model ; dev D_MotionSensor1.xml impl
ZWave (1) urn:schemas-micasaverde-com:device:ZWaveNetwork:1 (19/0); parent 0; plugin -; mfg model ; dev D_ZWaveNetwork.xml impl
*Edit: I did look at the new pulse option in 3.5 but it was late and I don’t think I was using it right so I went back to this interval solution instead.
The first interval will fire as soon as the garage door opens. That’s expected. If you want a delay there, as a “sustained for” option to the Group State condition that’s paired with the Interval condition. Also the Interval condition must be relative to the Group State condition it’s partnered with in this case, no the “Garage Open” group.
Yes, but to make sure that the events are properly coordinated, also make sure that (a) it’s the Group State test in the “Garage Left Open” group that gets the “sustained for” delay, and (b) the Interval is relative to the condition in (a). Important details!
Yes, in part. This fixes (a) from my post above, but not (b). To fix (b) change the highlighted field so it refers to the (a) condition–you need to refer to the condition that has the “sustained for” so that the interval starts when the sustained-for restriction is met, not before…
