Commands: Difference between revisions
Jump to navigation
Jump to search
Telcredstaff (talk | contribs) |
Telcredstaff (talk | contribs) |
||
| (82 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
== Overview == |
== Overview == |
||
A ''command'' is |
A ''command'' is one or more predefined actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]] being activated. |
||
Some use cases for commands include: |
|||
* Perform an action simultaneously on a set of doors, e.g. block all doors in a section of the building to achieve a "lockdown". |
|||
* Interact with an external system (e.g. arm or disarm an intrusion detection system or turn on the lights). |
|||
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule). |
|||
=== Origin dependency for commands and relevance for triggers === |
|||
With ''origin'' is meant a door or a controller that forms the context for executing a command. [[Triggers]] of the type 'Remote action from overview’ do not provide one, and may therefore only execute commands that are origin independent. |
|||
All other types of triggers provide an origin and may thus execute both origin independent and origin dependent commands. |
|||
Some use cases for commands and triggers include: |
|||
* Perform an action simultaneously on a number of doors, a door group, or a combination of both (e.g. block all doors in a section of the building to achieve a "lockdown"). |
|||
* Interact with an external system (e.g. arm or disarm an intrusion detection system or turn on the lights) |
|||
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule) |
|||
== Origin independent commands == |
|||
=== Commands === |
|||
Origin independent commands always operate on the same door(s) / controller(s) / external target(s) regardless of how or from where the command is triggered. An example of an origin independent command could be to always unlock the same two doors. |
|||
==== Command targets ==== |
|||
=== Perform: On doors === |
|||
When creating a new command, you need to give it a name and define its target: |
|||
* ''Doors''. Performs an action on one or more doors. The actions available are the same that the administrator can perform from the [[Doors|door detail page]]. |
|||
* ''External''. Will make an http request to an external system. It is possible to specify the URL, http method, and body. |
|||
* ''Output port''. Activate, deactivate, or pulse an output port. |
|||
* ''Controllers''. Target the output port(s) of one or more specific controllers. |
|||
* ''Compound''. Perform a series of commands of any type listed above. Furthermore, a compound command can also refer to other compound commands (they can be nested). One example usage of compound commands is to create a command which both affects doors and can interact with external systems, e.g. block all doors in one building, turn on a siren connected to an output port, and make an http request to an alarm center. |
|||
Choose the command to be executed and the door(s) to operate on. |
|||
The available commands are: |
|||
[[File:new-command.png|New command]] |
|||
* Grant access |
|||
* Override to blocked |
|||
* Override to double locked |
|||
* Override to locked |
|||
* Override to unlocked |
|||
* Release override |
|||
==== Performing commands from the administrator GUI ==== |
|||
[[File:command-independent-doors.png|Independent command on doors]] |
|||
In most cases, it is possible to perform (or "run") the command straight from its detail page: |
|||
If ''All doors'' is selected the command will be performed on all of the doors in the [[Delegation|organization]]. |
|||
[[File:perform-command.png|Perform command]] |
|||
=== Perform: On controllers === |
|||
Choose the command to be executed and the controller(s) to operate on. |
|||
The exception to this rule is ouput port commands, which need to be started from a controller detail page (see below). |
|||
The available commands are the ones that have been defined for ''Origin port output'' (see the section on Origin dependent commands below). |
|||
==== Commands targeting output ports ==== |
|||
Configuring commands that target the output port(s) on one or more controllers is a little complicated. First, it is necessary to configure the command(s) with target ''Output port''. It is necessary to specify which output port the command should act on and what the action should be (''activate'', ''deactivate'', or ''pulse''). |
|||
[[File:command-independent-controllers.png|Independent command on controllers]] |
|||
[[File:activate-output-port.png|Activate output port]] |
|||
If ''All controllers'' is selected the command will be performed on all of the controllers in the [[Delegation|organization]]. |
|||
=== Perform: Externally === |
|||
Note that not all controllers have all IO ports (e.g. Axis A1001 only has IO1 and IO2) so it is necessary to know which type of controller that will be used when specifying the output port of the command. It is also necessary to [[A1001_settings#IO_port_settings|configure the IO ports of the controller]]. |
|||
Construct the API call to be performed by choosing the http method (GET/PUT/POST) and the body of the message. |
|||
Command(s) with target ''output port'' cannot be performed directly from the command detail page (as it has not been defined which controller(s) they should target). Instead, they can be performed from a controller detail page if the controller has a matching output port configured. The command button(s) will show up under the ''Actions'' section for the controller. |
|||
[[File: |
[[File:command-independent-externally.png|Independent command externally]] |
||
=== Perform: Independent sequence === |
|||
A list of origin independent commands to be executed in a given order. Note that if one command fails, the sequence will be terminated. |
|||
Another way to perform an output port command is to specify it as the action of a command with target ''Controllers'' and then tie the command to a ''trigger'' (see further below). One example where this could be relevant is if the output port of a specific controller has been directly connected to e.g. an alarm panel and it should be possible to arm or disarm the alarm from any of a number of readers. |
|||
[[File:command-independent-sequence.png|Independent command sequence]] |
|||
== Origin dependent commands == |
|||
[[File:controller-command.png|Controller command]] |
|||
For origin dependent commands, it matters ''from where'' the command is triggered. The door or controller on which the command operates is dependent on the ''origin'' of the trigger. |
|||
One example of an origin dependent command is to unlock a door by entering a special code on its associated reader. |
|||
Note: If no specific controllers are specified, the command will act on the output port of ALL the controllers in the system. |
|||
An origin is either a door or a controller. Given a door origin, a command that requires a controller, when executed, will be applied on the controller of the door. Given a controller origin, a command that requires a door, when executed, will be applied on each of the doors of the controller. |
|||
=== Triggers === |
|||
=== Perform: Native door command === |
|||
Door commands are "native", i.e. are already available in the system, so there is no need to define them before they can be invoked by a trigger or included in other commands. |
|||
Triggers are a way to start one or more commands. There are several trigger types: |
|||
* ''Reader anonymously''. The trigger is activated by entering a special code on an access control reader. No authentication required. |
|||
* ''Reader - PIN authentication''. The trigger is activated by entering a special code on an access control reader, followed by a personal PIN. |
|||
* ''Reader - card authentication''. The trigger is activated by entering a special code on an access control reader, followed by a card credential. |
|||
* ''Access granted''. The trigger is activated when access is granted through a reader, the [[Telcred Entry]] app, a ''[[Visits|visit]]'' URL, or REX (but not by an administrator or through the API). |
|||
* ''Remote by overview''. The trigger is available from the [[Telcred Entry]] app, without first selecting a specific door. |
|||
* ''Remote by door''. The trigger is available from the [[Telcred Entry]] app, after selecting a specific door. The door from which the trigger was activated will be considered in the command. |
|||
* ''IO port activity''. The trigger is activated when an input port on a door controller changes state. |
|||
The native door commands are: |
|||
==== Setting up a reader (door) trigger ==== |
|||
* Grant access |
|||
* Override to blocked |
|||
* Override to double locked |
|||
* Override to locked |
|||
* Override to unlocked |
|||
* Release override |
|||
=== Perform: Origin port output === |
|||
Reader triggers are activated by entering a special code on an access control reader. First, it is necessary to define which command(s) the trigger should start. A reader trigger can start any type of command(s), including both door actions and user defined commands. |
|||
Select the target output port and the action that should be performed. |
|||
Note that not all controllers have all IO ports (e.g. Axis A1001 only has IO1 and IO2) so it is necessary to know which type of controller that will be used when specifying the output port of the command. It is also necessary to [[A1001_settings#IO_port_settings|configure the IO ports of the controller]]. |
|||
[[File:door-trigger.png|Door trigger]] |
|||
Native door actions are applied to the door of the reader where the trigger is activated and output port commands are applied to the controller of the reader where the trigger is activated. If it is desired to manipulate other doors or other controllers, it is necessary to first create commands with target ''Doors'' and/or ''Controllers''. |
|||
The next step is to define how to activate the trigger. Reader trigger activation codes always start with a * followed by one or more digits. It is recommended to use the same number of digits as for normal user PIN codes minus one, so that the total length of the activation code including the * matches the max PIN length. |
|||
Reader trigger activation codes need to be unique over the doors in their scope. This means that two different triggers can have the same activation code, as long as the doors they are restricted to (see below) do not overlap. An example of where this can be useful is if a trigger is used to lock down the building where the trigger is used. In this example, users only have to remember one code, but only the doors of the building where the activation code is entered will be affected. |
|||
[[file:trigger-activation.png|Trigger activation]] |
|||
For reader trigger types that require an authentication credential (PIN or card) it is necessary to specify which role(s) that should have access to the trigger. Note that in this context, the PIN is the user's PIN, which has nothing to do with the trigger activation code. |
|||
Finally, it is possible to define restrictions on the trigger: |
|||
* When it can be entered (schedule) |
|||
* From which doors it can be entered (doors and/or door groups) |
|||
[[file:trigger-restrictions.png|Trigger restrictions]] |
|||
==== Activating a reader trigger ==== |
|||
All readers behave a bit differently, however the general process will look like this: |
|||
===== No authentication credential required ===== |
|||
# Enter the activation code (e.g. *111). |
|||
# Wait for a blinking "success indicator" (will blink for approx. two seconds). The success indicator indicates that the command completed successfully, and will look different on different readers. If the success indicator is not displayed, the command failed to complete all of its actions. |
|||
===== Authentication credential required ===== |
|||
The available actions are: |
|||
# Enter the activation code (e.g. *111). |
|||
* Activate |
|||
# Wait for the reader to start blinking (can take a few seconds). This means that the reader has been temporarily blocked and is ready to receive the authentication credential (i.e. user PIN or card) without granting access. |
|||
* Deactivate |
|||
# Wait for a blinking "success indicator" (will blink for approx two seconds). The success indicator indicates that the command completed successfully, and will look different on different readers. If the success indicator is not displayed, the command failed to complete all of its actions. |
|||
* Pulse |
|||
For Pulse, it is possible to set the pulse length in seconds. |
|||
==== Setting up an access granted trigger ==== |
|||
For an access granted trigger it is not necessary to specify any activation. The trigger will activate on all user initiated access granted events (but not on access granted events initiated from the Telcred API). |
|||
[[File:command-dependent-port.png|Dependent command port output]] |
|||
=== Perform: Sequence applied on origin === |
|||
[[file:access-granted-activation.png|Access granted trigger activation]] |
|||
A list of commands of any type to be executed in a given order. The origin will be used for any origin dependent commands in the list. |
|||
As for other trigger types, it is possible to define restrictions on the trigger: |
|||
[[File:command-dependent-sequence.png|Dependent command sequence]] |
|||
* When it can be entered (schedule) |
|||
* From which doors it can be entered (doors and/or door groups) |
|||
==== Setting up a remote trigger ==== |
|||
Note that if one command fails, the sequence will be terminated. |
|||
Remote triggers are activated in the [[Telcred Entry]] app. There are two types of remote triggers: |
|||
== Performing commands from the administrator GUI == |
|||
* Remote by overview |
|||
* Remote by door |
|||
=== Origin independent commands === |
|||
Remote by overview triggers do not include information about any specific door when they are activated by the user. Therefore, they can only be used with commands defined by the administrator (as opposed to "native" door commands, e.g. ''override to unlock''). In other words, remote by overview should be used for commands that do not target a specific door. |
|||
Origin independent commands can be performed from their detail page: |
|||
[[file:remote-by-overview.png|Remote by overview]] |
|||
[[File:perform-command-independent.png|border|Perform independent command]] |
|||
=== Native door commands === |
|||
Remote by door commands are available from the door page in the [[Telcred Entry]] app, and include information about the door when they are activated by the user. Therefore, they are suitable for triggering commands that target individual doors, e.g. override to unlock, override to locked, etc. |
|||
Native door commands can be performed from a door detail page, where they are called ''Actions''. |
|||
[[file:remote-by-door.png|Remote by door]] |
|||
[[File:perform-door-actions.png|border|Perform door actions]] |
|||
=== Origin port commands === |
|||
It is possible to define a ''remote by door'' trigger that invokes a command that does not target any specific door. However, that has the potential to confuse the end user, so it is not recommended to do so. The reason administrator defined commands are available also for ''remote by door'' triggers is that a trigger can invoke several commands of which one could be door specific and others not (e.g. unlock the door and turn on the light). |
|||
Origin port output commands can be performed from a controller detail page (if the controller has a matching output port configured). |
|||
==== Setting up an IO port trigger ==== |
|||
[[File:perform-origin-port-commands.png|border|Perform origin port commands]] |
|||
For an IO port trigger it is necessary to specify the input port and transition that should activate the trigger. |
|||
=== Sequence applied on origin === |
|||
A sequence of commands of which at least one is origin dependent can be launched from either a door detail page or a controller detail page. |
|||
[[file:controller-trigger-activation.png|Controller trigger activation]] |
|||
[[File:perform-sequence-on-origin.png|border|Perform sequence applied on origin commands]] |
|||
Just as for commands targeting the output port(s) not all controllers have the same number of IO ports, so it is necessary to know which type of controller that will be used when specifying the input port for the trigger. It is also necessary to [[A1001_settings#IO_port_settings|configure the IO ports of the controller]]. |
|||
As for other trigger types, it is possible to define restrictions on the trigger: |
|||
Given a door origin, a command that requires a controller, when executed, will be applied on the controller of the door. Given a controller origin, a command that requires a door, when executed, will be applied on each of the doors of the controller. |
|||
* When it can be entered (schedule) |
|||
* From which doors it can be entered (doors and/or door groups) |
|||
Latest revision as of 16:41, 13 October 2021
Overview
A command is one or more predefined actions that can either be performed by an administrator or as a result of a trigger being activated.
Some use cases for commands include:
- Perform an action simultaneously on a set of doors, e.g. block all doors in a section of the building to achieve a "lockdown".
- Interact with an external system (e.g. arm or disarm an intrusion detection system or turn on the lights).
- Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule).
Origin dependency for commands and relevance for triggers
With origin is meant a door or a controller that forms the context for executing a command. Triggers of the type 'Remote action from overview’ do not provide one, and may therefore only execute commands that are origin independent.
All other types of triggers provide an origin and may thus execute both origin independent and origin dependent commands.
Origin independent commands
Origin independent commands always operate on the same door(s) / controller(s) / external target(s) regardless of how or from where the command is triggered. An example of an origin independent command could be to always unlock the same two doors.
Perform: On doors
Choose the command to be executed and the door(s) to operate on.
The available commands are:
- Grant access
- Override to blocked
- Override to double locked
- Override to locked
- Override to unlocked
- Release override
If All doors is selected the command will be performed on all of the doors in the organization.
Perform: On controllers
Choose the command to be executed and the controller(s) to operate on.
The available commands are the ones that have been defined for Origin port output (see the section on Origin dependent commands below).
If All controllers is selected the command will be performed on all of the controllers in the organization.
Perform: Externally
Construct the API call to be performed by choosing the http method (GET/PUT/POST) and the body of the message.
Perform: Independent sequence
A list of origin independent commands to be executed in a given order. Note that if one command fails, the sequence will be terminated.
Origin dependent commands
For origin dependent commands, it matters from where the command is triggered. The door or controller on which the command operates is dependent on the origin of the trigger.
One example of an origin dependent command is to unlock a door by entering a special code on its associated reader.
An origin is either a door or a controller. Given a door origin, a command that requires a controller, when executed, will be applied on the controller of the door. Given a controller origin, a command that requires a door, when executed, will be applied on each of the doors of the controller.
Perform: Native door command
Door commands are "native", i.e. are already available in the system, so there is no need to define them before they can be invoked by a trigger or included in other commands.
The native door commands are:
- Grant access
- Override to blocked
- Override to double locked
- Override to locked
- Override to unlocked
- Release override
Perform: Origin port output
Select the target output port and the action that should be performed.
Note that not all controllers have all IO ports (e.g. Axis A1001 only has IO1 and IO2) so it is necessary to know which type of controller that will be used when specifying the output port of the command. It is also necessary to configure the IO ports of the controller.
The available actions are:
- Activate
- Deactivate
- Pulse
For Pulse, it is possible to set the pulse length in seconds.
Perform: Sequence applied on origin
A list of commands of any type to be executed in a given order. The origin will be used for any origin dependent commands in the list.
Note that if one command fails, the sequence will be terminated.
Performing commands from the administrator GUI
Origin independent commands
Origin independent commands can be performed from their detail page:
Native door commands
Native door commands can be performed from a door detail page, where they are called Actions.
Origin port commands
Origin port output commands can be performed from a controller detail page (if the controller has a matching output port configured).
Sequence applied on origin
A sequence of commands of which at least one is origin dependent can be launched from either a door detail page or a controller detail page.
Given a door origin, a command that requires a controller, when executed, will be applied on the controller of the door. Given a controller origin, a command that requires a door, when executed, will be applied on each of the doors of the controller.