Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Class: Security
#1
General Description
[INDENT]This thread is for discussion of the Security device class. Security devices will expose the follow basic information and functionality:
  • A list of areas and their current arming status and alarm status. Some will only have one area, some will have more than one or a configurable number.
  • A list of security zones and their current status (secure, violated, etc...)
  • Provide a means to arm and disarm each area
  • An indication of the alarms currently active in each area
  • Provide information about arming modes available, since these are too device specific to codify
  • Provide information about which zones are part of which areas
  • A command field that allows for formatted text commands of a more complex nature. Generally the driver will provide a number more than are required by this device class.

Each area is assumed to contain some number of zones. Each zone is tracking the state of something like a window or door, motion, fire, etc... and reports whether it is in a safe or unsafe state. An area can be armed or disarmed. If armed, then non-motion zones not being in a safe state is a very bad thing. If disarmed, it may or may not be a very bad thing. It could just be a window open, which is fine if the area is not armed.

Each device will support some set of 'arming modes' it can be put into, such as Stay, Away, Night, etc... It is not possible to require all devices to use a single set of arming modes, so they are free to define the modes they require. However, the disarmed mode MUST always be Off for consistency, and the first value in the arming mode fields' enumerated limits.
[/INDENT]

Fields Provided
[INDENT]It is assumed that generally area and zone related fields can be renamed by the user to something more meaningful to them, so no assumptions are made about the names, as long as they are in the form:

SEC#fieldname

where SEC# indicates it is a security class field, and fieldname meets the general requirements for field name syntax.
  • Area Alarm Fields. Area alarm fields are StringList type, read only. They MUST be in the form Area_X_Alarms, where X is the assigned name for that area. It is RECOMMENDED that the initial names assigned until/if the user customizes them just set X to the 1 based area number, no leading zeros, or to the device provided area names if available (though adjusted to legal field name requirements.) The value of the field is the list of alarms that are currently active for the area.
  • Area Alarm Status Fields. Area alarm status fields are Boolean type, read only. They MUST be in the form Area_X_InAlarm, where X is the assigned name for that area. It is RECOMMENDED that the initial names assigned until/if the user customizes them just set X to the 1 based area number, no leading zeros, or to the device provided area names if available (though adjusted to legal field name requirements.) This field MUST be true if there are any alarms active for the area, else False.
  • Area Arming Mode Fields. Area arming mode fields indicate the current arming mode of each area. They are String type, read only, and with an enumerated limit that indicates the possible arming modes. They MUST be in the form Area_X_ArmMode, where X is the area name. It is RECOMMENDED that the initial names assigned until/if the user customizes them just set X to the 1 based area number, no leading zeros, or to the device provided area names if available (though adjusted to legal field name requirements.) As per above, the disarmed value of the limits MUST be Off, and it must be the first value in the enumerated limit list.
  • Area Arming Fields. Some devices will not report the new arming mode until after an exit countdown has completed. I.e. if you arm, it gives you a certain amount of time to prepare for that before it actually goes into that armed mode. During that time, though it is not actually armed, you can do a disarm to cancel the arming operation. In order for CQC to know that the device, though not armed, is ok to disarm, this field can be set while in that intermediate state. It MUST be a Boolean field, and read-only. If the device just goes straight to the new arm mode, even during the countdown, there's no actual need to set this. Just leave it false. The new arm mode is sufficient.
  • Zone Status Fields. Zone status fields indicate the current status of security zones. These fields must be marked with the SecZoneStat semantic field type and conform to that type. The field names should be in the form Zone_X_Status, where X is the zone name. It is RECOMMENDED that the initial names assigned until/if the user customizes them just set X to the 1 based zone number, no leading zeros, or to the device provided zone name if available (though adjusted to legal field name requirements.)
  • InvokeCmd. The driver must provide an InvokeCmd field, which is a write only, write always, String field. This field will accept formatted commands for more complex operations that are not handled by regular field writes, which is basically all of them in the case of this device class, where all of the fields are read only. The commands that must be supported are listed below.

Note that the zone status semantic field type includes an Unknown value, which is often convenient to have a field value, if the zone is not provably in one of the three standard states (Secure, Not Ready, Violated.) However it's not valid as a Zone Alarm event trigger state. The CML driver base class' helpers that send Zone Alarm triggers will ignore the driver if it calls with the Unknown value.

Clients need to use both the arming mode and arming fields to determine if an area is armed or disarmed, from the perspective of what type of operation to present to the user. If the arming mode is not Off, then that's all you need to know. It's armed and you can do a disarm. If the arming mode is Off, you still must check the Arming field to see if it is in the process of arming. If the Arming mode is True, then you still must treat the area as armed and let the user disarm (to cancel the arming operation.)

InvokeCmd Field
The InvokeCmd field MUST support a specific set of commands, in this exact form. Drivers MUST be written so as to accommodate these commands and map them in the most appropriate manner to the native functionality.
[INDENT]ArmArea : aaa, mmm, ccc. This command will arm area aaa, using mode mmm, and using security code ccc.
DisarmArea : aaa, ccc. This command will disarm area aaa, using security code ccc.
[/INDENT]
[/INDENT]

Multi-Unit Considerations
[INDENT]There are no multi-unit considerations for these devices. Since all fields can generally be named by the user, and are on equal footing, they are treated as one big field name space for all of them. There is nothing in the zone field names, unless the user chooses to do so himself, that indicate which area they belong to. A command is available to query the zones for a specific area.
[/INDENT]
Dean Roddey
Software Geek Extraordinaire
Reply
#2
Backdoor Commands/Queries
[INDENT]In order to help get around the issues mentioned above with respect to the inability to really achieve full standardization of this device class, Security devices MUST support a set of backdoor queries which support the auto-generation system and allow it to get the information it requires to deal with the non-standardized aspects of these devices.[/INDENT]

[INDENT]Via Query Text Value
[INDENT]These are used to query security panel information that just can't really be fully standardized very easily, or that would be difficult or tedious to obtain via the regular field interfaces. The text value query takes two values the query type and the data name parameter indicates specifically what you are wanting to query. This information is used, for instance, by the auto-generation system to support native arming modes in the absence of a standard set of modes.

QSecPanelInfo/SecAreaList. Returns a list of area names, as a quoted comma list, so something like:

"GroundFloor", "SecondFloor", "Garage"

From this information, clients can present lists of areas, or create from these names the various area oriented fields, by appending these names onto the pre-defined area field name prefixes.

QSecPanelInfo/SecArmInfo. Returns information about the available arming modes. These are too varied to try to force a single list. So they must be queried and presented to the user. The returned value should be comma separated list of the arming modes available. DO NOT include disarm. That is a separate command, for instance:

Day, Night, Away, Vacation

QAreaZones/nnn. This one queryies all of the zones that are assigned to a given area, where nnn is the name of the area. The returned value is a quoted comma list of the zone names for all of the zones assigned to the area indicated. If the area doesn't exist the query should return false and an empty list. If it does, then it should return true and the list of zones (which might still be empty if none are assigned.) The caller can use these names for display, or use the names to generate any zone oriented field names by combining these base names with the predefined zone field name prefixes (though QAreaZStats below is a more convenient way to do that if that's all you need.)

QAreaZStats/nnn. This one queryies all of the zones that are assigned to a given area, where nnn is the name of the area. The returned value is a quoted comma list of the zone status fields for all of the zones assigned to the area indicated. If the area doesn't exist the query should return false and an empty list. If it does, then it should return true and the list of zones (which might still be empty if none are assigned.) Note that you could effectively get to this information by using QAreaZones above and building up the zone status fields from those, but this is often more convenient so it's nice to have the driver provide the field names already formatted out.

QAreaAlarms/aaa. Query the list of alarms for area aaa. There is a field with these, but that is just for simple display purposes. This will return the list as a quoted comma list that can be loaded directly into a list browser. If there are none active, just return true and an empty list.
[/INDENT][/INDENT]

Event Triggers
[INDENT]Security devices must support some standard event triggers, which are used to invoke triggered events in response to changes in the security system. If the device supports more than a fairly small number of zones, it is REQUIRED that the sending of these event triggers be configurable on a per-zone basis. This is used to avoid undue numbers of unneeded triggers being generated.

Security Zone Status. Any time the state of a security zone changes, the driver should (if configured to do so) send out a standard Zone Alarm event trigger.
[/INDENT]
Dean Roddey
Software Geek Extraordinaire
Reply
#3
(reserved for expansion 2)
Dean Roddey
Software Geek Extraordinaire
Reply
#4
I kind of got started but haven't finished yet. This one is going to be a tough one. It walks the line between needing to expose sufficient functionality and being a non-standard standard.

It may be that we really do standardize this guy, and anything beyond that has to be provided by driver specific stuff outside of the device class. Ultimately, I think that the system will be better served in the broader market by having a less functional but thoroughly transportable device class for security so that functionality based on it can be re-deployed against any compliant security system.

The auto-generation system is less constrained and can still make use of native arming modes and such, since it can generate separate logic for each possible security system configured. But in terms of hand generated logic and interfaces, it really makes a lot of sense to provide a portable representation of security systems, even if it ends up being fairly minimalistic.
Dean Roddey
Software Geek Extraordinaire
Reply
#5
You need alarm status too. No much point of a security system if you can't tell when it is in alarm...
Wuench
My Home Theater/Automation Website

[THREAD=5957]BlueGlass CQC Config[/THREAD]
[THREAD=10624]Wuench's CQC Drivers[/THREAD]
Reply
#6
Took another whack at this one, with a lot more info. I think it's fairly complete now.
Dean Roddey
Software Geek Extraordinaire
Reply
#7
Dean,

I'm trying to get my head wrapped around this in the context of my DSC alarm panel. I have multiple zones that contain multiple sensors. I can arm the whole house, a zone, multiple zones, etc. A zone can be a set of sensors that monitor for water or freeze conditions,they are handled differently as it is not a burglary fire, CO situation.

I'm not clear that I would have visibility to individual sensors within a zone. Am I missing something?

Thanks,
-Ben
Reply
#8
A zone can be one or more sensors, it depends on how they are wired to the panel.
Wuench
My Home Theater/Automation Website

[THREAD=5957]BlueGlass CQC Config[/THREAD]
[THREAD=10624]Wuench's CQC Drivers[/THREAD]
Reply
#9
Ultimately, the term 'zone' may be a little loose. It's effectively what the Elk or Omni consider a zone. That's really a single sensor, right? So I guess 'zone' doesn't mean a place, but zone in the sense of something being protected by a sensor. In which case you might have a Zone_MBRWind1_Status or something like that, to distinguish between one window and another.

I can't see how we can support *arming* individual zones. Ultimately only areas can be reasonably be armed in any way that would be portable to the Elk/Omni world, right? I can't imagine how it would be useful to arm a single zone.

Perhaps in the DSC they are calling a zone what Elk/Omni call an area?
Dean Roddey
Software Geek Extraordinaire
Reply
#10
Oh, and keep in mind, this device class only speaks to security oriented stuff. The same device can also have zones configured for others things, but they wouldn't be exposed via this device class, because they are not security zones. The driver would implement other device classes (or provide driver specific functionality in some cases) to expose those others things.

You have to be careful not to think in terms of one to one associations between device classes and the driver or device itself. Each device class may only expose a specific slice of functionality of a device. In some cases they are basically one to one, but for these types of devices, often not.
Dean Roddey
Software Geek Extraordinaire
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Class: Thermostat Dean Roddey 17 9,141 01-29-2016, 10:15 AM
Last Post: Dean Roddey
  Class: SceneCtrl Dean Roddey 20 3,777 03-31-2015, 12:38 PM
Last Post: Dean Roddey
  Class: Irrigation Dean Roddey 8 1,970 01-28-2015, 12:09 PM
Last Post: Dean Roddey
  Class: NowPlaying Dean Roddey 8 2,085 09-23-2014, 02:01 PM
Last Post: Dean Roddey
  Class: Switcher Dean Roddey 9 2,164 08-20-2014, 08:17 AM
Last Post: Dean Roddey
  Class: Projector Dean Roddey 29 4,490 08-11-2014, 08:56 AM
Last Post: Dean Roddey
  Class: Lock Dean Roddey 5 1,628 07-31-2014, 01:24 PM
Last Post: Dean Roddey
  Class: ContactClosure Dean Roddey 7 1,746 07-31-2014, 10:14 AM
Last Post: Dean Roddey
  Class: DIO Dean Roddey 7 2,042 07-31-2014, 10:08 AM
Last Post: Dean Roddey
  Class: Relay Dean Roddey 4 1,517 07-31-2014, 09:56 AM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)