Charmed Quark Systems, Ltd. - Support Forums and Community

Full Version: ELK V2 Driver - AreaArm field & Triggers?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Sorry for the pleathora of questions regarding the v2 drivers and 5.+ system.  I'm late to the game upgrading my system and feel like perhaps I missed out on the explainations. That being said.....

With the v1 Elk driver, I had a trigger on the AreaArm1 field.  This field changed with the arm status of the system.  So when I armed the system "Away" or "Vacation" or "Disarm", my CQC system would react to that and change thermostat set points, power on/off devices, etc.

With the V2 Elk driver, I don't see this field anymore.  Furthermore, I don't even see a way to add a trigger to the Area fields in the client side driver.  You can add triggers for the individual zones, but not an area.

Is there a method to accomplish what I was doing with the V1 driver with the V2 driver?  Currently I still have the V1 driver installed so that my triggers continue to work.  But obviously that is a little overkill and it would be nice to get rid of the duplicate driver.

OK. I guess I finally did something that made my ELK v2 driver reload (edit - I probably had not saved it until directed to when I tried to close it's tab), because now I see all the zones/areas that I set up in the client side driver. I understand that SEC#Area_XXXXXXXXXX_ArmMode will give me the functionality of the old AreaArm field. However, I still cannot see a way to set a trigger off that field. Is it unneccessary now to set a field to trigger, or is it more of an oversight that only zones can be triggered and not areas as well?
OK - after a little more exploring, I found the "Edit Trigger" button at the bottom of the driver tab. Obviously I can use this to add a trigger to the ArmMode field. So I have answered all of my initial questions....

However I do have one more question......what type of field should a glass break be set up as in the client side driver? I assume it works more like a motion detector, but there are only two choices - security and motion detector.
Ultimately, the difference between security and motion (as best I remember for this driver) is that motion just makes it a V2 motion field and it sends out a motion trigger. Security would make it a V2 zone status type field and that would send out zone status change triggers.

So presumably for a glass break it would be a security zone. If it ever was broken it would send out a security zone status trigger showing it not-ready/violated, which is probably what you'd want I guess.

For these two types of fields you wouldn't add a trigger. They send out standardized triggers. In the Admin Intf, under the /System section there's a tool in there to monitor what triggers are being sent as well, which helps with debugging.
The docs for the standard trigger types are under "/Reference/Events/Trigger Format" in the help.