Contact ID

Also known as Point ID.

Format

Contact ID has the following format:

Format CCCC FF QEEE GG UZZZ

• CCCC: Client Code
• FF: Indicates Contact ID format
• Q: Indicates if it is a New Alarm or a Restore event
• EEE: Event Code
• GG: Area (sometimes referred to as Group Code)
• ZZZ: Zone/User. (Interpretation depends on whether the Action Plan is set to Zone Info or User Info.)

Contact ID format can vary depending on receiver, Ademco can use either 18 or 98 format. Surgard can use either 18, 58 or 98 format. The most common format is 18 format.

Event codes are standard to Contact ID and are ideally set up as a standard Contact ID template client. If you have a standard template, whenever a Contact ID client is being added to the database, the template can be used instead of unnecessarily re-entering all the standard types. Event codes can be in either decimal format or hex format. The most common format is using Decimal Event codes, these will be used in their native form.

Decimal Format Events

Under contact ID the same event code can have two meanings, depending on whether it is a new alarm or a restore according to the Q indicator in the signal. If the event is a restore, Patriot adds the digit 1 in front of the event type number. For instance, if the closing event type happens to be 401, its corresponding restore code will be an opening. To distinguish the two as separate events, the restore or opening will become 1401.

Event	Alarm	Restore
Fire Alarm	110	1110
Burglary	130	1130
AC Loss	301	1301
Open/Close	400 (Opening)	1400 (Closing)

Examples:

1234 18 R401 02 U001

Here GG = 02. This will give a client account code of 1234-0002-01 (assuming a Port ID of 01).

1234 18 R401 03 U001

Here GG = 03, which will give a full account code of 1234-0003-01.

1234 18 E401 00 U001

This gives client code = 1234, type = 401, and zone/user = 1.

1234 18 R401 00 U001

This gives client code = 1234, type = 1401, and zone/user = 1.

Hex Format Events

Hex event codes will be converted to decimal format and incremented to prevent any overlapping. Event codes will be incremented by 5,000, restore codes will be incremented by 10,000, and repeat codes will be incremented by 15,000.

Examples:

1234 18 EBCE 00 U001

BCE in decimal format is 3022. This gives client code = 1234, type = 8022, and zone/user = 1.

1234 18 RBCE 00 U001

This gives client code = 1234, type = 13022, and zone/user = 1.

Module Numbers

By default Contact ID is handled in Patriot using a module number of 0 for all zones. This effectively means all event types share a common zone list. For example, if you receive 2 signals:

Event	Zone
Burglary (130)	1
Tamper(137)	1

They will both use the same zone record (Zone 1, Module No 0) in Patriot. This works in practice with most event types and zone combinations, but there are times when a particular zone means something different depending on the event type. It is common for alarm panels to have system zones defined which only apply to a particular event type. To cope with these situations, you need to either override the module number on the type, or change over to using Contact ID Expanded.

Both methods mean that the event type will now have a separate list of zones, on a different module number to the default of 0.

Contact ID Expanded

If you need to ensure that a particular zone only relates to a particular event type, then you need to use Contact ID expanded.

You can set individual event types to be treated as expanded, by setting the type records, module field to a value other than 0. Generally you set this to the same value as the type number for simplicity, but there are cases where you can set multiple types up with the same module number (see Restore handling below).

You can also set the Interpreter on the client to 'Contact ID Expanded'. This has the effect of treating all event types as expanded. But it doesn't allow you share the same module number across multiple event types.

With Contact ID Expanded set on the event type, Patriot will use a different module no for the event type received so it can potentially have a complete new sequence of zone numbers. This is done by setting the module number of the signal to a value other than 0. If the Contact ID interpreter is used, this sets the module number to the same value as the type number. If you change the module number from 0 in the event type record, this is the module number assigned.

For example: 1234 18 R130 00 U001

This gives:

• 1234: Client ID
• 130: Type No
• 130: Module No
• 1: Zone/User

Each new module number provides another 65000 zones that can be used. Zone No. 1 Module No. 1 is a completely different record from Zone No. 1 Module No 2.

A wildcard zone can also be entered, which works like a fall back if the specific zone is not found for a matching module. This is setup by checking the wildcard checkbox on a zone (sets the zone number value to 64000), and a specific module number, e.g. 130. Then if a signal is logged with an event type 130 (module 130), and zone 5, Patriot will attempt to find a zone 5, module 130. If this doesn't exist, it will search for the wildcard zone, module 130. This zone should have a generalised description that matches the event type. Wildcard zones are only used to stop a further search of the client's general zones on module 0, as discussed next.

If a matching zone still hasn't been found, Patriot will finally fall back to checking for a matching standard (module 0) zone. This allows you to setup only the few specific zones that need to be treated as expanded, and then fall back to the general zone list. As noted, you can also setup a wildcard zone to stop this behaviour for a particular type if required, which would be generally done in the zone template.

Patriot will work through the following sequence until a matching zone record is found.

1. Add-on templates checked first if used.
2. Client Zone with matching Zone No and Module No.
3. Client Zone with matching module no, and wildcard zone.
4. Zone Templates with matching Zone No and Module No.
5. Zone Templates with matching Module no, and wildcard zone.
6. Client General Zone, with matching Zone number, and Module number of 0.
7. Template General Zone with matching Zone number, and Module number of 0. Add-on templates checked first, then the regular zone template.

All searches on templates (steps 1, 4, 5, and 7) allow template chaining to two additional chained templates. So if the template itself has a template specified this template will also be searched.

If a matching zone record is found at any one of the first 4 steps above, it is treated as an expanded zone. The description of the signal then comes purely from the zone description. The type description is removed. This allows you to completely override the event type behaviour of a particular zone.

Zones assigned to a template have an additional option called Merge Client Zone. When a template zone with this option enabled is found (i.e. step 1, 4 or step 5 above), Patriot will continue to look for a client general zone with matching zone number (or matching Zone No Redirect if specified) and module number of 0 (i.e. step 6 above). If such a client zone is found then its zone description will be merged into the template zone's description and the result becomes the signal description. Any Action Plan or Action Plan Overrides on the merged client zone will also be applied. Use this feature in cases where you want the template zone description to always appear, and also include the general zone description if it has been entered.

In practice if you are supporting a large amount of Contact ID from a number of different panel manufacturers, it's suggested you use Contact ID expanded in all cases to keep things simple and standardised. But if you only setup the expanded zones where needed, and fall back to general zones in all other cases, this allows for all possible situations to be covered, with the least amount of data setup and duplication of data involved. Try to avoid using expanded zones in all cases as this will lead to a large amount of data being setup and in many cases unnecessarily.

Restore Handling

As the default behaviour of Contact ID expanded is to use a different set of zones per event type, then means the alarm event and the restore event will effectively report using different zones. For example an alarm of Type 130 will look for a zone with a module of 130, and the restore on the same zone will look for a zone on module 1130. So the zone would need to be setup twice. To avoid this situation of duplicated data setup you can set the module number of both event types to share the same module number. In the example above you would set both type 130, and 1130 to use a module number of 130. It's good to follow the standard of using the event type's type number for the module number. This solution is not possible if using the Contact ID Expanded Interpreter.

In many cases you will want to change the action plan of the zone so it's different from the event type. If you use this scheme and share the same module number for the restores, then you can't just set the action plan directly on the zone otherwise you will change the action plan of the restore as well. The solution here is to only override the action plan of the alarm events action plan using Zone Action Plan Overrides, and then the Restore event will be unaffected.

Here is an example of a common setup.

Contact ID Generic Template.

Event Type 140. General Alarm. Module 140. Action Plan Medium Priority Alarm.

Event Type 1140. Restore. Module 140. Action Plan Restore.

Panel Specific Zone Template.

Zone 900. Module 140. Panic Alarm. Action Plan Override 'Medium Priority Alarm' > 'Panic alarm'

Recommended Setup

Create a Patriot Template for each alarm panel you need to support which reports in Contact ID. Most templates are already available for download from the patriot website, and are setup using the following procedures.

Each Panel Template should have its event type template pointed to the same generalised Contact ID event type template. This generalised Contact ID template will have the full Contact ID event types loaded with the module number set in each type so all events are treated as expanded. It will also have all the Restore event module numbers set as per the Restore Handling section above. This generalised Contact ID Expanded template is available from the Patriot website for download.

In general most alarm panels will be able to use the same generalised Contact ID event types from the generalised Contact ID template. In some particular cases you may need to override a few event types for a particular panel. These can be entered directly into the Panel templates event types tab, which will override the generalised template.

Each Panel Template will have a different list of system events. These should all be configured using expanded zones and entered directly into the Panel Templates Zones tab. Using all of the features of Contact ID Expanded processing will allow the zone list in each panel template to be kept to a minimum.

Using the above setup, the data needed to be setup on a client is minimal. Use panel defaults to setup template assignments which makes the client setup much easier for operators. Generally only the standard zone list be need to be entered in, all on module 0. Try to keep client zone lists as small as possible and try to keep all panel related setup in the panel specific zone templates.

If you are using IP reporting devices, which clip onto standard alarm panels, use Add-on Templates to keep the add-on device templates separate from the alarm panel templates.

Concept Zone Mappings

When supporting a Concept alarm panels from Inner Range using Contact ID as the format, there are a number of standard templates to cover a variety of situations.

• Access 1
• Map 1
• School 19
• School 30
• Standard

Patriot has a pre-loaded template to cover each of these, available from the Templates page. These templates include both a types template and a zone template. No Types Interpreter is required when using any of these mappings. The zone templates maps the zone number to the appropriate module and individual zone.

An alternative to using the Zone Mappings, is to change to using IR Fast format.

SIMSII Mapping

When the panel is setup to report in Conact ID, with a SIMSII mapping, Patriot supports this using the CID SIMMS II interpreter, and the SIMSII Template, available from the Templates page.

The CID SIMMS II interpreter has the affect of setting the module number to a value of the Area number, plus the upper most (hundreds) digit of the zone number. The Zone number also gets set to the lower 2 digits of the original zone number.

So a signal with Type: 130, Zone 101, Area 6, gets translated into a Patriot signal of Type 130, Zone 1, Area 6, Module No of 106.

SIMSII By Zone Interpreter

There is also an extended way to handle SIMSII Mapping. This is the SIMSII By Zone Interpreter. The same translation occurs as per the standard SIMSII interpreter. Then the signal is logged using the By Zone feature, as if the Area code was set to By Zone. This allows the signal to be directed to the appropriate area. Note that opening and closing signals are excluded from this behaviour, as they report with the correct group code (area number). The SIMSII By Zone Interpreter also has the effect of treating system events as zone events i.e. type 145 is a system alarm, but in some cases this can also be a zone alarm. To differentiate between a type system alarm from zone alarm, we calculate the module number and find a zone with a matching module number. To calculate the module number we add the signal module number and type module number.

Signal: Type: 145, Zone: 101, Area: 0001 - Module calculated as 101 (100 from zone + 1 from Area).

Event Type: Type 145, Module: 1000.

Gets translated into a Patriot signal of Type: 145, Zone: 1, Area: 0001, Module: 1101

note

All system event types should ideally be on module 1000.