Door control service
Door control service guide
The door control service is used to manage and control the status of doors and devices connected to doors.
The diagram shows the data types that will be covered in following subsections.

Set a door representation
Setting a representation of a door is the most basic use case for the door control service. This is done in two steps; setting the door basic configuration, and setting the door hardware configuration. The order of these steps is irrelevant, the set requests will set up a working door representation in any request order.
Door data structure
The Door data structure is the main representation of a physical door connected to the door controller. It is used to control the state of the door and its locks, i.e. whether the door is closed or open and locked or unlocked.
The Door contains all non-hardware related information about the door, such as timeouts for different situations. The following example shows a Door, which is set by calling axtdc:SetDoor in the Door Control Service:
{
"Door": [
{
"token": "Axis-00408c184bdb:1352121495.979065000",
"Name": "Front Door",
"Description": "Front door description",
"AccessTime": "PT10S",
"DefaultPriority": "",
"OpenTooLongTime": "PT10S",
"PreAlarmTime": "PT5S",
"ExtendedAccessTime": "PT30S",
"ExtendedOpenTooLongTime": "PT30S",
"PriorityConfiguration": "Standard"
}
]
}
<axtdc:Door token="Axis-00408c184bdb:1352121495.979065000">
<axtdc:Name>Front Door</axtdc:Name>
<axtdc:Description>Front door description</axtdc:Description>
<axtdc:AccessTime>PT10S</axtdc:AccessTime>
<axtdc:OpenTooLongTime>PT10S</axtdc:OpenTooLongTime>
<axtdc:PreAlarmTime>PT5S</axtdc:PreAlarmTime>
<axtdc:ExtendedAccessTime>PT30S</axtdc:ExtendedAccessTime>
<axtdc:ExtendedOpenTooLongTime>PT30S</axtdc:ExtendedOpenTooLongTime>
<axtdc:HeartbeatInterval>PT600S</axtdc:HeartbeatInterval>
<axtdc:PriorityConfiguration>Standard</axtdc:PriorityConfiguration>
<axtdc:DefaultPriority />
</axtdc:Door>
The timeout values are described by elements of type xs:duration. The example above illustrates how this type is used to specify time in periods of seconds.
The timeout values specifies time limits for different activities. If a timeout is triggered it will result in state changes and dispatching of events. The possible timeouts are:
-
AccessTimeThe time, specified in seconds in the example above, that the door shall remain unlocked after access has been granted.
-
OpenTooLongTimeThe time, specified in seconds in the example above, that the door is allowed to stay open.
DoorAlarmevent is sent if the door is still open when theOpenTooLongTimehas been reached. -
PreAlarmTimeThis specifies how long before the
OpenTooLongTimeexpires that aDoorWarningevent should be sent.
The diagram shows the different timeouts when a door is accessed and kept open.
The priority parameters will be discussed in section Manage doors with priority levels.
Door configuration
The door hardware configuration is used to set up the actual door and lock hardware. Doors may have one or two locks. In the following, two locks (consisting of a primary lock and a secondary lock) will be referred to as a double-lock.
The lock is configured by the type of lock and how the lock is controlled. If using double-locks, the secondary lock has similar configuration to the primary lock. The door monitor is configured by how to determine if the door is open or closed.
The following example shows a minor DoorConfiguration. Note that the token, marked in bold, is the link between Door and DoorConfiguration entities, thus it is the same as for the Door in the example in section Door data structure:
{
"DoorConfiguration": [
{
"token": "Axis-00408c184bdb:1352121495.979065000",
"DeviceUUID": "",
"DoorScheduleConfiguration": "",
"Configuration": [
{ "Name": "Lock.Type", "Value": "Standard" },
{ "Name": "DoorMonitor.ValueWhenOpen", "Value": "Input Open" },
{ "Name": "DoorMonitor.ValueWhenClosed", "Value": "Input Ground" }
]
}
]
}
<axtdc:DoorConfiguration token="Axis-00408c184bdb:1352121495.979065000">
<axtdc:DeviceUUID />
<axtdc:Configuration>
<ns0:Name>Lock.Type</ns0:Name>
<ns0:Value>Standard</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:DoorScheduleConfiguration />
</axtdc:DoorConfiguration>
Setting a DoorConfiguration is done by calling axtdc:SetDoorConfiguration. The DeviceUUID specifies the door controller on which the door exists. When setting a DoorConfiguration directly on the intended door controller, the DeviceUUID may be omitted and the UUID of the local device will be set automatically.
The previous example illustrates only a few Configuration options. It is not mandatory to set all configuration options, and the unspecified options will be set to their default values. To view all hardware configuration options for a door, the following API requests can be used:
axtdc:GetDoorConfigurationList:Returns a list ofDoorConfiguration.axtdc:GetDoorConfiguration:ReturnsDoorConfigurationfor the specified token.axtdc:GetDoorConfigurationInfo:Returns only theConfigurationof theDoorConfigurationfor the specified token.
The response from any of the above get requests will include default values as well, including those which were not set during setup. The table summarizes the possible configuration options.
Available parameters in the Configuration data structure.
| Name | Valid values | Default Value | Description |
|---|---|---|---|
Lock.Type | NoneStandardRelayRS485HDRemoteIOTCPIP | None | The type of lock.Use RS485HD for Aperio locks, see section Aperio doors.Use RemoteIO for locks/doors connected to I/Os on a remote device added to the door controller, see section Elevator access control.Use TCPIP for Smart Intego locks, see section Smart Intego doors.Lock type None is a virtual lock that can be used for testing. None works as other locks but without physically locking and unlocking a door. |
Lock.LockWhenDoorOpens | truefalse | false | If the lock should be locked when the door is opened (true) or if it should be unlocked (false). |
Lock.ValueWhenLocked | GndFloat12V | Gnd | Applies to the Standard lock type. Output value to use when door is in the locked state. |
Lock.ValueWhenUnlocked | GndFloat12V | 12V | Applies to the Standard lock type. Output value to use when door is in the unlocked state. |
Lock.RelayStateWhenLocked | OpenClosed | Open | Applies to the Relay lock type. The state of the relay when the lock is locked. |
Lock.BoltOutTime | ms | 700 | The maximum time allowed for lock to be opened. The actual time used may be shortened if using lock monitor. |
Lock.BoltInTime | ms | 700 | The maximum time allowed for lock to be closed. The actual time used may be shortened if using lock monitor. |
Lock.LockMonitor.ValueWhenLocked | NoneInput OpenInput 12VInput Ground | None | The value of the lock monitor, if existing, when the lock is locked. |
Lock.LockMonitor.ValueWhenUnlocked | NoneInput OpenInput 12VInput Ground | None | The value of the lock monitor, if existing, when the lock is unlocked. |
Lock.Hardware.Address | String | The lock’s hardware address. Aperio doors: A six-digit hexadecimal number. Smart Intego doors: A hexadecimal number, for example 0x200.RemoteIO: The remote I/Os id in the form remote/<token>/<id>.Use the id returned by axissd:GetServiceProviderList. | |
Lock.Hardware.Id | string | Applies to Smart Intego locks. The "phi" string of a Smart Intego lock device. See section Smart Intego doors. | |
Lock.Hub.Hardware.Address | Hexadecimal number | Applies to Smart Intego locks. The gateway’s device address, for example: 0x100. See section Smart Intego doors. | |
Lock.Protocol | AADP SmartIntego | The protocol to use to communicate with locks.Use AADP for Aperio locks.Use SmartIntego for Smart Intego locks. | |
Lock.TCPIP.Address | Dotted-decimal number | Address for TCPIP lock/gatway in dotted-decimal format, for example 192.168.123.132. | |
Lock.TCPIP.Port | Decimal number | Port number of TCPIP reader/gateway in decimal format. Use 2010 for Smart Intego lock. | |
DoubleLock.Type | NoneStandardRelay | None | Applicable when using double locks. The type of the secondary lock. |
DoubleLock.ValueWhenLocked | GndFloat12V | Gnd | Applies to a Standard secondary lock. Output value to use when the door is in the locked state. |
DoubleLock.ValueWhenUnlocked | GndFloat12V | 12V | Applies to a Standard secondary lock. Output value to use when the door is in the unlocked state. |
DoubleLock.RelayStateWhenLocked | OpenClosed | Open | Applies to a Relay secondary lock. The state of the relay when the lock is locked. |
DoubleLock.BoltOutTime | ms | 700 | The maximum time allowed for the secondary lock to be opened. The actual time used may be shortened if using lock monitor. |
DoubleLock.BoltInTime | ms | 700 | The maximum time allowed for the secondary lock to be closed. The actual time used may be shortened if using lock monitor. |
DoubleLock.LockMonitor.ValueWhenLocked | NoneInput OpenInput 12VInput Ground | None | The value of the lock monitor, if existing, when the door is locked. |
DoubleLock.LockMonitor.ValueWhenUnlocked | NoneInput OpenInput 12VInput Ground | None | The value of the lock monitor, if existing, when the door is unlocked. |
Door.Type | ElevatorFloorRegular | Regular | The type of door. Use ElevatorFloor for doors connected to I/Os on a remote device added to the door controller. See section Elevator access control. |
DoorMonitor.Hardware.Address | Hexadecimal number | Applies to Aperio doors. The door monitor’s hardware address. A six-digit hexadecimal number. | |
DoorMonitor.Protocol | NoneAADPSmartIntego | None | Protocol to use for locks. Use AADP for Aperio door monitors. Use SmartIntego for Smart Intego locks. |
DoorMonitor.Type | NoneStandardRS485HDTCPIP | None | The type of door monitor. Use RS485HD for Aperio doors, see section Aperio doors. Use TCPIP for Smart Intego locks, see section Smart Intego locks. |
DoorMonitor.ValueWhenOpen | NoneInput OpenInput GroundSupervised OpenSupervised Ground | None | The value of the door monitor, if existing, when the door is open.If using supervised inputs, select Supervised Open or Supervised Ground. |
DoorMonitor.ValueWhenClosed | NoneInput OpenInput GroundSupervised OpenSupervised Ground | None | The value of the door monitor, if existing, when the door is closed.If using supervised inputs, select Supervised Open or Supervised Ground. |
DoorMonitor.SupervisedCut | mV | Applicable if IoMode in IoAssignment is set to supervised, see section Assign I/O:s to services. Target voltage (in millivolts) for the door monitor cut (open circuit) state when using supervised inputs. End of line resistors must be used. | |
DoorMonitor.SupervisedShort | mV | Applicable if IoMode in IoAssignment is set to supervised, see section Assign I/O:s to services. Target voltage (in millivolts) for the door monitor short circuit state when using supervised inputs. End of line resistors must be used. | |
DoorMonitor.SupervisedHigh | mV | Applicable if IoMode in IoAssignment is set to supervised, see section Assign I/O:s to services. Target voltage (in millivolts) for the door monitor high state when using supervised inputs. End of line resistors must be used. | |
DoorMonitor.SupervisedLow | mV | Applicable if IoMode in IoAssignment is set to supervised, see section Assign I/O:s to services. Target voltage (in millivolts) for the door monitor low state when using supervised inputs. End of line resistors must be used. |
Unlock the door
There are several states for the door and its locks, and the Door Control API provides requests to change the state of the door locks. The function tdc:GetDoorState retrieves the current state of a door, including its locks and monitors. Events are dispatched upon state changes. Unlocking the door comes in three different flavors, the API requests tdc:UnlockDoor, tdc:AccessDoor and axtdc:AccessDoorWithoutUnlock:
axtdc:AccessDoorWithoutUnlock is used to temporarily grant access to a door without unlocking it. This is used for doors that can be unlocked manually without the need for the controller to unlock the door. The reason for this state is to ensure that no DoorForcedOpenAlarm is sent if the door is opened manually during the time a user is granted access.
-
tdc:UnlockDoorwill unlock the door until Door Control Service is told otherwise, for example when locked again by callingtdc:LockDoor. -
tdc:AccessDoormeans temporarily unlocking the door and it will be automatically locked again when closed or whenAccessTimeexpires if not opened, as specified in Door data structure.AccessDooris typically used when someone has been granted access to a door, and the door is unlocked for a specified time to let the person pass.axtdc:AccessDoorWithoutUnlockis used to temporarily grant access to a door without unlocking it. This is used for doors that can be unlocked manually without the need for the controller to unlock the door. The reason for this state is to ensure that noDoorForcedOpenAlarmis sent if the door is opened manually during the time a user is granted access.
The following examples illustrate simple calls to tdc:AccessDoor, tdc:UnlockDoor, and axtdc:AccessDoorWithoutUnlock using the door from the examples in Set a door representation:
Request
{
"tdc:AccessDoor": {
"Token": "Axis-00408c184bdb:1352121495.979065000"
}
}
Request
<tdc:AccessDoor>
<tdc:Token>Axis-00408c184bdb:1352121495.979065000</tdc:Token>
</tdc:AccessDoor>
Request
{
"tdc:UnlockDoor": {
"Token": "Axis-00408c184bdb:1352121495.979065000"
}
}
Request
<tdc:UnlockDoor>
<Token>Axis-00408c184bdb:1352121495.979065000</Token>
</tdc:UnlockDoor>
Request
{
"axtdc:AccessDoorWithoutUnlock": {
"Token": "Axis-00408c184bdb:1352121495.979065000"
}
}
Request
<axtdc:AccessDoorWithoutUnlock>
<axtdc:Token>Axis-00408c184bdb:1352121495.979065000</axtdc:Token>
</axtdc:AccessDoorWithoutUnlock>
In the first example, if the door is locked, then it will become accessible. The API function provides optional values for overriding settings in the door configuration, such as AccessTime and OpenTooLongTime. The second example will unlock the door instead, see Door states. AccessDoorWithoutUnlock can be used with the same optional values as AccessDoor.
No return values are given by the API functions, but the API function may raise errors, e.g. if specified token is not found.
Door states
The states and possible transitions are summarized in this section’s diagram and table.

Door states and corresponding API function
| State | API function | Description |
|---|---|---|
Locked | tdc:LockDoor | Door is locked, and will stay in this state until told otherwise. |
Unlocked | tdc:UnlockDoor | Door is unlocked, and will stay in this state until told otherwise. |
Accessed | tdc:AccessDoor | Door unlocked for a period of time, specified by AccessTime in the door configuration or in the function call. The door will return to locked after the time has elapsed or door is closed. Call to tdc:UnlockDoor is possible to keep the door unlocked. |
Blocked | tdc:BlockDoor | Door is locked and access via tdc:AccessDoor is prevented. |
LockedDown | tdc:LockDownDoor | In the lock down state, the door is inaccessible until tdc:LockDownReleaseDoor is called. All other attempts to change the door state will generate an error to the caller |
LockedOpen | tdc:LockOpenDoor | In the lock open state, the door is opened until tdc:LockOpenReleaseDoor is called. All other attempts to change the door state will generate an error to the caller. |
DoubleLocked | tdc:DoubleLockDoor | The secondary lock is locked as well. Requesting tdc:UnlockDoor will move the door state to Locked. |
The API function tdc:GetDoorInfoList lists supported door capabilities for each door and makes it possible to find out which door states to expect.
Events when door state is changed
The door control service dispatches an event each time a door changes state. One stateful event is used for all state changes, and will provide information about which door has entered what state.
The following example illustrates the event for an accessed door, where the DoorMode state is marked in bold:
{
"rowid": 133,
"token": "Axis-00408c184bdb:1383216924.148152000",
"UUID": "5581ad80-95b0-11e0-b883-00408c184bdb",
"UtcTime": "2013-10-31T10:55:24.067163Z",
"KeyValues": [
{
"Key": "State",
"Value": "Accessed",
"Tags": ["property-state", "wstype:tdc:DoorMode", "onvif-data"]
},
{
"Key": "DoorToken",
"Value": "Axis-00408c184bdb:1352121495.979065000",
"Tags": ["wstype:pt:ReferenceToken", "onvif-source"]
},
{ "Key": "topic2", "Value": "DoorMode", "Tags": [] },
{ "Key": "topic1", "Value": "State" },
{ "Key": "topic0", "Value": "Door", "Tags": [] }
],
"Tags": []
}
<axlog:Event>
<axlog:rowid>133</axlog:rowid>
<axlog:UUID>5581ad80-95b0-11e0-b883-00408c184bdb</axlog:UUID>
<axlog:UtcTime>2013-10-31T10:55:24Z</axlog:UtcTime>
<axlog:KeyValues>
<axlog:Key>State</axlog:Key>
<axlog:Value>Accessed</axlog:Value>
<axlog:Tags>property-state</axlog:Tags>
<axlog:Tags>wstype:tdc:DoorMode</axlog:Tags>
<axlog:Tags>onvif-data</axlog:Tags>
</axlog:KeyValues>
<axlog:KeyValues>
<axlog:Key>DoorToken</axlog:Key>
<axlog:Value>Axis-00408c184bdb:1352121495.979065000</axlog:Value>
<axlog:Tags>wstype:pt:ReferenceToken</axlog:Tags>
<axlog:Tags>onvif-source</axlog:Tags>
</axlog:KeyValues>
<axlog:KeyValues>
<axlog:Key>topic2</axlog:Key>
<axlog:Value>DoorMode</axlog:Value>
</axlog:KeyValues>
<axlog:KeyValues>
<axlog:Key>topic1</axlog:Key>
<axlog:Value>State</axlog:Value>
</axlog:KeyValues>
<axlog:KeyValues>
<axlog:Key>topic0</axlog:Key>
<axlog:Value>Door</axlog:Value>
</axlog:KeyValues>
</axlog:Event>
DoorMode gives the new state of the door. At start-up of the door controller the initial state will be dispatched. Analogously, there will also be stateful events dispatched for the door and lock monitors, giving the entered monitor state. For example, the door monitor event gives the new door monitor state, which might beOpen, Closed, or, possibly Fault. For example:
{
"rowid": 372,
"token": "Axis-00408c184c74:1383299532.611446000",
"UUID": "5581ad80-95b0-11e0-b883-00408c184c74",
"UtcTime": "2013-11-01T09:52:12.412969Z",
"KeyValues": [
{
"Key": "State",
"Value": "Open",
"Tags": ["property-state", "wstype:tdc:DoorPhysicalState", "onvif-data"]
},
{
"Key": "DoorToken",
"Value": "Axis-00408c184bdb:1352121495.979065000",
"Tags": ["wstype:pt:ReferenceToken", "onvif-source"]
},
{ "Key": "topic2", "Value": "DoorPhysicalState", "Tags": [] },
{ "Key": "topic1", "Value": "State", "Tags": [] },
{ "Key": "topic0", "Value": "Door", "Tags": [] }
],
"Tags": []
}
<axlog:Event>
<axlog:rowid>372</axlog:rowid>
<axlog:UUID>5581ad80-95b0-11e0-b883-00408c184c74</axlog:UUID>
<axlog:UtcTime>2013-11-01T09:52:12Z</axlog:UtcTime>
<axlog:KeyValues>
<axlog:Key>State</axlog:Key>
<axlog:Value>Open</axlog:Value>
<axlog:Tags>property-state</axlog:Tags>
<axlog:Tags>wstype:tdc:DoorPhysicalState</axlog:Tags>
<axlog:Tags>onvif-data</axlog:Tags>
</axlog:KeyValues>
<axlog:KeyValues>
<axlog:Key>DoorToken</axlog:Key>
<axlog:Value>Axis-00408c184bdb:1352121495.979065000</axlog:Value>
<axlog:Tags>wstype:pt:ReferenceToken</axlog:Tags>
<axlog:Tags>onvif-source</axlog:Tags>
</axlog:KeyValues>
<axlog:KeyValues>
<axlog:Key>topic2</axlog:Key>
<axlog:Value>DoorPhysicalState</axlog:Value>
</axlog:KeyValues>
<axlog:KeyValues>
<axlog:Key>topic1</axlog:Key>
<axlog:Value>State</axlog:Value>
</axlog:KeyValues>
<axlog:KeyValues>
<axlog:Key>topic0</axlog:Key>
<axlog:Value>Door</axlog:Value>
</axlog:KeyValues>
</axlog:Event>
Manage doors with priority levels
Door actions can be prioritized using a PriorityConfiguration. By setting different priority levels for different actions, it is possible to override door actions, for example to unlock doors in emergency situations.
As an example, consider a door that has Locked as its default state but that should be unlocked in emergency situations. This can be achieved by using two priority levels. The default action, locked, is set to have a low priority while a higher priority is used for actions sent in emergency situations. If, in an emergency situation, an unlock action is sent and the unlock action has a higher priority than lock, then unlock overrides lock and the door is unlocked.
When the emergency situation has been solved, the unlock action can be released using the API function axtdc:ReleaseDoor. Releasing an action with a given priority level removes the action from the PriorityConfiguration array and the next action, in order of priority, will automatically take control of the door. If all actions are released, the door will automatically fall back to the Locked state.
The default priority configuration in the door control service is called Standard and has only one priority level. Use Standard if priority levels are not needed.
Setting a priority configuration
The priority configuration PriorityConfiguration array specifies priorities for different door actions. To set a priority configuration, use the API function axtdc:SetPriorityConfiguration. The following example shows a setup with five levels, from Highest to Lowest:
{
"PriorityConfiguration": [
{
"DefaultPriority": "Medium",
"DoorPriorityAction": [
{ "DoorAction": "Release", "PriorityLevel": "Highest" },
{ "DoorAction": "Release", "PriorityLevel": "High" },
{ "DoorAction": "Release", "PriorityLevel": "Medium" },
{ "DoorAction": "Release", "PriorityLevel": "Low" },
{ "DoorAction": "Lock", "PriorityLevel": "Lowest" }
],
"Name": "Prio Configuration Name",
"token": "Axis-00408c184bdb:1352207054.721964001"
}
]
}
<axtdc:PriorityConfiguration token="Axis-00408c184bdb:1352207054.721964001">
<axtdc:Name>Prio Configuration Name</axtdc:Name>
<axtdc:DefaultPriority>Medium</axtdc:DefaultPriority>
<axtdc:DoorPriorityAction>
<axtdc:DoorAction>Release</axtdc:DoorAction>
<axtdc:PriorityLevel>Highest</axtdc:PriorityLevel>
</axtdc:DoorPriorityAction>
<axtdc:DoorPriorityAction>
<axtdc:DoorAction>Release</axtdc:DoorAction>
<axtdc:PriorityLevel>High</axtdc:PriorityLevel>
</axtdc:DoorPriorityAction>
<axtdc:DoorPriorityAction>
<axtdc:DoorAction>Release</axtdc:DoorAction>
<axtdc:PriorityLevel>Medium</axtdc:PriorityLevel>
</axtdc:DoorPriorityAction>
<axtdc:DoorPriorityAction>
<axtdc:DoorAction>Release</axtdc:DoorAction>
<axtdc:PriorityLevel>Low</axtdc:PriorityLevel>
</axtdc:DoorPriorityAction>
<axtdc:DoorPriorityAction>
<axtdc:DoorAction>Lock</axtdc:DoorAction>
<axtdc:PriorityLevel>Lowest</axtdc:PriorityLevel>
</axtdc:DoorPriorityAction>
</axtdc:PriorityConfiguration>
The DoorPriorityAction array is a list of priorities for the door. The items in the array must be specified in order of priority so that the first item in the array has the highest priority and the last item has the lowest priority. The PriorityLevel is only a name and does not affect the priority order. In addition to the PriorityLevel, each item has an initial DoorAction which is the state that will be applied until a door action request has been sent. State Release means that the priority does not have a set action.
The DefaultPriority item specifies the priority level to use if no priority is specified in the door action request. The following example uses the Door from section Set a door representation, updated with the necessary token (marked in bold) to apply the PriorityConfiguration above:
{
"Door": [
{
"token": "Axis-00408c184bdb:1352121495.979065000",
"Name": "Front Door",
"Description": "Front door description",
"AccessTime": "PT10S",
"DefaultPriority": "",
"HeartbeatInterval": "PT0S",
"OpenTooLongTime": "PT10S",
"PreAlarmTime": "PT5S",
"ExtendedAccessTime": "PT30S",
"ExtendedOpenTooLongTime": "PT30S",
"PriorityConfiguration": "Axis-00408c184bdb:1352207054.721964001"
}
]
}
<axtdc:Door token="Axis-00408c184bdb:1352121495.979065000">
<axtdc:Name>Front Door</axtdc:Name>
<axtdc:Description>Front door description</axtdc:Description>
<axtdc:AccessTime>PT10S</axtdc:AccessTime>
<axtdc:OpenTooLongTime>PT10S</axtdc:OpenTooLongTime>
<axtdc:PreAlarmTime>PT5S</axtdc:PreAlarmTime>
<axtdc:ExtendedAccessTime>PT30S</axtdc:ExtendedAccessTime>
<axtdc:ExtendedOpenTooLongTime>PT30S</axtdc:ExtendedOpenTooLongTime>
<axtdc:HeartbeatInterval>PT0S</axtdc:HeartbeatInterval>
<axtdc:PriorityConfiguration>Axis-00408c184bdb:1352207054.721964001</axtdc:PriorityConfiguration>
<axtdc:DefaultPriority />
</axtdc:Door>
Using door priorities
The current states of a door, including priority levels, can be retrieved using the API function axtdc:GetDoorPriorityState. The following example shows the states for a door with the priority configuration from section Setting a priority configuration:
Request
{
"axtdc:GetDoorPriorityState": {
"Token": "Axis-00408c184bdb:1352121495.979065000"
}
}
Request
<axtdc:GetDoorPriorityState>
<axtdc:Token>Axis-00408c184bdb:1352121495.979065000</axtdc:Token>
</axtdc:GetDoorPriorityState>
Response
{
"DoorPriorityAction": [
{ "DoorAction": "Release", "PriorityLevel": "Highest" },
{ "DoorAction": "Release", "PriorityLevel": "High" },
{ "DoorAction": "Release", "PriorityLevel": "Medium" },
{ "DoorAction": "Release", "PriorityLevel": "Low" },
{ "DoorAction": "Lock", "PriorityLevel": "Lowest" }
]
}
Response
<axtdc:GetDoorPriorityStateResponse>
<axtdc:DoorPriorityAction>
<axtdc:PriorityLevel>Highest</axtdc:PriorityLevel>
<axtdc:Reason />
<axtdc:DoorAction>Release</axtdc:DoorAction>
</axtdc:DoorPriorityAction>
<axtdc:DoorPriorityAction>
<axtdc:PriorityLevel>High</axtdc:PriorityLevel>
<axtdc:Reason />
<axtdc:DoorAction>Release</axtdc:DoorAction>
</axtdc:DoorPriorityAction>
<axtdc:DoorPriorityAction>
<axtdc:PriorityLevel>Medium</axtdc:PriorityLevel>
<axtdc:Reason />
<axtdc:DoorAction>Release</axtdc:DoorAction>
</axtdc:DoorPriorityAction>
<axtdc:DoorPriorityAction>
<axtdc:PriorityLevel>Low</axtdc:PriorityLevel>
<axtdc:Reason />
<axtdc:DoorAction>Release</axtdc:DoorAction>
</axtdc:DoorPriorityAction>
<axtdc:DoorPriorityAction>
<axtdc:PriorityLevel>Lowest</axtdc:PriorityLevel>
<axtdc:Reason />
<axtdc:DoorAction>Lock</axtdc:DoorAction>
</axtdc:DoorPriorityAction>
</axtdc:GetDoorPriorityStateResponse>
In this case, the door is locked. State Release means that the priority does not have a set action. Sending a door action request with a specified priority level will replace the door action for the priority with that level. If the priority level is omitted, the default priority DefaultPriority will be used so that the submitted action replaces the action for the default priority level.
The following example shows a tdc:UnlockDoor request with priority level medium. The example also shows the response to axtdc:GetDoorPriorityState with relevant changes marked in bold.
Request
{
"tdc:UnlockDoor": {
"Token": "Axis-00408c184bdb:1352121495.979065000",
"PriorityLevel": "Medium"
}
}
Request
<tdc:UnlockDoor>
<PriorityLevel>Medium</PriorityLevel>
<Token>Axis-00408c184bdb:1352121495.979065000</Token>
</tdc:UnlockDoor>
Response
{
"DoorPriorityAction": [
{ "DoorAction": "Release", "PriorityLevel": "Highest" },
{ "DoorAction": "Release", "PriorityLevel": "High" },
{ "DoorAction": "Unlock", "PriorityLevel": "Medium" },
{ "DoorAction": "Release", "PriorityLevel": "Low" },
{ "DoorAction": "Lock", "PriorityLevel": "Lowest" }
]
}
Response
<axtdc:GetDoorPriorityStateResponse>
<axtdc:DoorPriorityAction>
<axtdc:PriorityLevel>Highest</axtdc:PriorityLevel>
<axtdc:Reason />
<axtdc:DoorAction>Release</axtdc:DoorAction>
</axtdc:DoorPriorityAction>
<axtdc:DoorPriorityAction>
<axtdc:PriorityLevel>High</axtdc:PriorityLevel>
<axtdc:Reason />
<axtdc:DoorAction>Release</axtdc:DoorAction>
</axtdc:DoorPriorityAction>
<axtdc:DoorPriorityAction>
<axtdc:PriorityLevel>Medium</axtdc:PriorityLevel>
<axtdc:Reason />
<axtdc:DoorAction>Unlock</axtdc:DoorAction>
</axtdc:DoorPriorityAction>
<axtdc:DoorPriorityAction>
<axtdc:PriorityLevel>Low</axtdc:PriorityLevel>
<axtdc:Reason />
<axtdc:DoorAction>Release</axtdc:DoorAction>
</axtdc:DoorPriorityAction>
<axtdc:DoorPriorityAction>
<axtdc:PriorityLevel>Lowest</axtdc:PriorityLevel>
<axtdc:Reason />
<axtdc:DoorAction>Lock</axtdc:DoorAction>
</axtdc:DoorPriorityAction>
</axtdc:GetDoorPriorityStateResponse>
The door is now unlocked.
To remove an action from the DoorPriorityAction array, use the API function axtdc:ReleaseDoor with desired priority level to release the action for the priority with that level. In the following example, the Unlock action is released.
Request
{
"axtdc:ReleaseDoor": {
"Token": "Axis-00408c184bdb:1352121495.979065000",
"PriorityLevel": "Medium"
}
}
Request
<axtdc:ReleaseDoor>
<axtdc:PriorityLevel>Medium</axtdc:PriorityLevel>
<axtdc:Token>Axis-00408c184bdb:1352121495.979065000</axtdc:Token>
</axtdc:ReleaseDoor>
Response
{
"DoorPriorityAction": [
{ "DoorAction": "Release", "PriorityLevel": "Highest" },
{ "DoorAction": "Release", "PriorityLevel": "High" },
{ "DoorAction": "Release", "PriorityLevel": "Medium" },
{ "DoorAction": "Release", "PriorityLevel": "Low" },
{ "DoorAction": "Lock", "PriorityLevel": "Lowest" }
]
}
Response
<axtdc:GetDoorPriorityStateResponse>
<axtdc:DoorPriorityAction>
<axtdc:PriorityLevel>Highest</axtdc:PriorityLevel>
<axtdc:Reason />
<axtdc:DoorAction>Release</axtdc:DoorAction>
</axtdc:DoorPriorityAction>
<axtdc:DoorPriorityAction>
<axtdc:PriorityLevel>High</axtdc:PriorityLevel>
<axtdc:Reason />
<axtdc:DoorAction>Release</axtdc:DoorAction>
</axtdc:DoorPriorityAction>
<axtdc:DoorPriorityAction>
<axtdc:PriorityLevel>Medium</axtdc:PriorityLevel>
<axtdc:Reason />
<axtdc:DoorAction>Release</axtdc:DoorAction>
</axtdc:DoorPriorityAction>
<axtdc:DoorPriorityAction>
<axtdc:PriorityLevel>Low</axtdc:PriorityLevel>
<axtdc:Reason />
<axtdc:DoorAction>Release</axtdc:DoorAction>
</axtdc:DoorPriorityAction>
<axtdc:DoorPriorityAction>
<axtdc:PriorityLevel>Lowest</axtdc:PriorityLevel>
<axtdc:Reason />
<axtdc:DoorAction>Lock</axtdc:DoorAction>
</axtdc:DoorPriorityAction>
</axtdc:GetDoorPriorityStateResponse>
Door open within specific time period
It is possible to set up doors that should be in a specific state at a specific time. For example, the front door of an office building should automatically be unlocked during office hours. This is achieved by using door schedule configurations.
As described in the Schedule Service section Schedule service, the format is iCalendar compliant which allows for schedules occurring once, at recurring times, and with optional start and/or stop dates. It is possible to specify both when schedule shall be active and when there should be an exception.
The schedule for a door is set using the door schedule configuration, DoorScheduleConfiguration. It is possible, and sometimes necessary, to have more than one schedule referenced from each configuration.
A door schedule configuration entry will have an associated enter action, which is performed when the schedule becomes active. Note that once a schedule becomes inactive, there is no corresponding exit or leave behavior: this must be handled by using priorities or having several overlapping schedules. For example, if the door should open at certain time one schedule could have Unlock as the enter action, while another, overlapping, schedule has Lock as its enter action.
Setting schedule configuration
A door schedule configuration is set by calling axtdc:SetDoorScheduleConfiguration. The following is a simple example of a configuration using the standard_always schedule:
{
"DoorScheduleConfiguration": [
{
"Name": "Door Schedule Name",
"Description": "This is a description for schedule configuration",
"DoorSchedule": [
{
"PriorityLevel": "",
"ScheduledState": [{ "EnterAction": "Lock", "ScheduleToken": ["standard_always"] }]
}
],
"token": "Axis-00408c184bdb:1331557205.709394000"
}
]
}
<axtdc:DoorScheduleConfiguration token="Axis-00408c184bdb:1331557205.709394000">
<axtdc:Name>Door Schedule Name</axtdc:Name>
<axtdc:Description>
This is a description for schedule
configuration
</axtdc:Description>
<axtdc:DoorSchedule>
<axtdc:PriorityLevel />
<axtdc:ScheduledState>
<axtdc:ScheduleToken>standard_always</axtdc:ScheduleToken>
<axtdc:EnterAction>Lock</axtdc:EnterAction>
</axtdc:ScheduledState>
</axtdc:DoorSchedule>
</axtdc:DoorScheduleConfiguration>
The ScheduledState array contains the schedule, referenced by the ScheduleToken, and the enter action. The ScheduleState list will be verified in order - the first active schedule’s EnterAction will be used.
The DoorSchedule list contains the ScheduledState list and the assigned priority level. Each entry in the DoorSchedule list will be validated, and if the schedule is active, the DoorPriorityAction will be updated with the EnterAction at the specified priority level. PriorityLevel can be left empty if unused, but, if so, the DoorSchedule array is required to contain only one element.
A DoorScheduleConfiguration which uses a schedule that is already active, like the standard_always, means that there will not be any enter action. However, when setting the DoorScheduleConfiguration, the enter action is generated, and similarly when restarting the door controller.
To start using this schedule for a door, the DoorConfiguration needs to be updated with the token of the DoorScheduleConfiguration (Default DoorConfiguration assumed as parts are omitted here):
{
"DoorConfiguration": [
{
"token": "Axis-00408c184bdb:1352121495.979065000",
"DeviceUUID": "5581ad80-95b0-11e0-b883-00408c184bdb",
"DoorScheduleConfiguration": "Axis-00408c184bdb:1331557205.709394000"
}
]
}
<axtdc:DoorConfiguration token="Axis-00408c184bdb:1352121495.979065000">
<axtdc:DeviceUUID />
<axtdc:DoorScheduleConfiguration>Axis-00408c184bdb:1331557205.709394000</axtdc:DoorScheduleConfiguration>
</axtdc:DoorConfiguration>
Door open during office hours
Returning to the use case where a door should be open during office hours, there are a few ways to configure this. The following examples illustrate different ways of setting it up. The examples assume that there exists a schedule called office_hours in the Schedule Service, in addition to the defaultstandard_always.
Using several schedules listed in priority order:
{
"DoorScheduleConfiguration": [
{
"Name": "Door Schedule Name",
"Description": "This is a description for schedule configuration",
"DoorSchedule": [
{
"PriorityLevel": "",
"ScheduledState": [
{ "EnterAction": "Unlock", "ScheduleToken": ["office_hours"] },
{ "EnterAction": "Lock", "ScheduleToken": ["standard_always"] }
]
}
],
"token": "Axis-00408c184bdb:1331557205.709394000"
}
]
}
<axtdc:DoorScheduleConfiguration token="Axis-00408c184bdb:1331557205.709394000">
<axtdc:Name>Door Schedule Name</axtdc:Name>
<axtdc:Description>
This is a description for schedule
configuration
</axtdc:Description>
<axtdc:DoorSchedule>
<axtdc:PriorityLevel />
<axtdc:ScheduledState>
<axtdc:EnterAction>Unlock</axtdc:EnterAction>
<axtdc:ScheduleToken>office_hours</axtdc:ScheduleToken>
</axtdc:ScheduledState>
<axtdc:ScheduledState>
<axtdc:EnterAction>Lock</axtdc:EnterAction>
<axtdc:ScheduleToken>standard_always</axtdc:ScheduleToken>
</axtdc:ScheduledState>
</axtdc:DoorSchedule>
</axtdc:DoorScheduleConfiguration>
This DoorScheduleConfiguration unlocks the door whenever office_hours starts, as this ScheduledState overrides thestandard_always. When office_hours becomes inactive, the next ScheduledState is evaluated and active again and the door will be locked by the EnterAction.
Using priority levels
The door has the following priority levels and initial states:
{
"DoorPriorityAction": [
{ "DoorAction": "Release", "PriorityLevel": "High" },
{ "DoorAction": "Release", "PriorityLevel": "Medium" },
{ "DoorAction": "Lock", "PriorityLevel": "Low" }
]
}
<DoorPriorityAction>
<DoorAction>Release</DoorAction>
<PriorityLevel>High</PriorityLevel>
</DoorPriorityAction>
<DoorPriorityAction>
<DoorAction>Release</DoorAction>
<PriorityLevel>Medium</PriorityLevel>
</DoorPriorityAction>
<DoorPriorityAction>
<DoorAction>LockDoor<Action>
<PriorityLevel>Low<PriorityLevel>
</DoorPriorityAction>
Using the DoorScheduleConfiguration works as follows, this time also taking into account a schedule where public holidays (called public_holidays) should have locked doors:
{
"DoorScheduleConfiguration": [
{
"Name": "Door Schedule Name",
"Description": "This is a description for schedule configuration",
"DoorSchedule": [
{
"PriorityLevel": "Medium",
"ScheduledState": [
{ "EnterAction": "Unlock", "ScheduleToken": ["office_hours"] },
{ "EnterAction": "Release", "ScheduleToken": ["standard_always"] }
]
},
{
"PriorityLevel": "High",
"ScheduledState": [
{ "EnterAction": "Lock", "ScheduleToken": ["public_holidays"] },
{ "EnterAction": "Release", "ScheduleToken": ["standard_always"] }
]
}
],
"token": "Axis-00408c184bdb:1331557205.709394000"
}
]
}
<axtdc:DoorScheduleConfiguration token="Axis-00408c184bdb:1331557205.709394000">
<axtdc:Name>Door Schedule Name</axtdc:Name>
<axtdc:Description>
This is a description for schedule
configuration
</axtdc:Description>
<axtdc:DoorSchedule>
<axtdc:PriorityLevel>High</axtdc:PriorityLevel>
<axtdc:ScheduledState>
<axtdc:EnterAction>Lock</axtdc:EnterAction>
<axtdc:ScheduleToken>public_holidays</axtdc:ScheduleToken>
</axtdc:ScheduledState>
<axtdc:ScheduledState>
<axtdc:EnterAction>Release</axtdc:EnterAction>
<axtdc:ScheduleToken>standard_always</axtdc:ScheduleToken>
</axtdc:ScheduledState>
</axtdc:DoorSchedule>
</axtdc:DoorScheduleConfiguration>
When the office_hours or public_holidays are inactive, the priority levels will be released. If office_hours becomes active the door will be unlocked, because that will have highest priority. This will hold until the public_holiday schedule becomes active, since it overrides all other scheduled states, and the door is/remains locked. See the following priority levels where all schedules are active:
{
"DoorPriorityAction": [
{ "DoorAction": "Lock", "PriorityLevel": "High" },
{ "DoorAction": "Unlock", "PriorityLevel": "Medium" },
{ "DoorAction": "Lock", "PriorityLevel": "Low" }
]
}
<DoorPriorityAction>
<DoorAction>Lock</DoorAction>
<PriorityLevel>High</PriorityLevel>
</DoorPriorityAction>
<DoorPriorityAction>
<DoorAction>Unlock</DoorAction>
<PriorityLevel>Medium</PriorityLevel>
</DoorPriorityAction>
<DoorPriorityAction>
<DoorAction>Lock</DoorAction>
<PriorityLevel>Low</PriorityLevel>
</DoorPriorityAction>
Door priorities and door schedules
The example in this section shows how priority levels and schedules can be used together. Consider a door that should be unlocked during office hours and locked outside office hours. In an emergency situation, it should be possible to temporarily override the default behavior and unlock or lock the door.
This can be achieved by using two priority levels and two schedules. The configuration contains:
- A
DoorScheduleConfigurationwith two schedules and priority level Normal. TheDoorScheduleConfigurationkeeps the door unlocked during office hours and locked outside office hours. - A
PriorityConfigurationwith priority levels high and normal. The high level makes it possible to override theDoorScheduleConfiguration. - A
Doorand aDoorConfiguration.
In an emergency situation during nighttime the door can be temporarily unlocked by sending tdc:UnlockDoor with priority high. Once the emergency is resolved, the high priority state can be released using axtdc:ReleaseDoor. The normal priority will then take precedence and the door will be locked/unlocked according to the DoorScheduleConfiguration.
The following steps illustrate how to set up this configuration. Here, the tokens are manually created tokens with user-friendly names. If not specified in the request, the token is created automatically and returned in the response.
Step 1: Use axtdc:SetPriorityConfiguration to create the PriorityConfiguration. The priority levels are listed in priority order, so the first level, here called High, has highest priority. The second level Normal has lower priority. The DoorAction is the initial door action for the priority level. Release means that the level does not have any assigned action, that is, that the level is inactive.
Request
{
"axtdc:SetPriorityConfiguration": {
"PriorityConfiguration": [
{
"DefaultPriority": "Normal",
"DoorPriorityAction": [
{
"PriorityLevel": "High",
"DoorAction": "Release"
},
{
"PriorityLevel": "Normal",
"DoorAction": "Lock"
}
],
"Name": "My Priority Configuration",
"token": "myPriorityConfiguration"
}
]
}
}
Request
<axtdc:SetPriorityConfiguration>
<axtdc:PriorityConfiguration token="myPriorityConfiguration">
<axtdc:DefaultPriority>Normal</axtdc:DefaultPriority>
<axtdc:DoorPriorityAction>
<axtdc:PriorityLevel>High</axtdc:PriorityLevel>
<axtdc:DoorAction>Release</axtdc:DoorAction>
</axtdc:DoorPriorityAction>
<axtdc:DoorPriorityAction>
<axtdc:PriorityLevel>Normal</axtdc:PriorityLevel>
<axtdc:DoorAction>Lock</axtdc:DoorAction>
</axtdc:DoorPriorityAction>
<axtdc:Name>My Priority Configuration</axtdc:Name>
</axtdc:PriorityConfiguration>
</axtdc:SetPriorityConfiguration>
Step 2: Use axtdc:SetDoor to create the Door. The myPriorityConfiguration token links the PriorityConfiguration to the Door.
Request
{
"axtdc:SetDoor": {
"Door": [
{
"Name": "My Door",
"Description": "My door description",
"AccessTime": "PT7S",
"DefaultPriority": "Normal",
"OpenTooLongTime": "PT30S",
"PreAlarmTime": "PT10S",
"ExtendedAccessTime": "PT30S",
"ExtendedOpenTooLongTime": "PT60S",
"HeartbeatInterval": "PT600S",
"token": "myDoor",
"PriorityConfiguration": "myPriorityConfiguration"
}
]
}
}
Request
<axtdc:SetDoor>
<axtdc:Door token="myDoor">
<axtdc:Name>My Door</axtdc:Name>
My Door
<axtdc:Description>My door description</axtdc:Description>
<axtdc:AccessTime>PT7S</axtdc:AccessTime>
<axtdc:DefaultPriority>Normal</axtdc:DefaultPriority>
<axtdc:OpenTooLongTime>PT30S</axtdc:OpenTooLongTime>
<axtdc:PreAlarmTime>PT10S</axtdc:PreAlarmTime>
<axtdc:ExtendedAccessTime>PT30S</axtdc:ExtendedAccessTime>
<axtdc:ExtendedOpenTooLongTime>PT60S</axtdc:ExtendedOpenTooLongTime>
<axtdc:HeartbeatInterval>PT600S</axtdc:HeartbeatInterval>
<axtdc:PriorityConfiguration>myPriorityConfiguration</axtdc:PriorityConfiguration>
</axtdc:Door>
</axtdc:SetDoor>
Step 3: Use axtdc:SetDoorScheduleConfiguration to create the DoorScheduleConfiguration.
The schedules standard_office_hours and standard_always are listed in priority order and each has an associated door action. When the first schedule, standard_office_hours, is active, the door will be unlocked. When standard_office_hours is inactive, the second schedule standard_always takes precedence and the door will be locked. The priority level Normal links the door schedule to the Normal priority in the PriorityConfiguration.
Request
{
"axtdc:SetDoorScheduleConfiguration": {
"DoorScheduleConfiguration": [
{
"DoorSchedule": [
{
"PriorityLevel": "Normal",
"ScheduledState": [
{
"ScheduleToken": ["standard_office_hours"],
"EnterAction": "Unlock"
},
{
"ScheduleToken": ["standard_always"],
"EnterAction": "Lock"
}
]
}
],
"token": "myDoorScheduleConfiguration",
"Name": "My Door Schedule Configuration",
"Description": "My door schedule configuration description"
}
]
}
}
Request
<axtdc:SetDoorScheduleConfiguration>
<axtdc:DoorScheduleConfiguration token="myDoorScheduleConfiguration">
<axtdc:DoorSchedule>
<axtdc:PriorityLevel>Normal</axtdc:PriorityLevel>
<axtdc:ScheduledState>
<axtdc:ScheduleToken>standard_office_hours</axtdc:ScheduleToken>
<axtdc:EnterAction>Unlock</axtdc:EnterAction>
</axtdc:ScheduledState>
<axtdc:ScheduledState>
<axtdc:ScheduleToken>standard_always</axtdc:ScheduleToken>
<axtdc:EnterAction>Lock</axtdc:EnterAction>
</axtdc:ScheduledState>
<axtdc:Name>My Door Schedule Configuration</axtdc:Name>
<axtdc:Description>My door schedule configuration description</axtdc:Description>
</axtdc:DoorSchedule>
</axtdc:DoorScheduleConfiguration>
</axtdc:SetDoorScheduleConfiguration>
Step 4: Use axtdc:SetDoorConfiguration to create a DoorConfiguration that connects the Door and the DoorScheduleConfiguration.
Request
{
"axtdc:SetDoorConfiguration": [
{
"DoorConfiguration": [
{
"token": "Axis-accc8ea52514:1550758557.437969000",
"DeviceUUID": "",
"Configuration": [
{
"Name": "DoorMonitor.ValueWhenClosed",
"Value": "Input Ground"
},
{
"Name": "Lock.LockWhenDoorOpens",
"Value": "true"
},
{
"Name": "DebounceTime",
"Value": "0"
},
{
"Name": "Lock.BoltOutTime",
"Value": "0"
},
{
"Name": "DoorMonitor.ValueWhenOpen",
"Value": "Input Open"
},
{
"Name": "Lock.RelayStateWhenLocked",
"Value": "Open"
},
{
"Name": "Lock.BoltInTime",
"Value": "0"
},
{
"Name": "Lock.Type",
"Value": "Relay"
},
{
"Name": "DoubleLock.Type",
"Value": "None"
},
{
"Name": "Lock.LockWhenDoorOpensDelay",
"Value": "3000"
},
{
"Name": "Lock.Protocol",
"Value": "None"
},
{
"Name": "Lock.Hardware.Address",
"Value": "0"
},
{
"Name": "Lock.Hardware.Id",
"Value": "0"
},
{
"Name": "Lock.ValueWhenLocked",
"Value": "Gnd"
},
{
"Name": "Lock.ValueWhenUnlocked",
"Value": "12V"
},
{
"Name": "Lock.LockMonitor.ValueWhenLocked",
"Value": "None"
},
{
"Name": "Lock.LockMonitor.ValueWhenUnlocked",
"Value": "None"
},
{
"Name": "DoubleLock.ValueWhenLocked",
"Value": "Gnd"
},
{
"Name": "DoubleLock.ValueWhenUnlocked",
"Value": "12V"
},
{
"Name": "DoubleLock.RelayStateWhenLocked",
"Value": "Open"
},
{
"Name": "DoubleLock.BoltOutTime",
"Value": "700"
},
{
"Name": "DoubleLock.BoltInTime",
"Value": "700"
},
{
"Name": "DoubleLock.LockMonitor.ValueWhenLocked",
"Value": "None"
},
{
"Name": "DoubleLock.LockMonitor.ValueWhenUnlocked",
"Value": "None"
},
{
"Name": "DoorMonitor.SupervisedHigh",
"Value": "1855"
},
{
"Name": "DoorMonitor.SupervisedLow",
"Value": "740"
},
{
"Name": "DoorMonitor.SupervisedShort",
"Value": "0"
},
{
"Name": "DoorMonitor.SupervisedCut",
"Value": "2755"
},
{
"Name": "DoorMonitor.Type",
"Value": "None"
},
{
"Name": "DoorMonitor.Protocol",
"Value": "None"
},
{
"Name": "DoorMonitor.Hardware.Address",
"Value": "0"
},
{
"Name": "UserData",
"Value": "0"
},
{
"Name": "Lock.TCPIP.Port",
"Value": "0"
},
{
"Name": "Lock.TCPIP.Address",
"Value": ""
},
{
"Name": "Lock.Hub.Hardware.Address",
"Value": ""
},
{
"Name": "Door.Type",
"Value": "Regular"
}
]
}
],
"DoorScheduleConfiguration": "myDoorScheduleConfiguration"
}
]
}
Request
<axtdc:SetDoorConfiguration>
<axtdc:DoorConfiguration>
token="Axis-accc8ea52514:1550758557.437969000"
<axtdc:DeviceUUID />
<axtdc:Configuration>
<ns0:Name>DoorMonitor.ValueWhenClosed</ns0:Name>
<ns0:Value>Input Ground</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>Lock.LockWhenDoorOpens</ns0:Name>
<ns0:Value>true</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>DebounceTime</ns0:Name>
<ns0:Value>0</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>Lock.BoltOutTime</ns0:Name>
<ns0:Value>0</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>DoorMonitor.ValueWhenOpen</ns0:Name>
<ns0:Value>Input Open</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>Lock.RelayStateWhenLocked</ns0:Name>
<ns0:Value>Open</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>Lock.BoltInTime</ns0:Name>
<ns0:Value>0</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>Lock.Type</ns0:Name>
<ns0:Value>Relay</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>DoubleLock.Type</ns0:Name>
<ns0:Value>None</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>Lock.LockWhenDoorOpensDelay</ns0:Name>
<ns0:Value>3000</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>Lock.Protocol</ns0:Name>
<ns0:Value>None</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>Lock.Hardware.Address</ns0:Name>
<ns0:Value>0</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>Lock.Hardware.Id</ns0:Name>
<ns0:Value>0</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.LockMonitor.ValueWhenLocked</ns0:Name>
<ns0:Value>None</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>Lock.LockMonitor.ValueWhenUnlocked</ns0:Name>
<ns0:Value>None</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>DoubleLock.ValueWhenLocked</ns0:Name>
<ns0:Value>Gnd</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>DoubleLock.ValueWhenUnlocked</ns0:Name>
<ns0:Value>12V</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>DoubleLock.RelayStateWhenLocked</ns0:Name>
<ns0:Value>Open</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>DoubleLock.BoltOutTime</ns0:Name>
<ns0:Value>700</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>DoubleLock.BoltInTime</ns0:Name>
<ns0:Value>700</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>DoubleLock.LockMonitor.ValueWhenLocked</ns0:Name>
<ns0:Value>None</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>DoubleLock.LockMonitor.ValueWhenUnlocked</ns0:Name>
<ns0:Value>None</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>DoorMonitor.SupervisedHigh</ns0:Name>
<ns0:Value>1855</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>DoorMonitor.SupervisedLow</ns0:Name>
<ns0:Value>740</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>DoorMonitor.SupervisedShort</ns0:Name>
<ns0:Value>0</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>DoorMonitor.SupervisedCut</ns0:Name>
<ns0:Value>2755</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>DoorMonitor.Type</ns0:Name>
<ns0:Value>None</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>DoorMonitor.Protocol</ns0:Name>
<ns0:Value>None</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>DoorMonitor.Hardware.Address</ns0:Name>
<ns0:Value>0</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>UserData</ns0:Name>
<ns0:Value>0</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>Lock.TCPIP.Port</ns0:Name>
<ns0:Value>0</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>Lock.TCPIP.Address</ns0:Name>
<ns0:Value>""</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>Lock.Hub.Hardware.Address</ns0:Name>
<ns0:Value>""</ns0:Value>
</axtdc:Configuration>
<axtdc:Configuration>
<ns0:Name>Door.Type</ns0:Name>
<ns0:Value>Regular</ns0:Value>
</axtdc:Configuration>
</axtdc:DoorConfiguration>
<axtdc:DoorScheduleConfiguration />
</axtdc:SetDoorConfiguration>
The configuration is now complete. To verify the configuration, set the time to inside office hours and use axtdc:GetDoorPriorityState to get the door’s current state.
Request
{
"axtdc:GetDoorPriorityState": {
"Token": "myDoor"
}
}
<axtdc:GetDoorPriorityState>
<axtdc:Token>myDoor</axtdc:Token>
</axtdc:GetDoorPriorityState>
Response
{
"DoorPriorityAction": [
{
"PriorityLevel": "High",
"Reason": "",
"DoorAction": "Release"
},
{
"PriorityLevel": "Normal",
"Reason": "Schedule",
"DoorAction": "Unlock"
}
]
}
Response
<axtdc:GetDoorPriorityStateResponse>
<axtdc:DoorPriorityAction>
<axtdc:PriorityLevel>High</axtdc:PriorityLevel>
<axtdc:Reason />
<axtdc:DoorAction>Release</axtdc:DoorAction>
</axtdc:DoorPriorityAction>
<axtdc:DoorPriorityAction>
<axtdc:PriorityLevel>Normal</axtdc:PriorityLevel>
<axtdc:Reason>Schedule</axtdc:Reason>
<axtdc:DoorAction>Unlock</axtdc:DoorAction>
</axtdc:DoorPriorityAction>
</axtdc:GetDoorPriorityStateResponse>
The response shows that priority level High is released. Priority level Normal is therefore active and the door is unlocked because the time is inside office hours. For priority level Normal, Reason is set to Schedule. This is because the DoorScheduleConfiguration was configured with priority level Normal.
To continue verifying the configuration, set the time to outside office hours and send a new axtdc:GetDoorPriorityState. The DoorAction for priority level Normal has changed to Lock and the door is now locked.
Response
{
"DoorPriorityAction": [
{
"PriorityLevel": "High",
"Reason": "",
"DoorAction": "Release"
},
{
"PriorityLevel": "Normal",
"Reason": "Schedule",
"DoorAction": "Lock"
}
]
}
Response
<axtdc:GetDoorPriorityStateResponse>
<axtdc:DoorPriorityAction>
<axtdc:PriorityLevel>High</axtdc:PriorityLevel>
<axtdc:Reason />
<axtdc:DoorAction>Release</axtdc:DoorAction>
</axtdc:DoorPriorityAction>
<axtdc:DoorPriorityAction>
<axtdc:PriorityLevel>Normal</axtdc:PriorityLevel>
<axtdc:Reason>Schedule</axtdc:Reason>
<axtdc:DoorAction>Lock</axtdc:DoorAction>
</axtdc:DoorPriorityAction>
</axtdc:GetDoorPriorityStateResponse>
To unlock the door in an emergency situation, a tdc:UnlockDoor with priority level High overrides the DoorScheduleConfiguration setting.
Request
{
"tdc:UnlockDoor": {
"Token": "myDoor",
"PriorityLevel": "High"
}
}
<tdc:UnlockDoor>
<tdc:Token>myDoor</tdc:Token>
<tdc:PriorityLevel>High</tdc:PriorityLevel>
</tdc:UnlockDoor>
The response from axtdc:GetDoorPriorityState shows that priority level High now has action Unlock. As Unlock has higher priority than Lock, the door is unlocked.
Response
{
"DoorPriorityAction": [
{
"PriorityLevel": "High",
"Reason": "API",
"DoorAction": "Unlock"
},
{
"PriorityLevel": "Normal",
"Reason": "Schedule",
"DoorAction": "Lock"
}
]
}
To release priority level High, that is, to return to the default behavior specified by DoorScheduleConfiguration, send a axtdc:ReleaseDoor with priority level High.
Request
{
"axtdc:ReleaseDoor": {
"Token": "myDoor",
"PriorityLevel": "High"
}
}
<axtdc:ReleaseDoor>
<axtdc:Token>myDoor</axtdc:Token>
<axtdc:PriorityLevel>High</axtdc:PriorityLevel>
</axtdc:ReleaseDoor>
The response from axtdc:GetDoorPriorityState shows that the door now is locked.
Response
{
"DoorPriorityAction": [
{
"PriorityLevel": "High",
"Reason": "API",
"DoorAction": "Release"
},
{
"PriorityLevel": "Normal",
"Reason": "Schedule",
"DoorAction": "Lock"
}
]
}
Door control service API
The door control service provides mechanisms for controlling physical door instances and monitoring their status.
The door in this specification can refer to such physical objects as an automatic barrier or a door equipped with electric lock. Turnstiles which can restrict access in either direction can be represented with a pair of doors.
The door is a subclass of a more generic term entity defined in the ONVIF access control specification.
Please refer to the ONVIF access control specification for generic operation guidelines and design principles behind ONVIF PACS services family.
The service includes the following operations:
- Getting list of doors including their capabilities (e.g., supported operations).
- Getting actual state (e.g., open or closed, locked or unlocked, health status).
- Locking and unlocking.
- Blocking door in locked state such that it can't be accessed.
- Holding door in either unlocked (locked open) or locked (locked down) state and releasing the hold.
- Momentary access.
- Double lock (also known as secure lock) for preventing night-time access.
The service also defines a number of events for real-time monitoring:
- Door physical status change (e.g., open or closed).
- Lock physical state change (e.g., locked or unlocked).
- Operation mode change (e.g., blocked, locked down or locked open).
- Alarm (if door was forced open or was open for too long during momentary access).
- Tamper (an attempt to physically damage its components).
- Hardware malfunction.
AxisConfig service
axconf = http://www.axis.com/vapix/ws/Config
Axis configuration API.
This provides the datatypes used by the Axis IdPoint and Axis DoorController services for hardware configuration which may vary between device software revisions and hardware models.
Configuration data structure
A configuration setting.
The following fields are available:
-
NameName of configuration setting.
-
ValueValue of configuration setting.
ConfigurationInfo data structure
A configuration setting and description.
The following fields are available:
-
NameName of configuration setting.
-
ValueValue of configuration setting.
-
EnumsSuggested/allowed values.
To provide more information, the device may include the following optional fields:
-
TypeType of configuration setting, e.g. xs:string, xs:boolean, xs:int.
-
DependOnNameName of the
Configthis config depends on. -
DependOnValueValue of the
Configthis config depends on. -
DescriptionDescription of configuration setting.
Service capabilities
tdc = http://www.onvif.org/ver10/doorcontrol/wsdl
An ONVIF compliant device shall provide service capabilities in two ways:
-
With the
GetServicesmethod of device service whenIncludeCapabilityis true. Refer to the ONVIF core specification for more details. -
With the
GetServiceCapabilitiesmethod.
ServiceCapabilities data structure
ServiceCapabilities structure reflects optional functionality of a service. The information is static and does not change during device operation. The following capabilities are available:
-
MaxLimitThe maximum number of entries returned by a single
GetListorGetrequest. The device shall never return more than this number of entities in a single response. -
GetDoorSupportedTrue if
GetDoorandGetDoorListoperations are supported. -
SetDoorSupportedTrue if
SetDoorandSetDoorListoperations are supported. -
PriorityConfigurationSupportedTrue if
PriorityConfigurationscan be modified.
GetServiceCapabilities command
This operation returns the capabilities of the service.
An ONVIF compliant device which provides the door control service shall implement this method.
GetServiceCapabilities command
- Name:
GetServiceCapabilities - Access Class: PRE_AUTH
| Message name | Description |
|---|---|
GetServiceCapabilitiesRequest | This message shall be empty. |
GetServiceCapabilitiesResponse | This message contains: - Capabilities: The capability response message contains the requested Door Control service capabilities using a hierarchical XML capability structure.tdc:ServiceCapabilities Capabilities [1][1] (extendable) |
Door information
tdc = http://www.onvif.org/ver10/doorcontrol/wsdl
DoorInfo data structure
The DoorInfo type represents the Door as a physical object. The structure contains information and capabilities of a specific door instance. An ONVIF compliant device shall provide the following fields for each Door instance:
-
tokenA service-unique identifier of the
Door. -
NameA user readable name. It shall be up to 64 characters.
-
CapabilitiesThe capabilities of the
Door.
To provide more information, the device may include the following optional field:
-
DescriptionA user readable description. It shall be up to 1024 characters.
DoorCapabilities data structure
DoorCapabilities reflect optional functionality of a particular physical entity. Different door instances may have different set of capabilities. This information may change during device operation, e.g. if hardware settings are changed. The following capabilities are available:
-
AccessIndicates whether or not this
Doorinstance supportsAccessDoorcommand to perform momentary access. -
AccessTimingOverrideIndicates that this
Doorinstance supports overriding configured timing in theAccessDoorcommand. -
LockIndicates that this
Doorinstance supportsLockDoorcommand to lock the door. -
UnlockIndicates that this
Doorinstance supportsUnlockDoorcommand to unlock the door. -
BlockIndicates that this
Doorinstance supportsBlockDoorcommand to block the door. -
DoubleLockIndicates that this
Doorinstance supportsDoubleLockDoorcommand to lock multiple locks on the door. -
LockDownIndicates that this
Doorinstance supportsLockDown(andLockDownRelease) commands to lock the door and put it inLockedDownmode. -
LockOpenIndicates that this
Doorinstance supportsLockOpen(andLockOpenRelease) commands to unlock the door and put it inLockedOpenmode. -
DoorMonitorIndicates that this
Doorinstance has aDoorMonitorand supports theDoorPhysicalStateevent. -
LockMonitorIndicates that this
Doorinstance has aLockMonitorand supports theLockPhysicalStateevent. -
DoubleLockMonitorIndicates that this
Doorinstance has aDoubleLockMonitorand supports theDoubleLockPhysicalStateevent. -
AlarmIndicates that this
Doorinstance supports door alarm and theDoorAlarmevent. -
TamperIndicates that this
Doorinstance has a tamper detector and supports theDoorTamperevent. -
FaultIndicates that this
Doorinstance supports door fault and theDoorFaultevent. -
WarningIndicates that this
Doorinstance supports door warning and theDoorWarningevent. -
ConfigurableIndicates if the
Doorsettings can be modified. -
PriorityLevelsNumber of priority levels supported for the door, 0 or 1 means priorities not supported.
GetDoorInfoList command
This operation requests a list of all DoorInfo items provided by the device. An ONVIF compliant device that provides Door Control service shall implement this method.
A call to this method shall return a StartReference when not all data is returned and more data is available. The reference shall be valid for retrieving the next set of data. The number of items returned shall not be greater than Limit parameter.
GetDoorInfoList command
- Name:
GetDoorInfoList - Access Class: READ_SYSTEM
| Message name | Description |
|---|---|
GetDoorInfoListRequest | This message contains: - Limit: Maximum number of entries to return. If not specified, or higher than what the device supports, the number of items shall be determined by the device.- StartReference: Start returning entries from this start reference. If not specified, entries shall start from the beginning of the dataset.xs:int Limit [0][1]xs:string StartReference [0][1] |
GetDoorInfoListResponse | This message contains: - NextStartReference: StartReference to use in next call to get the following items. If absent, no more items to get.- DoorInfo: List of DoorInfo items.xs:string NextStartReference [0][1]tdc:DoorInfo DoorInfo [0][unbounded] |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgVal ter:InvalidStartReference | StartReference is invalid or has timed out. Client needs to start fetching from the beginning. |
GetDoorInfo command
This operation requests a list of DoorInfo items matching the given tokens. An ONVIF-compliant device that provides a door control service shall implement this method.
The device shall ignore tokens it cannot resolve and may return an empty list if there are no items matching specified tokens. If the number of requested items is greater than MaxLimit, a TooManyItems fault shall be returned.
GetDoorInfo command
- Name:
GetDoorInfo - Access Class: READ_SYSTEM
| Message name | Description |
|---|---|
GetDoorInfoRequest | This message contains: - Token: Tokens of DoorInfo items to get.pt:ReferenceToken Token [1][unbounded] |
GetDoorInfoResponse | This message contains: - DoorInfo: List of DoorInfo items.tdc:DoorInfo DoorInfo [0][unbounded] |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgs ter:TooManyItems | Too many items were requested, see MaxLimit capability. |
Door status
tdc = http://www.onvif.org/ver10/doorcontrol/wsdl
The state of the door may be affected by a number of operations that can be performed on it depending on its capabilities: LockDoor, UnlockDoor, AccessDoor, BlockDoor, DoubleLockDoor, LockDownDoor, LockDownReleaseDoor, LockOpenDoorand LockOpenReleaseDoor.
DoorState data structure
The DoorState structure contains current aggregate runtime status of Door.
The following fields are available:
-
DoorModeThe logical operating mode of the door; it is of type
DoorMode. An ONVIF compatible device shall report current operating mode in this field.
To provide more information, the device may include the following optional fields:
-
DoorPhysicalStatePhysical state of
Door; it is of typeDoorPhysicalState. A device that signals support forDoorMonitorcapability for a particular door instance shall provide this field. -
LockPhysicalStatePhysical state of the
Lock; it is of typeLockPhysicalState. A device that signals support forLockMonitorcapability for a particular door instance shall provide this field. -
DoubleLockPhysicalStatePhysical state of the
DoubleLock; it is of typeLockPhysicalState. A device that signals support forDoubleLockMonitorcapability for a particular door instance shall provide this field. -
AlarmAlarm state of the door; it is of type
DoorAlarmState. A device that signals support forAlarmcapability for a particular door instance shall provide this field. -
TamperTampering state of the door; it is of type
DoorTamper. A device that signals support forTampercapability for a particular door instance shall provide this field. -
FaultFault information for door; it is of type
DoorFault. A device that signals support forFaultcapability for a particular door instance shall provide this field.
The following data types define states of DoorState elements.
DoorPhysicalState data structure
The physical state of a Door.
The following values are available:
-
UnknownValue is currently unknown (possibly due to initialization or monitors not giving a conclusive result).
-
OpenDoor is open.
-
ClosedDoor is closed.
-
FaultDoor monitor fault is detected.
LockPhysicalState data structure
The physical state of a Lock (including double lock).
The following values are available:
-
UnknownValue is currently not known.
-
LockedLock is activated.
-
UnlockedLock is not activated.
-
FaultLock fault is detected.
DoorAlarmState data structure
Describes the state of a Door with regard to alarms.
The following values are available:
-
NormalNo alarm.
-
DoorForcedOpenDoor is forced open.
-
DoorOpenTooLongDoor is held open too long.
DoorWarningState data structure
Describes the state of a Door with regard to warnings.
The following values are available:
-
NormalNo warning.
-
DoorOpenTooLongWarnDoor is soon held open too long.
DoorTamper data structure
Tampering information for a Door.
The following fields are available:
-
StateState of the tamper detector; it is of type
DoorTamperState.
To provide more information, the device may include the following optional field:
-
ReasonOptional field; Details describing tampering state change (e.g., reason, place and time). NOTE: All fields (including this one) which are designed to give end-user prompts can be localized to the customers's native language.
DoorTamperState data structure
Describes the state of a tamper detector.
The following values are available:
-
UnknownValue is currently not known.
-
NotInTamperNo tampering is detected.
-
TamperDetectedTampering is detected.
DoorFault data structure
Fault information for a Door. This can be extended with optional attributes in the future.
The following fields are available:
-
StateOverall fault state for the door; it is of type
DoorFaultState. If there are any faults, the value shall be:FaultDetected. Details of the detected fault shall be found in theReasonfield, and/or the variousDoorStatefields and/or in extensions to this structure.
To provide more information, the device may include the following optional fields:
-
ReasonOptional reason for fault.
-
DoorMonitorFaultTrue if there is fault in the
DoorMonitor. -
LockFaultTrue if there is fault in the lock.
-
DoubleLockFaultTrue if there is fault in the
DoubleLockMonitor -
LockMonitorFaultTrue if there is fault in the
LockMonitor.
It can be extended with optional attributes in the future.
DoorFaultState data structure
Describes the state of a door fault.
The following values are available:
-
UnknownFault state is unknown.
-
NotInFaultNo fault is detected.
-
FaultDetectedFault is detected.
DoorMode data structure
DoorMode parameters describe current Door mode from a logical perspective.
The following values are available:
-
UnknownThe
Dooris in anUnknownstate. -
LockedThe
Dooris in aLockedstate. In this mode the device shall provide momentary access using theAccessDoormethod if supported by theDoorinstance. -
UnlockedThe
Dooris in anUnlocked(Permanent Access) state. Alarms related to door timing operations such as open too long or forced are masked in this mode. -
AccessedThe
Dooris in anAccessedstate (momentary/temporary access). Alarms related to timing operations such as "door forced" are masked in this mode. -
BlockedThe
Dooris in aBlockedstate (Door is locked, andAccessDoorrequests are ignored, i.e., it is not possible for door to go toAccessedstate). -
LockedDownThe
Dooris in aLockedDownstate (Door is locked) until released using theLockDownReleaseDoorcommand.AccessDoor,LockDoor,UnlockDoor,BlockDoorandLockOpenDoorrequests are ignored, i.e., it is not possible for door to go toAccessed,Locked,Unlocked,BlockedorLockedOpenstate. -
LockedOpenThe
Dooris in aLockedOpenstate (Door is unlocked) until released using theLockOpenReleaseDoorcommand.AccessDoor,LockDoor,UnlockDoor,BlockDoorandLockDownDoorrequests are ignored, i.e., it is not possible for door to go toAccessed,Locked,Unlocked,BlockedorLockedDownstate. -
DoubleLockedThe
Dooris in aDoubleLockedstate - for doors with multiple locks. If the door does not have anyDoubleLock, this shall be treated as a normalLockedmode. When changing to anUnlockedmode from theDoubleLockedmode, the door may first go toLockedstate before unlocking.
GetDoorState command
This operation requests the state of a Door specified by the token.
A device implementing the Door Control service shall be capable of reporting the status of a door using a DoorState structure available from the GetDoorState command.
GetDoorState command
- Name:
GetDoorState - Access Class: READ_SYSTEM_SENSITIVE
| Message name | Description |
|---|---|
GetDoorStateRequest | This message contains: - Token: Token of the Door instance to get the state for.pt:ReferenceToken Token [1][1] (extendable) |
GetDoorStateResponse | This message contains: - DoorState: The state of the door.tdc:DoorState DoorState [1][1] (extendable) |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgVal ter:NotFound | The specified token is not found. |
Door control commands
tdc = http://www.onvif.org/ver10/doorcontrol/wsdl
axtdc = http://www.axis.com/vapix/ws/DoorControl
Use door control commands to control Door instances and to modify the states of Door instances.
| Command | Description |
|---|---|
tdc:AccessDoor | Access the door. Use when a credential holder is granted access, for example by swiping a card in a card reader. |
tdc:LockDoor | Lock the door. |
tdc:UnlockDoor | Unlock the door. |
tdc:BlockDoor | Block the door. |
tdc:LockDownDoor | Lock the door and prevent all other commands until a LockDownReleaseDoor command is sent. |
tdc:LockDownReleaseDoor | Release the door from the LockedDown state. |
tdc:LockOpenDoor | Unlock the door and prevent all other commands until a LockOpenReleaseDoor command is sent. |
tdc:LockOpenReleaseDoor | Release the door from the LockedOpen state. |
tdc:DoubleLockDoor | Lock the door with a double lock. |
axtdc:ReleaseDoor | Release the door from a priority level. |
AccessDoor command
This operation allows momentarily accessing a Door. It invokes the functionality typically used when a card holder presents a card to a card reader at the door and is granted access.
The DoorMode shall change to Accessed. For more information about the Accessed state and door mode restrictions, see section DoorMode data structure.
The Door shall remain accessible for the defined time. When the time span elapses, the DoorMode shall change back to its previous state.
If the request cannot be fulfilled, a Failure fault shall be returned.
A device that signals support for Access capability for a particular Door instance shall implement this method. A device that signals support for AccessTimingOverride capability for a particular Door instance shall also provide optional timing parameters (AccessTime, OpenTooLongTime and PreAlarmTime) when performing AccessDoor command.
The device shall take the best effort approach for parameters not supported, it must fallback to preconfigured time or limit the time to the closest supported time if the specified time is out of range.
AccessDoor command
- Name:
tdc:AccessDoor - Access Class: ACTUATE
| Message name | Description |
|---|---|
AccessDoorRequest | This message contains: - Token: Token of the Door instance to control.- UseExtendedTime: Optional. Indicates that the configured extended time should be used.- AccessTime: Optional. Overrides AccessTime if specified.- OpenTooLongTime: Optional. Overrides OpenTooLongTime if specified (DOTL).- PreAlarmTime: Optional. Overrides PreAlarmTime if specified.- Extension: Future extension.pt:ReferenceToken Token [1][1]xs:boolean UseExtendedTime [0][1]xs:duration AccessTime [0][1]xs:duration OpenTooLongTime [0][1]xs:duration PreAlarmTime [0][1]tdc:AccessDoorExtension Extension [0][1] |
AccessDoorResponse | This message is empty. |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgVal ter:NotFound | The specified token is not found. |
env:Receiver ter:Action ter:Failure | Failed to go to Accessed state and unlock the door. |
LockDoor command
This operation allows locking a Door. The DoorMode shall change to Locked. For more information about the Locked state and door mode restrictions, see section DoorMode data structure.
A device that signals support for Lock capability for a particular Door instance shall implement this method.
If the request cannot be fulfilled, a Failure fault shall be returned.
LockDoor command
- Name:
tdc:LockDoor - Access Class: ACTUATE
| Message name | Description |
|---|---|
LockDoorRequest | This message contains: - Token: Token of the Door instance to control.- PriorityLevel: Priority level for the lock command, if empty use default priority.- Extension: Future extension.pt:ReferenceToken Token [1][1]xs:string PriorityLevel [0][1]tdc:LockDoorExtension Extension [0][1] |
LockDoorResponse | This message is empty. |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgVal ter:NotFound | The specified token is not found. |
env:Receiver ter:Action ter:Failure | Failed to go to Locked state. |
UnlockDoor command
This operation allows unlocking a Door. The DoorMode shall change to Unlocked. For more information about the Unlocked state and door mode restrictions, see section DoorMode data structure.
A device that signals support for Unlock capability for a particular Door instance shall implement this method.
If the request cannot be fulfilled, a Failure fault shall be returned.
UnlockDoor command
- Name:
tdc:UnlockDoor - Access Class: ACTUATE
| Message name | Description |
|---|---|
UnlockDoorRequest | This message contains: - Token: Token of the Door instance to control.- PriorityLevel: Priority level for the unlock command, if empty use default priority.- Extension: Future extension.pt:ReferenceToken Token [1][1]xs:string PriorityLevel [0][1]tdc:UnlockDoorExtension Extension [0][1] |
UnlockDoorResponse | This message is empty. |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgVal ter:NotFound | The specified token is not found. |
env:Receiver ter:Action ter:Failure | Failed to go to Unlocked state. |
BlockDoor command
This operation allows blocking a Door and preventing momentary access (AccessDoor command). The DoorMode shall change to Blocked. For more information about the Blocked state and door mode restrictions, see section DoorMode data structure.
A device that signals support for Block capability for a particular Door instance shall implement this method.
If the request cannot be fulfilled, a Failure fault shall be returned.
BlockDoor command
- Name:
tdc:BlockDoor - Access Class: ACTUATE
| Message name | Description |
|---|---|
BlockDoorRequest | This message contains: - Token: Token of the Door instance to control.- PriorityLevel: Priority level for the block door command, if empty use default priority.- Extension: Future extension.pt:ReferenceToken Token [1][1]xs:string PriorityLevel [0][1]tdc:BlockDoorExtension Extension [0][1] |
BlockDoorResponse | This message is empty. |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgVal ter:NotFound | The specified token is not found. |
env:Receiver ter:Action ter:Failure | Failed to go to Blocked state. |
LockDownDoor command
This operation allows locking and preventing other actions until a LockDownReleaseDoor command is invoked. The DoorMode shall change to LockedDown. For more information about the LockedDown state and door mode restrictions, see section DoorMode data structure.
The device shall ignore other door control commands until a LockDownReleaseDoor command is performed.
A device that signals support for LockDown capability for a particular Door instance shall implement this method.
If a device supports DoubleLock capability for a particular Door instance, that operation may be engaged as well.
If the request cannot be fulfilled, a Failure fault shall be returned.
LockDownDoor command
- Name:
tdc:LockDownDoor - Access Class: ACTUATE
| Message name | Description |
|---|---|
LockDownDoorRequest | This message contains: - Token: Token of the Door instance to control.- PriorityLevel: Priority level for the command, if empty use default priority.- Extension: Future extension.pt:ReferenceToken Token [1][1]xs:string PriorityLevel [0][1]tdc:LockDoorExtension Extension [0][1] |
LockDownDoorResponse | This message is empty. |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgVal ter:NotFound | The specified token is not found. |
env:Receiver ter:Action ter:Failure | Failed to go to LockedDown state. |
LockDownReleaseDoor command
This operation allows releasing the LockedDown state of a Door. The DoorMode shall change back to its previous/next state. It is not defined what the previous/next state shall be, but typically - Locked.
This method shall only succeed if the current DoorMode is LockedDown.
LockDownReleaseDoor command
- Name:
tdc:LockDownReleaseDoor - Access Class: ACTUATE
| Message name | Description |
|---|---|
LockDownReleaseDoorRequest | This message contains: - Token: Token of the Door instance to control.- PriorityLevel: Priority level for the command, if empty use default priority.- Extension: Future extension.pt:ReferenceToken Token [1][1]xs:string PriorityLevel [0][1]tdc: LockDownReleaseDoorExtension Extension [0][1] |
LockDownReleaseDoorResponse | This message is empty. |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgVal ter:NotFound | The specified token is not found. |
env:Receiver ter:Action ter:Failure | Failed to go to Locked state. |
LockOpenDoor command
This operation allows unlocking a Door and preventing other actions until LockOpenReleaseDoor method is invoked. The DoorMode shall change to LockedOpen. For more information about the LockedOpen state and door mode restrictions, see section DoorMode data structure.
The device shall ignore other door control commands until a LockOpenReleaseDoor command is performed.
A device that signals support for LockOpen capability for a particular Door instance shall implement this method.
If the request cannot be fulfilled, a Failure fault shall be returned.
LockOpenDoor command
- Name:
tdc:LockOpenDoor - Access Class: ACTUATE
| Message name | Description |
|---|---|
LockOpenDoorRequest | This message contains: - Token: Token of the Door instance to control.- PriorityLevel: Priority level for the command, if empty use default priority.- Extension: Future extension.pt:ReferenceToken Token [1][1]xs:string PriorityLevel [0][1]tdc:LockOpenDoorExtension Extension [0][1] |
LockOpenDoorResponse | This message is empty. |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgVal ter:NotFound | The specified token is not found. |
env:Receiver ter:Action ter:Failure | Failed to go to LockOpenDoor state. |
LockOpenReleaseDoor command
This operation allows releasing the LockedOpen state of a Door. The DoorMode shall change state from the LockedOpen state back to its previous/next state. It is not defined what the previous/next state shall be, but typically - Unlocked.
This method shall only succeed if the current DoorMode is LockedOpen.
LockOpenReleaseDoor command
- Name:
tdc:LockOpenReleaseDoor - Access Class: ACTUATE
| Message name | Description |
|---|---|
LockOpenReleaseDoorRequest | This message contains: - Token: Token of the Door instance to control.- PriorityLevel: Priority level for the command, if empty use default priority.- Extension: Future extension.pt:ReferenceToken Token [1][1]xs:string PriorityLevel [0][1]tdc:LockOpenReleaseDoorExtension Extension [0][1] |
LockOpenReleaseDoorResponse | This message is empty. |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgVal ter:NotFound | The specified token is not found. |
env:Receiver ter:Action ter:Failure | Failed to go to LockedOpen state. |
DoubleLockDoor command
This operation is used for securely locking a Door. The DoorMode shall change to DoubleLocked. For more information about the DoubleLocked state and door mode restrictions, see section DoorMode data structure.
A device that signals support for DoubleLock capability for a particular Door instance shall implement this method. Otherwise this method can be performed as a standard Lock operation (see section LockDoor command).
If the door has an extra lock that shall be locked as well.
If the request cannot be fulfilled, a Failure fault shall be returned.
DoubleLockDoor command
- Name:
tdc:DoubleLockDoor - Access Class: ACTUATE
| Message name | Description |
|---|---|
DoubleLockDoorRequest | This message contains: - Token: Token of the Door instance to control.- PriorityLevel: Priority level for the double lock command, if empty use default priority.- Extension: Future extension.pt:ReferenceToken Token [1][1]xs:string PriorityLevel [0][1]tdc: DoubleLockDoorExtension Extension [0][1] |
DoubleLockDoorResponse | This message is empty. |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgVal ter:NotFound | The specified token is not found. |
env:Receiver ter:Action ter:Failure | Failed to go to DoubleLocked state. |
ReleaseDoor command
This operation allows releasing a door from the operation at the specified PriorityLevel.
A call to this method shall release door so that DoorMode contains no action for the specified PriorityLevel, the next state shall be determined by the next PriorityLevel specified by the PriorityConfiguration for the Door.
This method is optional and must be supported if the PriorityConfigurationSupported capability is true.
ReleaseDoor command
- Name:
axtdc:ReleaseDoor - Access Class: ACTUATE
| Message name | Description |
|---|---|
ReleaseDoorRequest | This message contains: - Token: Token of the Door to control.- PriorityLevel: Priority level for the Release command, if empty use default priority.- Extension: Future extension.pt:ReferenceToken Token [1][1]xs:string PriorityLevel [0][1]axtdc:ReleaseDoorExtension Extension [0][1] |
ReleaseDoorResponse | This message is empty. |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgVal ter:NotFound | The specified token is not found. |
Door configuration
axtdc = http://www.axis.com/vapix/ws/DoorControl
Door data structure
The device and configuration entity for a Door.
The following fields are available:
-
tokenA service-unique identifier of the
Door. -
NameA user readable name. It shall be up to 64 characters.
-
AccessTimeThe normal open time for a door. Starts when door goes to
Accessedstate. -
OpenTooLongTimeNormal open too long time for a door. Starts when door is opened.
-
PreAlarmTimeTime before
OpenTooLongtime expires and a warning event is sent. -
ExtendedAccessTimeThe extended open time for a door.
-
ExtendedOpenTooLongTimeExtended open too long time for a door.
-
HeartbeatIntervalThe time between heartbeat event updates. A time of 0 means no heartbeat events.
-
PriorityConfigurationToken of
PriorityConfigurationto use. -
DefaultPriorityDefault priority to use if no priority is specified in a door control command. If empty, the
DefaultPriorityspecified in thePriorityConfigurationis used.
To provide more information, the device may include the following optional field:
-
DescriptionA user readable description. It shall be up to 1024 characters.
SetDoor command
This operation to adds or updates a list of Door:s.
This method must be implemented if the SetDoorSupported service capability is true.
SetDoor command
- Name:
SetDoor - Access Class: WRITE_SYSTEM
| Message name | Description |
|---|---|
SetDoorRequest | This message contains: - Door: The new version of the Door(s)axtdc:Door Door [1][unbounded] |
SetDoorResponse | This message contains: - Token: Tokens of the added/updated Doorspt:ReferenceToken Token [0][unbounded] |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgs | |
env:Receiver ter:ActionNotSupported ter:NotSupported |
GetDoorList command
This operation requests a list of all Door items provided by the device.
This method must be implemented if the GetDoorSupported service capability is true.
A call to this method shall return a StartReference when not all data is returned and more data is available. The reference shall be valid for retrieving the next set of data. The number of items returned shall not be greater than Limit parameter.
GetDoorList command
- Name:
GetDoorList - Access Class: READ_SYSTEM_SENSITIVE
| Message name | Description |
|---|---|
GetDoorListRequest | This message contains: - Limit: Maximum number of entries to return. If not specified, or higher than what the device supports, the number of items shall be determined by the device.- StartReference: Start returning entries from this start reference. If not specified, entries shall start from the beginning of the dataset.xs:int Limit [0][1]xs:string StartReference [0][1] |
GetDoorListResponse | This message contains: - NextStartReference: StartReference to use in next call to get the following items. If absent, no more items to get.- Door: List of Door items.xs:string NextStartReference [0][1]tdc:Door Door [0][unbounded] |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgVal ter:InvalidStartReference | StartReference is invalid or has timed out. Client needs to start fetching from the beginning. |
GetDoor command
This operation request a list of Door items matching the given tokens.
This method must be implemented if the GetDoorSupported service capability is true.
The device shall ignore tokens it cannot resolve and may return an empty list if there are no items matching specified tokens. If the number of requested items is greater than MaxLimit, a TooManyItems fault shall be returned.
GetDoor command
- Name:
GetDoor - Access Class: READ_SYSTEM_SENSITIVE
| Message name | Description |
|---|---|
GetDoorRequest | This message contains: - Token: Tokens of Door items to get.pt:ReferenceToken Token [1][unbounded] |
GetDoorResponse | This message contains: - Door: List of Door items.tdc:Door Door [0][unbounded] |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgs ter:TooManyItems | Too many items were requested, see MaxLimit capability. |
RemoveDoor command
This operation removes Door items with specified tokens.
RemoveDoor command
- Name:
RemoveDoor - Access Class: WRITE_SYSTEM
| Message name | Description |
|---|---|
RemoveDoorRequest | This message contains: - Token: Token of the Door items to remove.pt:ReferenceToken Token [1][unbounded] |
RemoveDoorResponse | This message is empty. |
| Fault codes | Description |
|---|---|
env:Receiver ter:ActionNotSupported ter:NotSupported | Not allowed to remove the Door. |
env:Sender ter:InvalidArgVal ter:NotFound | The specified token is not found. |
Door priority
axtdc = http://www.axis.com/vapix/ws/DoorControl
Door priority configuration is an optional feature that makes it possible to assign door actions to different priority levels, and thus allow advanced control of the door in system where there are multiple clients controlling the same door.
This feature depends on if the PriorityConfigurationSupported service capability is true and the PriorityLevels instance capability.
The door may also support multiple levels of priority where the supported operations mentioned above can be performed on each PriorityLevel together with the ReleaseDoor operation that removes an action on the given PriorityLevel which will result in a DoorAction on each of the PriorityLevel items configured for the door by the referenced PriorityConfiguration.
Each PriorityLevel has its own setting of NoAction, Access, Lock, Unlock and DoubleLock etc. The list is processed by the service with highest priorities first, and when the first action differs from Release that action is taken.
The following is an example of the levels in a PriorityConfiguration and their default value.
- Emergency=Release
- Override=Release
- Logic=Release
- Schedule=Release
- Normal=Release
- Default=Lock
DoorActionType data structure
The possible actions on a door in a certain PriorityLevel.
The following values are available:
-
NoActionNo action for the door.
-
ReleaseRelease the action on the current priority.
-
LockDownReleaseRelease state
LockDown. -
LockOpenReleaseRelease state
LockOpen. -
LockLock door.
-
UnlockUnlock door.
-
AccessUnlock for the specified time and then return to previous state (typically
Lock,DoubleLockorRelease). -
BlockBlock the door (Access not allowed in this mode).
-
LockDownLock the door until
LockDownRelease. -
LockOpenUnlock the door until
LockOpenRelease. -
DoubleLockDouble lock door.
PriorityConfiguration data structure
Defines the ordered list of door priority levels and the initial DoorAction at each PriorityLevel. First in list has highest priority.
The following fields are available:
-
tokenA service-unique identifier of the
PriorityConfiguration. -
NameName of
PriorityConfiguration. -
DefaultPrioritySuggested default priority.
-
DoorPriorityActionList of
PriorityLevelitems and their initialDoorAction, with highest priorities first.
GetDoorPriorityState command
If supported, a call to this method shall return the Priority state for a door specified by the token.
This method must be implemented if the PriorityConfigurationSupported service capability is true.
GetDoorPriorityState command
- Name:
GetDoorPriorityState - Access Class: READ_SYSTEM_SENSITIVE
| Message name | Description |
|---|---|
GetDoorPriorityStateRequest | This message contains: - Token: Token of the Door to get the state for.pt:ReferenceToken Token [1][1](extendable) |
GetDoorPriorityStateResponse | This message contains: - DoorPriorityAction: The Priority state of the door, with highest priorities first.axtdc:DoorPriorityAction DoorPriorityAction [0][unbounded] |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgVal ter:NotFound | The specified token is not found. |
SetPriorityConfiguration command
Set a list of PriorityConfiguration items. If supported, a call to this operation shall set the specified PriorityConfiguration items.
This method must be implemented if the PriorityConfigurationSupported service capability is true.
SetPriorityConfiguration command
- Name:
SetPriorityConfiguration - Access Class: WRITE_SYSTEM
| Message name | Description |
|---|---|
SetPriorityConfigurationRequest | This message contains: - PriorityConfiguration: List of PriorityConfiguration:s to set.axtdc:PriorityConfiguration PriorityConfiguration [1][unbounded] |
SetPriorityConfigurationResponse | This message contains: - Token: Tokens of the added/updated PriorityConfiguration items.pt:ReferenceToken Token [0][unbounded] |
| Fault codes | Description |
|---|---|
env:Receiver ter:ActionNotSupported ter:NotSupported | Not allowed to modify the PriorityConfiguration. |
env:Sender ter:InvalidArgs | The specified token is not found. |
GetPriorityConfigurationList command
This operation requests a list of all PriorityConfiguration items provided by the device.
This method must be implemented if the PriorityConfigurationSupported service capability is true.
A call to this method shall return a StartReference when not all data is returned and more data is available. The reference shall be valid for retrieving the next set of data. The number of items returned shall not be greater than Limit parameter.
GetPriorityConfigurationList command
- Name:
GetPriorityConfigurationList - Access Class: READ_SYSTEM_SENSITIVE
| Message name | Description |
|---|---|
GetPriorityConfigurationListRequest | This message contains: - Limit: Maximum number of entries to return. If not specified, or higher than what the device supports, the number of items shall be determined by the device.- StartReference: Start returning entries from this start reference. If not specified, entries shall start from the beginning of the dataset.xs:int Limit [0][1]xs:string StartReference [0][1] |
GetPriorityConfigurationListResponse | This message contains: - NextStartReference: StartReference to use in next call to get the following items. If absent, no more items to get.- PriorityConfiguration: List of PriorityConfiguration items.xs:string NextStartReference [0][1]axtdc:PriorityConfiguration PriorityConfiguration [0][unbounded] |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgVal ter:InvalidStartReference | StartReference is invalid or has timed out. Client needs to start fetching from the beginning. |
GetPriorityConfiguration command
This operation request a list of PriorityConfiguration items matching the given tokens.
The device shall ignore tokens it cannot resolve and may return an empty list if there are no items matching specified tokens. If the number of requested items is greater than MaxLimit, a TooManyItems fault shall be returned.
This method must be implemented if the PriorityConfigurationSupported service capability is true.
GetPriorityConfiguration command
- Name:
GetPriorityConfiguration - Access Class: READ_SYSTEM_SENSITIVE
| Message name | Description |
|---|---|
GetPriorityConfigurationRequest | This message contains: - Token: Tokens of PriorityConfiguration items to get.pt:ReferenceToken Token [1][unbounded] |
GetPriorityConfigurationResponse | This message contains: - PriorityConfiguration: List of PriorityConfiguration items.axtdc:PriorityConfiguration PriorityConfiguration [0][unbounded] |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgs ter:TooManyItems | Too many items were requested, see MaxLimit capability. |
RemovePriorityConfiguration command
If supported, a call to this method shall remove the PriorityConfiguration items specified by the given tokens.
This method must be implemented if the PriorityConfigurationSupported service capability is true.
RemovePriorityConfiguration command
- Name:
RemovePriorityConfiguration - Access Class: WRITE_SYSTEM
| Message name | Description |
|---|---|
RemovePriorityConfigurationRequest | This message contains: - Token: Token of the PriorityConfiguration items to remove.pt:ReferenceToken Token [1][unbounded] |
RemovePriorityConfigurationResponse | This message is empty. |
| Fault codes | Description |
|---|---|
env:Receiver ter:ActionNotSupported ter:NotSupported | Not allowed to remove the PriorityConfiguration. |
env:Sender ter:InvalidArgVal ter:NotFound | The specified token is not found. |
DoorConfiguration
axtdc = http://www.axis.com/vapix/ws/DoorControl
The device and hardware configuration for a Door.
DoorConfiguration data structure
The device and hardware configuration for a Door.
The following fields are available:
-
tokenDoorControllerId to use for set, remove and usage. -
DeviceUUIDWhat device the
DoorControlleris on. -
ConfigurationConfiguration for the
Door.
To provide more information, the device may include the following optional field:
-
DoorScheduleConfigurationToken of a
DoorScheduleConfiguration.
GetDoorConfigurationList command
This operation requests a list of all of DoorConfiguration items provided by the device.
The returned list shall start with the item specified by a StartReference parameter. If it is not specified by the client, the device shall return items starting from the beginning of the dataset.
StartReference is a device internal identifier used to continue fetching data from the last position, and shall allow a client to iterate over a large dataset in smaller chunks. The device shall be able to handle a reasonable number of different StartReference;s at the same time and they must live for a reasonable time so that clients are able to fetch complete datasets.
An ONVIF compliant client shall not make any assumptions on StartReference contents and shall always pass the value returned from a previous request to continue fetching data. Client shall not use the same reference more than once.
For example, the StartReference can be incrementing start position number or underlying database transaction identifier.
The returned NextStartReference shall be used as the StartReference parameter in successive calls, and may be changed by device in each call. The number of items returned shall not be greater than Limit parameter. If Limit parameter is not specified by the client, the device shall assume it unbounded. The number of returned elements is determined by the device and may be less than requested if the device is limited in its resources.
GetDoorConfigurationList command
- Name:
GetDoorConfigurationList - Access Class: READ_SYSTEM_SENSITIVE
| Message name | Description |
|---|---|
GetDoorConfigurationListRequest | This message contains: - Limit: Maximum number of entries to return. If not specified, or higher than what the device supports, the number of items shall be determined by the device.- StartReference: Start returning entries from this start reference. If not specified, entries shall start from the beginning of the dataset.xs:int Limit [0][1]xs:string StartReference [0][1] |
GetDoorConfigurationListResponse | This message contains: - NextStartReference: StartReference to use in next call to get the following items. If absent, no more items to get.- DoorConfiguration: List of DoorConfiguration items.xs:string NextStartReference [0][1]axtdc:DoorConfiguration DoorConfiguration [0][unbounded] |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgVal ter:InvalidStartReference | StartReference is invalid or has timed out. Client needs to start fetching from the beginning. |
GetDoorConfiguration command
This operation request a list of DoorConfiguration items matching the given tokens.
The device shall ignore tokens it cannot resolve and may return an empty list if there are no items matching specified tokens.
If the number of requested items is greater than the max limit supported, a TooManyItems fault shall be returned
GetDoorConfiguration command
- Name:
GetDoorConfiguration - Access Class: READ_SYSTEM_SENSITIVE
| Message name | Description |
|---|---|
GetDoorConfigurationRequest | This message contains: - Token: Tokens of DoorConfiguration items to get.pt:ReferenceToken Token [1][unbounded] |
GetDoorConfigurationResponse | This message contains: - DoorConfiguration: List of DoorConfiguration items.axtdc:DoorConfiguration DoorConfiguration [0][unbounded] |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgs ter:TooManyItems | Too many items were requested, see MaxLimit capability. |
SetDoorConfiguration command
SetDoorConfiguration, the token in the DoorConfiguration should refer to an existing DoorController.
SetDoorConfiguration command
- Name:
SetDoorConfiguration - Access Class: WRITE_SYSTEM
| Message name | Description |
|---|---|
SetDoorConfigurationRequest | This message contains: - DoorConfiguration: The new version of the DoorConfiguration.axtdc:DoorConfiguration DoorConfiguration [1][unbounded] |
SetDoorConfigurationResponse | This message contains: - Token: Tokens of the Door:s.pt:ReferenceToken Token [0][unbounded] |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgVal ter:InvalidDoorConfigurationFault |
RemoveDoorConfiguration command
Remove the DoorConfiguration items specified by the given token. This is normally not needed, since when removing a DoorController, the configuration is removed as well - although it's possible to create configurations without a corresponding controller.
RemoveDoorConfiguration command
- Name:
RemoveDoorConfiguration - Access Class: WRITE_SYSTEM
| Message name | Description |
|---|---|
RemoveDoorConfigurationRequest | This message contains: - Token: Token of the DoorConfiguration items to remove.pt:ReferenceToken Token [1][unbounded] |
RemoveDoorConfigurationResponse | This message is empty. |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgVal ter:NotFound | DoorConfiguration not found. |
GetDoorConfigurationInfo command
Get the ConfigurationInfo for a single Door specified by a token.
GetDoorConfigurationInfo command
- Name:
GetDoorConfigurationInfo - Access Class: READ_SYSTEM
| Message name | Description |
|---|---|
GetDoorConfigurationInfoRequest | This message contains: - Token: Token of the Door to get the ConfigurationInfo for.pt:ReferenceToken Token [1][1] |
GetDoorConfigurationInfoResponse | This message contains: - ConfigurationInfo: Configuration information for the specified token.axconf:ConfigurationInfo ConfigurationInfo [0][unbounded] |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgVal ter:NotFound | Specified Door not found. |
ScheduledState data structure
Schedules and action for a state.
The following fields are available:
-
ScheduleTokenSchedules defining when state is active.
-
EnterActionThe action to run when entering the state.
DoorSchedule data structure
Scheduled states for a specific priority level.
The following fields are available:
-
ScheduledStateScheduled states for the door on
PriorityLevel.
To provide more information, the device may include the following optional field:
-
PriorityLevelThe priority level
DoorScheduleConfiguration data structure
Schedule configuration for a Door.
The following fields are available:
-
tokenA service-unique identifier of the
DoorScheduleConfiguration. -
DoorScheduleList of
DoorScheduleitems.
To provide more information, the device may include the following optional fields:
-
NameName of the
Door. -
DescriptionDescription of the
Door.
SetDoorScheduleConfiguration command
Set DoorScheduleConfiguration, the token in the DoorScheduleConfiguration should refer to an existing DoorController.
SetDoorScheduleConfiguration command
- Name:
SetDoorScheduleConfiguration - Access Class: WRITE_SYSTEM
| Message name | Description |
|---|---|
SetDoorScheduleConfigurationRequest | This message contains: - DoorScheduleConfiguration: The new version of the DoorScheduleConfiguration.axtdc:DoorScheduleConfiguration DoorScheduleConfiguration [1][unbounded] |
SetDoorScheduleConfigurationResponse | This message contains: - Token: Tokens of the DoorScheduleConfiguration items.pt:ReferenceToken Token [0][unbounded] |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgVal ter:InvalidDoorScheduleFault |
GetDoorScheduleConfigurationList command
This operation requests a list of all of DoorScheduleConfiguration items provided by the device.
The returned list shall start with the item specified by a StartReference parameter. If it is not specified by the client, the device shall return items starting from the beginning of the dataset.
StartReference is a device internal identifier used to continue fetching data from the last position, and shall allow a client to iterate over a large dataset in smaller chunks. The device shall be able to handle a reasonable number of different StartReference:s at the same time and they must live for a reasonable time so that clients are able to fetch complete datasets.
An ONVIF compliant client shall not make any assumptions on StartReference contents and shall always pass the value returned from a previous request to continue fetching data. Client shall not use the same reference more than once.
For example, the StartReference can be incrementing start position number or underlying database transaction identifier.
The returned NextStartReference shall be used as the StartReference parameter in successive calls, and may be changed by device in each call.
The number of items returned shall not be greater than Limit parameter. If Limit parameter is not specified by the client, the device shall assume it unbounded. The number of returned elements is determined by the device and may be less than requested if the device is limited in its resources.
GetDoorScheduleConfigurationList command
- Name:
GetDoorScheduleConfigurationList - Access Class: READ_SYSTEM_SENSITIVE
| Message name | Description |
|---|---|
GetDoorScheduleConfigurationListRequest | This message contains: - Limit: Maximum number of entries to return. If not specified, or higher than what the device supports, the number of items shall be determined by the device.- StartReference: Start returning entries from this start reference. If not specified, entries shall start from the beginning of the dataset.xs:int Limit [0][1]xs:string StartReference [0][1] |
GetDoorScheduleConfigurationListResponse | This message contains: - NextStartReference: StartReference to use in next call to get the following items. If absent, no more items to get.- DoorScheduleConfiguration: List of DoorScheduleConfiguration items.xs:string NextStartReference [0][1]axtdc:DoorScheduleConfiguration DoorScheduleConfiguration [0][unbounded] |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgVal ter:InvalidStartReference | StartReference is invalid or has timed out. Client needs to start fetching from the beginning. |
GetDoorScheduleConfiguration command
This operation request a list of DoorScheduleConfiguration items matching the given tokens.
The device shall ignore tokens it cannot resolve and may return an empty list if there are no items matching specified tokens.
If the number of requested items is greater than the max limit supported, a TooManyItems fault shall be returned
GetDoorScheduleConfiguration command
- Name:
GetDoorScheduleConfiguration - Access Class: READ_SYSTEM_SENSITIVE
| Message name | Description |
|---|---|
GetDoorScheduleConfigurationRequest | This message contains: - Token: Tokens of DoorConfiguration items to get.pt:ReferenceToken Token [1][unbounded] |
GetDoorScheduleConfigurationResponse | This message contains: - DoorScheduleConfiguration: List of DoorScheduleConfiguration items.axtdc:DoorScheduleConfiguration DoorScheduleConfiguration [0][unbounded] |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgs ter:TooManyItems | Too many items were requested, see MaxLimit capability. |
RemoveDoorScheduleConfiguration command
Remove the specified DoorScheduleConfiguration items.
RemoveDoorScheduleConfiguration command
- Name:
RemoveDoorScheduleConfiguration - Access Class: WRITE_SYSTEM
| Message name | Description |
|---|---|
RemoveDoorScheduleConfigurationRequest | This message contains: - Token: Tokens of the added/updated DoorScheduleConfiguration items.pt:ReferenceToken Token [1][unbounded] |
RemoveDoorScheduleConfigurationResponse | This message is empty. |
| Fault codes | Description |
|---|---|
env:Sender ter:InvalidArgVal ter:NotFound | DoorScheduleConfiguration not found. |
AccessDoorWithoutUnlock command
This operation allows momentarily accessing a Door, without unlocking the door. It is used to signal the system that for a defined period of time the door can be opened without any alarms being generated. The DoorMode shall change to Accessed. For more information about the Accessed state and door mode restrictions, see section DoorMode data structure.
The Door shall remain accessible for the defined time. When the time span elapses, the DoorMode shall change back to its previous state.
If the request cannot be fulfilled, a Failure fault shall be returned.
A device that signals support for Access capability for a particular Door instance shall implement this method. A device that signals support for AccessTimingOverride capability for a particular Door instance shall also provide optional timing parameters (AccessTime, OpenTooLongTime and PreAlarmTime) when performing AccessDoorWithoutUnlock command.
The device shall take the best effort approach for parameters not supported, it must fallback to preconfigured time or limit the time to the closest supported time if the specified time is out of range.
AccessDoorWithoutUnlock command
- Name:
AccessDoorWithoutUnlock - Access Class: ACTUATE
| Message name | Description |
|---|---|
AccessDoorWithoutUnlockRequest | This message contains: - Token: Token of the Door instance to control.- UseExtendedTime: Optional. Indicates that the configured extended time should be used.- AccessTime: Optional. Overrides AccessTime if specified.- OpenTooLongTime: Optional. Overrides OpenTooLongTime if specified (DOTL).- PreAlarmTime: Optional. Overrides PreAlarmTime if specified.- Extension: Future extension.pt:ReferenceToken Token [1][1]xs:boolean UseExtendedTime [0][1]xs:duration AccessTime [0][1]xs:duration OpenTooLongTime [0][1]xs:duration PreAlarmTime [0][1]axtdc:AccessDoorWithoutUnlockExtension Extension [0][1] |
AccessDoorWithoutUnlockResponse | This message is empty. |
| Fault codes | Description |
|---|---|
env:Receiver ter:InvalidArgVal ter:NotFound | The specified token is not found. |
env:Receiver ter:Action ter:Failure | Failed to go to Accessed state. |