ViaVai Access Control
- Solution Overview
- Configuration
  - Phase 1: Thinknx Configurator
    - Keypad prototypes
    - Keypads
    - Areas
    - Roles
  - Examples

ViaVai Access Control

Solution Overview
Configuration & Features
- Phase 1: Thinknx Configurator
- Phase 2: Management
Application 1: Virtual Keypad
Application 2: Offices

Solution Overview

The Thinknx Access Control object permits to enhance the level of automation and security of the home/building where it is applied. It can be adapted to sectors where long term expirations are required such as service and industry sectors, but also applies to the hospitality sector where credentials are usually short term, and remote management is required.

Figure 1: Access Control Usability

The Access Control object can communicate directly with the KNX system through Thinknx server, making the integration very easy and flexible. Any standard KNX keypad can be used as an access keypad, and its buttons as code entries. Once the code is inserted, it is possible to operate a lock or switch on a KNX actuator. In addition, communication with Wiegand technology is possible through the Thinknx-Wiegand adapter, making it possible to install a suitable RFID or biometric reader.

Figure 2: Access Control Diagram

Configuration

To facilitate the work of end users and adminitrators and still be able to cover complex situations, Thinknx Access Control is configured in two different phases and with two different tools:

Phase 1: Thinknx Configurator The installer and system integrator will use Thinknx Configurator to completely define the topology of the system, creating and configuring readers, areas and roles, and creating interactions between KNX and other integrated systems.
Phase 2: Management The manager, who is most likely available on site, will focus on the everyday management tasks such as creating users and associating them with predefined roles, create calendars and time-based restrictions, add or delete access codes, view logs and movements, control area occupancy and much more. The manager will not have access to the Thinknx Configurator project, but will use a dedicated web page or Thinknx application.

Figure 3: Access Control Structure

Some of the most important features available within the Access Control:

Possibility to create Areas as parts of the building, limited by one or more gates with readers. Rights will be granted per area.
Possibility to define for each area Entry Gates and Exit Gates, which can lead to fully count the number of persons inside the area, or for timekeeping operations.
Possibility to create different Roles, with predefined privileges to access specific building areas. Any new user shall be assigned to a preconfigured role and will receive the same access rules as this role.
Possibility to define automatic expirations for user authorizations.
Automatic update of all gates when settings are modified.
Possibility to log all movements and save them inside the database or send them automatically as reports.

Phase 1: Thinknx Configurator

In the Thinknx Configurator software, open the project and add the Access Control object in the System tab. The below parameters are available for this object:

Parameters

Keypad prototypes

Keyboard prototypes allow defining the types of keyboards present in the system. To add and configure a prototype, click on the small button to the right to access the prototype creator window. For each added prototype, the following properties are available:

Parameters

Keypads

Keyboards are the devices that send codes to the server for system control. They can be physical, using KNX or Wiegand, or virtual through the Thinknx application. The number of keypads also determines the required license to use the service. At least one keypad protocol must be created prior adding the keypads. Clicking on the small button to the right will open the Keypads Manager. Each added keypad will have the following parameters:

Parameters

Checker device device label
Prototype communication prototype used for this device. A prototype must be created in Keypads Prototype in order to view it in the list here.
- If Doory(BX-DOORY(BX-Q120W)) is selected
  - KNX group for code enabled KNX group used by keypad to signal that the code is enabled (1 bit data type).
  - KNX group for storing/deleting codes KNX group to store and delete codes from the keypad (10 bytes data type).
  - KNX group for erase request KNX group to erase codes from the keypad (1 bit data type).
  - Command for tone command to execute to play tone.
  - Command if fail command to execute in case of failed entry attempt.
  - Command if success command to execute in case of successful entry.
- If a Generic KNX type is selected
  - KNX physical address physical address of the device.
  - Command if fail command to execute in case of failed entry attempt.
  - Command if success command to execute in case of successful entry.
- If Virtual key is selected
  - Command if fail command to execute in case of failed entry attempt.
  - Command if success command to execute in case of successful entry.
- If virtual key over ip is selected
  - Device IP Address: IP address of the checker device (keypad or any other access control device)
  - Device ID:Identifier of the device. Used in case there are multiple device connected to the same IP address. Can be any number associated to the checker device.
  - Command if fail command to execute in case of failed entry attempt.
  - Command if success command to execute in case of successful entry.
- If Zennio IWAC is selected
  - KNX Pin Log group KNX group used by keypad to report pin events
  - Delete all pins group KNX group used by server to delete all PINS already configured on the keypad
  - Delete PINS on startup If Enabled, the PINS already memorized inside the keypad will be deleted and the access will be granted only using VIAVAI system.
  - Command if fail command to execute in case of failed entry attempt.
  - Command if success command to execute in case of successful entry.

Areas

It contains all the areas (rooms or parts of the building) of the project, which can be monitored by one or more device checker. It will be possible to set up flow access, codes for continuous unlocking or fixed locking of the area, to know how many people are inside, and if there has been a valid entry. By clicking on the small button to the right, the Area Manager is accessible. Each added area will have the following parameters:

Parameters

Name label of the area.
Entrance doors allows you to select the checkers that are used on site to enter this specific area. The checkers should be created first in the Keypads collection.
Dual flow if disabled, the entrance checkers will be considered for both entrance and exit. If enabled, it means the area has different doors/checkers for entrance and exit. It permits to distinguish entrance and exit events and eventually count the people inside the area.
Exit doors only visible if Dual flow is enabled. allows you to select the checkers that are used on site to exit this specific area. The checkers should be created first in the Keypads collection.
Count persons only visible if Dual flow is enabled. If enabled, the system will count the number of persons inside the area based on the entrance and exit events.
Success enter command Command to execute in case of successful entrance event.
Success exit command Command to execute in case of successful exit event.
Nobody command only visit if Count persons is enabled. Command to execute in case nobody is in the area.
Somebody command only visible if Count persons is enabled. Command to execute in case somebody enters the area first.
Active codes command Command to execute whenever there is at least one active code for the area. If a new code is added for the area and there are not already valid codes, the command will be issued.
Inactive codes command Command to execute whenever there is no active codes for the area. If a code is removed from the area or expires and there are not other valid codes, the command will be issued.
Consider permanent codes If Enabled, when evaluating if the area
KNX group force closed KNX group (1 bit DPT1) to force all doors/checkers to refuse any code.
KNX group force open KNX group (1 bit DPT1) to force all doors/checkers to accept any code.
KNX group valid enter KNX gorup (1bit DPT1) to signal a valid entrance into the area.
KNX group valide exit KNX group (1bit DPT1) to signal a valid exit from the area.
KNX group someone inside only visit if Count persons is enabled. KNX group (1bit DPT1) to signal somebody is inside the area.
KNX group nobody inside only visit if Count persons is enabled. KNX group (1bit DPT1) to signal that nobody is inside the area.
KNX group n.persons KNX group (2byte unsigned integer - DPT7) to signal the number of persons in the area.

Roles

This parameter holds the collection of roles created inside the project. Users on site can be assigned a role with predefined privileges to access specific building areas. Clicking on the small button to the right will open the Roles Manager. Each added role will have the following parameters:

Parameters

Examples

Starting from the image above, let's assume we have Room 1 with a keypad (K1) to enter and a keypad (K2) to exit. Room 2 has a virtual keypad (K3) accessible via an application. Room 3 features a keypad (K4 - 2N access control Device) that can be accessed through an IP address. There is also a corridor with two keypads (K5/K6) to monitor entry and exit.

In this setup, we will have various user levels with different access permissions to these rooms. Let's assume a system with a 4-digit code, 6 possible numbers, and without zero available.

Part 1 - Room 1