Need Help Setting up LUUP to disable Sirens before they start going off

Rylannic · September 15, 2019, 1:30am

When my Vera is in Away, Night, Or Vacation mode. I have the Zooz Multisiren announce that the “Alarm is Active” when a sensor is triggered. When the sensor is triggered, I have a 30 seconds delay before the sirens start blaring.

I am doing this through a scene currently.

What I am trying to figure out is how to disable the sirens in my 30 second delay by putting the Vera into Home mode before they go off. Just like you would with a normal house alarm system where you have about 30 seconds to disable the alarm.

Any ideas, Luup or suggestions on how to accomplish this ?

Here is where I am at based on some other Posts I read…

luup.call_action(“urn:micasaverde-com:serviceId:ZWaveNetwork1”, “SendData”, {Node=47, Data=“x70 4 3 1 34”}, 1) <---- This tells my Zooz Speaker to Announce “the Alarm is ON”

local dID = 52 <----- Device 52 is my Modes Device

local allow = false

luup.call_delay(“delaycall”,30)

function delaycall()

local status = luup.variable_get(“urn:micasaverde-com:serviceId:HouseModes1”,“HMode”,dID)

if (status ~=“1”) then

luup.call_action(“urn:micasaverde-com:serviceId:HomeAutomationGateway1”,“RunScene”,{ SceneNum=“87” }, 0) <------ # 87 is the Scene device number for the Scene which turns on my Sirens

else

return allow

end

ranneman · September 15, 2019, 6:14am

Good question, it is possible to do this in Luup and I remember I once actually build this in Luup but never activated it as my children would have probably activated this alarm to many times (walking through the house at night and things like that). Lately I have been thinking to actually set this up and your question triggers me to use the Reactor plugin for scenes like this. It is easy to use.

I did a quick test and this is the result. Setup a condition like in below example. It will trip if the sensor is tripped in any of the states marked.

You might have to play a bit with pulse I had set the pulse for the tripped sensor to 37 seconds.

In your activities you can set what you like to happen using the delay option and reset everything if the mode is switched to home within the 30 seconds interval. In my example I start a radiostation (In you example you would have your system say something like Alarm is ON". As I do not have a sirene I switch on a lamp (kamer achter 3 spots) to test if this works.

If set to home the second activity resets it all.

rigpapa · September 15, 2019, 1:39pm

I would not go about it this way. Reactor provides a specific feature to address his need: the “sustained for” delay.

Group root - NUL
- Group “Siren Delay”
  - Device State Condition for whatever triggers the alarm + “sustained for” option 30 seconds for delay
  - House mode is any of (select all modes except “Home”
- Group “Siren Off”
  - House mode is any of Home (only)

Then, the activitity “Siren Delay is TRUE” sends the command to turn off the siren, and “Siren Off” sends the command to turn it off.

The “sustained for” delay will require that the device test state result remain true for the delay period before the condition actually goes true. When the delay expires and the condition goes true, if the house is also in Away, Vacation or Night modes then the “Siren Delay” group goes true and its activity runs (turn siren on). The siren will not be turned on in Home mode.

See https://www.youtube.com/watch?v=VBr4gBcgQRg

ranneman · September 15, 2019, 2:32pm

Thanks for pointing that out, indeed sustained for works better.

Rylannic · September 15, 2019, 7:02pm

I am having a hard time getting the delay correct.

I basically want it to start a 30 second countdown to sound alarm whenever a door/window sensor trips…

Any suggestions? Been watching your Youtube, great information, Thank you so much !

rigpapa · September 15, 2019, 8:03pm

Everything you’ve done looks right. You didn’t mention what, if anything, it’s doing that you don’t expect?

Edit: I don’t have a siren so I can’t judge the effect of “SetArmed”. Is that what tells it to make noise?

Rylannic · September 15, 2019, 8:04pm

The alarm is going off imediately not waiting 30 seconds.

Edit: Yes, set armed turns the alarm on

rigpapa · September 15, 2019, 8:12pm

OK. Watch the status display for the Reactor sensor and open the door. You should observe that the “Siren Delay” group does NOT immediately go green, and a countdown timer is shown on the device state condition. As soon as the timer reaches 30 seconds, the “Siren Delay” group will go green.

If the Siren Delay group is not green yet, but the siren starts sounding, something else is turning it on. You can also look at the “events” section of the logic summary to confirm that your activities are not being run until the group goes true.

Rylannic · September 15, 2019, 8:38pm

Ok I will figure out what else is triggering it. I am watiching the status as I open the door and the timer is starting but as soon as I close it, The Device state is resetting.

Is there something different I need to do to get the timer to continue counting when the door is opened, then closed?

rigpapa · September 15, 2019, 8:51pm

Set the output control type option on the device condition to “Latch”

Rylannic · September 15, 2019, 8:54pm

Tried that… and just tried again ,but the timer is still not latching and resets, once the window is closed (changed the device for now to get away from the door and also its closer)

I see the timer start when the window is open… just not holding.

rigpapa · September 15, 2019, 9:11pm

Let’s do logic summaries instead of screen shots. Tools tab

Rylannic · September 15, 2019, 9:13pm

INSTRUCTIONS: When pasting this report into the Vera Community forums, please include ALL lines below this one. The next and last lines will ensure proper formatting and must not be removed!

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
   Version: 3.4 config 19226 cdata 19082 ui 19237 pluginDevice 160
    System: Vera version 1.7.4453 on Sercomm G450; loadtime 1568573711; systemReady 1568573727; Lua 5.1; JSON dkjson 1.2
Local time: 2019-09-15T14:19:45-0700; DST=0; Phoenix, Arizona United States
House mode: plugin 4; system 4; tracking on
  Sun data: 
  Geofence: not running
====================================================================================================================================
Reactor Sensor 1 (#161)
    Version 19082.49 09/15/19 13:56:34
    Message/status: Not tripped
    Condition group "Alarm Delay" (NUL)  false as of n/a <root>
      Z-F-group "Siren Delay" (AND)  false as of 11:42:59 <grpi1f5yjw>
      |     &-F-service Office Window Sensor (126) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped = 1 for ge 30s; latching [1 => 0 at 14:11:37; F/F as of 14:11:37/11:42:59] <condi1f6wor>
      |     &-T-housemode in 2,3,4; latching [1 => 4 at 13:30:34; T/T as of 13:30:34/13:30:34] <condi1gwxt9>
      Z-F-group "Siren Off" (AND)  false as of 13:30:34 <grpi1g8slj>
      |     &-F-housemode in 1 [1 => 4 at 13:30:34; F/F as of 13:30:34/13:30:34] <condi1ga1ev>
    Activity grpi1g8slj.true
        Device Aeotec Siren (44) action urn:micasaverde-com:serviceId:SecuritySensor1/SetArmed( newArmedValue="0" )
    Activity grpi1f5yjw.true
        Device Aeotec Siren (44) action urn:micasaverde-com:serviceId:SecuritySensor1/SetArmed( newArmedValue="1" )
    Events
        09/15/19 13:29:47 condchange: newState=true, cond=grpi1g8slj, oldState=false
        09/15/19 13:29:47 evalchange: newState=true, cond=grpi1g8slj, oldState=false
        09/15/19 13:29:47 startscene: scene=grpi1g8slj.true, sceneName=grpi1g8slj.true
        09/15/19 13:29:47 runscene: scene=grpi1g8slj.true, sceneName=grpi1g8slj.true, group=1, notice=Starting scene group 1
        09/15/19 13:29:47 endscene: scene=grpi1g8slj.true, sceneName=grpi1g8slj.true
        09/15/19 13:30:34 devicewatch: name=Reactor, var=HouseMode, device=160
        09/15/19 13:30:34 condchange: newState=true, cond=condi1gwxt9, oldState=false
        09/15/19 13:30:34 evalchange: newState=true, cond=condi1gwxt9, oldState=false
        09/15/19 13:30:34 condchange: newState=false, cond=condi1ga1ev, oldState=true
        09/15/19 13:30:34 evalchange: newState=false, cond=condi1ga1ev, oldState=true
        09/15/19 13:30:34 condchange: newState=false, cond=grpi1g8slj, oldState=true
        09/15/19 13:30:34 evalchange: newState=false, cond=grpi1g8slj, oldState=true
        09/15/19 13:31:19 configchange: 
        09/15/19 13:34:14 configchange: 
        09/15/19 13:34:42 devicewatch: device=126, old="0", name=Office Window Sensor, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="1"
        09/15/19 13:34:42 condchange: newState=true, cond=condi1f6wor, oldState=false
        09/15/19 13:34:44 devicewatch: device=126, old="1", name=Office Window Sensor, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="0"
        09/15/19 13:34:44 condchange: newState=false, cond=condi1f6wor, oldState=true
        09/15/19 13:35:52 devicewatch: device=126, old="0", name=Office Window Sensor, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="1"
        09/15/19 13:35:52 condchange: newState=true, cond=condi1f6wor, oldState=false
        09/15/19 13:35:56 devicewatch: device=126, old="1", name=Office Window Sensor, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="0"
        09/15/19 13:35:56 condchange: newState=false, cond=condi1f6wor, oldState=true
        09/15/19 13:37:42 devicewatch: device=126, old="0", name=Office Window Sensor, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="1"
        09/15/19 13:37:42 condchange: newState=true, cond=condi1f6wor, oldState=false
        09/15/19 13:37:48 devicewatch: device=126, old="1", name=Office Window Sensor, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="0"
        09/15/19 13:37:48 condchange: newState=false, cond=condi1f6wor, oldState=true
        09/15/19 13:51:33 configchange: 
        09/15/19 13:51:46 devicewatch: device=126, old="0", name=Office Window Sensor, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="1"
        09/15/19 13:51:46 condchange: newState=true, cond=condi1f6wor, oldState=false
        09/15/19 13:51:48 devicewatch: device=126, old="1", name=Office Window Sensor, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="0"
        09/15/19 13:51:48 condchange: newState=false, cond=condi1f6wor, oldState=true
        09/15/19 13:53:20 devicewatch: device=126, old="0", name=Office Window Sensor, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="1"
        09/15/19 13:53:20 condchange: newState=true, cond=condi1f6wor, oldState=false
        09/15/19 13:53:25 devicewatch: device=126, old="1", name=Office Window Sensor, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="0"
        09/15/19 13:53:25 condchange: newState=false, cond=condi1f6wor, oldState=true
        09/15/19 13:56:34 configchange: 
        09/15/19 13:56:48 devicewatch: device=126, old="0", name=Office Window Sensor, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="1"
        09/15/19 13:56:48 condchange: newState=true, cond=condi1f6wor, oldState=false
        09/15/19 13:56:52 devicewatch: device=126, old="1", name=Office Window Sensor, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="0"
        09/15/19 13:56:52 condchange: newState=false, cond=condi1f6wor, oldState=true
        09/15/19 13:59:24 devicewatch: device=126, old="0", name=Office Window Sensor, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="1"
        09/15/19 13:59:24 condchange: newState=true, cond=condi1f6wor, oldState=false
        09/15/19 13:59:31 devicewatch: device=126, old="1", name=Office Window Sensor, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="0"
        09/15/19 13:59:31 condchange: newState=false, cond=condi1f6wor, oldState=true
        09/15/19 14:11:18 action: action=Reset
        09/15/19 14:11:18 sensorstate: state=false
        09/15/19 14:11:31 devicewatch: device=126, old="0", name=Office Window Sensor, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="1"
        09/15/19 14:11:31 condchange: newState=true, cond=condi1f6wor, oldState=false
        09/15/19 14:11:37 devicewatch: device=126, old="1", name=Office Window Sensor, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="0"
        09/15/19 14:11:37 condchange: newState=false, cond=condi1f6wor, oldState=true
    Devices
        ZWave (1) urn:schemas-micasaverde-com:device:ZWaveNetwork:1 (19/0); parent 0; plugin -
        Office Window Sensor (126) urn:schemas-micasaverde-com:device:DoorSensor:1 (4/1); parent 1; plugin -

rigpapa · September 15, 2019, 10:41pm

The house mode condition must not be latched (in either group).

Rylannic · September 15, 2019, 11:08pm

Took out the latch in Home Mode Condition to Siren Delay Group… Still not holding the counter…

I really appreciate the help!

Reactor Sensor 1 (#161)
Version 19082.50 09/15/19 16:04:25
Message/status: Not tripped
Condition group “Alarm Delay” (NUL) false as of n/a
Z-F-group “Siren Delay” (AND) false as of 11:42:59
| &-F-service Office Window Sensor (126) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped = 1 for ge 30s; latching [1 => 0 at 16:05:18; F/F as of 16:05:18/11:42:59]
| &-T-housemode in 2,3,4 [1 => 4 at 16:05:01; T/T as of 16:05:01/16:05:01]
Z-F-group “Siren Off” (AND) false as of 16:05:01
| &-F-housemode in 1 [1 => 4 at 16:05:01; F/F as of 16:05:01/16:05:01]
Activity grpi1g8slj.true
Device Aeotec Siren (44) action urn:micasaverde-com:serviceId:SecuritySensor1/SetArmed( newArmedValue=“0” )
Activity grpi1f5yjw.true
Device Aeotec Siren (44) action urn:micasaverde-com:serviceId:SecuritySensor1/SetArmed( newArmedValue=“1” )
Events
09/15/19 14:50:47 reload: notice=Luup reload
09/15/19 14:50:47 start:
09/15/19 15:56:06 devicewatch: name=Reactor, var=HouseMode, device=160
09/15/19 15:56:07 condchange: newState=false, cond=condi1gwxt9, oldState=true
09/15/19 15:56:07 evalchange: newState=false, cond=condi1gwxt9, oldState=true
09/15/19 15:56:07 condchange: newState=true, cond=condi1ga1ev, oldState=false
09/15/19 15:56:07 evalchange: newState=true, cond=condi1ga1ev, oldState=false
09/15/19 15:56:07 condchange: newState=true, cond=grpi1g8slj, oldState=false
09/15/19 15:56:07 evalchange: newState=true, cond=grpi1g8slj, oldState=false
09/15/19 15:56:07 startscene: scene=grpi1g8slj.true, sceneName=grpi1g8slj.true
09/15/19 15:56:07 runscene: scene=grpi1g8slj.true, sceneName=grpi1g8slj.true, group=1, notice=Starting scene group 1
09/15/19 15:56:07 endscene: scene=grpi1g8slj.true, sceneName=grpi1g8slj.true
09/15/19 16:04:25 configchange:
09/15/19 16:05:01 devicewatch: name=Reactor, var=HouseMode, device=160
09/15/19 16:05:01 condchange: newState=true, cond=condi1gwxt9, oldState=false
09/15/19 16:05:01 evalchange: newState=true, cond=condi1gwxt9, oldState=false
09/15/19 16:05:01 condchange: newState=false, cond=condi1ga1ev, oldState=true
09/15/19 16:05:01 evalchange: newState=false, cond=condi1ga1ev, oldState=true
09/15/19 16:05:01 condchange: newState=false, cond=grpi1g8slj, oldState=true
09/15/19 16:05:01 evalchange: newState=false, cond=grpi1g8slj, oldState=true
09/15/19 16:05:15 devicewatch: device=126, old=“0”, name=Office Window Sensor, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new=“1”
09/15/19 16:05:15 condchange: newState=true, cond=condi1f6wor, oldState=false
09/15/19 16:05:18 devicewatch: device=126, old=“1”, name=Office Window Sensor, var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new=“0”
09/15/19 16:05:18 condchange: newState=false, cond=condi1f6wor, oldState=true
Devices
ZWave (1) urn:schemas-micasaverde-com:device:ZWaveNetwork:1 (19/0); parent 0; plugin -
Office Window Sensor (126) urn:schemas-micasaverde-com:device:DoorSensor:1 (4/1); parent 1; plugin -

rigpapa · September 15, 2019, 11:43pm

wait… longer response coming…

rigpapa · September 16, 2019, 12:45am

OK. I think I understand what you want. In that case, a combination of @ranneman 's original idea and what we have already done should give us the desired result.

Remove the “latch” restriction and the “sustained for” delay, both. Your conditions should look like this:

Group “Alarm Delay” - NUL operator
- Group “Siren On” (rename) - AND operator
  - Device state sensor tripped is TRUE
  - House mode is any of Away, Night, Vacation
- Group “Siren Off”
  - House mode is Home

All groups and conditions have no options (follow mode only).

Then, for activities:

“Siren On is TRUE”:

Delay 30 seconds
Set siren to armed (sounding)

“Siren OFF is TRUE”:

Set siren disarmed (silence)
Device Action, (this ReactorSensor), StopScene - select “all scenes” from the menu.

The “all scenes” stop only applies to scenes being run by the current ReactorSensor, and that would only be the “Siren ON is True” activity if you catch it during the delay. Otherwise it does nothing.

What this changes about @ranneman 's approach was that he was working from a single (root) group and so had opposing activities–a TRUE and FALSE activity for the same group. The start of one automatically terminates any in-progress activity of the other, so he was fitting an additional delay in the form of a pulse to try to circumvent that behavior, so closing the door would not turn off the siren…

This arrangement of two different groups avoids that counter-activity effect. It also uses a SceneStop action to stop the mid-way operation of the “Siren On is TRUE” activity–if you switch to Home mode, you don’t want the siren to sound anyway, you want to preempt that activity (home mode = no siren). He was using a Reset of the RS, and the reset will stop running scenes, but it also does a bunch of other things and clears a lot of state that would then just need to be rebuilt every time.

What this highlights as well is the need for a specific “Stop Activity” action, so I’ll add that to the list for 3.5, but for now, the StopScene action should suffice.

ranneman · September 16, 2019, 3:25pm

Need to look into this, but very helpful in understanding some reactor functionality better.
I added the 30 seconds pulse also to not depend on the sensor setting. As I do not know how it is configured I set the pulse to 30 seconds. In that way I’ am sure I have the 30 seconds to switch my state to “home”, if I don’t make it in that time the alarm will start.
I was not aware on the impact of the restart and had no idea how to stop in case the status was switched to “home” in time.

rigpapa · September 16, 2019, 4:47pm

Understood, and pulse timing is certainly one way to isolate yourself from the unpredictable timing of an input. But it’s often the case in device triggering with sensors that we really don’t care when it untrips, we just care that it tripped, so if you focus the logic correctly, you end up with a trigger for your event that starts and completes independently of the input timing (starts when it trips, and the untrip is ignored and changes nothing)–desirable in this case.