Jump to content
dw886

Programming locks based on Elk M1 Alarm Status - driver bug?

Recommended Posts

So here's what I'd like to do:

If the alarm is disarmed

AND the Previous Alarm State <> [any stay modes]

THEN unlock the door

 

I'd think that this is pretty straightforward, but it doesn't seem to work.  It seems like the drive can't really tell the alarm sub status (what type of armed state it's really in), it can only tell if it's armed or disarmed.  From the looks of it, this should be possible, as all of these alarm states show up in Composer:

image.png.b353ddbfed4af46a5012e2ae958c578a.png

Here's what this looks like in composer.  The top option (which is what I'm really trying to do), doesn't actually unlock the door when I arm the Alarm to "Away" mode and subsequently disarm:

image.png.205eb15ce1f8c9d76c0394ceeb99a880.png

 

This second option works, but it unlocks the door regardless of whether it was armed to Stay or Away....If I'm on the inside of the house, I can turn the knob myself and save the battery on the lock...

image.png.fd182a725ab487b740a0c7d88133ca71.png

 

Does anyone have any experience with this, and am I simply doing this wrong, or is there something wrong with the driver?

Share this post


Link to post
Share on other sites

might need to check the system variables and check what the status of the armed variable is in each state. or i would just program a variable to be true false based on what arm status happens. then you can program the lock off that variable.

 

Share this post


Link to post
Share on other sites

 

2 hours ago, Matt Lowe said:

might need to check the system variables and check what the status of the armed variable is in each state. or i would just program a variable to be true false based on what arm status happens. then you can program the lock off that variable.

 

Good idea - interestingly enough, I'm wondering if the driver is checking for string values of PARTITION_TYPE of  "Armed Away" - I'm guessing at this only by the appearance of the conditional within Composer:

image.png.e79030c2a68df50f9090f896350cd063.png

Where when I look at the system values, there's two different variables that hold the Armed / Disarmed Status, and the Arm Type:

PARTITION_TYPE: "ARMED"
ARMED_TYPE: "Away" 

image.png.97ba90eeb34b61bad138323b5a074640.png

To me it still looks like there's a driver bug, but I'm also guessing I can work around it with a variable. 

I started looking at the "HOME_STATE" system variable as it sounded like what I need, but it looks like it may also have a bug, because when armed to "Stay", it says "True" (because you'd be home), but when armed to "Night" (a sub-set of "stay" with the ability to turn on motions, etc), it says "False".  There's a different variable called "AWAY_STATE", which looks to accurately reflect whether or not the system is in a stay mode. 

I'm guessing the easiest way about this is to toggle a boolean variable based on the "AWAY_STATE", only update it when the system becomes Armed.  Then on Disarm, look at the state, and if AWAY_STATE = True then Unlock.

Share this post


Link to post
Share on other sites

might be a bug for sure. just add variable and change it every time it arms. and then check the variable on unarmed and if the variable is X do y.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×