Triggers: Difference between revisions

From Telcred documentation
Jump to navigation Jump to search
No edit summary
Line 58: Line 58:
== Invoking notifications and commands ==
== Invoking notifications and commands ==


The final step of creating a trigger is to define what should happen when the trigger is activated. The same trigger can invoke both [[Notifications|notifications]] and [[Commands|commands]].






Revision as of 20:24, 29 March 2021

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

Trigger types and activation

Event

A trigger of type Event is activated when a matching event is received in the event log.


Create trigger for events

Reader input

A trigger of type Reader input is activated when a user enters a pre-defined code on an access control reader. Codes are always prefixed with a * (e.g. *112). It is possible to require authentication through either a personal PIN or card in order to activate the trigger. In this case, it is also necessary which roles should be allowed to activate the reader.


Activate trigger for readers


Remote action

A trigger of type Remote action is activated from the mobile app Telcred Personal. It is necessary to specify whether the origin is by Overview or by Door. This determines if the trigger will be displayed in the top menu of the app or on the respective page of the individual doors. It can also have consequences for what the trigger does, in case the trigger invokes a command (see further the section on origin independent commands vs. origin dependent commands in the commands documentation). Just as for Reader input with authentication, it is necessary to specify which roles are allowed to activate the trigger.


Activate remote trigger

IO port activity

Finally, a trigger of type IO port activity is activated when an input port on a controller changes state. It is necessary to specify which input port and transition should activate the trigger.


Activate IO port trigger

Optional restrictions

It is possible to restrict a trigger with regards to:

  • When the trigger can be activated
  • Which events or actions can activate the trigger

The options for restricting the trigger depend on the trigger type and possibly also on choices made regarding the trigger activation. For example, for a trigger of type Event, the available restrictions will depend on which event(s) activate the trigger. An Access granted event can be restricted with regards to time door, user, and method:


Restrictions for Access granted event


On the other hand, a Controller offline event can only be restricted with regards to time and controller:


Restrictions for Controller offline event


Restrictions that do not apply to all of the activation conditions will not be displayed. For example, if both Access granted and Controller offline are selected as activation conditions for a trigger of type Event, it will only be possible to restrict the trigger with regards to time since no event contains attributes for both door and controller. In this case, it may be necessary to create two separate triggers - each with its own restrictions.


Restrictions for mixed door and controller events


Invoking notifications and commands

The final step of creating a trigger is to define what should happen when the trigger is activated. The same trigger can invoke both notifications and commands.



No authentication credential required
  1. Enter the activation code (e.g. *111).
  2. 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
  1. Enter the activation code (e.g. *111).
  2. 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.
  3. 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.

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).


Access granted trigger activation


It is possible to define restrictions on the trigger:

  • When it can be activated (schedule)
  • From which doors it can be activated (doors and/or door groups)

Setting up a door forced open trigger

For a door forced open trigger it is not necessary to specify any activation. The trigger will activate when a door forced open event occurs.

It is possible to define restrictions on the trigger:

  • When it can be activated (schedule)
  • From which doors it can be activated (doors and/or door groups)

Setting up a remote trigger

Remote triggers are activated from the Telcred Entry app. There are two types of remote triggers:

  • Remote by overview
  • Remote by door

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.


Remote by overview


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.


Remote by door


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).

Setting up an IO port trigger

For an IO port trigger it is necessary to specify the input port and transition that should activate the trigger.


Controller trigger activation


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 configure the IO ports of the controller.

As for other trigger types, 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)