Premise Elk M1 countdowns

[Shinyshoes]

I am trying to figure out where to find out how much time is left in the countdowns on my M1 and cant seem to find it.  When you arm the system, there is a configurable countdown timer until the system is armed so you have time to leave the house before it is set.  Similarly, there is a countdown timer from the time the alarm is triggered to the time the alarm sounds so you have time to get in and disarm the alarm.  
 
Is there somewhere in the object model I can see these timers?  I'm hoping to add some announcements to my whole house audio system as I only have 1 elk speaker and it is not audible everywhere.  It would make sense for me to utilize the existing speakers I have rather than buying a bunch more Elk speakers.  
 
Can anyone help?
 
Thanks in advance.

 

[mikefamig]

Entry and exit delays are set in the "AREAS" settings of elkrp2 or the keypad.
 
Mike.

 

[Shinyshoes]

I know where to set them in the Elk.  I'm wanting to pull the remaining time in them into Premise when they are triggered.

 

[mikefamig]

Sorry I don't know Premise.
 
EDIT - I didn't notice that this question was posted in the Premise forum - DUH.

 

[TurboSam]

I know very little about Premise, but I have the impression that those of you who use it must have a bit of familiarity with coding.  So.....
 
Check out the M1 232 ASCII Protocol Interface Specification, which is available on the Elk website (though you will probably need to log in) or PM me with your email.  In particular, it looks like the Arming Status Request described in Section 4.2.10 MIGHT return the information you need (See Section 4.2.11) and then you could figure out a way to port the relevant data (if, in fact, it is there) into Premise.
 
Good luck!

 

[TurboSam]

Attached is the data a 4.2.10 request returns, and you can see that it returns an exit time of 9 seconds in this example.

 

[chucklyons]

Rather than start a new thread....
 
Have my Elk M1 system up and runnning inthe new house. As I plug along on my quest of completing my version of the MB, I'm curious as to how others have implemented Areas vs Zones (Premise-ish). In Premise (if I am tracking correctly), there are zones and sensors. In Elk, there are Areas and Zones.
So I'm binding Premise sensors to Elk Zones; Binding a Premise zone to an Elk area doesn't appear to trigger anything if a Premise sensor in that Zone is tripped.
So, do you bind the Premise Zone to each Premise sensor? Seems kludgy, but maybe its my learning curve.
 
BTW, really nice job on the Elk M1 module, 123!!

 

[mikefamig]

I think that you can use Elk rules to accomplish what you want.
 
Whenever alarm is violated
turn on a phantom output for 10 seconds or as many seconds as you like
when that output turns off then voice some message to your speakers via premise
 
Mike.

 

[chucklyons]

Thanks, but not exactly what I am trying to accomplish. I guess my question is: What is the purpose of a Premise zone with an Elk security environment? Would I bypass a Premise zone and bypass all sensors (Elk zones) in the Premise Zone?

 

[123]

In the Reference Manual for the ELK M1 module, the top of page 24 contains instructions for using an Area. Basically, you bind it to a SecuritySystem object.
 
In my system, I've created several SecurityZones objects as children of the SecuritySystem object. I bound (binded?) each one of these SecurityZone objects to its (ELK M1) Zone counterpart in the driver.
 
SecuritySystem
   - FrontDoor -----------> ELK M1 Front Door
   - GarageDoor --------> ELK M1 Garage Door
 
In addition, I've added DoorSensor objects, in desired locations throughout Premise Home such as /home/house/first/foyer/frontdoor, and bound those objects to their associated (ELK M1) Zones. Therefore, a given door has two representations, once as a SecurityZone object and a second time as a DoorSensor object. Both are bound to the same ELK M1 Zone.
 
The reason why I've done that is because it allows me to see all the SecurityZones listed in one place, as children of the SecuritySystem object, and to see them in their logical location as members of a given building/floor/room.

 

[chucklyons]

Got it, thanks! My hesitation on the Area implementation was that in reading on Elk installations, a lot of folks were only using one or two areas, which didn't make sense to me. 
 
In "playing" (I mean my scientific and methodical analysis!) with the Premise Elk M1 and the Elk M1 system, your implementation is the one that makes the most sense. And from my UI version, that will give me a much better security overview.
 
LOL - I should have "RTFM - Read The Fabulous Manual"