Rate-limit a trigger

My goal is to rate-limit a door/window sensor, so that if the door sensor is tripped multiple times within a 5-second period, the resulting action only occurs once (in this case a chime sound is played via a Dome siren/chime device).

Example situation: A door is opened and closed 3 times during a 5 second period.

Desired action: The Dome siren/chime plays a chime sound 1 time (and not 3 times)

Is this possible to do with the Reactor plugin, and if so, how would I go about implementing this?

Thank you in advance for any help!

[quote=“WalkRightThruThatDoor, post:1, topic:200629”]My goal is to rate-limit a door/window sensor, so that if the door sensor is tripped multiple times within a 5-second period, the resulting action only occurs once (in this case a chime sound is played via a Dome siren/chime device).

Example situation: A door is opened and closed 3 times during a 5 second period.

Desired action: The Dome siren/chime plays a chime sound 1 time (and not 3 times)

Is this possible to do with the Reactor plugin, and if so, how would I go about implementing this?

Thank you in advance for any help![/quote]

If you create your service condition for the door sensor’s Tripped value, then click the downward-pointing arrow to the right of the condition value, a series of options will open up. There you will find “Condition repeats”, where you can set the number of repeats and the time window in which they need to occur for the condition to fully evaluate to TRUE. That should be all you need based on what you’ve asked.

Just for fun: you can effectively “debounce” the sensor fully by adding another group (so you get an OR between the two groups) with the same device service condition, but in this case, use the “sustained for” option instead, and set it to the same duration as the “repeat within” in the first condition/group. The effect of this is that the ReactorSensor will trip if the door opens N times in X seconds or is held open for X seconds, so it tells you both that the door is open and/or swinging (as alarm old-timers may say) with a single chime. So to be clear about the structure for this:

Group #1:

  • Service condition, door sensor device, variable Tripped, condition “is TRUE” (or equals 1, or not equals 0, or whatever suits your style)
    • option: repeats N times within X seconds

Group #2: (new, separate group)

  • Service condition, same door sensor device, variable, and condition as in Group #1
    • option: duration >= X seconds (same duration as above)

Another option, if the device supports it, is to change the time it clears the motion. I have 1 in my kitchen and 1 in the living room set to send a stop motion after 5 minutes.

I think I understand how the plugin can accomplish want I want.

But in your example above, I want ?N? to be 1. So that if the door opens 1, 2, 3 or more times within X seconds, the activity/action occurs only one time (the chime sounds only once). The plugin won?t let me set N = 1

I think I understand how the plugin can accomplish want I want.

But in your example above, I want ?N? to be 1. So that if the door opens 1, 2, 3 or more times within X seconds, the activity/action occurs only one time (the chime sounds only once). The plugin won?t let me set N = 1

EDIT: The following describes a solution for Reactor version 2. Reactor version 3 now includes a “delay reset” option on conditions that accomplishes the same thing in one step as the multiple steps described below.

Something happening “within X seconds” implies two or more events with a constraint on the interval of time allowed between the first and last (e.g. for N=2, the second happens within X seconds of the first), so N=1 doesn’t make sense, because that would represent a point in time, not an interval of time.

So, what you really need is for door open condition to latch (one the door is opened the condition remains true, even if the door is subsequently closed), until some other condition resets that latch. That reset condition can be the door being closed for X seconds or more. In order to get the desired effect, let’s use TWO ReactorSensors:

Sensor #1: “Door Close Timeout”
One group with a single condition:

  • Condition: Service, device door sensor, variable Tripped, IS FALSE
    • option: sustain at least X seconds

OK. So basically, this ReactorSensor tells us when it’s OK to chime again. That is, it’s OK to chime again if the door has been closed for an unbroken period of X seconds. If the door is opened, this RS instantly untrips. If the door is closed, it will also remain false/untripped, until the door has been closed for X seconds, then it will go true/tripped.

Now, let’s handle the chime:

Sensor #2: “Door Chime”
One group only, containing two conditions:

  • Condition #1: Service, device door sensor, variable Tripped, IS TRUE
    • option: LATCHING
  • Condition #2: Service, device “Door Close Timeout” (the other ReactorSensor just created), variable Tripped, IS FALSE
    (no options whatsoever on this condition)

When the door opens, the “Door Close Timeout” RS instantly untrips/goes false, because the door is no longer closed. The first condition of “Door Chime” goes true, because the door is now open. The second condition of “Door Chime” is also now true, because “Door Close Timeout” has gone FALSE. So, with both of its conditions true in its one group, “Door Chime” trips (this is the signal for you to chime via Activities or scene activation).

Then, when the door closes, one of two things will happen:

  1. If the door closes, but is opened again within X seconds (as set on “Door Close Timeout”), then “Door Close Timeout” remains FALSE, and therefore the second condition in “Door Chime” remains true. But the door sensor test in “Door Chime”'s first condition also remains true, because it’s LATCHED–once it went true, it can only reset if other conditions in the same group go false, and since the “Door Close Timeout” condition in that group hasn’t yet gone false, it remains true even though the door has momentarily closed, and with both group conditions true, the “Door Chime” RS remains tripped. This does not trigger the Activities or scene again–those are only triggered when the state changes from untripped to tripped, and since it was previously tripped, and is now still tripped, that’s no change, so no triggering of actions.

  2. If the door remains closed for an unbroken period of X seconds (as set on “Door Close Timeout”), the “Door Close Timeout” RS will go TRUE. When that happens, the second condition in “Door Chime” goes false, so now the group it’s in is no longer true, causing the latched first condition to reset and the “Door Chime” RS to untrip.

I am after the same exact result as you have detailed here. The reason being is I am expirencing multiple “chimes” with Vera’s scene creator. I am not sure if my door sensors are sending multiple open signals or if Vera is interpreting incorrectly, but either way having the chime go off 3-4 times when you open the door is annoying.

I understand how you are setting up the conditions. My problem is I cannot figure out how to save the chime action in the RS activities. The image below is what I see when I “import scene to actions.” At this point the chime works when I click “try this action.” However, as soon as I save the RS or go to the conditions page it no longer works. Also note that the line with NewChimeValue disappears.

I’m missing something here

I can’t tell what your conditions are or where you’ve put these actions. Please go to the Tools tab and find the Logic Summary link… click that, and post the output here. Then we’ll give it a squiz and see what’s up…

EDIT: Can you also select your alarm device on the “Submit Device” tool on the Tools page and submit it? Thanks.

This was just a dummy sensor, I hadn’t even gone to the conditions since I couldn’t get the actions to perform while manually triggering the sensor. Nonetheless, I threw in a door sensor that would be a condition.

You can see that SetChimeProperty( ) has no value. Is this the reason?

I submitted the two DomeChime devices. Please note that the DomeAlarm, same physical device but separate in selection works with reactor. However, the only option is to turn the alarm on, not a chime.

Also, in case it matters- I am using a Vera scene with these two chimes. If any of the three door sensors are option then chime #1 is played on the two alarms.

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
   Version: 3.2 config 301 cdata 19082 ui 19143 pluginDevice 90
    System: Vera version 1.7.4454 on Sercomm G550; loadtime 1560300021; systemReady 1560300040; Lua 5.1
Local time: 2019-06-11T20:42:04-0400; DST=1
House mode: plugin 1; system 1; tracking on
  Sun data: { "stamp": 2019162, "civdawn": 1560243660, "nautdawn": 1560240949, "sunset": 1560300742, "nautdusk": 1560305549, "latitude": 42.7678, "astrodusk": 1560308863, "longitude": -78.6134, "civdusk": 1560302839, "astrodawn": 1560237635, "sunrise": 1560245756 }
  Geofence: running in long mode, last update 18:12:00, data version 2
            User 2464412 ishome=1 inlist= since=18:12:00
            Raw: { "updated": 1560300120, "users_settings": [ { "id": 2464412, "ishome": 1 } ], "mode": -1, "users": [ { "id": 2464412, "Level": 1, "Name": "derekkirsch", "IsGuest": 0 } ], "usergeofences": [ { "geotags": [  ], "iduser": 2464412 } ] }
     Power: utility, battery level 99
====================================================================================================================================
Reactor Sensor 20 (#295)
    Version 19082.10 06/11/19 20:40:08
    Message/status: Not tripped
    Condition group "Reactor Sensor 20" (AND) false as of 20:39:43 <root>
      &-F-service DOOR SENSOR - FRONT  (234) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped = 1 [0 at 20:39:43; F/F as of 20:39:43/20:39:43] <cond0>
    Activity root.true
        Device 275 (DOME ALARM - DOWNSTR Chime) action urn:micasaverde-com:serviceId:Dome1/SetChimeProperty(  )
        Device 273 (DOME ALARM - UPSTAIR Chime) action urn:micasaverde-com:serviceId:Dome1/SetChimeProperty(  )
    Events
        06/11/19 20:40:34 start: 
        06/11/19 20:40:41 action: action=Trip
        06/11/19 20:40:41 sensorstate: state=true
        06/11/19 20:40:41 startscene: scene=root.true, sceneName=root.true
        06/11/19 20:40:41 runscene: scene=root.true, sceneName=root.true, group=1, notice=Starting scene group 1
        06/11/19 20:40:41 endscene: scene=root.true, sceneName=root.true
        06/11/19 20:40:44 action: action=Reset
        06/11/19 20:40:44 sensorstate: state=false

OK. So for the first level issue, go to the Tools page and update your device information database. Then go back to your actions and fix them up. The NewChimeProperty value should now stick. There was no information in Reactor’s device info database for that device type, so your submission facilitated “training”.

Then…the original solution proposed for this question works for Reactor 2.x. It’s simpler in version 3. All you need is a single condition with a “delay reset” option set for some small debounce time, like 10-15 seconds (or whatever works for your sensibilities, but that’s a starting point). In version 3 you don’t need two ReactorSensors to do the work–the delay reset does it all.

The delay command you are referring to is the one in activities, correct? Whatever time value it has, the RS will “stall,” either untipped or tripped until the timers up.

So, I updated my device info, I forgot the value, but it was far out of date. Like you said, I can now store a value for NewChimeProperty, however I don’t know what it is. I went back to importing the scene, and it shows 0x87-0x1-0x01. It stores this value when I input it, but the action never works. It does not work right after importing either like it did before- only a prompt saying an Error occured, please try again, vera may be busy.

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
   Version: 3.2 config 301 cdata 19082 ui 19143 pluginDevice 90
    System: Vera version 1.7.4454 on Sercomm G550; loadtime 1560304869; systemReady 1560304888; Lua 5.1
Local time: 2019-06-11T22:19:04-0400; DST=1
House mode: plugin 1; system 1; tracking on
  Sun data: { "stamp": 2019162, "civdawn": 1560243660, "nautdawn": 1560240949, "sunset": 1560300742, "nautdusk": 1560305549, "latitude": 42.7678, "astrodusk": 1560308863, "longitude": -78.6134, "civdusk": 1560302839, "astrodawn": 1560237635, "sunrise": 1560245756 }
  Geofence: running in long mode, last update 18:12:00, data version 2
            User 2464412 ishome=1 inlist= since=18:12:00
            Raw: { "updated": 1560305940, "users_settings": [ { "id": 2464412, "ishome": 1 } ], "mode": -1, "users": [ { "id": 2464412, "Level": 1, "Name": "derekkirsch", "IsGuest": 0 } ], "usergeofences": [ { "geotags": [  ], "iduser": 2464412 } ] }
     Power: utility, battery level 99
====================================================================================================================================
Reactor Sensor 20 (#295)
    Version 19082.21 06/11/19 22:18:58
    Message/status: Not tripped
    Condition group "Reactor Sensor 20" (AND) false as of 20:39:43 <root>
      &-F-service DOOR SENSOR - FRONT  (234) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped = 1 [0 at 20:39:43; F/F as of 20:39:43/20:39:43] <cond0>
    Activity root.true
        Device 275 (DOME ALARM - DOWNSTR Chime) action urn:micasaverde-com:serviceId:Dome1/SetChimeProperty( NewChimeProperty="0x87-0x1-0x01" )
        Device 273 (DOME ALARM - UPSTAIR Chime) action urn:micasaverde-com:serviceId:Dome1/SetChimeProperty( NewChimeProperty="0x87-0x1-0x01" )
    Events
        06/11/19 22:01:22 start: 
        06/11/19 22:05:39 configchange: 
        06/11/19 22:06:06 configchange: 
        06/11/19 22:06:07 variable: newval=133, variable=e
        06/11/19 22:06:24 configchange: 
        06/11/19 22:06:54 configchange: 
        06/11/19 22:10:58 action: action=Trip
        06/11/19 22:10:58 sensorstate: state=true
        06/11/19 22:10:58 startscene: scene=root.true, sceneName=root.true
        06/11/19 22:10:58 runscene: scene=root.true, sceneName=root.true, group=1, notice=Starting scene group 1
        06/11/19 22:10:58 endscene: scene=root.true, sceneName=root.true
        06/11/19 22:11:03 action: action=Reset
        06/11/19 22:11:03 sensorstate: state=false
        06/11/19 22:11:16 configchange: 
        06/11/19 22:11:29 configchange: 
        06/11/19 22:11:36 action: action=Trip
        06/11/19 22:11:36 sensorstate: state=true
        06/11/19 22:11:36 startscene: scene=root.true, sceneName=root.true
        06/11/19 22:11:36 runscene: scene=root.true, sceneName=root.true, group=1, notice=Starting scene group 1
        06/11/19 22:11:36 endscene: scene=root.true, sceneName=root.true
        06/11/19 22:11:39 action: action=Reset
        06/11/19 22:11:39 sensorstate: state=false
        06/11/19 22:12:52 configchange: 
        06/11/19 22:13:34 configchange: 
        06/11/19 22:13:35 notify: delay=1560302015, cond=conde8t40vv, message=Detected missed interval Wed Dec 31 20:00:00 1969
        06/11/19 22:13:35 condchange: newState=true, cond=conde8t40vv
        06/11/19 22:13:35 evalchange: newState=true, cond=conde8t40vv
        06/11/19 22:13:50 condchange: newState=false, cond=conde8t40vv, oldState=true
        06/11/19 22:13:50 evalchange: newState=false, cond=conde8t40vv, oldState=true
        06/11/19 22:16:28 configchange: 
        06/11/19 22:18:56 configchange: 

No, the delay goes on the sensor condition(s). Open the condition options (downward-pointing chevon on the condition row), and find the “delay reset” option.

The value for the action is device-specific, and I have no way of knowing its structure of meaning–you’d have to work that out with the author of whatever plugin that service belongs to. But, the value should be exactly the same as you would see in Vera’s “Advanced Editor” when looking at the scene that you imported in the Vera scene editor.

Looks like what you’re doing is a bit different from recent instructions: https://dome.zendesk.com/hc/en-us/articles/115004360627-Using-the-Siren-s-Chimes-with-Vera

When I added the “door chime” scene with Vera it had the options available so I never looked up the Lua. So thank you, I followed the instructions and everything works great.

One last question- is there a way to “send data” in lua to multiple devices simultaneously? Not that it is too annoying but you can hear the first chime #78 go off, then chime #79 after.

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
   Version: 3.2 config 301 cdata 19082 ui 19143 pluginDevice 90
    System: Vera version 1.7.4454 on Sercomm G550; loadtime 1560386945; systemReady 1560386717; Lua 5.1
Local time: 2019-06-12T20:49:52-0400; DST=1
House mode: plugin 1; system 1; tracking on
  Sun data: { "stamp": 2019163, "civdawn": 1560330049, "nautdawn": 1560327333, "sunset": 1560387173, "nautdusk": 1560391988, "latitude": 42.7678, "astrodusk": 1560395314, "longitude": -78.6134, "civdusk": 1560389273, "astrodawn": 1560324007, "sunrise": 1560332148 }
  Geofence: running in long mode, last update 06-11.18:12:00, data version 2
            User 2464412 ishome=1 inlist= since=06-11.18:12:00
            Raw: { "updated": 1560386940, "users_settings": [ { "id": 2464412, "ishome": 1 } ], "mode": -1, "users": [ { "id": 2464412, "Level": 1, "Name": "derekkirsch", "IsGuest": 0 } ], "usergeofences": [ { "geotags": [  ], "iduser": 2464412 } ] }
     Power: utility, battery level 95
====================================================================================================================================
DOOR CHIME (#295)
    Version 19082.30 06/12/19 20:30:18
    Message/status: Not tripped
    Condition group "Reactor Sensor 20" (OR) false as of 20:31:20 <root>
      |-F-service DOOR SENSOR - FRONT  (234) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped = 1; delay reset for 15s [1 => 0 at 20:31:05; F/F as of 20:31:05/20:31:20] <cond0>
      |-F-service DOOR SENSOR DWNSTRS (233) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped = 1; delay reset for 15s [0 at 11:45:22; F/F as of 11:45:22/11:45:22] <conde9lre32>
      |-F-service DOOR SENSOR - PORCH (235) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped = 1; delay reset for 15s [0 at 11:45:22; F/F as of 11:45:22/11:45:22] <conde9m17b2>
    Activity root.true
        Run Lua:
             1: luup.call_action('urn:micasaverde-com:serviceId:ZWaveNetwork1','SendData',{Node='78',Data='x87 1 1'},1)
        Run Lua:
             1: luup.call_action('urn:micasaverde-com:serviceId:ZWaveNetwork1','SendData',{Node='79',Data='x87 1 1'},1)
    Events
        06/12/19 20:45:12 start: 
        06/12/19 20:48:28 action: action=Trip
        06/12/19 20:48:28 sensorstate: state=true
        06/12/19 20:48:28 startscene: scene=root.true, sceneName=root.true
        06/12/19 20:48:28 runscene: scene=root.true, sceneName=root.true, group=1, notice=Starting scene group 1
        06/12/19 20:48:28 endscene: scene=root.true, sceneName=root.true
        06/12/19 20:48:33 action: action=Reset
        06/12/19 20:48:33 sensorstate: state=false
        06/12/19 20:48:45 action: action=Trip
        06/12/19 20:48:46 sensorstate: state=true
        06/12/19 20:48:46 startscene: scene=root.true, sceneName=root.true
        06/12/19 20:48:46 runscene: scene=root.true, sceneName=root.true, group=1, notice=Starting scene group 1
        06/12/19 20:48:46 endscene: scene=root.true, sceneName=root.true
        06/12/19 20:48:53 action: action=Reset
        06/12/19 20:48:53 sensorstate: state=false
        06/12/19 20:49:15 action: action=Trip
        06/12/19 20:49:15 sensorstate: state=true
        06/12/19 20:49:15 startscene: scene=root.true, sceneName=root.true
        06/12/19 20:49:15 runscene: scene=root.true, sceneName=root.true, group=1, notice=Starting scene group 1
        06/12/19 20:49:15 endscene: scene=root.true, sceneName=root.true
        06/12/19 20:49:20 action: action=Reset
        06/12/19 20:49:20 sensorstate: state=false
        06/12/19 20:49:39 action: action=Restart
        06/12/19 20:49:39 start: 
        06/12/19 20:49:42 action: action=Trip
        06/12/19 20:49:42 sensorstate: state=true
        06/12/19 20:49:42 startscene: scene=root.true, sceneName=root.true
        06/12/19 20:49:42 runscene: scene=root.true, sceneName=root.true, group=1, notice=Starting scene group 1
        06/12/19 20:49:42 endscene: scene=root.true, sceneName=root.true
        06/12/19 20:49:46 action: action=Reset
        06/12/19 20:49:46 sensorstate: state=false

Looking good! You can put both actions in one Lua block–that will run more quickly.

luup.call_action('urn:micasaverde-com:serviceId:ZWaveNetwork1','SendData',{Node='78',Data='x87 1 1'},1)
luup.call_action('urn:micasaverde-com:serviceId:ZWaveNetwork1','SendData',{Node='79',Data='x87 1 1'},1)

You should also be able to use Device Actions directly to the ZWave controller to send the data (same thing the Lua is doing):

Just different styles. By all means do whatever works best for you and suits your sensibilities.