Versions Compared

Old Version 12

changes.mady.by.user Arnout van Wanrooij

Saved on

compared with

New Version 13

changes.mady.by.user Arnout van Wanrooij

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Installation Manual | IM-202401XX

iProtect Access / Security | Functionalities

Table of contents

Table of Contents

1. Introduction

The use of cards or tags with Mifare® DESFire® technology in combination with battery-powered locks, such as door handles or door cylinders, is already widely used. TKH-Security has a close collaboration with DOM and together we have developed a solution to gain access to both wired and battery-powered locks with a Mobile device.

Info

This manual describes only the use of a network-connected DOM controller (Bridge). When using an XML import/export, based on OSS version A1 or B1, please refer to another user manual.
Available in iProtect as of version 10.4.xx

Info

For setting up the system for using access control, in combination with a desfire card and with mobile access, please refer to another user manual. This manual describes how to add DOM (OSS and Mobile Access) to a working system.

1.1 The Solution 

IPROTECT connects to the DOM controller(s) based on a REST API. The connection works in real time, so both systems are always fully synchronized and there is no need to use old-fashioned XML import and export files (although this option will of course still exist).

When using DOM ENIQ hardware, the system is already prepared as standard for the use of "data on card", but also for mobile access. Using a mobile key makes it very flexible and easy. This applies not only to the use, but also to the creation and assignment of rights to locks and persons.

1.2 Features and Benefits DOMBox API-integration

The iProtect - DOM REST API is a new way to connect that greatly improves the A1/B1 setup. It brings new features to help both users and administrators.

Info

It's important to note that switching from A1/B1 to the API is not mandatory.

The A1/B1 setup will still work as it always has. However, the API setup provides many extra benefits and features that can make the overall experience better.

Below are the key benefits of the iProtect - DOM REST API:

  • Support for multiple DOM controllers: Users can manage several DOM controllers at the same time, making security management more flexible and scalable.

  • IPROTECT ACCESS (mobile access): Users can conveniently access the offline devices from their mobile phones, enabling them to utilize a single mobile identifier for both online and offline locks.

  • Compatibility with DOM RF Netmanager: The API works well with the DOM RF Netmanager, making it easy to update lock configurations and send door commands, which improves efficiency.

  • Real-time synchronization of OSS configuration data: Configuration data changes are instantly updated across all systems, minimizing errors and ensuring that everyone has the most current configuration status of the locks.

  • Real-time synchronization of OSS device status: Users can continuously monitor the status of their devices, allowing for quick responses to any problems.

  • Ability to add temporary DOM controller users (APP USERS): Administrators can easily add or remove users who need temporary access, like contractors who need to implement a new lock, improving security without losing convenience.

  • Automation of DOM controller backup and restore processes: Automating these processes helps prevent configuration data loss and ensures backups are regularly maintained.

  • Provisioning of AES DESFire keys to the Bridge: This feature allows for secure sharing of encryption keys. It sends the encryption keys and configurations from the iProtect system to the bridge, with the key encrypted in a KTL file (keystore).

  • Installation of discovery function processes: The API can automatically find new devices from the bridge and link those devices to the correct readers, making the setup process easier and faster.

In summary, the A1/B1 setup remains unchanged, but the iProtect - DOM REST API introduces key enhancements that improve functionality, security, and user experience.

2. Support

2.1 Hardware and licence

Expand
titleWhat hardware is supported and which licenses are needed...

Below is an overview of support for both the hardware and the software, including the necessary license:

Support

Hardware

License number

Minimum version

IPROTECT Access

IPS-ATL (Mobile access)

>= 10.4.xx

Pluto rootFS

>= 6.12.x

Reader manager (OSS Update/Enrollment reader)

>= 6.00.11

Orion (USB)

>= 1.5.34

Sirius iX (RS485)

IPS-ON - online card reader license (44)

>= 2.9.6

Access Keys

IPS-ACL - number of cards that can be created within the system

DOM

  • DOM ENiQ Pro v2

  • DOM ENiQ Guard

  • DOM ENiQ LoQ

  • ENiQ RF NetManager V2

 IPS-OFF - ofline card reader license (48)

 >= v5.9

Bridge

>= v24.07.31

Info

The following cards will be included with the DOM system:

  • RF-Wake-up

  • RF-Online

  • Replace battery

  • Master card (system specific, and this included card should be stored with safe)

Info

Software and firmware versions related to TKH Security controllers and readers are managed by iProtect.

2.2 RFID card type support

Expand
titleWhat type of cards/tags are supported...

The supported NXP rfid cards and tags are listed below:

MIFARE DESFIRE

SUPPORT

PIC MASTERKEY

TYPE

CARDNUMER LENGTH

TAG

CARD

SIZE

EV1

NO

EV2 / EV3

YES

3DES / AES

CARDNR

12 digits

70pF

17 / 70pf

4k / 8k

UID

7 byte

70pF

17 / 70pf

4k / 8k

2.3 Supported features

Expand
titleWhich features are supported in iProtect and which not...

The following features are supported:

DESCRIPTION

COMMENT

Offline access control support (data on card based on OSS)

Set unlock time in seconds

Set alternate unlock time in seconds

Office mode (Mobile access and data on card)

Reader access rights: Determ access authorisation, based on reader group(s)

SideID dependency, adjustable per reader

Max 1000 locations

Semi online access control support based on mobile devices (BLE)

Physical Controllers linked to one IPROTECT system

Max. 32 controllers

Online and real-time synchronisation with the DOM Controller

Discover function of new devices

Automatically add new DOM devices to none existing readers

Automatically add new DOM devices existing readers

Provisioning DOM controller configuration

Provisioning of OSS manufacturer settings

General BLE transmit setting per DOM controller

Automatic backup of DOM controller into iProtect

Restore DOM controller configuration

Change default password after first loging from iProtect to the DOM controller

Determine for each reader whether it should also support IPROTECT Access

When a reader is assigned for IPROTECT Access, determine the interaction:

  • All in background

  • Scan & Go device unlocked

  • Scan & Go in background

2.4 Known not supported features

The following features are NOT supported (yet):

DESCRIPTION

STATUS

Card card group limitation

Not available

Holidays

Not available

Intervention card / Firefighter card

Not available for mobile device

Office mode (Mobile Access)

Using UTC time and not Local time.

Example:

Amsterdam = UTC +1

Daylight saving time = +1

Office timezone = UTC + 2

2.5 Data on card and Mobile access

Expand
titleWhat is supported from card perspective and what are the standard capabilities...

2.5.1 MIFARE DESFire RFID

DESCRIPTION

COMMENT

Supported OSS events (enable/disable per event type)

See chapter: 2.6-OSS-Events

Office mode support

Access card authorisation

Based on card group(s) and reader(s) with time zone

Supported OSS black list cards

Firefighter (intervention) option per card

  • A tag with intervention mode can successfully open a device with a battery warning level 3 (battery dead)

  • Blok list check: yes

  • Expire date check: No

  • Access right check: Yes

  • Event write back on card: No

Info

Every customer has its own MIFARE DESFire KeyFile set

2.5.1.1 Standard OSS Application

OSS TYPE

 NUMBER

DESCRIPTION

DATA

69

No. of door or door-group (69-255)

8

Number of DayTimeSchedules (8-15)

4

Number of DayID per DayTimeSchedule (4-4)

2

Number if TimePeriods per DayID (2-4)

EVENT

18

Number if Events (18-18)

BLOCKLIST

5

 Number if Blocklisted cards (5-5)

Total

1792kB

Written on the card incl. backup file, conform OSS standard

Info

The card layout explained above can be modified but must be requested.

Please contact your account manager for this.

2.5.2 Mobile device

DESCRIPTION

COMMENT

Per card an overview of assigned reader(s) with a Mobile key

Per reader an overview of assigned persons with a Mobile key

Office mode support

Offline access rights synchronized automatically with mobile device

Semi online: All events (types) will be sent from Mobile device to iProtect.

See chapter: 2.6-OSS-Events

Support IPROTECT Access app.

IOS and ANDROID support

2.6 OSS Events

Expand
titleWhich OSS event type are used...

Possible OSS events are described below:

EVENT TYPE

DESCRIPTION

Internal error

Lock has detected an internal error. Several internal event types (memory error, power on test failure etc.) could be represented by this event when written to credential. The EventInfo field is used to supply ock manufacturer specific event codes

Access granted

Access granted

Access denied

No access. Possibility may be that the card needs to be updated.

Blocked card list full

tbt

Battery replaced

The batteries are replaced.

Failed to unlock

tbt

Blocklist

tbt

Lock jammed

tbt

Replace battery

Battery low event with the info bit from 1 to 3 depending on the level of alert

System event

General placeholder for lock events not detected as errors by the lock Intended use is for troubleshooting. The EventInfo field is used to supply lock manufacturer specific event codes.

Tampering

tbt

2.7 System architecture

Expand
titleBased on XML import/export A1/B1...

2.7.1 OSS data on card - XML Import/Export (A1/B1)

image-20241029-095843.png

Expand
titleBased on network connection (API) and Mobile access support...

2.7.2 OSS data on card & Mobile access with RF-NetManager

image-20241029-102245.png

2.7.2.1 Use of RF-NetManager

Info

When using the RF-NetManager, The following features are supported:

  • Max. 8 devices (1-15m)

  • Update configurations (no DOM service app is needed anymore)

  • Readermode change (Open, Closed, Normal)

  • Pulse lock (reaction time 2-8 Sec)

Note

The following features are NOT supported:

  • online access

  • support online events.

3. DOM Service app

Expand
titleConnection between DOM controller and the service app...

To use the DOM Service app, the configuration of the DOM controller must be synchronized with the DOM Service app.

The connection can be made via:

WIFI

For programming you can use a WIFI network. The DOM controller and the cell phone must be able to communicate with each other.

USB/Ethernet dongle

For programming you can use a USB/Ethernet dongle. The DOM controller and the cell phone must be able to communicate with each other.

4. IPROTECT

iProtect supports the OSS, standard offline access application by means that it can enroll or update
cards which are confirmed to the standard data on card solution. The OSS offline standard is a data on card
standard in which the access profiles are distributed via the access cards instead of online card readers. This
is also called: “native” or “offline”, because the access rights are defined in the iProtect database itself and are
distributed to the Sirius i-Serie update readers.

Supporting OSS does not mean that every lock can be integrated effortless since this part is not standardized. This manual only describes the DOM OSS manufacturer.

4.1 Presets

To begin the installation, you must first have the correct key and configuration files.

Warning

The KEY set is customer-specific and must be supplied by TKH Security.

Items required before the steps below can be performed:

File type

Type

Comment

OSS update.xml

Reader provisioner

Card number based on AID or UID

OSS enroll.xml

Reader provisioner

PMK dependency (AES, 3DES) and card number based on AID or UID

OSS.xml

Node provisioner

Customer specific, supplied by TKH-Security B.V.

OSS.ktl

Node and reader provisioner

Customer specific, supplied by TKH-Security B.V.

Expand
titleHow to add custom specific files to the system...

4.1.1 Add OSS manufacturer

  • Browse to the menu: Installation | Hardware | OSS manufacturer.

Field

Content

Name

OSS manufacturer name

OSS Manufacturer type

DOM

OSS version

DOM API-implementation

Default

TRUE

  • Save.

4.1.2 Add media element

Customer-specific elements supplied by TKH-Security.

  • Browse to the menu: General | Settings | Media element.

  • Add three types of files:

Field

Content

Name

Name of the .KTL file (General key file)

Type

Provisioner

Upload

Select .KTL file

  • Save this record.

Field

Content

Name

Name of the OSS update file (.xml)

Type

Provisioner

Upload

Select .xml file

  • Save this record.

Field

Content

Name

Name of the OSS Enrollment file (.xml)

Type

Provisioner

Upload

Select .xml file

  • Save this record.

Field

Content

Name

Name of the DOM Controller file (.xml)

Type

Provisioner

Upload

Select .xml file

  • Save this record.

4.2 Provisioner

A provisioner group consists of one or more elements. These elements can be configurations, key files or firmware.
The sections below describe the required combinations.

Expand
titleHow to create a group of files...

4.2.1 Provisioner element

  • Browse to the menu: Installation | Settings | Provisioner | Provisioner element..

  • Add provisioner elements.

Field

Content

Name

Logical name, e.g DOM-IP-Bridge.xml

Type

Reader - Offline settings (OSS)

Provisioner file

select the file which is created and saved in chapter 4.1.2

Active

Yes

  • Save this record.

Field

Content

Name

Logical name, e.g Keyfile.ktl

Type

Reader - Keystore

Provisioner file

select the file which is created and saved in chapter 4.1.2

Active

Yes

  • Save this record.

Field

Content

Name

Logical name, e.g OSS Enrollment.xml

Type

Reader - Sirius iX config

Provisioner file

select the file which is created and saved in chapter 4.1.2

Active

Yes

  • Save this record

Field

Content

Name

Logical name, e.g OSS update.xml

Type

Reader - Sirius iX config

Provisioner file

select the file which is created and saved in chapter 4.1.2

Active

Yes

  • Save this record.

4.2.1 Add Provisioner group (DOM Controller) and select elements

  • Browse to the menu: Installation | Settings | Provisioner | Provisioner group.

  • Add provisioner group DOM-IP-Bridge.xml.

Field

Content

Name

Logical name, e.g DOM-IP-Bridge

Visible

Yes

Provisioner tyoe

Node

  • After saving this record, open the treeview and go to Provisioner elementlist and select:

    • Element: OSS Enrollment.

    • Element: Keyfile.ktl.

    • Save this record.

4.2.2 Add Provisioner group (OSS Enrollment) and select elements

  • Browse to the menu: Installation | Settings | Provisioner | Provisioner group.

  • Add provisioner group OSS Enrollment.

Field

Content

Name

Logical name, e.g OSS Enrollment

Visible

Yes

Provisioner tyoe

Reader

  • After saving this record, open the treeview and go to Provisioner elementlist and select:

    • Element: OSS Enrollment.xml.

    • Element: Keyfile.ktl.

    • Element: Reader - LED settings, Led_act-red_acc-green_alt-blue.xml.

    • Save this record.

4.2.3 Add Provisioner group (OSS Update) and select elements

  • Browse to the menu: Installation | Settings | Provisioner | Provisioner group.

  • Add provisioner group OSS Update.

Field

Content

Name

Logical name, e.g OSS Update

Visible

Yes

Provisioner tyoe

Reader

  • After saving this record, open the treeview and go to Provisioner elementlist and select:

    • Element: OSS update.xml.

    • Element: Keyfile.ktl.

    • Element: Reader - LED settings, Led_act-red_acc-green_alt-blue.xml.

    • Save this record.

4.3 Card coding

Expand
titleHow to setup the card- and reader settings...
Info

Only fields with data, or fields that need to be specifically set are named in the table below.

4.3.1 Add Card number presentation

  • Browse to the menu: Access | Settings | Card coding | Card number presentation.

  • Add Default DesFire.

Field

Content

Name

Logical name, e.g TKH Desfire

Format

Decimal

Calculated length

6

Tab: Card

Start: 2

  • Save this record.

4.1.2 Add Card data interpretation group

  • Browse to the menu: Access | Settings | Card coding | Card data interpretation group

  • Add a group.

Field

Content

Name

Logical name, e.g Access group

  • Save this record.

4.1.3 Add DESFire Card data interpretation

  • Browse to the menu: Access | Settings | Card coding | Card data interpretation.

  • Add Default DESFire:

Field

Content

Name

Logical name, e.g TKH Desfire

Default card data interpretation

TKH Desfire

Card data interpretation group

Access group

Format

Reader communication protocol

ABA

Card type

None

Data length

12

System code

Start

1

Code

Supplied by TKH-Security (6 digits)

Note

Demo code is 002974

Card number

Start

7

Length

6

  • Save this record.

4.1.4 Add OSS Enrollment card data interpretation

  • Browse to the menu: Access | Settings | Card coding | Card data interpretation.

  • Add OSS Enrollment.

Field

Content

Name

Logical name, e.g OSS Enrollment

Default card data interpretation

TKH Desfire

Card data interpretation group

Access group

Format

Reader communication protocol

ABA

Card type

None

Data length

14

System code

Start

1

Code

Supplied by TKH-Security (6 digits)

Note

Demo code is 002974

Card number

Start

7

Length

6

Interpretation selection

Start

13

Length

2

Code

1

Offline validity

Validity period (hh:mm)

12:00

Validity update after (hh:mm)

08:00

  • Save this record.

4.1.5 Add OSS Update card data interpretation

  • Browse to the menu: Access | Settings | Card coding | Card data interpretation.

  • Add OSS Update.

Field

Content

Name

Logical name, e.g OSS Update

Default card data interpretation

TKH Desfire

Card data interpretation group

Access group

Format

Reader communication protocol

Hexadecimal

Card type

None

Data length

26

System code

Start

5

Length

6

Code

Supplied by TKH-Security (Hexadecimal)

Note

Demo code is 000B9E

Facility

Start

21

Length

4

Code

0001 (Site code)* (Decimal)

Card number

Start

15

Length

6

Interpretation selection

Start

25

Length

2

Code

1

Offline validity

Validity period (hh:mm)

12:00

Validity update after (hh:mm)

08:00

  • Save this record

Info

When using multiple locations, each location should get there own site code (and own card data interpretation).

Info

When using multiple locations, please take in to account that when physically moving from one location to another, as well as going back to the first location, that the update time is calculated accordingly.

4.4 Hardware used for update and enrollment of OSS cards

Expand
titleHow to setup the online hardware...

This chapter describes both DOM OSS data on card and mobile access. A physical controller line is created for using DOM OSS data on card that can also be used for normal access or mobile access The hardware which is used are:

  • Pluto network device.

  • Orion door controller.

  • Sirius iX card reader which supports BLE.

The on-line hardware is needed to profide the RFID card of a OSS application or to update these cards.

4.4.1 Add Network device for update- and enrollment function

Create a Pluto Network device. The readers connected to this line are used to write (add) an OSS application to the card and to update the cards when a card is presented on the reader before access is granted.

In iProtect, browse to menu: Installation | Hardware | Line.

  • Right click in the tree view and click on the icon “Add Line”:

Field

Content

Name

Logical name for the Line

Features

Type

Network device.

Host type

Pluto

Communication

Active

Activated

Active (with Nodes)

Activated

Status

Function of the line

Physical line

Address

IP Address

IP address of the relevant pluto

  • Save this record.

4.4.2 Add Orion door controller (Node)

In iProtect, browse to menu: Installation | Hardware | Line.

  • Select the Pluto line to which the Orion door controller is to be connected. Press right mouse-button: “Add Node”:

Field

Content

Name

Logical name of the Node

Status

Node online

Active

When activating the Node, the Orion will be detected automatically.

Info

When the line is active and the Orion is already connected to the Pluto, Press the button “Discover”. The Orion (with connected card readers) are created automatically.

  • Save this record.

4.4.3 Add online (Sirius) reader

4.4.3.1 Update reader

An update reader is required (per location) to read/write:

  • the events (e.g. access granted, no access).

  • the battery statuses of offline locks.

  • update access rights .

  • update the block list.

Info

When using multiple locations, each location should get there own site code. Select the corresponding Card data interpretation with the correct site code.

Browse to the menu: Installation | Hardware | Node.

  • Select the Orion door controller Node and open this in the treeview (+).

  • Select in the treeview Orion #1-4, prt 1 or prt2. Press right mouse-click, “Add Reader”

  • Fill in a logical name for the reader.

  • Select the OSS update card data interpretation at the tab “general”.

  • Select the correct provisioner group with the OSS update files.

  • See for more settings and setting details chapter “Reader dialog details”.

  • Save this record.

4.4.3.2 Enrollment reader

An enrollment reader is necessary to provide existing cards with an OSS application.

Browse to the menu: Installation | Hardware | Node.

  • Select the Orion door controller Node and open this in the treeview (+).

  • Select in the treeview Orion #1-4, prt 1 or prt2. Press right mouse-click, “add Reader”

  • Select the correct OSS update card data interpretation at the tab “general”.

  • Select the correct provisioner group with the OSS Enrollment files.

  • See for more settings and setting details chapter “Reader dialog details”.

  • Save this record.

Info

The reader is also created automatically by pressing the discover button on the pluto line

Note

For both the update reader and the enrollment reader, the update card data interpretation must be selected, the provisioner files determine whether a reader is an update or enrollment reader.

4.5 Add the DOM controller

Expand
titleHow to setup the DOM controller...

4.5.1 Add Virtual line (DOM)

Create a Virtual line. This line is needed to connect DOM controllers.

In iProtect, browse to menu: Installation | Hardware | Line.

  • Right click in the tree view and click on the icon “Add Line”:

Field

Content

Name

Logical name for the Line

Features

Type

Server

Host type

Server

Status

Virtual

  • Save this record.

4.5.2 Add DOM controller (Node)

In iProtect, browse to menu: Installation | Hardware | Line.

  • Select the virtual line to which the DOM Controller is to be connected. Press right mouse-button: “Add Node”: image-20240806-084437.png

Field

Content

Description

Name

Logical name of the Node

Features

Node type

OSS

Network

HTTP port

443

Port number of the connection to the DOM controller

IP address

e.g. 192.168.1.120

Unique IP address of the DOM controller

Password

Password of the DOM Controller (only visible for system users with Installer rights)

Set keys (SC)

Once the connection is established, you can modify the password to a unique one by clicking on the "Set Keys (SC)" button.

General image-20240806-084544.png

Provisioner group

Customer specific

Customer specific, supplied by TKH-Security B.V.

Other image-20240806-084622.png

Offline

OSS manufacturer

DOM API-implementation, see chapter 4.1.1

Bluetooth

Default TX power (iBeacon)

Transmit power 0 dBm

Logging

Log minutes

Installation option

  • Link to existing reader

  • Link to new reader

Chapter 4.6.1.2 and 4.6.1.3

Temparary login image-20240806-085557.png (root or installer only)

Button

Fetch

Retrieve the temporary users from the DOM controller.

Info

After updating iProtect or a restart of the system, the temporally users will be deleted.

Button

Add

You can utilize this button to create a temporary user, such as a user for the mobile app or a system user requiring temporary access to the DOMPloy application.

Info

After updating iProtect or a restart of the system, the temporally users will be deleted.

Select user

Delete button

Delete selected user

Edit button

Edit selected user

Global settings (root or installer only)

Button

Fetch

  • Mobile

  • Card

Get detailed system information

Field

Description

Discover

When a new device is added to the system (e.g. NetManager, lock or door handle), it can be discovered in iProtect by pressing this button. image-20240806-141349.png

Backup

Pressing the button will back up the configuration of the DOM controller. The backup is saved with the date/time of the moment of creation.

  • Activate the check mark behind "Node online.

  • Save this record.

Info

When the connection is successful, the status check mark behind "connected" will turn black.

Note

Temporary users will be automatically deleted when the OSS service restarts.

4.5.2.1 Node tree-view items image-20240806-091211.png

After creating a DOM controller (Node), multiple items are displayed under the Node in the treeview.

Tree-view item

Description

Node backup

Whenever something is changed in the configuration of the DOM controller, iProtect backs it up. The backup is kept for a maximum of 3 months.

Device manager: No

All offline devices associated with a door/reader.

Device manager: Yes

Devices which are associated to a RF-NetManager (on-line)

Device manager

Connected RF-NetManager, interfaced with the DOM Controller

Devices unbound

All offline devices, not linked to a door/reader.

4.6 Add offline device

Using DOM OSS, the device is always linked to a door (a card reader in iProtect). Access rights are then associated with the card reader.

DOM devices such as ENIQPro or ENIQGuard, for example, are added to the system using the DOM Service app.

Expand
titleHow to add offline devices to the system...

4.6.1 Add device

Although there are several methods to create the hardware, two methods will be described in this chapter.

  • The readers with access rights are prepared in iProtect and linked to the device in the Service app.

  • The reader and device are created in the DOM service app.

4.6.1.2 Link to existing reader image-20240806-092940.png

Start by adding manually readers within iProtect.

Browse to the menu: Installation | Hardware | Node.

  • Add a reader by clicking with the right-mouse button on the DOM node.

  • Click on the icon “add reader”.

  • Fill in the logical name of the reader and select the correct card data interpretation.

  • If desired, you can adjust the door open time in the "door behavior" tab.

  • Once everything has been filled in, you can press the save button.

  • You can grant access rights to the reader by adding the reader to the desired reader groups, you can do this in the reader group list under the created reader.

Browse back to the menu: Installation | Hardware | Node.

  • Select the DOM Controller Node.

  • Open the tab: Other and enable by Installation option the checkbox “Add automatically”.

  • Select “Link to existing reader' at the New device (app) option. image-20240806-092940.png

Info

When the auto-discovery process is started, assigning of new device and readers will be activated for 4 hours. After this time this process will stop automatically.

  • All newly added devices with the dom service app are automatically added to iProtect and linked to the correct reader.

    • After about a minute the device should been enrolled and linked to the reader, and you can also see this on the detail page of the readers.

  • The offline sync status will be visible and if everything is correct the status should be changed in a minute to the status “The configuration is synchronized”.

Info

If the status is different, you should check this within the DOM service app by first synchronizing the DOM service app with the DOM controller and then synchronizing the locks.

4.6.1.2.1 DOM Service app

Use the DOM service app to add the devices. During this process you can directly link the newly created readers to the correct devices in the DOM service app.

  • Synchronize the DOM service app with the DOM controller.

  • Add a device by clicking the Devices button and then clicking the + sign in the DOM service app.

  • Apply the mobile phone (Android) to the device or present de RF Wake-up card to the device (IOS).

  • Click on the OSS-SO-configuration button to link the device to the door (iProtect reader).

  • Press on the couple button.

  • Follow the instructions in the DOM service app.

Info

By using this way of configuration, only one synchronization with the device is needed

Info

If you change access rights or other reader settings after this step, synchronization must take place again for the device in question.

Once the new devices have been assigned from the DOM Service app and the app has been synchronized with the DOM controller, the devices will be enrolled and automatically linked to the correct reader in iProtect. After it has been linked automatically, when using mobile access, enable the checkbox “IPROTECT Access”.

4.6.1.3 Link to a new reader

This setup can be done automatically by the system by enabling the auto discovery function.
When a new device is assigned from the DOM Service app, and the app is synchronized with the DOM controller, iProtect will automatically recognize it and assign the preset settings to the device.

Info

By using this way of configuration, multiple synchronizations with the device are needed!

Note

The mobile phone used to program the locks must have a stable and direct online connection with the DOM controller. If this is not possible, we recommend using the manual method.

Browse to the menu: Installation | Hardware | Node.

  • Select the DOM Controller Node.

  • Open the tab: Other and enable by Installation option the checkbox “Add automatically”.

  • Select “Link to new reader' at the New device (app) option.

  • Select the correct Card data interpretation.

  • When using mobile access, enable the checkbox “IPROTECT Access”.

  • Select a Reader group which can be used during testing the system.

  • Start the auto discovery process by pressing on the start button.

Info

When the auto-discovery process is started, assigning of new device and readers will be activated for 4 hours. After this time this process will stop automatically.

4.6.1.3.1 DOM Service app

Use the DOM service app to add a new device.

  • Synchornize the DOM service app with the DOM controller.

  • Add a device by clicking the Devices button and then clicking the + sign in the DOM service app.

  • Apply the mobile phone (Android) to the device or present de RF Wake-up card to the device (IOS).

  • Change the name of the device (this will be the reader name in iProtect).

  • Press on the couple button.

  • Follow the instructions in the DOM service app (sometimes multiple synchronizations are necessary).

When the reader is synchronized, the following is displayed:

image-20240219-145840.png

4.7 Lock sensor

Expand
titleBattery condition of the device...

After connecting a DOM device to a card reader, after synchronizing the device, a sensor will automatically be created containing the battery status of the device.

Battery status

Discovery

No status available

No status available

Replace battery

Battery is almost empty

Battery replaced

Battery is replaced

Full

Battery is full

4.8 Add online device

To change the offline device into an online device, a RF-NetManager is required.

The RF-NetManager needs to be configured using the DOMPloy software, please consult the DOMConnect manual and go to next chapter "Configure and deploy a RFNM".

Expand
titleHow to add online devices to the system...

4.8.1 Discover a new RF-NetManager

Ones the RF-NetManager is configured in DOMPloy, follow the steps below.

Browse to the menu: Installation | Hardware | Node.

  • Open the tab: Other.

  • Press on the Discover button. image-20240806-105940.png

  • Add the RF-NetManager by selecting the checkbox and press the button Add.

  • In the treeview, below the DOM Node, go to RF-NetManager, the device will be displayedimage-20240806-110430.png

  • In the treeview, below the DOM Node, go to RF-NetManager: No, open this tree.

    • A list of devices are shown. Select the offline device which must be connected to the RF-NetManager.

    • Enter by Network-manager the RF-NetManager image-20240806-111638.png

    • Save this record.

  • In the treeview, the device will be moved to RF-NetManager: Yes.

  • Now the RF Wake-up card needs to be presented to the device (lock). After presenting, the leds of the device should blink blue.

Info

This linking process can take a view minutes. Sometimes a second time of presenting the RF Wake-up card is needed, or consult the DOMConnect manual.

  • After the device is synchronized, the paired reader is given the following options:

    • Reader | General

      • Reader mode: Open, Close and Normal.

    • Reader | Door behavior

      • Button option, Open ones.

Info

When using the RF-NetManager, The following features are supported:

  • Max. 8 devices (1-15m)

  • update configurations (no DOM service app is needed anymore)

  • Readermode change (Open, Closed, Normal)

  • Pulse lock (reaction time 2-8 Sec)

Note

The following features are NOT supported:

  • online access

  • support online events.

5. Configuration management

5.1 Offline devices

The following section uses the DOM Service App

Expand
titleHow to update or remove offline devices...

5.1.1 Access rights management

If you want to add or remove access rights to an offline lock, you can do this using the steps below.

Browse to the menu: Installation | Hardware | Reader.

  1. Find the desired reader and unfold the reader with the + sign.

  2. Click on the reader group list, here you can add or remove the desired reader groups.

  3. after +- one minute the offline synchronization status of the lock will change to "the configuration is not in sync"

  4. Get the configuration with the dom service app by syncing the app with the DOM controller.

  5. Sync the offline device with the DOM service app.

  6. Sync the DOM controller with the DOM service app.

  7. after +- one minute the offline synchronization status of the lock will change to "the configuration is synchronized".

Info

For more information about Access Rights see this *Access rights in iProtect™ - Knowledge Base - Confluence (atlassian.net) article on our knowledge base.

5.1.2 Remove a device

Browse to the menu: Installation | Hardware | Node

  • Double click on the DOM controller node.

  • Right-click on the reader to be deleted.

  • Press on the button Delete.

  • Open the Device unbound section below the DOM controller node.

  • Select the device and change the state from “coupled” to “not coupled”.

  • Sync the DOM service app with the DOM controller.

  • Sync the offline device with the DOM service app.

  • Sync the DOM controller with the DOM service app.

  • Remove the device from iProtect by using the delete button.

Info

When a device has been successfully removed and properly uncoupled, the device is in freewheel mode.

Warning

Be aware! When removing a device without proper disconnection, the device may enter a state that it can only be disconnected using the master card. In the worst case, the lock must be returned to the supplier.

5.2 Online devices

The following section uses the RF-NetManager. The DOM service app is not needed.

Expand
titleHow to update or remove online devices...

5.2.1 Access rights management

If you want to add or remove access rights to an offline lock, you can do this using the steps below.

Browse to the menu: Installation | Hardware | Reader.

  1. Find the desired reader and unfold the reader with the + sign.

  2. Click on the reader group list, here you can add or remove the desired reader groups.

  3. The device and the RF-NetManager start communication and synchronize the changes automaticaly.

5.2.2 Remove a device

Browse to the menu: Installation | Hardware | Node

  • Double click on the DOM controller node.

  • Right-click on the reader to be deleted.

  • Press on the button Delete.

  • Open the Device unbound section below the DOM controller node.

  • Select the device and change the state from “coupled” to “not coupled”.

  • The device and the RF-NetManager will start communication and the device will be uncoupled automaticaly.

6. Migrating from A1/B1 to DOM API-implementation

To take advantage of the new API-implementation and hereby the benefits (see Chapter 1.2), the setting in IPROTECT must be changed.

Expand
titleHow to convert A1/B1 config to API-implementation

If you want to convert A1/B1 configuration to API-implementation, the system must meet the minimum requirements, see Chapter 2.1.

  1. Browse to the menu: Installation | Hardware | Oss manufacturer.

  2. Select the used OSS element in the tree-view.

  3. Change the OSS Version from “A1” or “B1” to “DOM API-implementation“ .

  4. Browse to menu: Installation | Hardware | Node.

  5. Select the DOM OSS Node in the tree-view.

  6. Set the correct settings for the DOM controller see Chapter 4.5.2 .

Note

It is essential to configure the correct provisioner group at the DOM OSS node, as this will transmit the configuration and keys to the Bridge.

If an incorrect provisioner is selected, the locks may be programmed with the wrong keys, rendering them incompatible with the existing cards.

  1. Discover the devices by using the wizard or manually see chapter 4.6.1.2.

  2. Set the correct unbound “device address/PHI” to the reader .

  3. image-20241026-124444.png

  4. Synchronize the locks by using the DOM service app see Chapter 3 .

Note

The configuration file and the keys for the bridge are sent via the provisioner in version =>10.04. This is different from older iProtect versions. To set this up correctly, it is necessary to request a key set from TKH.

Info

When migrating a system from A1/B1 to API, all locks must be re-synchronized.

7. Extensive information

7.1 Reader dialog details

Expand
titleDetailed reader dialog information...

Below is a detailed description of the reader settings:

Field

State/Status

DOM ONLY or DOM & ORION

ORION ONLY

Name

Logical name for the Reader or same as DOM Device name

Hardware

ORION ONLY

Offline reader

Unique DOM reader ID

Automatically generated unique readerID which can be changed manually.

not available

Sub number

Unique IPROTECT sub number

Automatically generated unique Sub number which can be changed manually.

Read only field when the on-line card reader is connected the Pluto.

Status

ORION ONLY

Offline synchronization status

Not coupled

Not coupled

The coupling has been started

The coupling has been started

The configuration is not in sync

The configuration is not in sync.

The configuration is being synchronized

The configuration is being synchronized

The configuration is synchronized

The configuration is synchronized

Connection is lost

Connection is lost

Decoupling process has been started

Decoupling process has been started

Device address / PHI

Select the correct DOM Device

not available

Cosmos Access

ORION ONLY

Enable Cosmos Access

By enabling Cosmos Access on a reader, a new type of identification is activated.

By enabling Cosmos Access on a reader, a new type of identification is activated.

Only available when using SIRIUS IX card readers

Force remove button

When reader cannot be unassigned (broken), it will remove the reader from the Token Autority.

Be aware! When doing this action and the reader will be re-used again for Cosmos Access, the reader must be sent back to TKH-Security.

Synchronization status

Undefined

No status

Reader sent

Reader is signed up with the TokenAuthority

Reader assigned and tokens sent

Intermediate stage in assigning a reader

Reader assigned

Reader is assigned and can be used with Cosmos access

Interaction

All - In background

The mobile device does not need to be unlocked before it is presented to the reader. When opening the app nearby readers can be selected and opened in the app at the touch of a button

Scan & Go - Device unlocked

The mobile device does not need to be unlocked before it is presented to the reader

Scan & Go - In background

Nearby readers can be selected and opened in the app at the touch of a button

Scan & Go - and Select & Go

not available

Mobile device needs to be unlocked before presenting it to the reader. Select & Go can also be used for this reader.

Select & Go only supported when using SIRIUS IX card readers

Select & Go

not available

Nearby readers can be selected and opened in the app at the touch of a button

Select & Go only supported when using SIRIUS IX card readers

Entity state

Unknown

Unknown

To be assigned

Reader needs to be assigned

To be unassigned

Reader needs to be unassigned

Assigned

Reader is assigned

The table below describes the other reader settings:

Field

State/Status

DOM ONLY or DOM & ORION

ORION ONLY

General / General

Card data interpretation

Select the correct Card data interpretation

(Card data interpretation: update)

Per reader:

  • 1x OSS update per location

  • 1x OSS enroll

Provisioner group

NA for DOM

Per reader:

  • 1x OSS update

  • 1x OSS enroll

Reader mode (only available when reader is in connected to Device manager, when reader is on-line)

Locked

The door is closed. Access not granted.

Normal

Access granted.

Open

The door is open.

Door behavior / Door control

ORION ONLY

Unlock time (1/10 sec)

Default unlock time (3 sec - Default)

Alternate Unlock time (1/10 sec)

Default unlock time (3 sec - Default)

Device info

ORION ONLY

Public key for Cosmos

Public key is shown when the DOM controller and Mobile access are configured correctly

not available

Bluetooth / TX power (iBeacon)

Transmit power 0 dBm

Strength of the bluetooth signal can be adjusted. Do not adjust this at random! (0 dBm - Default)

not available

Fetch

Show all data from the device (registered at the DOM controller)

not available

IPROTECT ACCESS

ORION

Person

The person to check if it has a Mobile key (token) for the specific door/reader

Fetch

Shows which person(s) has a Mobile key (token) for the reader

7.2 DOMConnect Manual

View file
nameDOMConnect Manual.pdf