+- Charmed Quark Systems, Ltd. - Support Forums and Community (https://www.charmedquark.com/vb_forums)
+-- Forum: General Discussion (https://www.charmedquark.com/vb_forums/forumdisplay.php?fid=3)
+--- Forum: Device Classification (https://www.charmedquark.com/vb_forums/forumdisplay.php?fid=14)
+--- Thread: Class: Security (/showthread.php?tid=8305)
Class: Security - Dean Roddey - 05-01-2013
- As of 5.3.926, changes were made to the security zone state definition as follows: It now includes a Bypassed state which can be set if the device supports it, else it will never be used. And, changes to Unknown state are now sent as triggers, which used to not be the case, since leaving a known state is important even if going to an unknown state is not.
General Description
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.
Fields Provided
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 as a field value, if the zone is not provably in one of the four standard states (Secure, Not Ready, Violated, Bypassed.)
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.
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.
Multi-Unit Considerations
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.
Class: Security - Dean Roddey - 05-01-2013
Backdoor Commands/Queries
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.
Via Query Text Value
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.
Event Triggers
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
Class: Security - Dean Roddey - 05-01-2013
(reserved for expansion 2)
Class: Security - Dean Roddey - 05-08-2013
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.
Class: Security - wuench - 05-09-2013
You need alarm status too. No much point of a security system if you can't tell when it is in alarm...
Class: Security - Dean Roddey - 05-20-2013
Took another whack at this one, with a lot more info. I think it's fairly complete now.
Class: Security - batwater - 05-20-2013
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
Class: Security - wuench - 05-20-2013
A zone can be one or more sensors, it depends on how they are wired to the panel.
Class: Security - Dean Roddey - 05-20-2013
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?
Class: Security - Dean Roddey - 05-20-2013
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.