System integration examples
Entry manager
This part of the documentation describes how AXIS Entry Manager uses the access control APIs to set up and administrate an access control system.
The main intended audience of the AXIS Entry Manager sections are someone building an application that should be compatible with AXIS Entry Manager and that uses the access control APIs to administrate the door controller.
The access control APIs are flexible and there are often multiple ways to configure a given behavior. The AXIS Entry Manager has its strategy in how to use the API to configure specific behavior. By following the guidelines in this section, an application developer can build an application that will use AXIS Entry Manager compatible configuration.
Entry manager workflow
This section details some of the common use cases for the entry manager, listed roughly in the order in which they can be expected to be performed.
Configure device specific settings
This early setup step includes configuration of settings such as date and time, device IP address, and administrator password. Use appropriate API:s from the Network Video section in VAPIX®.
Hardware installation and configuration
Hardware configuration is the configuration of any hardware connected to a particular unit, such as readers, monitors, and locks. It consists of two steps:
-
Remove any old configuration.
-
Create a new configuration.
Both steps are handled by AXIS Entry Manager Hardware Configuration (HW Config).
The HW Config will remove and recreate API data structures related to doors and door monitors (Doors), locks and lock monitors (Locks and lock monitors), readers and REX devices (Id points – Readers and REX buttons), and I/O assignment (I/O assignment). This will affect access management as newly created doors will not permit any access, but will not affect users and groups directly.
Network door controllers in system
Network door controllers in system is the task of grouping devices together into a system of distributed units. Units are added using the aconn:AddPeers request and removed using the aconn:RemovePeers request, see Connection service for more details.
For a device in a distributed system, hardware installation and configuration can be done before or after the device is added to the system. Access management, which can be distributed, must be set up after the device is added to the system. This is due to the fact that the access management configuration of the system will override the exisiting configuration of the individual device when it is joined to the system.
Access management
Access management, e.g. who can pass through which door in a given way at a given time, is a complex subject. The APIs allow for considerable freedom on how to set up access rules. AXIS Entry Manager has one approach, an overview of which is provided in section Access management.
Entry manager examples
The following sections list a number of AXIS Entry Manager concepts and how AXIS Entry Manager uses data structures and requests.
Devices, controllers and units
Entry manager uses the terms ‘Device’, ‘Controller’, ‘Unit’, and ‘Network door controller’ to reference a physical door controller.
Devices can be joined together to form a distributed system.
API usage
The distributed system of units is managed using aconn:AddPeers and aconn:RemovePeers requests. A physical unit is modeled using the AccessController object, where:
Nameis used to identify units in the system.Descriptionis not used by AXIS Entry Manager.AccessPointobjects relate to the doors connected to the unit, for details see Doors.
Users and credentials
This section deals with the first type of user only, that is, a user may or may not have access to doors and represents, in most cases, a single physical person.
A user has one or more ID fields, which are used to identify the user. Two types of ID fields are supported by the entry manager:
- A four-digit PIN code.
- A card, identified by card number and/or card raw.
A user must have at least one ID field and only one ID field of each type is allowed. That is, a single user cannot have multiple cards for instance. If the administrator needs to support a physical person with multiple cards, that physical person must be modeled as two (or more) users.
Another exception to the "one user – one physical person" rule is the case where a door is opened with a PIN code known by several people. The administrator could then create a user for the PIN code and give that user access to the door, but the user will then represent not a single person but all persons using the PIN code. This situation is discussed in more detail in Access to a door using PIN only.
A user has a first name and a last name and may belong to zero or more groups.
API usage
A single user is modeled using axudb:User and pacsaxis:Credential, exactly one of each. The group memberships (if any) of a user, are modeled using CredentialAccessProfile in Credential.
Notes on User:
- The first name of the user is stored in an
AttributecalledFirstName. - The last name of the user is stored in an
AttributecalledLastName. - Name is a concatenation of the user’s names as "
LastName, FirstName". Descriptionis not used for anything.
Notes on Credential:
- There is exactly one
CredentialperUser.UserTokenis set to the token of the User. Descriptionis not used for anything.Enabledis set totrue.Statusis set to "Enabled".- Each credential has at least one
IdData, but not more than one of each type. - The PIN code, if present, is stored as an
IdDatawith Name set to "PIN". - The card number, if present, is stored as an
IdDatawith Name set to "CardNr". CredentialAccessProfileis used to list the groups the user belongs to. The user’s group membership are modeled usingCredentialAccessProfileobjects and groups usingAccessProfileobjects, see Groups. InCredentialAccessProfileobjects,ValidFromandValidToare never set and not used to limit access.AuthenticationProfileis not set.
Examples
Create a user The following requests create a user named Gordon Freeman with PIN 1234, and card number 12345678.
Request
{
"axudb:SetUser": {
"User": [
{
"Name": "Freeman, Gordon",
"Description": "",
"Attribute": [
{
"type": "string",
"Name": "FirstName",
"Value": "Gordon"
},
{
"type": "string",
"Name": "LastName",
"Value": "Freeman"
}
]
}
]
}
}
Request
<axudb:SetUser>
<axudb:User token="">
<axudb:Attribute type="string" Name="FirstName" Value="Gordon" />
<axudb:Attribute type="string" Name="LastName" Value="Freeman" />
<axudb:Description />
<axudb:Name>Freeman, Gordon</axudb:Name>
</axudb:User>
</axudb:SetUser>
Response
{
"Token": ["Axis-00408c184bd9:1350638010.566278000"]
}
Response
<Token>Axis-00408c184bd9:1350638010.566278000</Token>
Request
{
"pacsaxis:SetCredential": {
"Credential": [
{
"Enabled": true,
"Status": "Enabled",
"IdData": [
{
"Name": "PIN",
"Value": "1234"
},
{
"Name": "CardNr",
"Value": "12345678"
}
],
"CredentialAccessProfile": [],
"UserToken": "Axis-00408c184bd9:1350638010.566278000"
}
]
}
}
Request
<pacsaxis:SetCredential>
<pacsaxis:Credential token="">
<pacsaxis:Enabled>true</pacsaxis:Enabled>
<pacsaxis:IdData Name="CardNr" Value="12345678" />
<pacsaxis:IdData Name="PIN" Value="1234" />
<pacsaxis:Status>Enabled</pacsaxis:Status>
<pacsaxis:UserToken>Axis-00408c184bd9:1350638010.566278000</pacsaxis:UserToken>
</pacsaxis:Credential>
</pacsaxis:SetCredential>
Response
{
"Token": ["Axis-00408c184bd9:1350638011.004953000"]
}
Response
<Token>Axis-00408c184bd9:1350638011.004953000</Token>
Join a group The following is an example of the same user joining a group.
Request
{
"pacsaxis:SetCredential": {
"Credential": [
{
"Enabled": true,
"Status": "Enabled",
"IdData": [
{
"Name": "PIN",
"Value": "1234"
},
{
"Name": "CardNr",
"Value": "12345678"
}
],
"CredentialAccessProfile": [
{
"AccessProfile": "Axis-00408c184bd9:1350637958.280031000"
}
],
"UserToken": "Axis-00408c184bd9:1350638010.566278000",
"token": "Axis-00408c184bd9:1350638011.004953000"
}
]
}
}
Request
<pacsaxis:SetCredential>
<pacsaxis:Credential token="Axis-00408c184bd9:1350638011.004953000">
<pacsaxis:CredentialAccessProfile>
<pacsaxis:AccessProfile>Axis-00408c184bd9:1350637958.280031000</pacsaxis:AccessProfile>
</pacsaxis:CredentialAccessProfile>
<pacsaxis:Enabled>true</pacsaxis:Enabled>
<pacsaxis:IdData Name="CardNr" Value="12345678" />
<pacsaxis:IdData Name="PIN" Value="1234" />
<pacsaxis:Status>Enabled</pacsaxis:Status>
<pacsaxis:UserToken>Axis-00408c184bd9:1350638010.566278000</pacsaxis:UserToken>
</pacsaxis:Credential>
</pacsaxis:SetCredential>
Groups
In AXIS Entry Manager, a group is a set of users with access to certain doors at certain times.
For example, the group "Employees" has access to the door "Front door" at all times while the group "Consultants" only has access during "Office hours".
Note that a user being part of a group with access to a door does not necessarily mean that the user can access the door. For instance, the user must have the necessary type (or types) of IdData:s defined in its Credential and the door must be set up to allow access at the given time using those IdDatas. An overview of access management can be found in Access management.
API usage
A group is modeled in AXIS Entry Manager as an AccessProfile.
Note that this is currently the only use of AccessProfile in AXIS Entry Manager. AccessProfiles are flexible and can be used, for instance, to group doors together to simplify setting up a system where numerous doors share the same configuration. AXIS Entry Manager does not currently support this, and AccessProfile is used only for groups of users.
The access of a group is managed through a list of AccessPolicy structures where each structure refers to an AccessPoint object. Each AccessPoint represents an aspect of a door, e.g. a door which allows access in both directions will have one AccessPoint for going in, and one for going out. Doors shows how AccessPoint is used to model doors.
Notes on AccessProfile:
Nameholds the name of the group.Scheduleholds a list ofSchedulereferences for when the group is active (i.e. provides access), to see how the schedules are combined seeCombining schedules.- The optional fields
ValidFromandValidToare sometimes used to further limit the time the group is active. - The doors the group has access to are stored in
AccessPolicy. This field lists a number ofAccessPointobjects the group has access to. For a given door the group has access to, all theAccessPointobjects for that door are always included in the list. This means that for a door which allows passage both in and out, theAccessPointfor direction in and theAccessPointfor direction out must either both be present in the list, or none of them. For eachAccessPoint, there is also a list ofSchedulereferences indicating when the group has access to theAccessPoint. There is always exactly one schedule, "standard_always", denoting that the group always has access to theAccessPoint. Enabledis always set totrue.Descriptionis not used.AuthenticationProfileis always an empty list.
Examples
Create a Group The following creates a group which does not grant any access.
Request
{
"pacsaxis:SetAccessProfile": {
"AccessProfile": [
{
"Name": "Physicists",
"Description": "",
"Enabled": true,
"Schedule": [],
"AccessPolicy": [],
"Attribute": [],
"AuthenticationProfile": []
}
]
}
}
Request
<pacsaxis:SetAccessProfile>
<pacsaxis:AccessProfile token="">
<pacsaxis:AuthenticationProfile />
<pacsaxis:Description />
<pacsaxis:Enabled>true</pacsaxis:Enabled>
<pacsaxis:Name>Physicists</pacsaxis:Name>
<pacsaxis:Schedule />
</pacsaxis:AccessProfile>
</pacsaxis:SetAccessProfile>
Joining a Group See Examples.
Grant group access to door The following requests will give a group access to a door. Note that this does not necessarily mean that a user belonging to the group can open the door, see Access management for an overview of all the steps involved in setting up access.
Request
{
"pacsaxis:SetAccessProfile": {
"AccessProfile": [
{
"Name": "Physicists",
"Description": "",
"Enabled": true,
"Schedule": [],
"AccessPolicy": [
{
"Schedule": ["standard_always"],
"AccessPoint": "Axis-00408c184bd9:1350630875.789015000"
},
{
"Schedule": ["standard_always"],
"AccessPoint": "Axis-00408c184bd9:1350630876.738613000"
}
],
"Attribute": [],
"AuthenticationProfile": [],
"token": "Axis-00408c184bd9:1350644754.557727000"
}
]
}
}
Request
<pacsaxis:SetAccessProfile>
<pacsaxis:AccessProfile token="Axis-00408c184bd9:1350644754.557727000">
<pacsaxis:AccessPolicy>
<pacsaxis:AccessPoint>Axis-00408c184bd9:1350630875.789015000</pacsaxis:AccessPoint>
<pacsaxis:Schedule>standard_always</pacsaxis:Schedule>
</pacsaxis:AccessPolicy>
<pacsaxis:AccessPolicy>
<pacsaxis:AccessPoint>Axis-00408c184bd9:1350630876.738613000</pacsaxis:AccessPoint>
<pacsaxis:Schedule>standard_always</pacsaxis:Schedule>
</pacsaxis:AccessPolicy>
<pacsaxis:AuthenticationProfile />
<pacsaxis:Description />
<pacsaxis:Enabled>true</pacsaxis:Enabled>
<pacsaxis:Name>Physicists</pacsaxis:Name>
<pacsaxis:Schedule />
</pacsaxis:AccessProfile>
</pacsaxis:SetAccessProfile>
Doors
A door can have one or two locks, can be passed in two directions (in and out), can have zero or one reader and zero or one REX device in each of the two directions.
In AXIS Entry Manager, each direction of each door has an individual set of access rules specifying when the door can be accessed and what types of IdDatas are needed. For example, a door might require a card to pass into the building during office hours, and a card with a PIN code during all other hours. When leaving the building, only a card or a press of a REX device might be required.
A door can be scheduled to be locked, double locked (locked with two locks), or unlocked at certain times. For example, during night time it might be locked with two locks, but during day time only one lock is locked.
Note that AXIS Entry Manager does not allow doors to share common configuration, each door is configured individually.
Up to two doors per device are supported.
API usage
To model a door, AXIS Entry Manager uses the structures Door, DoorConfiguration, AccessPoint, AuthenticationProfile, DoorScheduleConfiguration and IoAssignment. IoAssignment:s are explained in I/O assignment, the others are explained below.
Each device supports up to two doors. Configuring a door includes creating the following objects:
- One
Doorobject. - One
DoorConfigurationobject. - One
AccessPointobject for each direction (in and out) which there are readers/REX devices that allow access in that direction. For example, a door with a reader allowing access going in and a REX device allowing access going out will require twoAccessPointsassociated with it. - Each
AccessPointis associated with zero or moreAuthenticationProfile:s indicating when it is possible to gain access to the door. For each type ofIdDatain credential (PIN, card, card and PIN, or REX) there is at most oneAuthenticationProfileobject perAccessPoint. - For each door, if the door is scheduled to be locked or unlocked according to a set of schedules, there exists one
DoorScheduleConfigurationobject. - I/O assignments for locks, monitors, etc., see I/O assignment.
Notes on DoorConfiguration:
-
Its token should match the token of the
Doorobject it corresponds to. -
The following items are set in the Configuration field:
-
-
DebounceTimeis set to "0". AXIS Entry Manager will work with other values, but will always set this value. -
DoorMonitor.ValueWhenOpenis set to "Input Open". AXIS Entry Manager will work with other values, but will always set this value. -
DoorMonitor.ValueWhenClosedis set to "Input Ground". AXIS Entry Manager will work with other values, but will always set this value. -
Other
Configurationitems are set according to what locks and door monitors are associated with the door, seeLocks and lock monitors for details.
-
-
DeviceUUIDis set by the device and left untouched by AXIS Entry Manager.
Notes on Door:
- Its token should match the token of the
DoorConfigurationobject it corresponds to. Nameis set to the name of the door.Descriptionis not used for anything.AccessTimeis set to "PT7S". AXIS Entry Manager will work with other values, but will always set this value.OpenTooLongTimeis set to "PT30S". AXIS Entry Manager will work with other values, but will always set this value.PreAlarmTimeis set to "PT10S". AXIS Entry Manager will work with other values, but will always set this value.ExtendedAccessTimeis set to "PT30S". AXIS Entry Manager will work with other values, but will always set this value.ExtendedOpenTooLongTimeis set to "PT60S". AXIS Entry Manager will work with other values, but will always set this value.HeartbeatIntervalis set to "PT600S". AXIS Entry Manager will work with other values, but will always set this value.PriorityConfigurationis not set. See Priority configurations for a discussion onPriorityConfigurationobjects.DefaultPriorityis set to "" which corresponds to the default priority. See Priority configurations for a discussion on priority levels.
Notes on AccessPoint:
- When creating an
AccessPoint, theAccessControllerobject representing the host device of the door must be updated with a reference to theAccessPoint. - Type is set to "
tdc:Door". Doors are the only type of access points handled by AXIS Entry Manager. Entityis set to the token of theDoorobject.Nameis set to the name of the door.Descriptionis not used by AXIS Entry Manager.Enabledis set totrue.Actionis set to "AccessDoor".ActionArgumentis not set.- As mentioned, for each door, up to two
AccessPointobjects are created. One for each direction (in/out) with a reader or a REX device. The direction is indicated on eachAccessPointby setting an itemDirectioninAttributeListto either "in" or "out". IdPointDeviceis used to list the readers/REX devices used to access the door in the given direction.DoorDeviceUUIDis the UUID of the door controller the door is connected to. This matches the value the device setsDeviceUUIDinDoorConfigurationto.AreaFromandAreaToare not used by AXIS Entry Manager.
Notes on AuthenticationProfile:
-
No more than one
AuthenticationProfileis ever created for each type ofIdData(PIN, card and PIN, card and REX) perAccessPoint. -
NameandDescriptionare not used by AXIS Entry Manager. -
Schedulelists the schedules for when the rules of theAuthenticationProfile:s applies, see Combining schedules for details on how the schedules are combined. -
IdFactor:s contains one or more items depending on what type of credentials are needed to access the door: -
-
If access should be granted using a PIN code without a card, one
IdFactoris created withIdDataNameset to "PIN",IdMatchOperatorNameset to "IdDataEqual", andOperatorValueset to "". -
If access should be granted using a card without a PIN code, one
IdFactoris created withIdDataNameset to "CardNr",IdMatchOperatorNameset to "IdDataEqual", andOperatorValueset to "". -
If access should be granted using a card in combination with a PIN, two
IDFactoritems are created. One withIdDataNameset to "PIN" and one withIdDataNameset to "CardNr". For bothIdFactoritems,IdMatchOperatorNameis set to "IdDataEqual" andOperatorValueis set to "". -
If access should be granted using a REX device, one
IdFactoris created withIdDataNameset to "REX",IdMatchOperatorNameset to "OperatorValueEqual", andOperatorValueset to "Active".
-
Notes on DoorScheduleConfiguration:
-
AXIS Entry Manager uses
DoorScheduleConfiguration:s for one purpose: to configure that the door is unlocked, locked, or double locked (locked with two locks) at certain times. -
For each door, there exists zero or one
DoorScheduleConfiguration.DoorScheduleConfigurationobjects are never shared between doors, the schedule for each door is configured individually. -
The
DoorScheduleConfigurationuses the same token as theDoorand theDoorConfiguration. This is to keep track of whichDoorScheduleConfigurationobjects to remove if the unit is reconfigured. When running the HW Config in AXIS Entry Manager, it will remove any old hardware configuration from the unit, including door schedule configurations. If aDoorScheduleConfigurationhas the same token as aDoorwhich is removed, theDoorScheduleConfigurationwill also be removed. -
NameandDescriptionare not used by AXIS Entry Manager. -
DoorScheduleis set to a door schedule without specifyingPriorityLevel, that is, the default priority level is used, see Priority configurations for a discussion on priority levels. The door schedule contains at leastoneScheduledState: -
-
ScheduledStateobjects haveEnterActionset to "Unlock", "Lock", or "DoubleLock". -
If multiple
ScheduledStateobjects are present, they are sorted according to their enter action, first "Unlock", then "Lock", then "DoubleLock". -
There is always at least one
ScheduledStatewith the maximum lock level available for the door. If the door has two locks this will be "DoubleLock", if the door has one door it will be "Lock". As per the sort order above, this will always be the lastScheduledStatein the list. ThisScheduledStateforms a baseline for the scheduling of the door and has always a singleScheduleTokenassociated with it, "standard_always".
-
Examples
Create a Door with a 12V lock and a reader going in The following requests will create a door with a 12V lock and a single reader for passing in through the door. Note the requests for setting up the reader and configure I/O assignments are not included, see I/O assignment and Schedules for details on how to do that.
Request
{
"axtdc:SetDoorConfiguration": {
"DoorConfiguration": [
{
"DeviceUUID": "",
"Configuration": [
{
"Name": "Lock.{LockWhenDoorOpens",
"Value": "false"
},
{
"Name": "DoorMonitor.ValueWhenOpen",
"Value": "Input Open"
},
{
"Name": "DoorMonitor.ValueWhenClosed",
"Value": "Input Ground"
},
{
"Name": "DoubleLock.Type",
"Value": "None"
},
{
"Name": "Lock.Type",
"Value": "Standard"
},
{
"Name": "Lock.ValueWhenLocked",
"Value": "Gnd"
},
{
"Name": "Lock.ValueWhenUnlocked",
"Value": "12V"
},
{
"Name": "Lock.BoltOutTime",
"Value": "0"
},
{
"Name": "Lock.BoltInTime",
"Value": "0"
}
]
}
]
}
}
Request
<axtdc:SetDoorConfiguration>
<axtdc:DoorConfiguration token="">
<axtdc:Configuration>
<ns0:Name>Lock.LockWhenDoorOpens</ns0:Name>
<ns0:Value>false</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>DoorMonitor.ValueWhenOpen</ns0:Name>
<ns0:Value>Input Open</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>DoorMonitor.ValueWhenClosed</ns0:Name>
<ns0:Value>Input Ground</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>DoubleLock.Type</ns0:Name>
<ns0:Value>None</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>Lock.Type</ns0:Name>
<ns0:Value>Standard</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>Lock.ValueWhenLocked</ns0:Name>
<ns0:Value>Gnd</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>Lock.ValueWhenUnlocked</ns0:Name>
<ns0:Value>12V</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>Lock.BoltOutTime</ns0:Name>
<ns0:Value>0</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>Lock.BoltInTime</ns0:Name>
<ns0:Value>0</ns0:Value>
</axtdc:Configuration>
<axtdc:DeviceUUID />
</axtdc:DoorConfiguration>
</axtdc:SetDoorConfiguration>
Response
{
"Token": "Axis-00408c184bd9:1350969415.227159000"
}
Response
<axtdc:Token>Axis-00408c184bd9:1350969415.227159000</axtdc:Token>
Request
{
"axtdc:SetDoor": {
"Door": [
{
"Name": "Front door",
"AccessTime": "PT7S",
"OpenTooLongTime": "PT30S",
"PreAlarmTime": "PT10S",
"ExtendedAccessTime": "PT30S",
"ExtendedOpenTooLongTime": "PT60S",
"HeartbeatInterval": "PT600S",
"DefaultPriority": "",
"token": "Axis-00408c184bd9:1350969415.227159000"
}
]
}
}
Request
<axtdc:SetDoor>
<axtdc:Door token="Axis-00408c184bd9:1350969415.227159000">
<axtdc:AccessTime>PT7S</axtdc:AccessTime>
<axtdc:DefaultPriority />
<axtdc:ExtendedAccessTime>PT30S</axtdc:ExtendedAccessTime>
<axtdc:ExtendedOpenTooLongTime>PT60S</axtdc:ExtendedOpenTooLongTime>
<axtdc:HeartbeatInterval>PT600S</axtdc:HeartbeatInterval>
<axtdc:Name>Front door</axtdc:Name>
<axtdc:OpenTooLongTime>PT30S</axtdc:OpenTooLongTime>
<axtdc:PreAlarmTime>PT10S</axtdc:PreAlarmTime>
<axtdc:PriorityConfiguration />
</axtdc:Door>
</axtdc:SetDoor>
Response
{
"Token": "Axis-00408c184bd9:1350969415.227159000"
}
Response
<axtdc:Token>Axis-00408c184bd9:1350969415.227159000</axtdc:Token>
Request
{
"pacsaxis:SetAccessPoint": {
"AccessPoint": [
{
"Type": "axtdc:Door",
"Name": "Front door",
"Enabled": true,
"Action": "AccessDoor",
"Entity": "Axis-00408c184bd9:1350969415.227159000",
"Attribute": [
{
"Name": "Direction",
"Value": "in"
}
],
"IdPointDevice": [
{
"IdPoint": "Axis-00408c184bd9:1350969415.294313000"
}
],
"AuthenticationProfile": [],
"DoorDeviceUUID": "5581ad80-95b0-11e0-b883-00408c184bd9"
}
]
}
}
Request
<pacsaxis:SetAccessPoint>
<pacsaxis:AccessPoint token="">
<pacsaxis:Action>AccessDoor</pacsaxis:Action>
<pacsaxis:Attribute Name="Direction" Value="in" />
<pacsaxis:AuthenticationProfile />
<pacsaxis:DoorDeviceUUID>5581ad80-95b0-11e0-b883-00408c184bd9</pacsaxis:DoorDeviceUUID>
<pacsaxis:Enabled>true</pacsaxis:Enabled>
<pacsaxis:Entity>Axis-00408c184bd9:1350969415.227159000</pacsaxis:Entity>
<pacsaxis:IdPointDevice>
<pacsaxis:IdPoint>Axis-00408c184bd9:1350969415.294313000</pacsaxis:IdPoint>
</pacsaxis:IdPointDevice>
<pacsaxis:Name>Front door</pacsaxis:Name>
<pacsaxis:Type>axtdc:Door</pacsaxis:Type>
</pacsaxis:AccessPoint>
</pacsaxis:SetAccessPoint>
Response
{
"Token": ["Axis-00408c184bd9:1350969417.922694000"]
}
Response
<Token>Axis-00408c184bd9:1350969417.922694000</Token>
Request
{
"pacsaxis:SetAccessController": {
"AccessController": [
{
"Name": "Axis-00408c184bd9 AccessController",
"Description": "",
"token": "Axis-00408c184bd9 AccessController",
"AccessPoint": ["Axis-00408c184bd9:1350969417.922694000"]
}
]
}
}
Request
<pacsaxis:SetAccessController>
<pacsaxis:AccessController token="Axis-00408c184bd9 AccessController">
<pacsaxis:AccessPoint>Axis-00408c184bd9:1350969417.922694000</pacsaxis:AccessPoint>
<pacsaxis:Description />
<pacsaxis:Name>Axis-00408c184bd9 AccessController</pacsaxis:Name>
</pacsaxis:AccessController>
</pacsaxis:SetAccessController>
Preparing Access to a Door using Card and PIN Configuring access to a door involves several steps, the requests below will configure a door so that it can be accessed at all times using card and PIN by a user belonging to a group with valid access to the specified door. See Access management for an overview of all the steps involved in setting up access. Create an AuthenticationProfile:
Request
{
"pacsaxis:SetAuthenticationProfile": {
"AuthenticationProfile": [
{
"Name": "",
"Description": "",
"Schedule": ["standard_always"],
"IdFactor": [
{
"IdDataName": "CardNr",
"IdMatchOperatorName": "IdDataEqual",
"OperatorValue": ""
},
{
"IdDataName": "PIN",
"IdMatchOperatorName": "IdDataEqual",
"OperatorValue": ""
}
]
}
]
}
}
Request
<pacsaxis:SetAuthenticationProfile>
<pacsaxis:AuthenticationProfile token="">
<pacsaxis:Description />
<pacsaxis:IdFactor>
<pacsaxis:IdDataName>CardNr</pacsaxis:IdDataName>
<pacsaxis:IdMatchOperatorName>IdDataEqual</pacsaxis:IdMatchOperatorName>
<pacsaxis:OperatorValue />
</pacsaxis:IdFactor>
<pacsaxis:IdFactor>
<pacsaxis:IdDataName>PIN</pacsaxis:IdDataName>
<pacsaxis:IdMatchOperatorName>IdDataEqual</pacsaxis:IdMatchOperatorName>
<pacsaxis:OperatorValue />
</pacsaxis:IdFactor>
<pacsaxis:Name />
<pacsaxis:Schedule>standard_always</pacsaxis:Schedule>
</pacsaxis:AuthenticationProfile>
</pacsaxis:SetAuthenticationProfile>
Response
{
"Token": ["Axis-00408c184bd9:1350970418.654225000"]
}
Response
<Token>Axis-00408c184bd9:1350970418.654225000</Token>
Update AccessPoint to use the new AuthenticationProfile:
Request
{
"pacsaxis:SetAccessPoint": {
"AccessPoint": [
{
"EntityType": "axtdc:Door",
"Name": "Front door",
"Enabled": true,
"Action": "AccessDoor",
"AuthenticationProfile": ["Axis-00408c184bd9:1350970418.654225000"],
"Entity": "Axis-00408c184bd9:1350969415.227159000",
"Attribute": [
{
"type": "",
"Name": "Direction",
"Value": "in"
}
],
"IdPointDevice": [
{
"IdPoint": "Axis-00408c184bd9:1350969415.294313000",
"DeviceUUID": ""
}
],
"token": "Axis-00408c184bd9:1350969417.922694000",
"Description": "",
"DoorDeviceUUID": "5581ad80-95b0-11e0-b883-00408c184bd9"
}
]
}
}
Request
<pacsaxis:SetAccessPoint>
<pacsaxis:AccessPoint token="Axis-00408c184bd9:1350969417.922694000">
<pacsaxis:Action>AccessDoor</pacsaxis:Action>
<pacsaxis:Attribute Name="Direction" Value="in" />
<pacsaxis:AuthenticationProfile>Axis-00408c184bd9:1350970418.654225000</pacsaxis:AuthenticationProfile>
<pacsaxis:Description />
<pacsaxis:DoorDeviceUUID>5581ad80-95b0-11e0-b883-00408c184bd9</pacsaxis:DoorDeviceUUID>
<pacsaxis:Enabled>true</pacsaxis:Enabled>
<pacsaxis:Entity>Axis-00408c184bd9:1350969415.227159000</pacsaxis:Entity>
<pacsaxis:IdPointDevice>
<pacsaxis:DeviceUUID />
<pacsaxis:IdPoint>Axis-00408c184bd9:1350969415.294313000</pacsaxis:IdPoint>
</pacsaxis:IdPointDevice>
<pacsaxis:Name>Front door</pacsaxis:Name>
<pacsaxis:Type>axtdc:Door</pacsaxis:Type>
</pacsaxis:AccessPoint>
</pacsaxis:SetAccessPoint>
Schedule a Door to be Unlocked During Office Hours The following request creates a schedule for office hours (09:00-17:00 Monday-Friday), see Schedules for more information about schedules.
Request
{
"axschSetSchedule": {
"Schedule": [
{
"Name": "Office hours",
"Description": "",
"ScheduleDefinition": "BEGIN:VCALENDAR\r\nPRODID:\r\nVERSION:2.0\r\nBEGIN:VEVENT\r\nSUMMARY:9 to 5\r\nDTSTART:20000103T090000\r\nDTEND:20000103T170000\r\nRRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR\r\nDTSTAMP:20121023T070313\r\nUID:b12275a419c40609\r\nEND:VEVENT\r\nEND:VCALENDAR\r\n",
"ExceptionScheduleDefinition": "",
"Attribute": []
}
]
}
}
Request
<axschSetSchedule>
<axschSchedule token="">
<axschDescription></axschDescription>
<axschExceptionScheduleDefinition></axschExceptionScheduleDefinition>
<axschName>Office hours</axschName>
<axschScheduleDefinition>BEGIN:VCALENDAR

PRODID:

VERSION:2.0

BEGIN:VEVENT

SUMMARY:9 to 5

DTSTART:20000103T090000

DTEND:20000103T170000

RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR

DTSTAMP:20121023T070313

UID:b12275a419c40609

END:VEVENT

END:VCALENDAR

</axschScheduleDefinition>
</axschSchedule>
</axschSetSchedule>
Response
{
"Token": ["Axis-00408c184bd9:1350975752.527366000"]
}
Response
Create the DoorScheduleConfiguration (using the same token as the door) and update the DoorConfiguration to reference the new DoorScheduleConfiguration:
Request
{
"axtdc:SetDoorScheduleConfiguration": {
"DoorScheduleConfiguration": [
{
"DoorSchedule": [
{
"ScheduledState": [
{
"ScheduleToken": ["Axis-00408c184bd9:1350975752.527366000"],
"EnterAction": "Unlock"
},
{
"ScheduleToken": ["standard_always"],
"EnterAction": "Lock"
}
]
}
],
"token": "Axis-00408c184bd9:1350976375.337548000"
}
]
}
}
Request
<axtdc:SetDoorScheduleConfiguration>
<axtdc:DoorScheduleConfiguration token="Axis-00408c184bd9:1350976375.337548000">
<axtdc:DoorSchedule>
<axtdc:ScheduledState>
<axtdc:EnterAction>Unlock</axtdc:EnterAction>
<axtdc:ScheduleToken>Axis-00408c184bd9:1350975752.527366000</axtdc:ScheduleToken>
</axtdc:ScheduledState>
<axtdc:ScheduledState>
<axtdc:EnterAction>Lock</axtdc:EnterAction>
<axtdc:ScheduleToken>standard_always</axtdc:ScheduleToken>
</axtdc:ScheduledState>
</axtdc:DoorSchedule>
</axtdc:DoorScheduleConfiguration>
</axtdc:SetDoorScheduleConfiguration>
Response
{
"Token": "Axis-00408c184bd9:1350969415.227159000"
}
Response
<axtdc:Token>Axis-00408c184bd9:1350969415.227159000</axtdc:Token>
{
"axtdc:SetDoorConfiguration": {
"DoorConfiguration": [
{
"DeviceUUID": "5581ad80-95b0-11e0-b883-00408c184bd9",
"token": "Axis-00408c184bd9:1350969415.227159000",
"DoorScheduleConfiguration": "Axis-00408c184bd9:1350969415.227159000",
"Configuration": [
{
"Name": "Lock.LockWhenDoorOpens",
"Value": "false"
},
{
"Name": "DoorMonitor.ValueWhenOpen",
"Value": "Input Open"
},
{
"Name": "DoorMonitor.ValueWhenClosed",
"Value": "Input Ground"
},
{
"Name": "DoubleLock.Type",
"Value": "None"
},
{
"Name": "Lock.Type",
"Value": "Standard"
},
{
"Name": "Lock.ValueWhenLocked",
"Value": "Gnd"
},
{
"Name": "Lock.ValueWhenUnlocked",
"Value": "12V"
},
{
"Name": "Lock.BoltOutTime",
"Value": "0"
},
{
"Name": "Lock.BoltInTime",
"Value": "0"
}
]
}
]
}
}
<axtdc:SetDoorConfiguration>
<axtdc:DoorConfiguration token="Axis-00408c184bd9:1350969415.227159000">
<axtdc:Configuration>
<axconf:Name>Lock.LockWhenDoorOpens</axconf:Name>
<axconf:Value>false</axconf:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<axconf:Name>DoorMonitor.ValueWhenOpen</axconf:Name>
<axconf:Value>Input Open</axconf:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<axconf:Name>DoorMonitor.ValueWhenClosed</axconf:Name>
<axconf:Value>Input Ground</axconf:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<axconf:Name>DoubleLock.Type</axconf:Name>
<axconf:Value>None</axconf:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<axconf:Name>Lock.Type</axconf:Name>
<axconf:Value>Standard</axconf:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<axconf:Name>Lock.ValueWhenLocked</axconf:Name>
<axconf:Value>Gnd</axconf:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<axconf:Name>Lock.ValueWhenUnlocked</axconf:Name>
<axconf:Value>12V</axconf:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<axconf:Name>Lock.BoltOutTime</axconf:Name>
<axconf:Value>0</axconf:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<axconf:Name>Lock.BoltInTime</axconf:Name>
<axconf:Value>0</axconf:Value>
</axtdc:Configuration>
<axtdc:DeviceUUID />
<axtdc:DoorScheduleConfiguration>Axis-00408c184bd9:1350969415.227159000</axtdc:DoorScheduleConfiguration>
</axtdc:DoorConfiguration>
</axtdc:SetDoorConfiguration>
Locks and lock monitors
Entry manager supports the following types of locks:
- 12V locks (also known as "standard locks").
- Relay locks.
- AperioTM locks. See, Aperio doors
If a given device has a single door connected, the door can then have one or two locks. If the device has two doors connected, the doors can have one lock each. All combinations of locks are not supported, for instance, the hardware has only one relay so only a single relay lock can be connected to a device.
API usage
Locks are configured when the door is set up using the DoorConfiguration object, by setting corresponding properties in Configuration. See I/O assignment on how the physical hardware to the locks is configured using IoAssignment objects.
Important note: The following subsections detail how AXIS Entry Manager sets Configuration for various types of locks. AXIS Entry Manager does not support setting other values than the values below, but it will correctly display them (where applicable) and allow administration of the system. For AXIS Entry Manager to correctly work however, the following two configuration items must be set as listed below:
Lock.Type.DoubleLock.Type.
Configuring a 12V lock
When configuring a 12V lock as the first lock on a door, the following configuration items are set:
Lock.Typeis set to "Standard".Lock.LockWhenDoorOpensis set to "false".Lock.ValueWhenLockedis set to either "12V" or "Gnd".Lock.ValueWhenUnlockedis set to either "12V" or "Gnd" (the opposite ofLock.ValueWhenLocked).Lock.BoltOutTimeis set to "0" (it is not applicable for 12V locks).Lock.BoltInTimeis set to "0" (it is not applicable for 12V locks).
When configuring a 12V lock as the second lock on a door, the following Configuration items are set:
- The same as for the first lock, except that each item is prefixed with "
DoubleLock" instead of "Lock", with one exception:Lock.LockWhenDoorOpensis not set.
Configuring a relay lock
When configuring a relay lock as the first lock on a door, the following configuration items are set:
Lock.Typeis set to "Relay".Lock.LockWhenDoorOpensis set to "false".Lock.RelayStateWhenLockedis set to either "Open" or "Closed".Lock.BoltOutTimeis set to "0" (it is not applicable for relay locks).Lock.BoltInTimeis set to "0" (it is not applicable for relay locks).
When configuring a 12V lock as the second lock on a door, the following Configuration items are set:
- The same as for the first lock, except that each item is prefixed with "
DoubleLock" instead of "Lock", with one exception:Lock.LockWhenDoorOpensis not set.
Configuring no lock
If there is no second lock connected to the door, the following configuration items must be set:
DoubleLock.Typemust be set to "None".
Examples
Set up a door with a single 12V lock See Examples for an example on how to set up a 12V lock.
Setup Door with Single Relay Lock The following request configures a door with a single relay lock:
{
"axtdc:SetDoorConfiguration": {
"DoorConfiguration": [
{
"DeviceUUID": "",
"Configuration": [
{
"Name": "Lock.LockWhenDoorOpens",
"Value": "false"
},
{
"Name": "DoorMonitor.ValueWhenOpen",
"Value": "Input Open"
},
{
"Name": "DoorMonitor.ValueWhenClosed",
"Value": "Input Ground"
},
{
"Name": "DoubleLock.Type",
"Value": "None"
},
{
"Name": "Lock.Type",
"Value": "Relay"
},
{
"Name": "Lock.RelayStateWhenLocked",
"Value": "Open"
},
{
"Name": "Lock.BoltOutTime",
"Value": "0"
},
{
"Name": "Lock.BoltInTime",
"Value": "0"
}
]
}
]
}
}
<axtdc:SetDoorConfiguration>
<axtdc:DoorConfiguration token="">
<axtdc:Configuration>
<axconf:Name>Lock.LockWhenDoorOpens</axconf:Name>
<axconf:Value>false</axconf:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<axconf:Name>DoorMonitor.ValueWhenOpen</axconf:Name>
<axconf:Value>Input Open</axconf:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<axconf:Name>DoorMonitor.ValueWhenClosed</axconf:Name>
<axconf:Value>Input Ground</axconf:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<axconf:Name>DoubleLock.Type</axconf:Name>
<axconf:Value>None</axconf:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<axconf:Name>Lock.Type</axconf:Name>
<axconf:Value>Relay</axconf:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<axconf:Name>Lock.RelayStateWhenLocked</axconf:Name>
<axconf:Value>Open</axconf:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<axconf:Name>Lock.BoltOutTime</axconf:Name>
<axconf:Value>0</axconf:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<axconf:Name>Lock.BoltInTime</axconf:Name>
<axconf:Value>0</axconf:Value>
</axtdc:Configuration>
<axtdc:DeviceUUID />
</axtdc:DoorConfiguration>
</axtdc:SetDoorConfiguration>
Setup Door with Two 12V Locks The following request configures a door with two 12V locks:
{
"axtdc:SetDoorConfiguration": {
"DoorConfiguration": [
{
"DeviceUUID": "",
"Configuration": [
{
"Name": "Lock.LockWhenDoorOpens",
"Value": "false"
},
{
"Name": "DoorMonitor.ValueWhenOpen",
"Value": "Input Open"
},
{
"Name": "DoorMonitor.ValueWhenClosed",
"Value": "Input Ground"
},
{
"Name": "DoubleLock.Type",
"Value": "Standard"
},
{
"Name": "DoubleLock.ValueWhenLocked",
"Value": "Gnd"
},
{
"Name": "DoubleLock.ValueWhenUnlocked",
"Value": "12V"
}
]
}
]
}
}
<axtdc:SetDoorConfiguration>
<axtdc:DoorConfiguration token="">
<axtdc:Configuration>
<axconf:Name>Lock.LockWhenDoorOpens</axconf:Name>
<axconf:Value>false</axconf:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<axconf:Name>DoorMonitor.ValueWhenOpen</axconf:Name>
<axconf:Value>Input Open</axconf:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<axconf:Name>DoorMonitor.ValueWhenClosed</axconf:Name>
<axconf:Value>Input Ground</axconf:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<axconf:Name>DoubleLock.Type</axconf:Name>
<axconf:Value>Standard</axconf:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<axconf:Name>DoubleLock.ValueWhenLocked</axconf:Name>
<axconf:Value>Gnd</axconf:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<axconf:Name>DoubleLock.ValueWhenUnlocked</axconf:Name>
<axconf:Value>12V</axconf:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<axconf:Name>Lock.Type</axconf:Name>
<axconf:Value>Standard</axconf:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<axconf:Name>Lock.ValueWhenLocked</axconf:Name>
<axconf:Value>Gnd</axconf:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<axconf:Name>Lock.ValueWhenUnlocked</axconf:Name>
<axconf:Value>12V</axconf:Value>
</axtdc:Configuration>
<axtdc:DeviceUUID />
</axtdc:DoorConfiguration>
</axtdc:SetDoorConfiguration>
Id points – Readers and REX buttons
Id points represent something with which it is possible to gain access to a door. The entry manager supports two types of ID points:
- A card reader, which is a device that can read the number of a card and allows the user to enter a PIN code.
- A REX device, which is a device that provides access to the door when pressed.
An ID point is always associated with a single door and can be used to gain access to that door if additional conditions are met (such as the user owning the card having access rights to that door at that time). AXIS Entry Manager supports the following readers:
- Wiegand readers
- OSDP readers using RS485 half duplex
- AperioTM readers, see Aperio doors.
AXIS Entry Manager supports the following REX devices:
- REX devices that are active low
- REX devices that are active high
API usage
ID points are modeled using IdPoint and IdPointConfiguration and references IdDataConfiguration objects. SeeI/O assignment on how to configure the hardware to the readers using IoAssignment objects.
For each ID point, reader or REX, there is exactly one IdPoint and one IdPointConfiguration object. AXIS Entry Manager does not modify the IdDataConfiguration objects, relying on the default objects created when the unit is programmed.
Door and IdPoint objects are connected using AccessPoint objects, see API usage for details.
Notes on IdPoint:
- It must use the same token as the corresponding
IdPointConfiguration. - Name contains the name of the reader/REX.
Actionis set to "Access". AXIS Entry Manager only supports ID points that lets a user access a door.Areais set to "". This setting is not used by AXIS Entry Manager.MinPINSizeis set to 4.MaxPINSizeis set to 4.EndOfPINis set to "#". AXIS Entry Manager will work with other values, but will always set this value.Timeoutis set to "PT10S". AXIS Entry Manager will work with other values, but will always set this value.
Notes on IdPointConfiguration:
- It must use the same token as the corresponding
IdPoint. - For readers, not REX devices,
IdDataConfigurationis set to allIdDataConfigurationthat are configured on the unit, as obtained usingGetIdDataConfigurationList. AXIS Entry Manager supports any set ofIdDataConfigurationobjects, but it will not create anything. Configurationis set depending on the type of reader/REX, see below.
Important note: In the subsections below it is detailed how AXIS Entry Manager sets Configuration for various types of readers and REX devices. Other configurations are possible, for instance, a different reader might require a different LED or tampering monitor. AXIS Entry Manager does not support setting other values than the values below, but it will correctly display them (where applicable) and allow administration of the system. However, for AXIS Entry Manager to work correctly, the following two configuration items must be set as listed below:
IdPoint.Reader.TypeIdPoint.REX.Type
Notes on IdDataConfiguration:
- AXIS Entry Manager does not modify the list of
IdDataConfigurationobjects on the unit.
Configuring a Wiegand reader
When configuring a Wiegand reader the following Configuration items are set in the IdPointConfiguration:
IdPoint.Reader.Typeis set to "Wiegand".IdPoint.LED.Typeis set to "SingleLED".IdPoint.LED.ActiveLevelis set to "ActiveLow".IdPoint.Beeper.Typeis set to "ActiveLow".IdPoint.Tampering.Typeis set to "ActiveLow".IdPoint.REX.Typeis set to "None".IdPoint.Keypress.Typeis set to "Auto".
Configuring an OSDP reader
When configuring an OSDP reader that uses RS485 half duplex, the following Configuration items are set in the IdPointConfiguration:
IdPoint.LED.Typeis set to "SingleLED".IdPoint.LED.ActiveLevelis set to "ActiveLow".IdPoint.Beeper.Typeis set to "ActiveLow".IdPoint.Tampering.Typeis set to "ActiveLow".IdPoint.REX.Typeis set to "None".IdPoint.Keypress.Typeis set to "Auto".IdPoint.Reader.Typeis set to "RS-485HD".IdPoint.RS-485FD.Protocolis set to "OSDP".
Configuring a REX device
When configuring a REX device the following Configuration items are set in the IdPointConfiguration:
IdPoint.Reader.Typeis set to "None".IdPoint.Keypress.Typeis set to "Auto".
If the REX device is active low, the following additional Configuration items are set:
IdPoint.REX.Typeis set to "ActiveLow".
If the REX device is active high, the following additional Configuration items are set:
IdPoint.REX.Typeis set to "ActiveHigh".
Examples
Setup Wiegand reader The following requests are used to set up a Wiegand reader. The I/O assignment setup is not included in this example but must also be completed before the setup can be used. For I/O assignment details, see I/O assignment. The following request fetches the current set of IdDataConfiguration objects that the unit knows of (response shortened for brevity).
Request
{
"axtid:GetIdDataConfigurationList": {}
}
Request
<axtid:GetIdDataConfigurationList />
Response
{
"IdDataConfiguration": [
{
"token": "iddataconf_wiegand_26bit_h10301",
...
}, {
"token": "iddataconf_wiegand_34bit",
...
}, {
"token": "iddataconf_wiegand_37bit_h10302",
...
}, {
"token": "iddataconf_wiegand_37bit_h10304",
...
}, {
"token": "iddataconf_wiegand_35bit_corporate1000",
...
}
]
}
Response
<axtid:IdDataConfiguration token="iddataconf_wiegand_26bit_h10301">
...
</axtid:IdDataConfiguration>
<axtid:IdDataConfiguration token="iddataconf_wiegand_34bit">
...
</axtid:IdDataConfiguration>
<axtid:IdDataConfiguration token="iddataconf_wiegand_37bit_h10302">
...
</axtid:IdDataConfiguration>
<axtid:IdDataConfiguration token="iddataconf_wiegand_37bit_h10304">
...
</axtid:IdDataConfiguration>
<axtid:IdDataConfiguration token="iddataconf_wiegand_35bit_corporate1000">
</axtid:IdDataConfiguration>
Create and configure ID point:
Request
{
"axtid:SetIdPointConfiguration": {
"IdPointConfiguration": [
{
"DeviceUUID": "",
"Configuration": [
{
"Name": "IdPoint.Reader.Type",
"Value": "Wiegand"
},
{
"Name": "IdPoint.LED.Type",
"Value": "SingleLED"
},
{
"Name": "IdPoint.LED.ActiveLevel",
"Value": "ActiveLow"
},
{
"Name": "IdPoint.Beeper.Type",
"Value": "ActiveLow"
},
{
"Name": "IdPoint.Tampering.Type",
"Value": "ActiveLow"
},
{
"Name": "IdPoint.REX.Type",
"Value": "None"
},
{
"Name": "IdPoint.Keypress.Type",
"Value": "Auto"
}
],
"IdDataConfiguration": [
"iddataconf_wiegand_26bit_h10301",
"iddataconf_wiegand_34bit",
"iddataconf_wiegand_37bit_h10302",
"iddataconf_wiegand_37bit_h10304",
"iddataconf_wiegand_35bit_corporate1000"
]
}
]
}
}
Request
<axtid:SetIdPointConfiguration>
<axtid:IdPointConfiguration token="">
<axtid:Configuration>
<axconf:Name>IdPoint.Reader.Type</axconf:Name>
<axconf:Value>Wiegand</axconf:Value>
</axtid:Configuration>
<axtid:Configuration>
<axconf:Name>IdPoint.LED.Type</axconf:Name>
<axconf:Value>SingleLED</axconf:Value>
</axtid:Configuration>
<axtid:Configuration>
<axconf:Name>IdPoint.LED.ActiveLevel</axconf:Name>
<axconf:Value>ActiveLow</axconf:Value>
</axtid:Configuration>
<axtid:Configuration>
<axconf:Name>IdPoint.Beeper.Type</axconf:Name>
<axconf:Value>ActiveLow</axconf:Value>
</axtid:Configuration>
<axtid:Configuration>
<axconf:Name>IdPoint.Tampering.Type</axconf:Name>
<axconf:Value>ActiveLow</axconf:Value>
</axtid:Configuration>
<axtid:Configuration>
<axconf:Name>IdPoint.REX.Type</axconf:Name>
<axconf:Value>None</axconf:Value>
</axtid:Configuration>
<axtid:Configuration>
<axconf:Name>IdPoint.Keypress.Type</axconf:Name>
<axconf:Value>Auto</axconf:Value>
</axtid:Configuration>
<axtid:DeviceUUID />
<axtid:IdDataConfiguration>iddataconf_wiegand_26bit_h10301</axtid:IdDataConfiguration>
<axtid:IdDataConfiguration>iddataconf_wiegand_34bit</axtid:IdDataConfiguration>
<axtid:IdDataConfiguration>iddataconf_wiegand_37bit_h10302</axtid:IdDataConfiguration>
<axtid:IdDataConfiguration>iddataconf_wiegand_37bit_h10304</axtid:IdDataConfiguration>
<axtid:IdDataConfiguration>iddataconf_wiegand_35bit_corporate1000</axtid:IdDataConfiguration>
</axtid:IdPointConfiguration>
</axtid:SetIdPointConfiguration>
Response
{
"Token": "Axis-00408c184bd9:1350984343.970492000"
}
Response
<axtid:Token>Axis-00408c184bd9:1350984343.970492000</axtid:Token>
Request
{
"axtid:SetIdPoint": {
"IdPoint": [
{
"Name": "Reader In",
"Action": "Access",
"Area": "",
"MinPINSize": 4,
"MaxPINSize": 4,
"EndOfPIN": "#",
"Timeout": "PT10S",
"token": "Axis-00408c184bd9:1350984343.970492000"
}
]
}
}
Request
<axtid:SetIdPoint>
<axtid:IdPoint token="Axis-00408c184bd9:1350984343.970492000">
<axtid:Action>Access</axtid:Action>
<axtid:Area />
<axtid:EndOfPIN>#</axtid:EndOfPIN>
<axtid:MaxPINSize>4</axtid:MaxPINSize>
<axtid:MinPINSize>4</axtid:MinPINSize>
<axtid:Name>Reader In</axtid:Name>
<axtid:Timeout>PT10S</axtid:Timeout>
<axtid:HeartbeatInterval />
<axtid:Location />
</axtid:IdPoint>
</axtid:SetIdPoint>
Setup Half Duplex OSDP Reader The following requests are used to set up a half-duplex OSDP reader. The IdDataConfiguration objects are obtained in the same way as in the Wiegand example above.
Request
{
"axtid:SetIdPointConfiguration": {
"IdPointConfiguration": [
{
"DeviceUUID": "",
"Configuration": [
{
"Name": "IdPoint.Reader.Type",
"Value": "RS-485HD"
},
{
"Name": "IdPoint.LED.Type",
"Value": "SingleLED"
},
{
"Name": "IdPoint.LED.ActiveLevel",
"Value": "ActiveLow"
},
{
"Name": "IdPoint.Beeper.Type",
"Value": "ActiveLow"
},
{
"Name": "IdPoint.Tampering.Type",
"Value": "ActiveLow"
},
{
"Name": "IdPoint.REX.Type",
"Value": "None"
},
{
"Name": "IdPoint.Keypress.Type",
"Value": "Auto"
},
{
"Name": "IdPoint.RS-485HD.Protocol",
"Value": "OSDP"
}
],
"IdDataConfiguration": [
"iddataconf_wiegand_26bit_h10301",
"iddataconf_wiegand_34bit",
"iddataconf_wiegand_37bit_h10302",
"iddataconf_wiegand_37bit_h10304",
"iddataconf_wiegand_35bit_corporate1000"
]
}
]
}
}
Request
<axtid:SetIdPointConfiguration>
<axtid:IdPointConfiguration token="">
<axtid:Configuration>
<axconf:Name>IdPoint.Reader.Type</axconf:Name>
<axconf:Value>RS-485HD</axconf:Value>
</axtid:Configuration>
<axtid:Configuration>
<axconf:Name>IdPoint.LED.Type</axconf:Name>
<axconf:Value>SingleLED</axconf:Value>
</axtid:Configuration>
<axtid:Configuration>
<axconf:Name>IdPoint.LED.ActiveLevel</axconf:Name>
<axconf:Value>ActiveLow</axconf:Value>
</axtid:Configuration>
<axtid:Configuration>
<axconf:Name>IdPoint.Beeper.Type</axconf:Name>
<axconf:Value>ActiveLow</axconf:Value>
</axtid:Configuration>
<axtid:Configuration>
<axconf:Name>IdPoint.Tampering.Type</axconf:Name>
<axconf:Value>ActiveLow</axconf:Value>
</axtid:Configuration>
<axtid:Configuration>
<axconf:Name>IdPoint.REX.Type</axconf:Name>
<axconf:Value>None</axconf:Value>
</axtid:Configuration>
<axtid:Configuration>
<axconf:Name>IdPoint.Keypress.Type</axconf:Name>
<axconf:Value>Auto</axconf:Value>
</axtid:Configuration>
<axtid:Configuration>
<axconf:Name>IdPoint.RS-485HD.Protocol</axconf:Name>
<axconf:Value>OSDP</axconf:Value>
</axtid:Configuration>
<axtid:DeviceUUID />
<axtid:IdDataConfiguration>iddataconf_wiegand_26bit_h10301</axtid:IdDataConfiguration>
<axtid:IdDataConfiguration>iddataconf_wiegand_34bit</axtid:IdDataConfiguration>
<axtid:IdDataConfiguration>iddataconf_wiegand_37bit_h10302</axtid:IdDataConfiguration>
<axtid:IdDataConfiguration>iddataconf_wiegand_37bit_h10304</axtid:IdDataConfiguration>
<axtid:IdDataConfiguration>iddataconf_wiegand_35bit_corporate1000</axtid:IdDataConfiguration>
</axtid:IdPointConfiguration>
</axtid:SetIdPointConfiguration>
Response
{
"Token": "Axis-00408c184bd9:1350990773.612849000"
}
Response
<axtid:Token>Axis-00408c184bd9:1350990773.612849000</axtid:Token>
Request
{
"axtid:SetIdPoint": {
"IdPoint": [
{
"Name": "Reader In",
"Action": "Access",
"Area": "",
"MinPINSize": 4,
"MaxPINSize": 4,
"EndOfPIN": "#",
"Timeout": "PT10S",
"token": "Axis-00408c184bd9:1350990773.612849000"
}
]
}
}
Request
<axtid:SetIdPoint>
<axtid:IdPoint token="Axis-00408c184bd9:1350990773.612849000">
<axtid:Action>Access</axtid:Action>
<axtid:Area />
<axtid:EndOfPIN>#</axtid:EndOfPIN>
<axtid:MaxPINSize>4</axtid:MaxPINSize>
<axtid:MinPINSize>4</axtid:MinPINSize>
<axtid:Name>Reader In</axtid:Name>
<axtid:Timeout>PT10S</axtid:Timeout>
PT10S
<axtid:HeartbeatInterval />
<axtid:Location />
</axtid:IdPoint>
</axtid:SetIdPoint>
Setup Active Low REX Button The following requests are used to set up a REX button that is activated by a closed circuit (ActiveLow).
Request
{
"axtid:SetIdPointConfiguration": {
"IdPointConfiguration": [
{
"DeviceUUID": "",
"Configuration": [
{
"Name": "IdPoint.Reader.Type",
"Value": "None"
},
{
"Name": "IdPoint.REX.Type",
"Value": "ActiveLow"
},
{
"Name": "IdPoint.Keypress.Type",
"Value": "Auto"
}
],
"IdDataConfiguration": []
}
]
}
}
Request
<axtid:SetIdPointConfiguration>
<axtid:IdPointConfiguration token="">
<axtid:Configuration>
<axconf:Name>IdPoint.Reader.Type</axconf:Name>
<axconf:Value>None</axconf:Value>
</axtid:Configuration>
<axtid:Configuration>
<axconf:Name>IdPoint.REX.Type</axconf:Name>
<axconf:Value>ActiveLow</axconf:Value>
</axtid:Configuration>
<axtid:Configuration>
<axconf:Name>IdPoint.Keypress.Type</axconf:Name>
<axconf:Value>Auto</axconf:Value>
</axtid:Configuration>
<axtid:DeviceUUID />
<axtid:IdDataConfiguration />
</axtid:IdPointConfiguration>
</axtid:SetIdPointConfiguration>
Response
{
"Token": "Axis-00408c184bd9:1350990775.948030000"
}
Response
<axtid:Token>Axis-00408c184bd9:1350990775.948030000</axtid:Token>
Request
{
"axtid:SetIdPoint": {
"IdPoint": [
{
"Name": "REX In",
"Action": "Access",
"Area": "",
"MinPINSize": 4,
"MaxPINSize": 4,
"EndOfPIN": "#",
"Timeout": "PT10S",
"token": "Axis-00408c184bd9:1350990775.948030000"
}
]
}
}
Request
<axtid:SetIdPoint>
<axtid:IdPoint token="Axis-00408c184bd9:1350990775.948030000">
<axtid:Action>Access</axtid:Action>
<axtid:Area />
<axtid:EndOfPIN>#</axtid:EndOfPIN>
<axtid:MaxPINSize>4</axtid:MaxPINSize>
<axtid:MinPINSize>4</axtid:MinPINSize>
<axtid:Name>REX In</axtid:Name>
<axtid:Timeout>PT10S</axtid:Timeout>
<axtid:HeartbeatInterval />
<axtid:Location />
</axtid:IdPoint>
</axtid:SetIdPoint>
I/O assignment
I/O assignments control how physical hardware are connected to the different services, that is, which service entities use which pins and for what. AXIS Entry Manager provides two basic functions regarding I/O assignment:
-
As a final step of the HW Config, I/O assignments are created for all the hardware that the user has indicated will be connected to the unit.
-
AXIS Entry Manager uses the I/O assignments to visualize to the user how hardware should be connected to the unit.
API usage
The access control APIs define a set of I/Os that each correspond to one or more physical pins on the device. The I/Os deal mainly with pins that carry information to and from the device. Most other pins, such as some ground pins and all power pins, are not part of any I/O. A given pin can belong to multiple I/Os if it has multiple uses. IoAssignment objects control which pins are to be used by which hardware devices. When creating I/O assignments as part of the hardware wizard, AXIS Entry Manager will assign pins according to the table. When visualizing I/O assignments read from the device, AXIS Entry Manager will use the information found in the IoAssignment objects. It will also try to deduce additional information about ground pins and present that as well. AXIS Entry Manager can visualize any legal I/O assignment configuration. Notes on IoAssignment:
IoName, IoMode, andIoUser TypeandUsageare set as listed in the table.IoUserfieldMultiIois set tofalse.
I/O assignment setup in AXIS A1001's WebGUI.
| Hardware device | I/O name | I/O mode | I/O user type | I/O user usage |
|---|---|---|---|---|
| 12V first lock on first door | H1 | inout:12V/gnd | doorcontrol | Lock_Standard |
| 12V second lock on first door | H2 | inout:12V/gnd | doorcontrol | DoubleLock_Standard |
| 12V first lock on second door | H2 | inout:12V/gnd | doorcontrol | Lock_Standard |
| Relay first lock | relay1 | open/closed | doorcontrol | Lock_Relay |
| Relay second lock | relay1 | open/closed | doorcontrol | DoubleLock_Relay |
| Door monitor on first door | IN1 | in:pu/gnd | doorcontrol | DoorOpenMonitor |
| IN1 | in:pu/gnd | doorcontrol | DoorClosedMonitor | |
| Door monitor on second door | IN3 | in:pu/gnd | doorcontrol | DoorOpenMonitor |
| IN3 | in:pu/gnd | doorcontrol | DoorClosedMonitor | |
| Wiegand reader as 1st reader | IO3 | inout:pu/gnd | idpoint | Tampering |
| IO5 | inout:pu/gnd | idpoint | LedSingle | |
| IO6 | inout:pu/gnd | idpoint | Beeper | |
| Wiegand1 | wiegand | idpoint | Wiegand | |
| Wiegand reader as 2nd reader | IO7 | inout:pu/gnd | idpoint | Tampering |
| IO9 | inout:pu/gnd | idpoint | LedSingle | |
| IO10 | inout:pu/gnd | idpoint | Beeper | |
| Wiegand2 | wiegand | idpoint | Wiegand | |
| OSDP reader as first reader (RS485 half duplex) | Ser0hd | rs485hd | idpoint | RS-485HD |
| OSDP reader as second reader (RS485 half duplex) | Ser2hd | rs485hd | idpoint | RS-485HD |
| Aperio hub (RS485 half duplex) | Ser3hd | rs485hd | doorcontrolidpoint | RS-485HD |
| REX device 1 | IN2 | inout:pu/gnd | idpoint | REX |
| REX device 2 | IN4 | inout:pu/gnd | idpoint | REX |
I/O assignment setup in AXIS A1601's WebGUI
| Hardware device | I/O name | I/O mode | I/O user type | I/O user usage |
|---|---|---|---|---|
| First lock of Door 1 | relay1 | open/closed | doorcontrol | Lock_Relay |
| Second lock of Door 1 | relay2 | open/closed | doorcontrol | DoubleLock_Relay |
| First lock on Door 2 | relay2 | open/closed | doorcontrol | Lock_Relay |
| Door monitor of Door 1 | IO5 | inout:pu/gnd | doorcontrol | DoorOpenMonitor |
| IO5 | inout:pu/gnd | doorcontrol | DoorClosedMonitor | |
| Door monitor of Door 2 | IO11 | inout:pu/gnd | doorcontrol | DoorOpenMonitor |
| IO11 | inout:pu/gnd | doorcontrol | DoorClosedMonitor | |
| REX of Door 1 | IO6 | inout:pu/gnd | idpoint | REX |
| REX of Door 2 | IO12 | inout:pu/gnd | idpoint | REX |
| Wiegand reader as Reader 1 | IO7 | inout:pu/gnd | idpoint | Tampering |
| O1 | out:pu/gnd | idpoint | LedSingle | |
| IO8 | inout:pu/gnd | idpoint | Beeper | |
| Wiegand1 | wiegand | idpoint | Wiegand | |
| Wiegand reader as Reader 2 | IO9 | inout:pu/gnd | idpoint | Tampering |
| O3 | out:pu/gnd | idpoint | LedSingle | |
| IO10 | inout:pu/gnd | idpoint | Beeper | |
| Wiegand2 | wiegand | idpoint | Wiegand | |
| OSDP reader as Reader 1 | Ser0hd | rs485hd | idpoint | RS-485HD |
| OSDP reader as Reader 2 | Ser1hd | rs485hd | idpoint | RS-485HD |
Examples
Create I/O Assignments for Wiegand Reader The following requests create I/O assignments for connecting a Wiegand reader as the first reader:
Request
{
"axisio:SetIoAssignment": {
"IoAssignment": [
{
"IoName": "IO3",
"IoMode": "inout:pu/gnd",
"IoUser": [
{
"Type": "idpoint",
"Usage": "Tampering",
"MultiIo": false,
"token": "Axis-00408c184bd9:1351067611.049683000"
}
]
},
{
"IoName": "IO5",
"IoMode": "inout:pu/gnd",
"IoUser": [
{
"Type": "idpoint",
"Usage": "LedSingle",
"MultiIo": false,
"token": "Axis-00408c184bd9:1351067611.049683000"
}
]
},
{
"IoName": "IO6",
"IoMode": "inout:pu/gnd",
"IoUser": [
{
"Type": "idpoint",
"Usage": "Beeper",
"MultiIo": false,
"token": "Axis-00408c184bd9:1351067611.049683000"
}
]
},
{
"IoName": "Wiegand1",
"IoMode": "wiegand",
"IoUser": [
{
"Type": "idpoint",
"Usage": "Wiegand",
"MultiIo": false,
"token": "Axis-00408c184bd9:1351067611.049683000"
}
]
}
]
}
}
Request
<axisio:SetIoAssignment>
<axisio:IoAssignment>
<axisio:IoMode>inout:pu/gnd</axisio:IoMode>
<axisio:IoName>IO3</axisio:IoName>
<axisio:IoUser>
<axisio:MultiIo>false</axisio:MultiIo>
<axisio:Type>idpoint</axisio:Type>
<axisio:Usage>Tampering</axisio:Usage>
<axisio:token>Axis-00408c184bd9:1351067611.049683000</axisio:token>
</axisio:IoUser>
</axisio:IoAssignment>
<axisio:IoAssignment>
<axisio:IoMode>inout:pu/gnd</axisio:IoMode>
<axisio:IoName>IO5</axisio:IoName>
<axisio:IoUser>
<axisio:MultiIo>false</axisio:MultiIo>
<axisio:Type>idpoint</axisio:Type>
<axisio:Usage>LedSingle</axisio:Usage>
<axisio:token>Axis-00408c184bd9:1351067611.049683000</axisio:token>
</axisio:IoUser>
</axisio:IoAssignment>
<axisio:IoAssignment>
<axisio:IoMode>inout:pu/gnd</axisio:IoMode>
<axisio:IoName>IO6</axisio:IoName>
<axisio:IoUser>
<axisio:MultiIo>false</axisio:MultiIo>
<axisio:Type>idpoint</axisio:Type>
<axisio:Usage>Beeper</axisio:Usage>
<axisio:token>Axis-00408c184bd9:1351067611.049683000</axisio:token>
</axisio:IoUser>
</axisio:IoAssignment>
<axisio:IoAssignment>
<axisio:IoMode>wiegand</axisio:IoMode>
<axisio:IoName>Wiegand1</axisio:IoName>
<axisio:IoUser>
<axisio:MultiIo>false</axisio:MultiIo>
<axisio:Type>idpoint</axisio:Type>
<axisio:Usage>Wiegand</axisio:Usage>
<axisio:token>Axis-00408c184bd9:1351067611.049683000</axisio:token>
</axisio:IoUser>
</axisio:IoAssignment>
</axisio:SetIoAssignment>
Schedules
Schedules describe when in time a certain state of some kind applies. A schedule is a set of time intervals. An example of a schedule would be "every Tuesday between 14:00 and 16:00". However, "every Tuesday at 14:00" is not a schedule since it describes a set of points in time, not a set of time intervals.
AXIS Entry Manager sets up schedules with either normal schedules or exceptions. Exceptions are subtracted from normal schedules as described in on Combining schedules.
There are currently three types of supported time intervals, where each schedule can contain a mix of intervals of the three types:
-
One-off intervals defines a single interval in time, for instance, 12:00-14:00 on April 1 2012. The interval can be of any length.
-
Yearly intervals define an interval that occurs yearly, for instance, every year 12:00-14:00 on April 1. The interval can be no longer than 24 hours.
-
Weekly intervals define intervals that occurs every week on certain week days, for example, 12:00-14:00 every Tuesday and Thursday. The intervals can be no longer than 24 hours.
Recurring intervals (types 2, 3) can have an optional end date. Any time interval starting after the end date are ignored. When it comes to rules for leap years, leap seconds and so forth, schedules follow the same rules as iCalendar objects since they are internally represented using iCalendar.
Combining schedules
In most situations where a schedule is specified, it is possible to specify a set of schedules. The schedules in the set are then combined in two steps:
-
All normal schedules are combined, creating the union of their time intervals.
-
All exception schedules are subtracted.
Note the order, first all normal schedules are combined, then all exception schedules are subtracted. All exception schedules always take precedence over normal schedules.
API usage
Schedules are modeled using Schedule objects.
AXIS Entry Manager assumes that there is a standard schedule on the device with the token standard_always that matches any point in time. This schedule exists by default but it can later be modified using the API. Doing so will break AXIS Entry Manager, so do not change standard_always if you want to use AXIS Entry Manager. Notes on Schedule:
Namecontains the name of the schedule.Descriptionis not used.Attributeis not used.
Notes on iCalendar:
-
AXIS Entry Manager follows the iCalendar specification as described in RFC 5545. This includes setting of mandatory fields such as
VERSION, PRODID, DTSTAMP, UIDand so forth. -
Time granularity is minutes. No time specifications use seconds or fractions of a second (exception:
UNTILuses seconds, see below). In all instances where it is possible to choose between date types, AXIS Entry Manager uses Date-Time. -
Intervals are defined using
VEVENTs, withRRULEs where applicable. -
Each
VEVENTuses theSUMMARYfield to name theVEVENT. -
One-off intervals are represented using a
VEVENTwhereDTSTARTandDTENDholds the start and end of the interval. -
Yearly recurring intervals are represented using a
VEVENTwhereDTSTARTandDTENDholds the start and end of the first occurrence of the interval.Note that the first occurrence can start on one day and end on another (for instance, 23:00-11:00), but its length must not exceed 24 hours.
RRULEis set to yearly, like this: "RRULE:FREQ=YEARLY". -
Weekly recurring intervals are represented using a
VEVENTwhereDTSTARTandDTENDholds the start and end of the first occurrence of the interval.Note that the first occurrence can start on one day and end on another (for instance, 23:00-11:00), but its length must not exceed 24 hours. RRULE is set to weekly, like this: "RRULE is set to weekly, like this: "
RRULE:FREQ=WEEKLY;BYDAY=<list of days>", for example "RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR". -
For recurring intervals, the optional end date is specified by appending an
UNTILclause to theRRULE, specifying the last second of a day. Example:UNTIL=20121031T225959. This is the only instance where AXIS Entry Manager specifies Date-Times with second granularity.
Examples
Create an Empty Schedule The following request creates an empty Schedule:
{
"axsch:SetSchedule": {
"Schedule": [
{
"Name": "Never",
"Description": "",
"ScheduleDefinition": "BEGIN:VCALENDAR\r\nPRODID:\r\nVERSION:2.0\r\nEND:VCALENDAR\r\n",
"ExceptionScheduleDefinition": "",
"Attribute": []
}
]
}
}
<axsch:SetSchedule>
<axsch:Schedule token="">
<axsch:Description></axsch:Description>
<axsch:ExceptionScheduleDefinition></axsch:ExceptionScheduleDefinition>
<axsch:Name>Never</axsch:Name>
<axsch:ScheduleDefinition>BEGIN:VCALENDAR

PRODID:

VERSION:2.0

END:VCALENDAR

</axsch:ScheduleDefinition>
</axsch:Schedule>
</axsch:SetSchedule>
Create a One-Off Schedule The following request creates a schedule that contains one time interval, December 24 2012 00:00-24:00.
{
"axsch:SetSchedule": {
"Schedule": [
{
"Name": "Christmas 2012",
"Description": "",
"ScheduleDefinition": "BEGIN:VCALENDAR\r\nPRODID:\r\nVERSION:2.0\r\nBEGIN:VEVENT\r\nSUMMARY:December 24 2012\r\nDTSTART:20121224T000000\r\nDTEND:20121225T000000\r\nDTSTAMP:20121019T122502\r\nUID:c674cc86cf597f1c\r\nEND:VEVENT\r\nEND:VCALENDAR\r\n",
"ExceptionScheduleDefinition": "",
"Attribute": []
}
]
}
}
<axsch:SetSchedule>
<axsch:Schedule token="">
<axsch:Description></axsch:Description>
<axsch:ExceptionScheduleDefinition></axsch:ExceptionScheduleDefinition>
<axsch:Name>Christmas 2012</axsch:Name>
<axsch:ScheduleDefinition>BEGIN:VCALENDAR

PRODID:

VERSION:2.0

BEGIN:VEVENT

SUMMARY:December 24 2012

DTSTART:20121224T000000

DTEND:20121225T000000

DTSTAMP:20121019T122502

UID:c674cc86cf597f1c

END:VEVENT

END:VCALENDAR

</axsch:ScheduleDefinition>

</axsch:Schedule>
</axsch:SetSchedule>
Create a Yearly Recurring Schedule The following request creates a schedule that contains yearly recurring intervals 00:00-24:00 each December 24, starting 2000:
{
"axsch:SetSchedule": {
"Schedule": [
{
"Name": "Christmas",
"Description": "",
"ScheduleDefinition": "BEGIN:VCALENDAR\r\nPRODID:\r\nVERSION:2.0\r\nBEGIN:VEVENT\r\nSUMMARY:December 24\r\nDTSTART:20001224T000000\r\nDTEND:20001225T000000\r\nRRULE:FREQ=YEARLY\r\nDTSTAMP:20121019T122814\r\nUID:7628d2029b87d980\r\nEND:VEVENT\r\nEND:VCALENDAR\r\n",
"ExceptionScheduleDefinition": "",
"Attribute": []
}
]
}
}
<axsch:SetSchedule>
<axsch:Schedule token="">
<axsch:Description></axsch:Description>
<axsch:ExceptionScheduleDefinition></axsch:ExceptionScheduleDefinition>
<axsch:Name>Christmas</axsch:Name>
<axsch:ScheduleDefinition>BEGIN:VCALENDAR

PRODID:

VERSION:2.0

BEGIN:VEVENT

SUMMARY:December 24

DTSTART:20001224T000000

DTEND:20001225T000000

RRULE:FREQ=YEARLY

DTSTAMP:20121019T122814

UID:7628d2029b87d980

END:VEVENT

END:VCALENDAR

</axsch:ScheduleDefinition>
</axsch:Schedule>
</axsch:SetSchedule>
Create a Weekly Recurring Schedule The following request creates a schedule that contains intervals that occurs every week day between 11:00 and 12:00:
{
"axsch:SetSchedule": {
"Schedule": [
{
"Name": "Lunch",
"Description": "",
"ScheduleDefinition": "BEGIN:VCALENDAR\r\nPRODID:\r\nVERSION:2.0\r\nBEGIN:VEVENT\r\nSUMMARY:Lunch\r\nDTSTART:20000103T110000\r\nDTEND:20000103T120000\r\nRRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR\r\nDTSTAMP:20121019T123359\r\nUID:c5d62887d9a269ab\r\nEND:VEVENT\r\nEND:VCALENDAR\r\n",
"ExceptionScheduleDefinition": "",
"Attribute": []
}
]
}
}
<axsch:SetSchedule>
<axsch:Schedule token="">
<axsch:Description></axsch:Description>
<axsch:ExceptionScheduleDefinition></axsch:ExceptionScheduleDefinition>
<axsch:Name>Lunch</axsch:Name>
<axsch:ScheduleDefinition>BEGIN:VCALENDAR

PRODID:

VERSION:2.0

BEGIN:VEVENT

SUMMARY:Lunch

DTSTART:20000103T110000

DTEND:20000103T120000

RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR

DTSTAMP:20121019T123359

UID:c5d62887d9a269

END:VEVENT

END:VCALENDAR

</axsch:ScheduleDefinition>
</axsch:Schedule>
</axsch:SetSchedule>
Create Schedule with End Date The following request creates a schedule that contains intervals every day between 12:00 and 14:00 between October 1 2012 and October 31 2012:
{
"axsch:SetSchedule": {
"Schedule": [
{
"Name": "October 2012",
"Description": "",
"ScheduleDefinition": "BEGIN:VCALENDAR\r\nPRODID:\r\nVERSION:2.0\r\nBEGIN:VEVENT\r\nSUMMARY:October 2012\r\nDTSTART:20121001T120000\r\nDTEND:20121001T140000\r\nRRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU;UNTIL=20121031T225959\r\nDTSTAMP:20121019T131655\r\nUID:1a102424e6d45bb4\r\nEND:VEVENT\r\nEND:VCALENDAR\r\n",
"ExceptionScheduleDefinition": "",
"Attribute": []
}
]
}
}
<axsch:SetSchedule>
<axsch:Schedule token="">
<axsch:Description></axsch:Description>
<axsch:ExceptionScheduleDefinition></axsch:ExceptionScheduleDefinition>
<axsch:Name>October 2012</axsch:Name>
<axsch:ScheduleDefinition>BEGIN:VCALENDAR

PRODID:

VERSION:2.0

BEGIN:VEVENT

SUMMARY:October 2012

DTSTART:20121001T120000

DTEND:20121001T140000

RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU;UNTIL=20121031T225959

DTSTAMP:20121019T131655

UID:1a102424e6d45bb4

END:VEVENT

END:VCALENDAR

</axsch:ScheduleDefinition>
</axsch:Schedule>
</axsch:SetSchedule>
Access management
With a system set up and administrated using AXIS Entry Manager, there are three ways to gain access to a door:
-
By manually unlocking it pressing a device in the user interface. This will use the UnlockDoor or AccessDoor requests found in the DoorControl service.
-
By configuring the door to unlock at certain times, based on a schedule. For details, see Doors
-
By configuring access so that the user can unlock the door by presenting a credential (card and/or PIN) to a reader or pressing a REX device.
This section deals with alternative 3.
API usage
This section describes how the entry manager configures access to a door for a particular user (or groups of users). Note that the access control APIs are flexible and there are many ways of configuring access, AXIS Entry Manager only uses specific parts of the API.
Access to a door using reader, card, and PIN code
For a user to be able to pass in through a door by presenting a card to a reader and entering a PIN code, the following API objects must be set up:
-
The door itself must be configured.
This includes creating a
Door, aDoorConfigurationand I/O assignments for the hardware of the door.Dooris explained in Doors,DoorConfigurationin Locks and lock monitors, and I/O assignments in section I/O assignment. -
The reader must be configured.
This includes creating an
IdPoint, anIdPointConfigurationand I/O assignments for the hardware of the reader.IdPointandIdPointConfigurationare explained in Id points – Readers and REX buttons. -
An
AccessPointfor the direction "in".This is explained in Doors. The
AccessPointmust reference the door from step 1 and the reader from step 2. -
An
AuthenticationProfile, which grants access using "card and PIN, must be added to theAccessPointfrom step 3. TheAuthenticationProfileis associated with aSchedulefor when access is granted. The schedule could be the standard schedulestandard_always, or a custom schedule could be created, see Schedules.AuthenticationProfileis described in Doors. -
A group must be created, for details see Groups. This includes creating an
AccessProfileobject. -
-
The
Schedulefield of theAccessProfilemust contain at least oneScheduleindicating when the group is active. This can be theSchedule standard_alwaysor a customSchedule. -
The
AccessProfile’sAccessPolicyfield must reference theAccessPointcreated in step 3. The schedule associated with theAccessPointmust bestandard_alwaysand nothing else, as described in Groups.
-
-
A user must be created, for details see Users and credentials.
This includes creating one
Userand oneCredential. TheCredentialmust contain twoIdDataitems, one for the user’s card number, one for the user’s PIN code. TheCredentialAccessProfileof theCredentialmust reference theAccessProfileof the group created in step 5.
This will grant the user access to the door when two specific conditions are met:
- The Schedule of the AuthenticationProfile created in step 4 must be active.
- The Schedule of the AccessProfile created in step 5 must be active.
Access to a door using PIN only
Letting someone access a door using a PIN code (without a card) is similar to accessing it using a card and PIN, and involves the same steps as in section Access to a door using reader, card, and PIN code with the following exceptions:
- The
AuthenticationProfilecreatedin step 4 must grant access to PIN, not card and PIN. - The user created in step 6 does not represent an actual person but is a collective user used by all people entering the PIN. The user is used mainly to store the PIN code. The
Credentialof the user should have only oneIdDatawith the PIN code.
Access to a door using REX button
Letting someone access a door using a REX device is similar to accessing it using a reader, and involves the same steps as in section Access to a door using reader, card, and PIN code with the following exceptions:
- A REX device is configured instead of a reader in step 2. This is done analogously, for details see Id points – Readers and REX buttons.
- REX devices are most often used to let a person pass out through a door, not in. Both are allowed, but the
AccessPointcreated in step 3 should be updated with the corresponding direction. - The
AuthenticationProfilecreated in step 4 must grant access to REX, not card and PIN. - Since REX devices are anonymous, a user is not needed and step 6 can be ignored.
Priority configurations
AXIS Entry Manager uses the default PriorityConfiguration, which contains a single priority level. All actions that can have a priority level associated with them uses the default (unspecified) priority level. Examples:
- When manually locking/unlocking/accessing a given door, it uses the default priority level.
- When scheduling a door state using
DoorScheduleConfiguration, see Doors, it uses the default priority level. - When accessing a door using a REX, PIN and/or card, the access action uses the default priority level.
Since all actions use the same priority level they will override each other. For example, if a door is manually unlocked, it will only stay so until the DoorScheduleConfiguration specifies another action (if ever).