Jump to content
C4 Forums | Control4

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


dw886

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?

Link to comment
Share on other sites


  • 2 weeks later...

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.

 

Link to comment
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.

Link to comment
Share on other sites

  • 3 weeks later...

Interesting. Wonder who built this new one? The last one was developed by houselogix (which is shutting down). I reached out to them (which went to Snap because they own houselogix) to report the issue, and I had also reached out to Elk...

Sent from my SM-N960U using Tapatalk

Link to comment
Share on other sites

Looks like it goes from v2.0 to v2.2.  Not sure if that means that HouseLogix fixed the bugs, but it's the same driver with the following changes from the changelog:

v2.2
Fixed major bug regarding the deletion of zones during panel boot sequence.
Added Remove Zone action button to manually remove a zone from the panel.

v2.1
Handle Zone Changed event for bypassed zones.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.