Due to the great work gone into Reactor and its simplicity, I am almost exclusively using it over PLEG now, however I cant figure out how to make a notification repeat until an action is completed.
For example, if I have a door that has been left open, I want every 5 minutes a TTS notification to be sent (using Vera Alerts) and keep repeating until I close the door.
I can do this in PLEG, but suspect its so simple in Reactor Im not seeing it?
any advice appreciated
I can tell you how to do it for the current version of Reactor (2.5), but Iām going to publish 3.0 for general release on Monday, and it will be easier to do this in the new release, so unless youāre dying for a solution today, Iām going to hold off answering your question until Monday. If you need it now, let me know.
Thanks for that, will hold off for Monday and 3.0!
Has it upgraded? Are you ready?
Yes, on 3.0 and ready to go
OK. Hereās the basic idea. This makes use of the new hierarchical group structure in 3.0, and group activities, to simplify the logic (well, I think itās simpler)ā¦
Conditions:
Root group: use AND operator, name it āDoor Monitorā (or whatever/similar)
(Sub)Group 1: AND operator, name it āDoor Openā
(Sub)Group 2: AND operator + NOT, name it āNotification Intervalā
Activities:
Thatās right, no activities. Butā¦ on the notifications tab, set up a notification for when the sensor is tripped (whether armed or disarmed).
That should do it. Hereās how it works:
The first subgroup, āDoor Openā, contains the single condition that checks the door. The group will be true if the door sensor is tripped, since thatās the only condition in this AND group.
The second subgroup, āNotification Intervalā has a little trick. It uses the NOT group operator to invert the state of its conditions, which is only a single Interval condition set for 300 seconds (5 minutes). If we used the interval condition by itself, it would be true every 5 minutes for a few seconds and then return to false. By putting it inside a group with a NOT, the group sits at true most of the time, but every 5 minutes goes false for a few seconds (itās the inverse state of the Interval conditionās state). Hereās why we do thisā¦
Since the root group is an āANDā, and the root group controls the tripped/untripped state of the ReactorSensor, the ReactorSensor will only be tripped when both subgroups are true. Since the Notification Interval group spends most of its time in true state (because of the NOT), then when the door is opened, the other group becomes true, both groups are then true and the ReactorSensor instantly trips, sending the first notification. If the door remains open, the Notification Interval group periodically becomes false for a few seconds, which causes the ReactorSensor to untrip. When the Intervalās pulse period of a few seconds lapses, the Notification Interval group returns to true, causing the ReactorSensor to trip again, causing a subsequent notification. This cycle continues while the door is open.
If we had not inverted the Interval condition using the NOT on a container subgroup, then when the door opened, the first notification would be delayed until the first interval expired, which means the first notification could be delayed up to 4 minutes 59 seconds. Not great. So by being a little tricky and inverting the Interval condition, the first notification when the door opens goes out immediately.
Wow, very indepth āhow toā, much appreciated!
Hi Patrick, I thought Iād try this logic on my Garage door but it seems to not reset and I get multiple frequent alerts even if the door only just opened. The only difference I can see is I used 30 mins instead of 5.
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.
Is that Veraās default notice along with your custom one?
Itās using the standard Vera notifications, the logic sensor is called āgarage still openā
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
Atm I have 2 logic sensors, one is simply open / close notifications and the other is to remind my wife sheās left the garage open.
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).
Am I reading that right?
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.
This is also described in this post from earlier today.
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.
Best Home Automation shopping experience. Shop at Ezlo!
Ā© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules