MrGibbage
Super User
Joined: October 23 2006
Location: United States
Online Status: Offline
Posts: 513
|
| Posted: July 06 2007 at 21:45 | IP Logged
|
|
|
My (serial connected) Elk macros and triggers as of now. I have been playing with ver .11 for a few days now, and I thought I'd share some of my Elk macros in case anyone was having a hard time getting started. These may be some really basic things to some of you, but it took me a few days to really get my arms around these. First thing I would recommend is that you get your hands on the Elk RS-232 protocol guide. It really helped me, anyway. Next, make sure you have global options 40, "Transmit Keypad Keys", 30, "Zone Status Messages" and 35, "System Log Data" all turned on. There you go. Add your Elk as a controller as per the help file, and you should be getting your elk messages in PH. Finally, if you need to do some troubleshooting, it may help to get yourself a serial port monitor to see what PH is receiving. I got mine for free from Microsoft at http://www.microsoft.com/technet/sysinternals/ProcessesAndTh reads/Portmon.mspx.
My first three trigger are set up to know whenever the Elk passes something to PH. Here they are:
ELK_ARM_MSG; Elk Arming Status; Macro; STORE_ARM_STATUS; Generic Controller; Elk; Command 5; Option 1; 1
ELK_ARM_REQUEST; Arm/Disarm Requests; Macro; VALID_USER_CODE; Generic Controller; Elk; Command 4; Option 1; 1
ELK_LOG_UPDATE; Elk System Log Messages; Macro; ELK_LOG_MSG; Generic Controller; Elk; Command 1; Option 1; 1
The way these work (I am probably way oversimplifying these), are as follows:
I'll start with the easiest first. Any time a system log event occurs, it fires the ELK_LOG_UPDATE trigger. A whole bunch of data is passed over the [TEMP1]-[TEMP10] system variables. The most important one is [TEMP5]. That's where the event code is stored. The Elk RS-232 manual has all of the event codes listed. There are easily hundreds of them.
Next easiest to understand are the ELK_ARM_MSG triggers. Any time your elk changes status with respect to arming, including zone violations (and possbily including motion sensors, depending on how you have them configured), disarming, any type of arming event, entry and exit delays, and active alarm status, this trigger will fire. You will see a lot of these events in your PH log. The data is stored in the [TEMP5] and [TEMP10] variables which can easily be parsed out by area. By "area" I mean your Elk areas, which you may have up to eight of them. I only use one area, which has all of my zones in my house.
Finally, the ELK_ARM_REQUEST trigger is fired pretty much whenever a key is pressed on your keypads. It will notice when a valid use code has been entered and will return some information, but to be quite honest, I had a lot more luck using the system log and arm messages. In fact, I have this trigger disabled right now because I couldn't get it to do anything useful. Maybe if I play with it a little more, I can get some more elegant macros, but for now, my setup is working.
All right. So now we have some triggers that are passing a bunch of great information into PH, but what can we do with it? Well, first I'd like to turn off all of my lights when I arm my system to Away mode. Then I want to turn certain lights on when I come back home and disarm the system (assuming it is dark out).
Let's get the lights out first:
10 WAIT 2
20 Set Global; ELK_LOG_MSG5; "[TEMP5]"
60 GOTO Label; case ("[TEMP5]" when "1174" then "DISARMED" when "1173" then "ARMED" when "1239" then "ZONE_BYPASSED" when "1240" then "ZONE_UNBYPASSED" else "UNKNOWN")
70 Label DISARMED
80 Macro; DISARMED; Post
90 GOTO Label; "END"
100 Label ARMED
110 GOTO Label; case("{ARM_STATUS_PART1}" when "1" then "ARMED_AWAY" when "2" then "ARMED_STAY" when "3" then "ARMED_STAY_INSTANT" when "4" then "ARMED_NIGHT" when "5" then "ARMED_NIGHT_INSTANT" when "6" then "ARMED_VACATION" when "0" then "DISARMED_ERROR")
120 GOTO Label; "DISARMED ERROR"
130 Label; ARMED_AWAY
140 Macro; ARMED_AWAY; Post
150 GOTO Label "END"
.... (more macros just like this one)
310 Label DISARMED_ERROR
320 User Message; "DISARM Error status in ELK_LOG_MSG macro. TEMP5 = {ELK_LOG_MSG5}, ARM_STATUS_PART1 = {ARM_STATUS_PART1}"
330 Formula; Immediate; ph_sendsmtpemail("smtp.east.cox.net", 25, "xxx@domain.com", "xxx@domain.com", "DISARMED ERROR", "TEMP5 = {ELK_LOG_MSG5}. ARM_STATUS_PART1 = {ARM_STATUS_PART1}")
340 GOTO Label "END"
350 Label ZONE_BYPASSED
360 GOTO Label "END"
.... more things that can happen when you put different cases in line 60
390 Label UNKNOWN
400 User Message; "Unknown event number stored - {ELK_LOG_MSG5}"
410 Formula; Immediate; ph_sendsmtpemail("smtp.east.cox.net", 25, "xxx@domain.com", "xxx@domain.com", "Unknown Event Number", "Unknown event number stored - {ELK_LOG_MSG5}. Check the ELK_LOG_MSG Macro")
420 Label; END
Here's how this macro works. First I had to put a two second delay in processing this macro because if you think about it, when you arm your system, different messages and log events will happen pretty much simultaneously. I noticed that the log event would often hapen before the arm status had changed, and therefore wasn't able to figure out what type of arming status I had just armed my system to. Hence, the WAIT 2 in line 10. Line 20 just stores the [TEMP5] to a global variable. Next, we will go to different parts of the macro depending on the event number. In this case the Elk will log a "1173" which just says "ARMED" but doesn't say what type. Also not the ELSE "UNKNOWN" at the end of the case statement. You will see that I don't have every elk event number that exists in this case statement. I think I have the most common ones, but I'd still like to know when a new event number comes through, so I log it and send myself an email with the data. But in this case we got the "1173" so let's jump down to line 100. Line 110 is anothe case statement which checks a global variable {ARM_STATUS_PART1} This comes from the ELK_ARM_MSG trigger which executes the STORE_ARM_STATUS macro. Here's how the STORE_ARM_STATUS macro works
10 GOTO Label; if ("{ALARMSTATE_PART1}"=mid("[TEMP10]",9,1),2,1)
20 Label 1
30 Set Global; ALARMSTATE_PART1; mid("[TEMP10]",9,1)
40 Label 2
50 GOTO Label; if("{ARMUPSTATE_PART1}"=mid("[TEMP10]",1,1),4,3)
60 Label 3
70 Set Global; ARMUPSTATE_PART1; mid("[TEMP10]",1,1)
80 Label 4
90 GOTO Label; if("{ARM_STATUS_PART1}"=mid("[TEMP5]",1,1),6,5)
100 Label 5
110 Set Global; ARM_STATUS_PART1; mid("[TEMP5]",1,1)
120 Label 6
All I'm doing here is storing the Arm status to some global variables.
Back to turning the lights out. Line 110's case statement should send execution to the "ARMED_AWAY" label since it should contain a "1" at this point. We're getting close. We go to the ARMED_AWAY label on line 130, which simply executes a macro, surprisingly called "ARMED_AWAY" Here's my ARMED_AWAY macro
10 User Message; "Armed Away"
20 Wait 60
30 Insteon Group; GOODBYE; Fast Off
Line 10 just puts a note in the PH log. Line 20 puts a 60 second delay on turning off the lights because I don't want the lights to turn off until I leave the house. I have a 30 second exit delay on my Elk (the Elk Log trigger actually fires as soon as you arm the system. It doesn't wait for the exit delay to expire. You could also set up your triggers to look for that, but I went the low-tech route). And line 30 turns my lights off. Bada bing, bada boom.
I also put some lines in my DISARM macro to make sure I kill the ARM_AWAY macro if it is waiting. This works good because sometimes you arm your system, thinking you are about to walk out of the house, and then change your mind and disarm the system right away without even leaving. Well, if you don't kill the waiting macro to turn the lights off, then the lights will all go off while you are running through the house looking for your car keys and cell phone. So just put a ph_killmacrowait("ARMED_AWAY") in your DISARM macro and you won't have to worry about this.
The other cool Elk lighting thing that I've done is to turn the lights on in my garage for seven minutes whenever any of the garage doors are opened. Well, that's not quite accurate. What I really do is turn the lights on if any of the garage doors are opened. And if all three doors are closed, then turn the lights out after seven minutes. To do this, make sure your zones are all entered in the Analog IO setup section as per the Elk Help page in PH. Then just set up two triggers for each door: One that detects the zone opening, and one that detects it closing. In my case, that's a total of six triggers. Here's what the first two look like:
GARAGE_LIGHT_OFF1; Gar int door closed; Macro; GAR_LIGHTS_OFF; Multi-state In; GAR_INT; Trigger 9; 1
GARAGE_LIGHT_ON1; Gar int door opened; Macro; GAR_LIGHTS_ON; Multi-state In; GAR_INT; Trigger 3; 1
Then my two macros
GAR_LIGHTS_ON
10 formula; Immediate; ph_killmacrowait("GAR_LIGHT_OFF_MACRO")
20 Insteon; Garage Lights; FAST ON
GAR_LIGHTS_OFF
10 GOTO Label; if (ph_getmultistate("GAR_SIDE_DOOR")=3 and ph_getmultistate("GAR_DOOR")=3 and ph_getmultistate("GAR_INT_NON_ALM") = 3, "START", "END")
20 Label START
30 Wait 420
40 Insteon; Garage Lights; Fast Off
50 Label END
There you go. Enjoy and have fun.
Edited by MrGibbage - July 07 2007 at 08:46
|
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome Programming
Topic: Working with the Elk (RS-232) Tutorial
