Disarm trigger

[brians]

I can’t seem to find a way to trigger a program based disarm. I can do for arm stay and away and alarming etc but no way to trigger a program when the alarm has been disarmed. 

[TJF1960]

Hi @brians,

I don't think the API includes a disarm node. I am away d from my ISY programs but I use something like this:

If alarm panel is not armed stay

And

If alarm panel is not armed away

And

If alarm panel is not exit delay

And

If alarm panel is not entry delay

Then 

Else

The Program will be true it the alarm panel is disarmed, but The program will be false if either the entry delay or the exit delay are Active or if the alarm panel is armed either stay or away.

Tim

Edited March 20, 2022 by TJF1960

[brians]

@TJF1960 I was thinking of that but the program triggers between ready and not ready if I open/close the front door.

What I ended up doing is making a variable named something like Alarm_Armed

When my program detects armed stay or away, it sets the variable to 1

Then another program that detects disarm, it checks if partition state is ready and Alarm_Armed=1 then is true, and the then sets Alarm_Armed=0, and also inits in case ISY was rebooted.

 

Alarm Disarmed - [ID 006C][Parent 0061]

If
        'Alarm Panel / Partition 1' Partition State is Ready
    And $Alarm_Armed is 1
 
Then
        Set 'Notification Controller / Service Pushover Brian' Priority Normal
        Set 'Notification Controller' Message Alarm - Disarmed
        Set 'Notification Controller / Service Pushover Brian' Send
        $Alarm_Armed  = 0
        $Alarm_Armed Init To 0
 
Else
   - No Actions - (To add one, press 'Action')

Alarm Armed Stay - [ID 006A][Parent 0061]

If
        'Alarm Panel / Partition 1' Partition State is Armed Stay
 
Then
        $Alarm_Armed  = 1
        $Alarm_Armed Init To 1
        Set 'Notification Controller / Service Pushover Brian' Priority Normal
        Set 'Notification Controller' Message Alarm - Armed Stay
        Set 'Notification Controller / Service Pushover Brian' Send
 
Else
   - No Actions - (To add one, press 'Action')
 

 

Edited March 20, 2022 by brians

[Goose66]

Are you not getting an "Alarm Restored" (DOF) command from the partition when the partition is disarmed? Perhaps this should be renamed, but that's what the Alarm Restored command on the partition is for - it is (should be) sent when the partition is disarmed, either from an alarming state or an armed state. The reason for this command is because the partition remains in an undefined state for a second or two after it is disarmed (so the ISY sees no state change), and then eventually the partition will return to the "Ready" state.

[TJF1960]

Hi @brians, after looking at my programming and reading your response, we are basically doing the same thing. I had forgotten I had set up a state variable as well. I am sorry I shouldn't have responded without having the program at my fingertips but am glad you had figured it out. Nice job!

Hi @Goose66, Not seeing "Alarm Restored" command in the Partition State field.

 

Thanks,

Tim

 

 

Edited March 20, 2022 by TJF1960

[Goose66]

@TJF1960 "Status" will only show states (driver values) for the node, e.g., "Partition" state. Setting an if condition on a state will trigger the program whenever the state (driver) value changes, regardless of the value being tested for in the if statement. As I mentioned above, there is no "Disarm" state - it just goes to "Ready" after a few seconds.

"Control" will show commands that the node generates that are received by the ISY. If you put a control in the If statement, the program will be triggered only when that command is generated, e.g.:

 

resulting in:

If
        'Perimeter / Alarm Panel / Partition 1' is switched Alarm Restored
Then
        Set 'Perimeter / House MyQ Gateway / Light Module' Off
Else
   - No Actions - (To add one, press 'Action')

 

Edited March 20, 2022 by Goose66

[Goose66]

The commands that the Node server sends for each node type are here:

https://github.com/Goose66/NSDocs/blob/main/evldsc-pg3.md

I just updated it to show the values for the "Control" conditions in the ISY. That said, I am open to changing how these work based on how people use them. I toyed with the idea of changing the DON and DOF for the partition to be armed and disarmed. Currently I use the Zone "Opened" and "Closed" commands (in ISY scenes with Insteon devices) and I use partition "Alarm Triggered" and "Alarm Restored" to turn on my floods when an alarm goes off. But the Alarm Panel "Alarm Triggered" and "Alarm Restored" are probably better for this, since the floods would be best used for a fire alarm at night.

Edited March 20, 2022 by Goose66

[brians]

@Goose66Thanks, Alarm Restored works perfect for Disarm.

I have a program that disarms the alarm based on a particular user unlocking  my z-wave door lock. When the alarm disarms now, an alarm disarm program prepares a pushover message which includes the door lock user so I know who had opened the door and therefore disarmed.

Having said that, is there a way to disarm via a particular user? I am always seeing User 40 disarm when I do it through ISY.

[Goose66]

According to API documentation and the current programming, if a partition is armed or disarmed with a user code, then the "Last Arm/Disarm User" state values for the partition is set to the number of the user code. If a partition is armed or disarmed using some other method (by key switch, by button on a keypad, etc.), then the "Last Arm/Disarm User" is set to 0.

So when you disarm from the ISY via the Node server, it uses the user code configured in the Custom Configuration Parameters. Accordingly, the number of that user code (40=mater user code) is what will appear in "Last Arm/Disarm User." So I would think that is technically accurate - the master user code configured in the panel was used to disarm the alarm.

That said, there maybe could be a way to add a disarm command that took a different user code. It would have to be able to pass an integer between 1 and 999,999 and would result in a dropdown list in the ISY with 1,000,000 selections (which would probably break Java). It would also result in your user code being transmitted across the network in an unencrypted REST request.

Edited March 21, 2022 by Goose66

[brians]

Ok thanks, the way it currently works is fine!

 

[Goose66]

Maybe create a user code specifically for the ISY/Node server, then at least you could differentiate disarms from the automation system from those done with the master code.