Architecture
...
Architecture
It is possible to integrate event information from Salto online door locks. The following figure shows how the integration has to be done.
Salto door locks are using a wireless communication protocol which is based on ZigBee. In order to retrieve information like door events, ZigBee/IP gateways are required. These gateways are provided by Salto and have the aim to translate ZigBee packet into IP packets for the local area network (LAN). Depending on the project multiple ZigBee gateways are needed.
The events are centrally collected by the Salto server software. This software package provides an interface called Salto Event Stream. This interface provides the opportunity to send events via push notification to third-party software. This means that the Salto software (TCP client) which sends TCP/IP packets to our NETx BMS Core Server (TCP server). The Salto Event Stream interface provides two event message formats - CSV or JSON based. The NETx BMS Core Server uses the JSON based variant.
...
The driver is implement as a plugin for the NETx BMS Core Server. Therefore, it has to be installed via the Extension Manager. To do so, stop the NETx BMS Core Server server and open the Extension Manager from "Extensions" tab. Select the "Salto" interface and press install as shown in the following screenshot:
...
After having installed the interface, restart the NETx BMS Core ServerServer.
Integration steps
First, the Salto Event Stream has to be configured. Open the Salto Software "RW Pro-Access For Service" and create a new Event Stream within the menu "Tools". In the second step of the wizard, give the event stream a name, select TCP/IP, enter the IP where the NETx BMS Core Server is running, select a communication port (e.g. 6001), select "JSON" as event message format and "ANSI" as encoding. The following screenshot shows an example.
In the next step, select the information that shall be retrieved by the NETx BMS Core Server. If you want to retrieve all available information, select all fields. In the next step, the users, doors, operation, and the time can be limited. After having created a new event stream, the Salto service has to be restarted.
As next, open the BMS Studiostudio. First, configure the communication port. This can be done by selecting "Driver Configuration" within the menu "Modules" -> "Salto".
SC
Then, the used doors have to be created. This is done within the "Door definitions" within the menu "Modules" -> "Salto". Each definition line corresponds to one door. Either the column "Door name" or "Door ExtID" must be present. These fields must exactly contain the same name which are used within the Salto system since they are used to assign a retrieved event to the corresponding door. The 3rd column "Path" is used to define an optional structure within the item tree. "Description" is used to provide additional information which is stored within the item property "Description". The remaining field "Persistent", "Historical" (NETx BMS 2.0 only) and "Synchronize" have the same functionality as for all other interfaces within the NETx Server.
| Field | Description |
|---|---|
| Door name* | Must exactly contain the same name which are used within the Salto system |
| Door ExtID* | Must exactly contain the same name which are used within the Salto system |
| Path | Define an optional structure within the item tree |
| Description | Provide additional information which is stored within the item property |
SC
After having defined all doors, the NETx BMS Core Server server has to be restarted. Afterwards, the configured doors are shown within the item tree under the sub tree "NETx\XIO\SALTO".
SC
The retrieved information from Salto is stored as Server Items. Each retrieved field is stored as one server item. Regardless which fields are selected within the Salto Event Stream information, all fields are always shown within the NETx BMS Core Server. However, only 5 Server Items are counted to the license for each defined door. All other items are not counted to the license and are thus for free.
The most important information is the "Operation ID" which indicates the event type. This ID can be linked to an XLogic command or LUA task in order to trigger some actions like changing a data point (e.g. trigger a lighting scene). The following table gives an overview of all "Operation IDs" and their meaning:
Operation ID | Description |
|---|---|
Operation ID | Description |
8 | New renovation code for key (online). |
| 16 | Door opened: inside handle. |
| 17 | Door opened: key. |
| 18 | Door opened: key and keyboard. |
| 19 | Door opened: multiple guest key. |
| 20 | Door opened: unique opening. |
| 21 | Door opened: switch. |
| 22 | Door opened: mechanical key. |
| 25 | Door opened: PPD. |
| 26 | Door opened: keyboard. |
| 27 | Door opened: spare card (hotel). |
| 28 | Door opened: online command. |
| 29 | Door most probably opened: key and PIN. |
| 33 | Door closed: key. |
| 34 | Door closed: key and keyboard. |
| 35 | Door closed: keyboard. |
| 36 | Door closed: switch. |
| 37 | Key inserted (energy saving device). |
| 38 | Key removed (energy saving device). |
| 39 | Room prepared (energy saving device). |
| 40 | Start of privacy. |
| 41 | End of privacy. |
| 49 | Start of office mode. |
| 50 | End of office mode. |
| 51 | Hotel guest cancelled. |
| 54 | Door programmed with spare key. |
| 55 | New hotel guest key. |
| 56 | Start of forced opening (online). |
| 57 | End of forced opening (online). |
| 58 | Start of forced closing (online). |
| 59 | End of forced closing (online). |
| 60 | Alarm: intrusion (online). |
| 61 | Alarm: tamper (online) |
| 62 | Door left opened (DLO). |
| 63 | End of DLO (door left opened). |
| 64 | End of intrusion. |
| 65 | Start of office mode (online). |
| 66 | End of office mode (online). |
| 67 | End of tamper. |
| 68 | Automatic change. |
| 69 | Key updated in "out of site" mode (online). |
| 70 | Expiration automatically extended (offline). |
| 72 | Online peripheral updated. |
| 76 | Key updated (online). |
| 78 | Key deleted (online). |
79 | Door has lost communication with the Salto software. |
| 80 | Door has re-established communication with the Salto software. |
| 81 | Opening not allowed: key no activated. |
| 82 | Opening not allowed: key expired. |
| 83 | Opening not allowed: key out of date. |
| 84 | Opening not allowed: key not allowed in this door. |
| 85 | Opening not allowed: out of time. |
| 87 | Opening not allowed: key does not override privacy. |
| 88 | Opening not allowed: old hotel guest key. |
| 89 | Opening not allowed: hotel guest key cancelled. |
| 90 | Opening not allowed: antipassback. |
| 92 | Opening not allowed: no associated authorization. |
| 93 | Opening not allowed: invalid PIN. |
| 95 | Opening not allowed: door in emergency state. |
| 96 | Opening not allowed: key cancelled. |
| 97 | Opening not allowed: unique opening key already used. |
| 98 | Opening not allowed: key with old renovation number. |
| 99 | Warning: key has not been completely updated (online). |
| 100 | Opening not allowed: run out of battery. |
| 101 | Opening not allowed: unable to audit on the key. |
| 102 | Opening not allowed: locker occupancy timeout. |
| 103 | Opening not allowed: denied by host. |
| 104 | Blacklisted key deleted. |
| 107 | Opening not allowed: key with data manipulated. |
| 111 | Closing not allowed: door in emergency state. |
| 112 | New renovation code. |
| 113 | PPD connection. |
| 114 | Time modified (daylight saving time). |
| 115 | Low battery level. |
| 116 | Incorrect clock value. |
| 117 | RF Lock date and time updated. |
| 118 | RF Lock updated. |
| 1000 | The Salto software has re-established communication with the door. |
| 1001 | The Salto software has lost communication with the door. |
| 2000 | Guest new key |
| 2001 | Guest copy key |
Article applies to the following products:
- NETx BMS Platform
- NETx Multi Protocol Server
- NETx BMS Server 2.0