Events

Overview

The events page displays all events in chronological order, with the most recent event at the top. It is possible to navigate to older events using the page selector next to the text indicating the timestamp of the oldest event on the current page.

The columns display:

• Time. Expressed in the timezone of the current organization
• Type. For example, access granted, access denied, alert,...
• Method. What credential was used in an access event
• Door
• User/Officer/Trigger
• Device
• Controller

It is possible to filter the list by using either the dropdown menus or by entering text in the text fields.

Note that not all events have values for all the columns. For example, a controller offline event does not have method, user, device, or door.

Event types

Access granted

Access granted means that the door was successfully and temporarily unlocked so that someone could enter. The access time (the amount of time that the door should be unlocked during an access granted event) can be set for the individual door.

Access denied

A grant access request can be denied for a variety of reasons depending on the credential used and how the access rules have been set up. Here are the reasons displayed in the events list with a short explanation:

• Device lacks user. The device was recognized by the system, but it is not linked to a user and therefore has no access rights.
• User lacks role. The device is linked to a user, but the user is not member of any role.
• Role lacks privilege. The user is included in one or more roles, but none of these has a privilege which provides access to this door.
• Time not in privilege. The user is included in a role which has a privilege for this door, but the privilege does not provide access to the door at this time.
• Device blocked. The device has been blocked by an administrator.
• Door blocked. The door has been blocked by an administrator or a command.
• User blocked. The user has been blocked by an administrator.
• Invalid PIN. Only a PIN was entered and it did not match the PIN of any user.
• Incorrect PIN. Access required a PIN in addition to a card and it was not entered correctly.
• Device error. Access was requested but we couldn't read the device identity correctly (typically a card that was removed too quickly).
• Unknown device. The card identity is not known by the system.
• Controller unreachable. An administrator or a user with the Telcred Personal app tried to remote open the door, but it was not possible to reach the controller.

Alerts

Alerts indicate a problem and are displayed in red in the events list. They are:

• Door forced open. The door monitor detected that the door was opened without a prior access granted event.
• Door left open. The door monitor detected that the door was open longer than specified by the Open too long alarm setting (see Doors).
• Controller tamper. The controller generated a tamper event. The Axis door controllers have two tamper sensors; one that detects motion (e.g. if the controller is removed from the wall) and one that detects light (if the lid is removed).
• Reader offline. The controller lost contact with the reader. Typically due to poor electrical connection.
• Reader tamper. The reader generated a tamper event. The reason depends on the specific reader model, but typically if the reader is removed from the wall.
• Battery alarm. Only applies to wireless locks.
• Mechanical jam. Only applies to wireless locks.
• Weak radio signal. Only applies to wireless locks.

Actions

Actions are initiated either by the administrator from the door page, or by a predefined trigger. They are:

• Override to blocked. The door is locked and access granted events are prevented. It will remain in this state until the administrator generates another override event or the door is returned to schedule.
• Override to double locked. If the door has two locks, both will be locked. It will remain in this state until the administrator generates another override event.
• Override to locked. The door will be locked. If it has two locks, only lock 1 will be locked. It will remain in this state until the administrator generates another override event.
• Override to unlocked. The door will be unlocked (regardless if it has one or two locks). It will remain in this state until the administrator generates another override event.
• Return to schedule. The door will return to being unlocked / locked / double locked as specified by its schedule(s). See further Doors.
• Trigger. A predefined trigger was activated.
• Command start. A predefined command was started by a trigger.
• Command done. A command completed successfully.
• Command failed. A command completed, but not all included actions could be carried out successfully.

Connectivity

These events have to do with the connection between the door controllers and the Telcred service. They are:

• Controller online. After having been offline, the controller came back online.
• Controller offline. The controller went offline, i.e. the Telcred service was not able to communicate with it.
• Controller reset. The controller was reset to factory default settings by the administrator. During this procedure, the controller becomes offline for approx. five minutes.
• Controller restarted. The controller was restarted by the administrator. During this procedure, the controller becomes offline for approx. two minutes.

Event methods

The event method indicates the source of an access request or change of lock state. The methods are:

• Card. A card was presented to the reader.
• PIN only. A PIN was entered on the reader, without a card being presented first. Events based on PIN only credentials cannot always be attributed to an individual user. This is because there is no guarantee that the PIN is unique (several users could have the same PIN). If the user's PIN is indeed unique, the system will display the user's name in the event log. If not, no user will be displayed in the event log.
• Remote. Access was requested via the Telcred Personal app.
• REX. The Request to EXit button was used to get access.
• Officer. An officer (administrator) initiated the event.
• URL. A URL was used to initiate the event (URLs can created for a visit.
• Command. An event was carried out by a predefined command.
• Trigger. a predefined trigger started a command. Also displayed when a command ends.
• API 1. Only used in connection with the API request Request Access by User ID.
• API 2. Only used in connection with the API request Request Access by User ID.

Events for offline wireless locks

If wireless locks from SimonsVoss SmartIntego are connected to an Axis controller via a hub, some events may be generated that do not correspond to what actually happened if the Axis controller is online while at the same time the wireless lock is offline. This special situation is further described here.