Installation Manual | IM-202401XX iProtect Access / Security | Functionalities | |
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.
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.
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
What 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 |
2.2 RFID card type support
What 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
Which 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: | |
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
What 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: 3.3-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 | |
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 |
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: 3.3-OSS-Events |
Support IPROTECT Access app. | IOS and ANDROID support |
2.6 OSS Events
Which 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
Based on XML import/export A1/B1...
2.7.1 OSS data on card - XML Import/Export (A1/B1)
Based on network connection (API) and Mobile access support...
2.7.2 OSS data on card & Mobile access with RF-NetManager
2.7.2.1 Use of RF-NetManager
3. DOM Service app
Connection 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.
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. |
How to add custom specific files to the system...
4.1.1 Add OSS manufacturer
Field | Content |
---|
Name | OSS manufacturer name |
OSS Manufacturer type | DOM |
OSS version | DOM API-implementation |
Default | TRUE |
Customer-specific elements supplied by TKH-Security.
Field | Content |
---|
Name | Name of the .KTL file (General key file) |
Type | Provisioner |
Upload | Select .KTL file |
Field | Content |
---|
Name | Name of the OSS update file (.xml) |
Type | Provisioner |
Upload | Select .xml file |
Field | Content |
---|
Name | Name of the OSS Enrollment file (.xml) |
Type | Provisioner |
Upload | Select .xml file |
Field | Content |
---|
Name | Name of the DOM Controller file (.xml) |
Type | Provisioner |
Upload | Select .xml file |
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.
How to create a group of files...
4.2.1 Provisioner element
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 |
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 |
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 |
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 |
4.2.1 Add Provisioner group (DOM Controller) and select elements
Field | Content |
Name | Logical name, e.g DOM-IP-Bridge |
Visible | Yes |
Provisioner tyoe | Node |
4.2.2 Add Provisioner group (OSS Enrollment) and select elements
Field | Content |
Name | Logical name, e.g OSS Enrollment |
Visible | Yes |
Provisioner tyoe | Reader |
4.2.3 Add Provisioner group (OSS Update) and select elements
Field | Content |
Name | Logical name, e.g OSS Update |
Visible | Yes |
Provisioner tyoe | Reader |
4.3 Card coding
How to setup the card- and reader settings...
4.3.1 Add Card number presentation
Field | Content |
Name | Logical name, e.g TKH Desfire |
Format | Decimal |
Calculated length | 6 |
Tab: Card | Start: 2 |
4.1.2 Add Card data interpretation group
Field | Content |
Name | Logical name, e.g Access group |
4.1.3 Add DESFire Card data interpretation
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) |
Card number |
Start | 7 |
Length | 6 |
4.1.4 Add OSS Enrollment card data interpretation
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) |
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 |
4.1.5 Add OSS Update card data interpretation
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) |
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 |
4.4 Hardware used for update and enrollment of OSS cards
How 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:
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.
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 |
4.4.2 Add Orion door controller (Node)
In iProtect, browse to menu: Installation | Hardware | Line.
Field | Content | |
---|
Name | Logical name of the Node |
Status |
Node online | Active | When activating the Node, the Orion will be detected automatically. |
4.4.3 Add online (Sirius) reader
4.4.3.1 Update reader
An update reader is required (per location) to read/write:
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.
4.5 Add the DOM controller
How 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.
Field | Content |
---|
Name | Logical name for the Line |
Features | Type | Server |
Host type | Server |
Status | Virtual |
4.5.2 Add DOM controller (Node)
In iProtect, browse to menu: Installation | Hardware | Line.
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 |
Provisioner group | Customer specific | Customer specific, supplied by TKH-Security B.V. |
Other |
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 (root or installer only) |
Button | Fetch | Retrieve the temporary users from the DOM controller. |
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. |
Select user | Delete button | Delete selected user |
| Edit button | Edit selected user |
Global settings (root or installer only) |
Button | Fetch | 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. |
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. |
4.5.2.1 Node tree-view items
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.
How 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.
4.6.1.2 Link to existing reader
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.
All newly added devices with the dom service app are automatically added to iProtect and linked to the correct reader.
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”.
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.
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.
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.
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:
4.7 Lock sensor
Battery 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".
How 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.
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 displayed
In the treeview, below the DOM Node, go to RF-NetManager: No, open this tree.
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.
5. Configuration management
5.1 Offline devices
The following section uses the DOM Service App
How 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.
Find the desired reader and unfold the reader with the + sign.
Click on the reader group list, here you can add or remove the desired reader groups.
after +- one minute the offline synchronization status of the lock will change to "the configuration is not in sync"
Get the configuration with the dom service app by syncing the app with the DOM controller.
Sync the offline device with the DOM service app.
Sync the DOM controller with the DOM service app.
after +- one minute the offline synchronization status of the lock will change to "the configuration is synchronized".
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.
5.2 Online devices
The following section uses the RF-NetManager. The DOM service app is not needed.
How 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.
Find the desired reader and unfold the reader with the + sign.
Click on the reader group list, here you can add or remove the desired reader groups.
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. Using the 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.
How 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.
Browse to the menu: Installation | Hardware | Oss manufacturer.
Select the used OSS element in the tree-view.
Change the OSS Version from “A1” or “B1” to “DOM API-implementation“ .
Browse to menu: Installation | Hardware | Node.
Select the DOM OSS Node in the tree-view.
Set the correct settings for the DOM controller see Chapter 4.5.2 .
Discover the devices by using the wizard or manually see chapter 4.6.1.2.
Set the correct unbound “device address/PHI” to the reader .
Synchronize the locks by using the DOM service app see Chapter 3 .
7.1 Reader dialog details
Detailed 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: |
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