Cosec Panel200 API Guide
Cosec Panel200 API Guide
SECURITY SOLUTIONS
User Guide
Documentation Disclaimer
Matrix Comsec reserves the right to make changes in the design or components of the product as engineering and
manufacturing may warrant. Specifications are subject to change without notice.
This is a general documentation for all variants of the product. The product may not support all the features and
facilities described in the documentation.
Information in this documentation may change from time to time. Matrix Comsec reserves the right to revise
information in this publication for any reason without prior notice. Matrix Comsec makes no warranties with respect
to this documentation and disclaims any implied warranties. While every precaution has been taken in the
preparation of this system manual, Matrix Comsec assumes no responsibility for errors or omissions. Neither is any
liability assumed for damages resulting from the use of the information contained herein.
Neither Matrix Comsec nor its affiliates shall be liable to the buyer of this product or third parties for damages,
losses, costs or expenses incurred by the buyer or third parties as a result of: accident, misuse or abuse of this
product or unauthorized modifications, repairs or alterations to this product or failure to strictly comply with Matrix
Comsec operating and maintenance instructions.
Copyright
All rights reserved. No part of this system manual may be copied or reproduced in any form or by any means
without the prior written consent of Matrix Comsec.
Version 15.0
Release date: December 27, 2024
Contents
Table of Contents i
Events ........................................................................................................................................................... 81
Retrieving Events ............................................................................................................................................... 82
Retrieving Events in the TCP Socket ................................................................................................................. 85
Access Zone ................................................................................................................................................. 87
Sending Commands to Panel ..................................................................................................................... 89
IMEI Registration Request .......................................................................................................................... 93
Request for Security Code .......................................................................................................................... 95
To get Random Key on Code ...................................................................................................................... 97
Access Request on QR Scanning .............................................................................................................. 99
Access Policies .......................................................................................................................................... 103
Advanced Parameter for Access Route ........................................................................................................... 104
API Response Codes ................................................................................................................................. 105
Error Responses ........................................................................................................................................ 107
Appendix .................................................................................................................................................... 109
Event Configuration Reference ........................................................................................................................ 110
ii Table of Contents
List of Tables
Welcome to the COSEC Panel200 API User Guide. Using this document you can learn more about COSEC APIs,
browse through detailed descriptions of individual APIs and test them using sample scenarios.
Document Conventions
This API User Guide will follow a set of document conventions to make it consistent and easier for you to read.
These are as follows:
1. Text within angle brackets (e.g. “<request-type>”) denotes content in URL syntax and should be replaced
with either a value or a string. The angle brackets should be ommitted in all instances except those used to
denote “tags” within XML responses (e.g. “<name></name>”).
2. The term device used in this document, will refer only to Panel200 in standalone mode or otherwise
mentioned explicitly.
3. Any expression resembling <x~y>, indicates that the field should be repeated for index values x to index
values y. This is to avoid duplicating the same parameter for multiple index numbers.
4. Additional information about any section appears in the form of notices. The following symbols have been
used for notices to draw your attention to important items.
Important: to indicate something that requires your special attention or to remind you of
something you might need to do when you are using the system.
Caution: to indicate an action or condition that is likely to result in malfunction or damage to the
system or your property.
Warning: to indicate a hazard or an action that will cause damage to the system and or cause
bodily harm to the user.
Tip: to indicate a helpful hint giving you an alternative way to operate the system or carry out a
procedure, or use a feature more efficiently.
Topics 1 and 2 will provide a general understanding of COSEC Panel200 APIs and the basic interface
communication. Topic 3 provides a list of all supported APIs. Topics 4 provides detailed explanation of individual
APIs. The following information has been provided on each request type:
Topic 5 provides illustrations of error messages. Topic 6 provides a list of API Response Codes and their meaning.
The Appendix will provide additional material for the user’s reference.
For a list of all tables provided in the document, refer to List of Tables. Click on the links to view the
respective tables for the required data.
COSEC Devices APIs provide an interface for communication with COSEC Devices via HTTP methods. These
APIs will enable specific functions to be performed on your remote devices such as setting basic and advanced
device configurations, configuring users on device, performing enrollment of credentials, monitoring events and
sending commands to device. For a complete list of COSEC Device APIs, refer to Supported APIs.
How It Works
Following is an illustration of how the COSEC system typically communicates in a client-server based architecture.
However, here the communication with COSEC devices occurs via the COSEC Web server. On the other hand,
Devices APIs enable a client application to access and monitor a remotely installed COSEC device directly, without
installing the COSEC server/Monitor.
• Support some predefined parameters and their corresponding values for each action. Each parameter will
either be mandatory or bear a system-defined default value (when no value is specified).
• Use a mandatory parameter action universally, which takes action values (such as get, set, delete etc.)
and specifies the action to be requested.
• XML
• A Panel200 (pre-installed)
For information on installing a Panel200 and assigning an IP address to it, please refer to the respective
device documentation.
Authentication
The device shall request basic authentication for granting access. Default username and password for HTTP
session authentication are:
Username: admin
Password: password set on device
HTTP Request-Response
Basic HTTP communication is based on a request-response paradigm. The message structure for both request
and response has a generic format.
C os ec 3 rd party
D ev ic e s oftw are
R E S P O N S E: denied
R es pons e s tatus c ode ( 4x x ) along w ith s ugges tions of s upported
authentic ation m ethod
R E S P O N S E: denied
R es pons e s tatus c ode (4x x )
R E S P O N S E: s uc c es s ful
R eques ted M es s age body along w ith res pons e s tatus c ode i .e 2x x
4. In case of an error (invalid syntax, invalid authentication etc.), the request is denied and an error response
is returned. Else, the requested data is returned with the appropriate response code.
Request Format
All HTTP Requests follow a generic message format. It consists of the following components:
3 Empty Line This is an empty line separating headers from the message body.
Example:
Response Format
An HTTP response is a collection of lines sent by the server to the client. A generic HTTP response format will
resemble the following:
HTTP/1.0 200 OK
Date: Sat, 15 Jan 2000 14:37:12 GMT
Server: Microsoft-IIS/2.0
Content-Type: text/HTML
Content-Length: 1245
Last-Modified: Fri, 14 Jan 2000 08:25:13
GMT
HTTP Status Codes: Status codes are 3-digit numeric codes returned in HTTP responses that enable
recipients to understand the successful or failed status of the request issued. In general, codes in the 1xx
range indicate an informational message only, 2xx codes indicate a successful request, 3xx codes indicate
an incomplete request that requires further action, 4xx codes point at client-side errors while 5xx codes
point at server-side errors.
URL Syntax
All Panel200 APIs follow a common HTTP query syntax for the third party to generate a request. The generic URL
is stated below.
Syntax
http://<deviceIP:deviceport>/device.cgi/<request-type>?<argument>=<value>&<argument>=<value>......
This is a mandatory entity required to specify the CGI directory for all the
device.cgi
device-related commands.
This specifies the type of API request. For the mandatory request types,
<request-type>
please refer to the individual API descriptions.
Example
Let us assume that the target device has the IP address 192.168.x.y and the device port number is 80. The user
wants to fetch basic configured parameters for the device. In this case, a sample request would resemble the
following:
http://192.168.x.y:80/device.cgi/device-basic-config?action=get&format=xml
In this case, the query uses an action=get parameter which is commonly used to retrieve information from the
device-side. The URL takes another argument called format which specifies that the response returned should be
in the XML format.
• Special characters ( &, ‘, “, <, >, #, % and ;) will not be allowed in arguments or their values. Special
character “&” will be allowed as a separator between consecutive arguments and “?” will be allowed as
a separator between the request-type and an argument.
• The request line and headers must all end with <CR><LF> that is carriage return character followed by
a line feed character.
• The status line and header must all end with <CR><LF>.
• The empty line must consist of only <CR><LF> and no other white space.
Common Actions
The following actions are commonly used in COSEC APIs as values for the ‘action’ argument:
Action Use
Additional Information
• Generally, all the commands will be supported in the GET Method and hence the arguments and valid
values will be expected in the URL. Wherever applicable POST method will be specified explicitly. For the
POST method, the parameters must be included in the body of the HTTP request.
• To set blank values in a particular field, a blank can follow the “=”. E.g. “argument=&”
• If the format is not specified then by default, the values should be returned in text format.
• For all arguments other than ‘action’, the position in the URL may be changed.
COSEC APIs use basic authentication and can be tested on any standard Web browser. Enter the request
URL in the address field of your browser and press the ‘Enter’ key to send query to the device. Enter the
authentication credentials when prompted. The response will be displayed on your browser in the specified
format.
COSEC Devices support the following groups of APIs categorized on the basis of functions to be performed:
• Panel Configuration
• Panel Door Configuration
• User Configuration
• Enrollment
• Events
• Access Zone
• Sending Commands to Panel
• IMEI Registration Request
• Request for Security Code
• Access Request on QR Scanning
• To get Random Key on Code
This group of APIs enables users to perform the following types of Panel Door Configuration:
• Reader Configuration
• Commands
• Alarm Configuration
Actions: get
Syntax: http://deviceIP:deviceport/device.cgi/panel-door-list?action=get
Parameters: All arguments for this query and their corresponding valid values are listed below:
Parameters Description
Sample Request
http://deviceIP:deviceport/device.cgi/panel-door-list?action=get&format=xml
Sample Response
Content-Type: <type>
Content-Length: <length>
Body:
<COSEC_API>
<COSEC DOOR>
<pdid>1</pdid>
<door-name>test1-v3</door-name>
<door-type>12</door-type>
</COSEC DOOR>
<COSEC DOOR>
<pdid>2</pdid>
<door-name>test2-vega</door-name>
<door-type>9</door-type>
</COSEC DOOR>
<COSEC DOOR>
<pdid>3</pdid>
<door-name>test3-io</door-name>
<door-type>14</door-type>
</COSEC DOOR>
</COSEC_API>
Syntax: http://<deviceIP:deviceport>/device.cgi/panel-door-
config?<argument>=<value>[&<argument>=<value>....]
1 to 255(for Panel200), 1 to
pdid Yes To define the door id
75 (for Panel/Panellite v1)
1 - V1 Door
3 - V2 Door
6 - Compact Door (PATH
V1)
7 - PVR Door
9 - VEGA Door
11 - ARC DC100
door-type Yes To specify the door type
12 - V3 Door
14 - ARC IO800
16 - Path V2
17 - ARC DC200
19 - V4 DOOR
20 - ARGO
21 - ARGO FACE
0 = Inactive
active No To activate/deactivate the door
1 = Active
Yes
17 characters To specify the MAC address of the
mac-address Not Mandatory for
("A-F, a-f, 0 -9, : ") door.
RS485
0 = Un mute
mute-buzzer No To mute/unmute the door buzzer
1 = Mute
0- Inactive
door-sense No To enable/disable the door sense.
1- Active
Parameters Description
communication-type Defines the communication type of the door with the panel
Defines the MAC address of the door. Not mandatory if the communication type is
mac-address
defined as RS-485.
door-relay-unlock- Defines the output group number of the door for door relay for unlocking the door.
output-group-num
door-relay-lock-output- Defines the output group number of the door for door relay locking the door.
group-num
Defines whether the aux input of the door is enabled/disabled. Not applicable for door
aux-input
type=16,20 and 21.
Defines whether the supervised sense of the door is enabled/disabled. Not applicable
aux-input-supervised
for door type=16,20 and 21.
aux-input-sense-type defines the sense type of the aux input. Not applicable for door type=16,20 and 21.
debounce-time
defines the debounce time.Not applicable for door type=16,20 and 21.
(sec)
defines the aux output group number of the door. Not applicable for door type=16,20
aux-output-group-num
and 21.
duplicate-access-time-
To define the subsequent punch restriction time.
interval
For IO Controller, Valid Parameters are: action, pdid, door-name, door-type, active, communication-type,
ip-address, rs-485-address, mac-address, aux-input, aux-input-(2 to 8), aux-input-supervised, aux-input-
supervised-(2 to 8), aux-input-sense, aux-input-sense-(2 to 8), debounce-time, debounce-time-(2 to 8),
aux-output, aux-output-(2 to 8), aux-output-group-num, aux-output-group-num-(2 to 8), format
Syntax: http://<deviceIP:deviceport>/device.cgi/reader-config?action=<value>&<argument>=<value>….
Parameters: All arguments for this query and their corresponding valid values are listed below:
Table: Reader Configuration Parameters (All doors except COSEC ARC Controller)
0 = None
1 = EM Prox Reader
2 = HID Prox Reader To define the internal card
internal-card-reader No
3 = MiFare Reader reader.
4 = HID iCLASS-U Reader
5 = HID iCLASS-W Reader
0 = None
internal-biometric- To define the internal biometric
1 = Finger Reader No
reader reader.
2 = Palm Vein Reader
0 = None
1 = EM Prox Reader
2 = HID Prox Reader
3 = MiFare U Reader
4 = HID iCLASS-U Reader
5 = Finger Reader
To define the external reader.
6 = HID iCLASS-W Reader
Finger Reader (type=5) is not
7 = UHF Reader
external-reader No applicable for applicable for door
8 = Combo Exit Reader
type=16,20 and 21.
9 = MiFare-W Reader
10=PIN-W Reader
11=CB - U Reader
12=CB - W Reader
13=ATOM RD300
14=ATOM RD200
15=ATOM RD100
0 = Inactive
exit-switch No To activate exit switch.
1 = Active
Yes if action is
pdid 1 to 255 desired on To select the Panel door
Panel door
0 = None
1 = EM Prox Reader
2 = HID Prox Reader
3 = MiFare Reader
4 = HID iCLASS-U Reader To define the RS-485 reader in
rs-485-readergrp1 No
5 = Combo Reader reader1 group.
6 = CB - U Reader
7 = ATOM RD300
8 = ATOM RD200
9 = ATOM RD100
0 = None
1 = Short-Range Reader
2 = Long-Range Reader To define the Wiegand reader in
wiegand-readergrp1 No
3 = PIN Reader reader1 group.
4 = Card+ PIN W Reader
5 = CB - W Reader
0 = None
1 = EM Prox Reader
2 = HID Prox Reader
3 = MiFare Reader
4 = HID iCLASS-U Reader To define the RS-485 reader in
rs-485-readergrp2 No
5 = Combo Reader reader2 group.
6 = CB - U Reader
7 = ATOM RD300
8 = ATOM RD200
9 = ATOM RD100
0 = None
1 = Short-Range Reader
2 = Long-Range Reader To define the Wiegand reader in
wiegand-readergrp2 No
3 = PIN Reader reader2 group.
4 = Card+ PIN W Reader
5 = CB - W Reader
0 = 9600
To define OSDP 3rd Party
1 = 19200
Reader Baud Rate.
2 = 38400
baud-rate-readergrp1 No
3 = 57600
Note: This argument is
4 = 115200
applicable to ARC DC 200 only.
5 = 230400
0 = 9600
To define OSDP 3rd Party
1 = 19200
Reader Baud Rate.
2 = 38400
baud-rate-readergrp2 No
3 = 57600
Note: This argument is
4 = 115200
applicable to ARC DC 200 only.
5 = 230400
Example
1. To configure internal card reader as an HID Prox reader and internal reader mode as entry.
Sample Request
http://<deviceIP:deviceport>/device.cgi/reader-config?action=set&pdid=1&reader1=2&door-access-mode=0
Sample Response
HTTP Code: 200 OK
Content-Type: <type>
Content-Length: <length>
Body: Response-Code=0
Syntax: http://<deviceIP:deviceport>/device.cgi/door-commands?action=<value>&<argument>=<value>….
Parameters: All arguments for this query and their corresponding valid values are listed below:
Action=lockdoor
Parameters: All arguments for this query and their corresponding valid values are listed below:
Action=unlockdoor
Parameters: All arguments for this query and their corresponding valid values are listed below:
Parameters: All arguments for this query and their corresponding valid values are listed below:
Parameters: All arguments for this query and their corresponding valid values are listed below:
Action= disabledoorsense
Parameters: All arguments for this query and their corresponding valid values are listed below:
Action= normalizedoorsense
Parameters: All arguments for this query and their corresponding valid values are listed below:
Parameters: All arguments for this query and their corresponding valid values are listed below:
Action=clearbiometriccredentials
Parameters: All arguments for this query and their corresponding valid values are listed below:
Action= synccredentials
Parameters: All arguments for this query and their corresponding valid values are listed below:
Action= calibratefpsensor
Parameters: All arguments for this query and their corresponding valid values are listed below:
Action= activateauxrelay
Parameters: All arguments for this query and their corresponding valid values are listed below:
Action= deactivateauxrelay
Parameters: All arguments for this query and their corresponding valid values are listed below:
Action= clearfacecredentials
Parameters: All arguments for this query and their corresponding valid values are listed below:
Currently, the action= clearfacecredentials is applicable for ARGO FACE Door only and is not applicable for
Panel SDK1.
Syntax: http://<deviceIP:deviceport>/device.cgi/function-key?action=<value>&<argument>=<value>….
Parameters: All arguments for this query and their corresponding valid values are listed below:
F1 0 = None
1 = Official IN
F2
2 = Official OUT
F3 3 = Short Leave IN
4 = Short Leave OUT Assigning special functions to
5 = Regular IN No respective function keys.
6 = Regular OUT
F4 7 = Post Break IN
8 = Pre - Break OUT
9 = Overtime IN
10 = Overtime OUT
Example
Sample Request
http://<deviceIP:deviceport>/device.cgi/function-key?action=set&f1=1
Sample Response
HTTP Code: 200 OK
Content-Type: <type>
Content-Length: <length>
Body: Response-Code=0
Syntax: http://<deviceIP:deviceport>/device.cgi/multi-language-file-door?<argument>=<value>[&<argument>=<value>]
Parameters: All arguments for this query and their corresponding valid values are listed below:
Syntax: http://<deviceIP:deviceport>/device.cgi/alarm?<argument>=<value>[&<argument>=<value>….]
Parameters: All arguments for this query and their corresponding valid values are listed below:
1 to 255(for Panel200), 1
pdid to 75 (for Panel/Panellite Yes To define the door id
v1)
0- Inactive
door-fault-alarm No To enable/disable “Door Fault” alarm
1- Active
0- Inactive
panic alarm No To enable/disable “Panic” alarm
1- Active
0- Inactive
deadman-alarm No To enable/disable “Deadman” alarm
1- Active
0- Inactive
other-alarm No To enable/disable “Other” alarms
1- Active
Description: To set or retrieve configuration of face identification settings on the Panel Door.
Syntax: http://<deviceIP:deviceport>/device.cgi/fr-settings?<argument>=<value>[&<argument>=<value>….]
Parameters: All arguments for this query and their corresponding valid values are listed below:
Syntax: http://<deviceIP:deviceport>/device.cgi/face-mask?<argument>=<value>[&<argument>=<value>….]
Parameters: All arguments for this query and their corresponding valid values are listed below:
0- Soft
restriction No To select the Restriction type.
1- Hard
This group of APIs enables users to perform the following types of Panel Configuration:
• Enrollment Configuration
• Alarm Configuration
• Multi-Language Support
• Access Features
Syntax: http://<deviceIP:deviceport>/device.cgi/panel-basic-config?<argument>=<value>[&<argument>=<value>….]
Parameters: All arguments for this query and their corresponding valid values are listed below:
Alphanumeric,
name No To identify/configure the device name.
Max. 30 characters
where,
0 - 1 Finger
1 - 2 Fingers
2 - 3 Fingers
3 - 4 Fingers
4 - 5 Fingers
5 - 6 Fingers
6 - 7 Fingers
7 - 8 Fingers Maximum no. of finger templates that can
max-fingers No
8 - 9 Fingers be stored per user on this device.
9 - 10 Fingers
where,
0 - 1 Finger
1 - 2 Fingers
2 - 3 Fingers
3 - 4 Fingers
4 - 5 Fingers
0 - 1 Face
1 - 2 Faces
2 - 3 Faces
3 - 4 Faces
4 - 5 Faces
5 - 6 Faces
6 - 7 Faces
7 - 8 Faces
8 - 9 Faces
9 - 10 Faces
10 - 11 Faces
11 - 12 Faces
12 - 13 Faces
13 - 14 Faces
14 - 15 Faces Maximum no. of face templates that can
max-faces No
15 - 16 Faces be stored per user on this device.
16 - 17 Faces
17 - 18 Faces
18 - 19 Faces
19 - 20 Faces
20 - 21 Faces
21 - 22 Faces
22- 23 Faces
23 - 24 Faces
24- 25 Faces
25- 26 Faces
26- 27 Faces
27- 28 Faces
28- 29 Faces
29 - 30 Faces
0 - 1 Palm
1 - 2 Palms
2 - 3 Palms
3 - 4 Palms
Maximum no. of palm templates that can
4 - 5 Palms
max-palms No be stored per user on this device.
5 - 6 Palms
6 - 7 Palms
7 - 8 Palms
8 - 9 Palms
9 - 10 Palms
To get the default values for any parameter, use the action=getdefault method. To restore configuration
parameters on device to default values, use the action=setdefault method.
Parameters: All arguments for this query and their corresponding valid values are listed below:
Syntax: http://<deviceIP:deviceport>/device.cgi/panel-advanced-config?action=<value>&<argument>=<value>….
Parameters: All arguments for this query and their corresponding valid values are listed below:
generate-
0 - No To generate invalid user events when
invalid-user- No
1 - Yes invalid user is punched in.
events
generate-exit- 0 - No
No To generate exit switch events.
switch-events 1 - Yes
degrade- 0- Inactive
No To enable the access in degrade mode.
access 1- Active
degrade-
access-wait- 1 to 99 sec No To specify the degrade wait timer.
timer
Syntax:http://<deviceIP:deviceport>/device.cgi /enroll-options?<argument>=<value>[&<argument>=<value>….]
Parameters: All arguments for this query and their corresponding valid values are listed below:
Single Template/Finger: 0-
9
where,
0 = 1 Finger
1 = 2 Fingers
2 = 3 Fingers
3 = 4 Fingers
4 = 5 Fingers No. of fingers allowed to be enrolled in one
5 = 6 Fingers enrollment cycle.
6 = 7 Fingers
enroll-finger-count 7= 8 Fingers No Note: For the action=set method, this
8 = 9 Fingers value should not be greater than the max-
9 = 10 Fingers finger value set in Panel Device
Configuration API.
Dual Template/Finger: 0-4
where,
0 = 1 Finger
1 = 2 Fingers
2 = 3 Fingers
3 = 4 Fingers
4 = 5 Fingers
0 = 1 Palm
1 = 2 Palms
2 = 3 Palms
3 = 4 Palms
No. of palms allowed to be enrolled in one
4 = 5 Palms
enroll-palm-count No enrollment cycle.
5 = 6 Palms
6 = 7 Palms
7 = 8 Palms
8 = 9 Palms
9 = 10 Palms
0 = 1 Card
No. of special function cards allowed to be
1 = 2 Cards
enroll-card-count No enrolled in one enrollment cycle.
2 = 3 Cards
3 = 4 Cards
• If the temp-per-finger mode is changed, then the templates have to be restored to the device explicitly
by the third party software, else mismatch will occur in the module.
• If Single Template/Finger mode is selected on the device and some users are already enrolled
according to it and if abruptly the mode is changed to Dual Template/Finger then:
i. If the maximum finger count was greater than 5 fingers in Single Template/Finger mode, then after
changing the mode to the Dual Template/Finger, the finger count will set to 5.
ii. If the maximum finger count was less than 5 fingers in Single Template/Finger mode, then after
changing the mode to the Dual Template/Finger, the finger count will remain same.
• If the mode is changed back to Single Template/Finger, then finger count should not be changed. If
users want to increase the finger count they should mention it explicitly.
Syntax:http://<deviceIP:deviceport>/device.cgi /alarm?<argument>=<value>[&<argument>=<value>….]
Parameters: All arguments for this query and their corresponding valid values are listed below:
doorcontroller-offline- 0 = Inactive
No To enable or disable the alarm.
alarm 1 = Active
doorcontroller-fault- 0 = Inactive
No To enable or disable the alarm.
alarm 1 = Active
Parameters: All arguments for this query and their corresponding valid values are listed below:
0 = 24 hours
time-format No Note: This is applicable only for the
1 = 12 hours
time shown on the device display and
not for general date-time which will
always be in 24 hours format.
0 = ntp1.cs.wisc.edu
ntp-server 1 = time.windows.com No To define the NTP Address.
2 = time.nist.gov
Alphanumeric, Max. 40
user-defined-ntp No To define the user-defined NTP.
characters.
0 = Disable
dst-enable No To enable/disable DST.
1 = Enable
0 = January
1 = February
2 = March
3 = April
4 = May
5 = June
fwd-month
6 = July
7 = August
8 = September
9 = October
10 = November
11 = December
No Forward clock day
0 = 1st
1 = 2nd
fwd-week 2 = 3rd
3 = 4th
4 = Last
0 = Sunday
1 = Monday
2 = Tuesday
fwd-day 3 = Wednesday
4 = Thursday
5 = Friday
6 = Saturday
fwd-time-mm 00 - 59
0 = January
1 = February
2 = March
3 = April
4 = May
5 = June
rev-month No
6 = July
7 = August
8 = September Reverse clock day
9 = October
10 = November
11 = December
0 = 1st
1 = 2nd
rev-week 2 = 3rd No
3 = 4th
4 = Last
0 = Sunday
1 = Monday
2 = Tuesday
rev-day 3 = Wednesday No Reverse clock day
4 = Thursday
5 = Friday
6 = Saturday
rev-time-mm 00 - 59
• When user sets the time locally it should be GMT time. And in GET command also the time value to
be returned will be GMT time irrespective of the time displaying on the device.
• While configuring Daylight Saving Parameters, users are responsible to define the forward and
reverse time properly.
Auto Alarm Acknowledgement Timer Specifies the time period in seconds after which an unacknowledged
alarm will acknowledge itself automatically.
Inter Digit Wait Timer Specifies time period in seconds between two key inputs on the
device keypad. On the expiry of this timer, the system considers the
user input to be complete and is ready for the next input.
Multi Access Wait Timer Defines the time in seconds for which the system needs to wait for
the second credential input from a user when more than one
credential is required to grant access.
Palm Enrollment Time Out Timer Defines the time period in seconds within which a palm must be
enrolled after generating the enrollment command.
Door Abnormal Wait Timer Defines the time in seconds required for a door to be energized for a
valid credential. If the opened door does not return to its closed state
before the expiry of this timer, the door will generate a “Door
Abnormal Alarm”.
Special Function Timer Defines the time in minutes for which the Late-IN and Early-OUT special
functions will remain active after being enabled at the door controller.
Parameters: All arguments for this query and their corresponding valid values are listed below:
Use this API to enable, disable, define or retrieve Special Functions configuration on a device.
Syntax: http://<deviceIP:deviceport>/device.cgi/special-function?<argument>=<value>[&<argument>=<value>….]
Parameters: All arguments for this query and their corresponding valid values are listed below:
Syntax: http://<deviceIP:deviceport>/device.cgi/multi-language?<argument>=<value>[&<argument>=<value>….]
Parameters: All arguments for this query and their corresponding valid values are listed below:
Parameters: All arguments for this query and their corresponding valid values are listed below:
Description: To download/upload custom string file or download the sample file of the panel door
Parameters: All arguments for this query and their corresponding valid values are listed below:
Syntax: http://<deviceIP:deviceport>/device.cgi/access-feature?<argument>=<value>[&<argument>=<value>….]
Parameters: All arguments for this query and their corresponding valid values are listed below:
0 to 1
To enable/disable access route policy
access-route-enable No
0= Inactive on panel
1= Active
0 to 1
allow-access-not-in To enable/disable “Allow access while
No
route 0= Inactive not in Route” flag on panel
1= Active
This group of APIs enables users to add or delete users, set user photographs, add or fetch various configurations
related to users on or from a device as well as synchronize credentials with device. The following functions can be
called:
Syntax: http://<deviceIP:deviceport>/device.cgi/users?<argument>=<value>[&<argu-
ment>=<value>….]
Parameters: All arguments for this query and their corresponding valid values are listed below:
Yes (Not
To select the numeric user ID on
mandatory
ref-user-id Maximum 8 digits which the specified operation is
for the get
to be done.
action)
0 = Inactive
user-active No to activate or deactivate a user.
1 = Active
0 = Inactive
vip No Note: A VIP user is a user with
1 = Active
the special privilege to access a
particular door.
validity-date-dd 1-31 No
To define the end date for user
validity-date-mm 1-12 No
validity.
validity-date-yyyy 2000-2037 No
• To create a new user on device, both user-id and ref-user-id are mandatory parameters to be
provided, and these should be unique for each user.
• If a user is already configured in the system and admin wants to update the user with new
information/data, only Alphanumeric User ID is sufficient but if the reference user ID is also
mentioned then it would be verified whether this belongs to the same user or not.
• Whenever an event is generated related to a user, the required user ID field upon calling the event
will always show user’s reference user ID. Whereas if “Get” action is sent to call user configuration
then it will show alphanumeric user ID.
Example
Sample Request
http://deviceIP:deviceport/device.cgi/users?action=get&user-id=1&format=xml
Sample Response
HTTP Code: 200 OK
Content-Type: <xml>
Content-Length: <length>
Body:
<COSEC_API>
<user-id>1</user-id>
<user-index>0</user-index>
<ref-user-id></ref-user-id>
<name></name>
<user-active>0</user-active>
<vip>0</vip>
<validity-enable>0</validity-enable>
<validity-date-dd>1</validity-date-dd>
<validity-date-mm>1</validity-date-mm>
<validity-date-yyyy>2009</validity-date-yyyy>
<user-pin></user-pin>
<by-pass-finger>0</by-pass-finger>
<card1>0</card1>
<card2>0</card2>
</COSEC_API>
Actions: delete
Syntax: http://<deviceIP:deviceport>/device.cgi/users?action=delete&<argument>=<value>….
Parameters: All arguments for this query and their corresponding valid values are listed below:
Actions: set
Syntax: http://<deviceIP:deviceport>/device.cgi/credential?action=set&<argument>=<value>….
Parameters: All arguments for this query and their corresponding valid values are listed below:
1 = Finger
2 = Card
To define the user credentials
type 3 = Palm Yes
type.
4 = Palm template with guide mode
5 = Face Image
At a time only finger or palm or face can be get/set. All cannot be set at the same time. Also, multiple face
images cannot be set at a time.
For type=5, file size should be less than 200 KB and supported file format= jpg only.
Actions: get
Syntax: http://<deviceIP:deviceport>/device.cgi/credential?action=get&<argument>=<value>….
Parameters: All arguments for this query and their corresponding valid values are listed below:
1 = Finger
2 = Card
To define the user credentials
type 3 = Palm Yes
type.
4 = Palm template with guide mode
5 = Face Image
1 = 1 Finger
2 = 2 Finger
3 = 3 Finger
4 = 4 Finger
5 = 5 Finger
finger-index No
6 = 6 Finger
7 = 7 Finger
8 = 8 Finger
9 = 9 Finger Identifies the finger template/
10 = 10 Finger palm template is to be set or
retrieved from the device. The
1 = 1 Palm template will be set and retrieved
2 = 2 Palm from the data portion of the
3 = 3 Palm request and response.
4 = 4 Palm
5 = 5 Palm
palm-index 6 = 6 Palm No
7 = 7 Palm
8 = 8 Palm
9 = 9 Palm
10 = 10 Palm
11 = 11 Palm (Compressed)
1 = 1 Face
2 = 2 Face
3 = 3 Face
4 = 4 Face
5 = 5 Face
6 = 6 Face
7 = 7 Face
8 = 8 Face
9 = 9 Face
10 = 10 Face
11 = 11 Face
12 = 12 Face
13 = 13 Face
Identifies the face template to be
14 = 14 Face
set or retrieved from the device.
15 = 15 Face
face-index No The template will be set and
16 = 16 Face retrieved from the data portion of
17 = 17 Face
the request and response.
18 = 18 Face
19 = 19 Face
20 = 20 Face
21 = 21 Face
22 = 22 Face
23 = 23 Face
24 = 24 Face
25 = 25 Face
26 = 26 Face
27 = 27 Face
28 = 28 Face
29 = 29 Face
30 = 30 Face
• The Face Image uploaded should be less than 200 KB and in jpg format only.
• The set command is basically similar to adding and duplication of finger template will not be verified
by the device. It is expected to be handled by the 3rd party software.
• The method used in this case should be POST method as it consists of raw/ hex data in the data
portion of the request and the response.
• Finger/palm/Face index fields are not mentioned as mandatory fields because if user selects
credential type card then there is no need to specify the finger or palm index or Face index, similarly
if credential type is finger then palm index in not a mandatory field and vice versa.
• For type=5 (Face Image), only enrolled face image count will be displayed in response.
• Type=5 (Face Image) and face-index are not applicable for Panel SDK1.
Actions: delete
Syntax: http://<deviceIP:deviceport>/device.cgi/credential?action=delete&<argument>=<value>….
Parameters: All arguments for this query and their corresponding valid values are listed below:
For delete if type is All then card, biometric credentials and face images should be deleted.
Example
1. To delete finger templates of user id 1.
Sample Request
http://deviceIP:deviceport/device.cgi/credential?action=delete&user-id=1&type=1
Sample Response
Syntax: http://<deviceIP:deviceport>/device.cgi/photo?<argument>=<value>[&<argument>=<value>….]
Parameters: All arguments for this query and their corresponding valid values are listed below:
The Enrollment APIs can be used to generate an enrollment request for a device. Once the enrollment request is
successfully sent on the device, the device will initiate the enrollment process and request credentials to be
provided physically, as per the credential type and sequence specified.
Perform the enrollment function on a remote door controller using these enrollment APIs:
• Enrolling a User
• Enrolling Special Cards
Actions: enroll
Syntax: http://<deviceIP:deviceport>/device.cgi/enrolluser?action=enroll&<argument>=<value>….
Parameters: All arguments for this query and their corresponding valid values are listed below:
where,
0 = 1 Finger
1 = 2 Fingers
2 = 3 Fingers
3 = 4 Fingers
4 = 5 Fingers
department
• This is only to send enrollment command, if the credential is to be retrieved then it has to be
retrieved explicitly using the get and set credential command.
• By default, if count is not specified for enroll command then consider it as one and perform the
enroll operation.
• This enrollment has no links to the parameter configured on the device for “enroll through special
function”.
Example
Sample Request
http://deviceIP:deviceport/device.cgi/enrolluser?action=enroll&pdid=1&user-id=45&type=2&finger-count=2
Actions: enroll
Syntax: http://<deviceIP:deviceport>/device.cgi/enrollspcard?action=enroll&<argument>=<value>….
Parameters: All arguments for this query and their corresponding valid values are listed below:
sp-fn-id All configured Special Functions Yes Defines the special function
(special function ID) identification number.
Any action that occurs or is performed using a live COSEC device is referred on the COSEC system as an Event. A
client application can directly request event logs to be fetched from a specific device or be fed with live events data
via the device listening port. The functions available in this API group are as follows:
• Retrieving Events
• Retrieving Events in the TCP Socket
Actions: getevent
Syntax: http://<deviceIP:deviceport>/device.cgi/events?action=getevent&<argument>=<value>….
Parameters: All arguments for this query and their corresponding valid values are listed below:
no-of-events 1 to 5 (for Direct Door V2 and Path No Specifies the number of events to be
Controller) fetched.
1 to 100 (for all other Direct Doors)
• For different kind of events, different fields are required, to understand the functionality of an event,
which are denoted as Detail fields.
• The Detail field in the response depends on the type of device. For further information, refer to relevant
tables in the Event Configuration Reference (Appendix).
• For Panel200 will Firmware Version V1R66 and later, the Panel Door ID will also be sent in the
response for HTTP Events.
Example
Sample Request
http://panelip:port/device.cgi/events?action=getevent&roll-over-count=0&seq-number=10&format=xml
-<Events>
<roll-over-count>0</roll-over-count>
<seq-No>10</seq-No>
<pd-id>1</pd-id>
<date>30/05/2024</date>
<time>10:55:33</time>
<event-id>101</event-id>
<detail-1>1</detail-1>
<detail-2>0</detail-2>
<detail-3>10</detail-3>
<detail-4>0</detail-4>
<detail-5/>
<Events>
-<Events>
<roll-over-count>0</roll-over-count>
<seq-No>11</seq-No>
<pd-id>1</pd-id>
<date>30/05/2024</date>
<time>10:59:60</time>
<event-id>101</event-id>
<detail-1>1</detail-1>
<detail-2>0</detail-2>
<detail-3>20</detail-3>
<detail-4>0</detail-4>
<detail-5/>
<Events>
-<Events>
<roll-over-count>0</roll-over-count>
<seq-No>12</seq-No>
<pd-id>1</pd-id>
<date>30/05/2024</date>
<time>10:59:12</time>
<event-id>101</event-id>
<detail-1>1</detail-1>
<detail-2>0</detail-2>
<detail-3>40</detail-3>
<detail-4>0</detail-4>
<detail-5/>
<Events>
</COSEC_API>
• detail-3: It represents the credential used and the Access Mode of the Reader (Entry/Exit).
• Event with seq-No=10 and detail-3=10 denotes that PIN credential is used.
• Event with seq-No=11 and detail-3=20 denotes that Card credential is used.
• Event with seq-No=12 and detail-3=40 denotes that Finger credential is used.
The detail-3 value will be as per the credential used. For details, refer to Table: Field 3 Detail (User Events)
Reference* and Table: Information of Bit 4 to 14*.
Actions: getevent
Syntax: http://<deviceIP:deviceport>/device.cgi/tcp-events?action=getevent&<argument>=<value>….
Parameters: All arguments for this query and their corresponding valid values are listed below:
ipaddress 0 to 15 char ASCII 0-9,'.' Yes Defines the IP Address on which the
events are to be sent.
Sample Request
http://deviceIP:deviceport/device.cgi/tcp-events?action=getevent&ipaddress=192.168.102.42&port=80&roll-over-
count=0&seq-number=1
Sample Response
• The default TCP protocol acknowledgement should be used to send the next event. If in case any
event is missed in between, then it is the responsibility of the 3rd party to re-request for that event.
This shouldn’t be done via TCP port but missed events can be re-requested through HTTP API.
• If during the event transferring if reboot occurs then the prior command (to send events) will no
longer be valid and client must re-request events. In such a case, the events which have already
been sent, will be overwritten by the same.
• The user ID against which an event is stored must be the Reference ID for a user. This being
numeric (max. 8 digits), will enable efficient utilization of storage space on devices, especially those
having high event logging capacity (upto 5,00,000 events).
Access Zones are areas with well defined boundaries, which are defined to effectively implement an Access
Security System with Access Policies. A site can have multiple Access Zones, each Zone having multiple door
controllers. User needs to define the Access Zones before defining the door controllers and assigning the Access
Zones.
Syntax: http://<deviceIP:deviceport>/device.cgi/access-zone?<argument>=<value>[&<argument>=<value>….]
Argument Description
degrade-mode-type Defines the level of degrade mode access ie. Basic or Advance
http://<deviceIP:deviceport>/device.cgi/command?action=<value>&<argument>=<value>….
Get Current Event Sequence To get the current event sequence number
5 geteventcount
Number and roll over count in a device.
For valid values of this action, refer to the following argument-value table.
For action=getcount
For valid values of this action, refer to the following argument-value table.
user-id 1 to max. User ID in the door Yes Defines the numeric ID of the user
(2 bytes) whose data is to be fetched.
card-count Actual enrolled card count will be No To get the number of cards enrolled.
fetched.
finger-count Actual enrolled finger count will be No To get the count pass the
fetched. parameter as argument
palm-count Actual enrolled palm count will be No To get the count pass the
fetched. parameter as argument
face-count Actual enrolled face count will be No To get the count pass the
fetched. parameter as argument
• If no parameter is requested then all the count values will be returned by default (of supported
credential types e.g. for PVR door, only card and palm template count will be returned).
• Palm template count and finger template counts depend on the device type i.e. Palm template
count is only applicable for PVR doors and FP template counts are applicable for other devices. The
specified credential should be applicable for the device on which the command is sent.
For action=acknowledgealarm
For valid values of this action, refer to the following argument-value table.
For valid values of this action, refer to the following argument-value table.
Syntax= http://<deviceIP:deviceport>/device.cgi/command?action=resetaccesspolicy
For valid values of this action, refer to the following argument-value table.
user-id 15 Character ASCII Yes To select the user for which access
route access policy needs reset
Example
Following are some sample cases for your reference:
1. To get the current rollover count and sequence number of events in the device.
Sample Request
http://<deviceIP:deviceport>/device.cgi/command?action=geteventcount&format=xml
Sample Response
HTTP Code: 200 OK
Content-Type: <xml>
Body:
<COSEC_API>
<Roll-over-count>1</roll-over-count>
<seq-number>1</seq-number>
</COSEC_API >
To register the IMEI number of the user on COSEC Standalone Panel200, the IMEI Registration request is sent
from the COSEC APTA.
Description: To send IMEI Registration Request from COSEC APTA installed in mobile device.
Actions: set
Syntax: http://<deviceIP:deviceport>/device.cgi/imei-register?<argument>=<value>[&<argument>=<value>…...]
Parameters: All arguments for this query and their corresponding valid values are listed below:
40 characters
ABCDEFGHIJKLMNOPQ
RSTUVWXYZabcdefghijkl The imei through which the panel will
imei Yes
mnopqrstuvwxyz authenticate the user's mobile device.
1234567890 allowed
format xml - -
2.IMEI was already present against the user and 1 1= authorized to gain
auto register flag=1. (here the new IMEI received will access through API
be replaced with old IMEI)
2=not authorized to gain
3. The Device ID stored in IMEI field against the user access through API
matches with the Device ID received in Request API
(here the Device ID will be replaced by IMEI umber
once it matches)
*Note:
when code =1 ; it indicates the IMEI registration is successful
when code =2,3,4,5,6,7; it indicates the IMEI registration is not successful
To establish secured connection with the Panel200 through COSEC APTA after registering IMEI number of the
user.
Actions: get
Syntax: http://<deviceIP:deviceport>/device.cgi/security-code?<argument>=<value>[&<argument>=<value>…]
Parameters: All arguments for this query and their corresponding valid values are listed below:
format xml - -
2 bytes(2 char)
ABCDEFGHIJKLMNOPQ
security-code RSTUVWXYZabcdefghijkl As per configured in the panel
mnopqrstuvwxyz
1234567890
Description: To get a random key for particular user for secured access.
Actions: get
Parameters: All arguments for this query and their corresponding valid values are listed below:
15 characters
ABCDEFGHIJKLMNOPQ
The user ID (alphanumeric user ID) on
RSTUVWXYZabcdefghijkl
user-id Yes which the specified operation is to be
mnopqrstuvwxyz
done.
1234567890 and white
space allowed
format xml - -
Note:
• Whenever the received user id doesn't exist in the panel, response code13(user id not exists) will be sent.
• Whenever the access through API is not enabled in the panel, response code24 (Feature not enabled in
config) will be sent.
• Whenever the feature mobile access is not enabled for the received user id in the panel, response 24
(Feature not enabled in config) will be sent
• Whenever the door is offline, response code30 (Door Offline) will be sent.
To access COSEC device without biometric credentials is a new feature. You can access COSEC Panel doors
using COSEC APTA by QR scanning.
This API will be applicable with COSEC Server and Third Party Software also.
Actions: set
Syntax: http://<deviceIP:deviceport>/device.cgi/access-request-qr?<argu-
ment>=<value>[&<argument>=<value>….]
Parameters: All arguments for this query and their corresponding valid values are listed below:
Table: Group:access-request-qr
40 characters
ABCDEFGHIJKLMNOP
The imei through which the panel will
imei QRSTUVWXYZabcdefg Yes
authenticate the user’s mobile device.
hijklmnopqrstuvwxyz
1234567890 allowed
format xml - -
Waiting for second user -Occupancy Panel doors & Linux based
3 0
1st user identified direct doors
In above table:
route name 15 Char ASCII Code Yes To define the access route name
For valid values of this action, refer to the following argument-value table.
Action: get
For valid values of this action, refer to the following argument-value table.
These numerical codes will be returned with an API response. These response codes shall indicate the result of a
particular request made by the client. For e.g. the response code ‘0’ will indicate that the requested action was
performed successfully. Refer to the given table for a list of response codes and their meanings.
0 Successful -
On every set command for user API and set credential API,
8 Card ID exists
Set Special Function API
Event sequence number and roll over count not found, image
10 No Record Found not found, file not found.
No panel doors are added in panel
Template size/ format If the expected template size is not as per the required size,
11
mismatch format or any checksum error etc. in Set credential API
The enroll request is for smart card and the device has
proximity reader or if enroll request has palm template but door
Reader mismatch/
15 has finger reader and similar cases.
Reader not configured
If OSDP Reader is connected with ARC DC200 and if
enrollment type is other than Reader Only Card (type=0).
18 PIN already exists Set User API: PIN is already assigned to another user
Palm template mode In Set Credentials API, when palm template with particular
23
mismatch mode does not match with the selected mode.
26 Error in Import Data Import API if any of the import rules are violated
Whenever the value set for any parameter is not as per its field
type defined.
Whenever IP/MAC entered is not valid.
29 Invalid value
Whenever username/door name is set as blank.
Whenever the Pdid received in the API doesnot exists in the
panel.
These are some possible error response types obtained from incorrect API requests.
Sample Response
Sample Response
Sample Response
Sample Response
Sample Response
314 RTC
405 Enrolment
*The Events listed above is a consolidated list considering all the Doors. The events displayed will depend on the
Door Type and features supported.
Reply Event
Reply Event
Send Event
Send Event
This structure will be used to send events to CCC Server or when TCP Events API is fired.
(Field
(Field 1) 4)
(Field 2) (Field 3)
and
Event
ID Special
(Field Panel200/Panel/Panel-Lite/Standalone Panellite
Reference 5)
Code Entry/Exit
ID
Special
Detail
Xxxx Function
code
(Referenc
101 (Reference
e ID=0 for
ID=0 for (Reference
REX input)
REX input) ID=0 for
REX input)
Special
102 Xxxx Function
code
Detail
Special
103 Xxxx Function Detail
code
Special
104 Xxxx Function Detail
code
Special
105 Xxxx Function Detail
code
Special (Refe
rence
106 Xxxx Function Detail
ID=0
code
for
REX
Special input)
107 Xxxx Function Detail
code
Special
108 Xxxx Function Detail
code
Special
109 Xxxx Function Detail
code
Special
110 Xxxx Function Detail
code
0 = Door
unlock
112 Xxxx
1 = Door
Detail
lock
(Field
(Field 1) 4)
(Field 2) (Field 3)
and
Event
ID Special
(Field Panel200/Panel/Panel-Lite/Standalone Panellite
Reference 5)
Code Entry/Exit
ID
Special
Function
151 Xxxx
code
Detail
2=Door Not
in Sequence
for Smart
card based
165 Xxxx Route Detail
3=Door Not
in Smart
card based
Route
4=Credentia
l Invalid for
Smart card
based
Route
Access
(Field
(Field 1) 4)
(Field 2) (Field 3)
and
Event
ID Special
(Field Panel200/Panel/Panel-Lite/Standalone Panellite
Reference 5)
Code Entry/Exit
ID
0=Outside
working
hours
1=Holiday
3=Field
Break
4=Rest Day
1
Official Work-IN Marking in
1
T&A
2
Official Work-OUT Marking
2
in T&A
3
Short Leave-IN Marking in
3
T&A
4
Short Leave-OUT Marking
4
in T&A
6
Clock - OUT Marking in
6
T&A
7
Post Lunch-IN Marking in
7
T&A
8
Pre Lunch -OUT Marking
8
in T&A
9
Over time – IN Marking in
9
T&A
10
Over time – OUT Marking
10
in T&A
11
Late –IN Allowed Marking
11
in T&A
12
Early - OUT Allowed
12
Marking in T&A
14 Smart Identification 98
15 e-Canteen 97
Bit 15 Bit 14 Bit 13 Bit 12 Bit 11 Bit 10 Bit 9 Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Entry 0 0 0
Exit 0 1 1
Credential Bit 14 Bit 13 Bit 12 Bit 11 Bit 10 Bit 9 Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Value
PIN 0 0 0 0 0 0 0 0 0 0 1 1
Card 1 0 0 1 0 0 0 0 0 0 1 0 258
Finger 0 0 0 0 0 0 0 0 1 0 0 4
Finger + PIN 0 0 0 0 0 0 0 0 1 0 1 5
Finger + Card 1 +
0 0 1 0 0 0 0 0 1 1 1 263
PIN
Palm 0 0 0 0 0 0 0 1 0 0 0 8
PIN + Palm 0 0 0 0 0 0 0 1 0 0 1 9
PIN + Card 1 +
0 0 1 0 0 0 0 1 0 1 1 267
Palm
Group + Palm 0 0 0 0 0 0 1 1 0 0 0 24
API 0 0 0 0 0 1 0 0 0 0 0 32
API + Finger 0 0 0 0 0 1 0 0 1 0 0 36
API + Palm 0 0 0 0 0 1 0 1 0 0 0 40
API + Face 0 0 0 0 1 1 0 0 0 0 0 96
API + PIN 0 0 0 0 0 1 0 0 0 0 1 33
Group + Finger 0 0 0 0 0 0 1 0 1 0 0 20
Face 0 0 0 0 1 0 0 0 0 0 0 64
PIN + Face 0 0 0 0 1 0 0 0 0 0 1 65
Finger + Face 0 0 0 0 1 0 0 0 1 0 0 68
Palm + Face 0 0 0 0 1 0 0 1 0 0 0 72
BLE 1 0 0 1 1 0 0 0 0 0 0 0 384
BLE 2 0 1 0 1 0 0 0 0 0 0 0 640
Card 2 0 1 0 0 0 0 0 0 0 1 0 514
Finger + Card 2 +
0 1 0 0 0 0 0 0 1 1 1 519
PIN
PIN + Card 2 +
0 1 0 0 0 0 0 1 0 1 1 523
Palm
QR 1** 1 0 1 0 0 0 0 0 0 0 0 1280
QR 1 + PIN 1 0 1 0 0 0 0 0 0 0 1 1281
API + QR 1 1 0 1 0 0 1 0 0 0 0 0 1312
QR 1 + Face 1 0 1 0 1 0 0 0 0 0 0 1344
BLE 1 + QR 1 1 0 1 1 0 0 0 0 0 0 0 1408
BLE 2 + QR 1 1 1 1 1 0 0 0 0 0 0 0 1920
QR 2 1 1 0 0 0 0 0 0 0 0 0 1536
QR 2 + PIN 1 1 0 0 0 0 0 0 0 0 1 1537
API + QR 2 1 1 0 0 0 1 0 0 0 0 0 1568
QR 2 + Face 1 1 0 0 1 0 0 0 0 0 0 1600
BLE 1 + QR 2 1 1 1 1 0 0 0 0 0 0 0 1920
BLE 2 + QR 2 1 1 0 1 0 0 0 0 0 0 0 1664
Bit 15 Bit 14 Bit 13 Bit 12 Bit 11 Bit 10 Bit 9 Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Entry/
RFU BLE Face API Group Palm Finger Card PIN RFU RFU
Exit
Entry 0 0 0
Exit 0 1 1
Credential Bit 11 Bit 10 Bit 9 Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Value
PIN 0 0 0 0 0 0 0 1 1
Card 0 0 0 0 0 0 1 0 2
Card + PIN 0 0 0 0 0 0 1 1 3
Finger 0 0 0 0 0 1 0 0 4
Finger + PIN 0 0 0 0 0 1 0 1 5
Finger + Card 0 0 0 0 0 1 1 0 6
Finger + Card
0 0 0 0 0 1 1 1 7
+ PIN
Palm 0 0 0 0 1 0 0 0 8
PIN + Palm 0 0 0 0 1 0 0 1 9
Card + Palm 0 0 0 0 1 0 1 0 10
PIN + Card +
0 0 0 0 1 0 1 1 11
Palm
Group + Palm 0 0 0 1 1 0 0 0 24
API 0 0 1 0 0 0 0 0 32
API + Finger 0 0 1 0 0 1 0 0 36
API + Palm 0 0 1 0 1 0 0 0 40
API + PIN 0 0 1 0 0 0 0 1 33
Group + Finger 0 0 0 1 0 1 0 0 20
Face 0 1 0 0 0 0 0 0 64
Card + Face 0 1 0 0 0 0 1 0 66
PIN + Face 0 1 0 0 0 0 0 1 65
Finger + Face 0 1 0 0 0 1 0 0 68
Palm + Face 0 1 0 0 1 0 0 0 72
BLE 1 0 0 0 0 0 0 0 128
Pane
(Field
l200/
4) Direct Path Wirele Vega
Event NGT PVR Door ARGO ARC Pane
(Field 1) (Field 2) (Field 3) and Door Contro ss Contr ARGO
ID Door Door FMX FACE DC200 l/
(Field V2 ller Door oller
Pane
5)
l Lite
Alarm
301
Reference
ID Xxxx
1 = Critical
Seque-
nce
Number
302
Reference
ID Xxxx
1 = Critical
Same as
above
Pane
(Field
l200/
4) Direct Path Wirele Vega
Event NGT PVR Door ARGO ARC Pane
(Field 1) (Field 2) (Field 3) and Door Contro ss Contr ARGO
ID Door Door FMX FACE DC200 l/
(Field V2 ller Door oller
Pane
5)
l Lite
303
Reference
ID Xxxx
1 = Critical
Same as
above
304
1= Internal
2= External
3 = Minor
Same as
above
305 3 = Minor
Same as
above
Same as
306 2 = Major
above
307 1 = Critical
Same as
above
308 2 = Major
Same as
above
Same as
309 2 = Major
above
Same as
310 1 = Critical
above
311 2 = Major
Same as
above
312 1 = Critical
Same as
above
313 1 = Critical
Same as
above
1= Power
ON/OFF
Detected
(time not in
sync)
2 = Major
314 2= low 1 = Critical
Same as
above
battery
detected
3= RTC
Not
Detected
315
2 = Major
1 = Critical
Same as
above
First four Last two
317
bytes of
Extension
bytes of
extension
Same as
above
number number
318
Reference
ID Xxxx
2 = Major
Same as
above
319
Reference
ID Xxxx
2 = Major
Same as
above
320
Reference
ID Xxxx
2 = Major
Same as
above
321
Reference
ID Xxxx
2 = Major
Same as
above
322
Reference
ID Xxxx
2 = Major
Same as
above
323 2 = Major
Same as
above
324 2 = Major
Same as
above
325 2 = Major
Same as
above
326 2 = Major
Same as
above
Pane
(Field
l200/
4) Direct Path Wirele Vega
Event NGT PVR Door ARGO ARC Pane
(Field 1) (Field 2) (Field 3) and Door Contro ss Contr ARGO
ID Door Door FMX FACE DC200 l/
(Field V2 ller Door oller
Pane
5)
l Lite
327
Reference
ID Xxxx
2 = Major
Same as
above
328
Reference
ID Xxxx
2 = Major
Same as
above
329
Reference
ID Xxxx
2 = Major
Same as
above
4=
SysInterlo
ck
5=
User_Jeev Same as
351
es above
6=
User_AC
MS
9 = Auto
4=
SysInterlo
ck
5=
User_Jeev
Same as
352 es
above
6=
User_AC
MS
7= Special
Function
353
Same as
above
Panel200
/Panel/
(Field 4) Direct Path Vega Panel IO
Event Wireles NGT PVR Door
(Field 1) (Field 2) (Field 3) and Door Controlle Control Lite/ Control
ID s Door Door Door FMX
(Field 5) V2 r ler Standalo ler
ne Panel
lite
0= Unused
(Restore User)
1= Blocked
401
User ID:
xxxx
2=Unauthorize
d access 0= Restored
4=Invalid PIN
5= SA
402 6= SE
1=Success
0=Fail
7= Operator
Transact 1=Success
403 ion ID: 0=Fail
Xxxx
Guard
404
Tour no.
Xxxx +
1=Success
0=Fail
cycle no.
0= FP-1/Palm-1
1= Card1/FP-2/
8 = User Card Palm-2
10 = Special 3 = Card-3/FP-
Cards 4/Palm-
9= FP-10/Palm-
10
Panel200
/Panel/
(Field 4) Direct Path Vega Panel IO
Event Wireles NGT PVR Door
(Field 1) (Field 2) (Field 3) and Door Controlle Control Lite/ Control
ID s Door Door Door FMX
(Field 5) V2 r ler Standalo ler
ne Panel
lite
1=Normal
2=Fault (Open)
406
3= Fault(Short)
4= Activated
407
1=Normal
4=Activated
11 = Pulse
12 = Interlock
13 = Latch
I/O Link 15 = Toggle 1=Normal
408
ID (only with 4=Activated
activated
event)
8 = User Cards
5= Web Jeeves
9 = User
409 ID: Xxxx Fingers
6= ACMS
7= Special
14 = Palm
Function
Time
1=Normal/
Triggere
Deactivated
410 d
Function
4=Activated
Id
Time
1=Normal/
Stampin
411 g
Deactivated
Function
4=Activated
ID
Guard
412
tour no.
+cycle
Door Controller
sequence no.
1=Success
0=Fail
no.
event
413
sequenc
e
roll over count
1=Success
0=Fail
number
Configur
451
-ation
Table ID
Index start Index end
xxx
Roll over
452 number
00 to 99
453
Configur
454
-ation
Table ID
Index start Index end
xxx
Panel200
/Panel/
(Field 4) Direct Path Vega Panel IO
Event Wireles NGT PVR Door
(Field 1) (Field 2) (Field 3) and Door Controlle Control Lite/ Control
ID s Door Door Door FMX
(Field 5) V2 r ler Standalo ler
ne Panel
lite
Time
Period =
xxx
1= 2-person
(configur
Rule
ed
2= Access
value)
Policies
3= Alarms
(this field
4= Anti-pass
455
is used
only with
back
1= Overridden
0= Resumed
5= First In User
Overridd
6= Mantrap
en
7= Occupancy
events)
control
8= Visitor
Resume
Escort Rule
events
will have
blank
6 = from ACMS
457 8 = from
Hardware
0 = Internal
0 = Fail
Finger Reader
458
1 = Success
2 = Not
1 = External
Supported
Finger Reader
Referen
461 ce ID:
0 = Authorized
1 = Rejected
System User
Index 1 to 10
xxxx
Head Office:
394-GIDC, Makarpura, Vadodara - 390010, India.
Ph.:+91 265 2630555, +918511173344
E-mail: Tech.Support@MatrixComSec.com
Website: www.matrixcomsec.com