PLEG not picking up alarm state STAY

This is an odd one. I use PLEG to do stuff when I set my alarm to AWAY… shut off lights, secure doors, etc. I do the same sort of thing when the alarm is disarmed, and that works fine, too. Now… I’d like to do the same for STAY. I’ve had it as a trigger for like a year, but it’s never worked. Have a look at my screen shots. Just this morning, I set the alarm to STAY, and PLEG didn’t reflect the alarm state. When I disarmed, PLEG picked that up.

Any idea why PLEG doesn’t get the STAY trigger? I’ve tried STAY and NIGHT-STAY. Neither works.

Have you tried binding a PLEG Device Property to the alarm status? First you will be able to see the range of values that get set. With that, you could change your Conditions to react to the modes by using string comparison terms.

That’s one way to go–I just did it, and attached is what I have.

Now… I don’t know how to use that string to do anything. Help? How would I make something happen when that property = Stay?

If that works… I might even replace the others with Ready & Armed properties.

EDIT: Maybe add this italicized stuff to the existing condition? “Alarm_Armed_STAY_t28” is the one that’s not working.

Sleeping_c6 Sleep_Mode_On_t4 OR Alarm_Armed_STAY_t28 OR (Alarm_State_p1 == “Stay”)

Need to review the PLEG syntax

== 

Is a numeric comparison

eq 

Is a string comparison

I tried the string above, changing the alarm state from disarmed (Ready) to Stay, and that condition doesn’t turn true.

Oh, I just saw your post. Lemme try that…

Sleeping_c6 Sleep_Mode_On_t4 OR (Alarm_State_p1 eq “Stay”)

That worked, but… this is bizarre. Does the alarm system store the current time somewhere? I just saw a detailed state I’ve never seen before. I set the alarm to STAY, and the detailed state went to NIGHT. I’ve never, ever seen this alarm state. It could be that I’ve never set the alarm to STAY during the day, and for some reason, the alarm thinks it’s night-time. This bothers me a bit.

However… that seems to have worked. Thanks for your help. I’ll play with it a bit.

Ah hah! This is interesting. The reason I saw that new status NIGHT is because the condition went true, and then re-triggered itself based on the fact that I also set Sleep_Mode_On_t4 to 1 in the actions. It’s a loop. And I wasn’t aware that if you sent the alarm to STAY, and then (essentially) press the STAY button again, the detailed state goes to NIGHT. I really don’t know what the difference is between the two… but I’ll have to figure out a way to prevent that from happening.

I have done a similiar thing with PLEG and my Elk M1 panel. But I think I need to clean up a few things in PLEG with regards to my Elk state.

So, REX, when you say “binding” do you mean to use the device properties tab in PLEG to watch my ELK state? If so, should I use “detailedarmmode” or “armMode” to capture this state (arm, disarm, night, stay,etc)?

Finally is there a way I can I see a name list beforhand of what the ELK will report in the “Current Value”? When I use eq in a condition, I need to write this string value exactly how ELK sends it. The only way I know to do this is by arming the Elk to the different modes and then look at PLEG status report. I hope there is an easier way.\

I think I need to redo my inputs and conditions in PLEG after looking at the way DeltaNu1142 did his. For instance I have a PLEG input named ArmedAway and also a condition named the same. PLEG renamed the input name to ArmedAway1.

Yeah, I dig it. This is my first (successful) foray into the use of device properties in PLEG. See the “Alarm State PLEG Property.png” screenshot above. That’s how I set up the property. Now, the text can be any number of detailed alarm states… here’s what I ended up using for my Sleep condition:

(Sleep_Mode_On_t4 AND (Alarm_State_p1 eq “Ready”)) OR (!Sleep_Mode_On_t4 AND (Alarm_State_p1 eq “Stay”))

See, the Sleep condition will set the alarm to STAY and set my sleep mode button to ON… so when the condition becomes true, I don’t want it to trigger itself (as I encountered in the loop above). So if I press the sleep mode button and my alarm detailed state is READY, the Sleep condition will become true. OR, if the sleep mode button is off and someone (SWMBO) sets the alarm to STAY, the condition becomes true.

This still isn’t working exactly how I want, but it’s getting there.

I like this, because I was able to delete a number of triggers that I’ve been using related to the alarm… one for each detailed state I needed. Kudos, Rex!

So, REX, when you say "binding" do you mean to use the device properties tab in PLEG to watch my ELK state?

Exactly. A PLEG Device Property can be set for any device variable and will reflect its current value.

If so, should I use "detailedarmmode" or "armMode" to capture this state (arm, disarm, night, stay,etc)?

I’m not familiar with the Elk alarm modes. See the next point.

Finally is there a way I can I see a name list beforhand of what the ELK will report in the "Current Value"? When I use eq in a condition, I need to write this string value exactly how ELK sends it. The only way I know to do this is by arming the Elk to the different modes and then look at PLEG status report.

I don’t know if this is documented anywhere. Another member may be able to enlighten you. I generally take the simple approach to these things. I would set a Device Property on each of the possible variables then run through each of the arming states and see what how the values changed. It is often quicker to just try something than to spend a bunch of time trying to avoid it. :wink:

I have a PLEG input named ArmedAway and also a condition named the same. PLEG renamed the input name to ArmedAway1.

PLEG is very helpful that way. One name can only refer to one Trigger, Schedule, Device Property or Condition. Some people find it helpful to use PLEG’s default prefixes: t, s, p and c to distinguish between different items that they want to have the same name.

Thank you guys for the heads up. I need to get my alarm functions cleaned up a bit.

This is (sort of) what I ended up doing. I just tested each of the states I need, and checked the PLEG status screen to see what text the property contained. What’s great about that is I now have access to states (like “ExitDelay”) that I didn’t with the use of triggers.