Basic architecture
The NETx BMS Server provides an interface which can be used to integrate information from the hotel management system MICROS Fidelio/Opera. Using this interface, information about the check-in/check-out procedure, the hotel guests and the hotel room states can be retrieved. In addition, it is also possible to send dedicated information from the NETx BMS Server to the MICROS Fidelio/Opera system. This interface for the NETx BMS Server is certified by MICROS. The offical certificate can be found here.
The following figure shows how the integration has to be done.
In order to connect to MICROS Fidelio/Opera system, the so called IFC interface from MICROS Fidelio/Opera has to be activated at the MICROS Fidelio/Opera side. This has to be done by the MICROS Fidelio/Opera integrator. The following figure shows a screenshot of the IFC logging window:
The communication between the IFC interface and the NETx BMS Server is based on TCP/IP. In detail, the IFC interface acts as a TCP server and the NETx BMS Server acts a TCP client. The protocol itself is based on a communication standard called FIAS.
| Info |
|---|
FIAS is a common protocol for interfacing with hotel management system. Many other vendor for hotel management system are also using FIAS. If you have to integrate a hotel management system other than supported ones, please contact the team of NETxAutomation. |
Integration steps
| Info |
|---|
The MICROS Fidelio/Opera interface is already included in the setup of the NETx BMS Server. In order to use it, an extra license is needed – for testing purposes, the "Demo" license includes the MICROS Fidelio/Opera interface. Please contact the team of NETxAutomation for more information. |
To start, open the BMS Studio. First, configure the IP address and port number that you have enter within the web service URL.This can be done by selecting "Driver Configuration" within the menu "Modules" -> "Fidelio/Opera". If this information is not known, please ask the Fidelio/Opera integrator.
| Info |
|---|
In addition the IP address and the port number, there are several configuration options which depend on the IFC settings at the Fidelio/Opera side. Normally, you can leave the default options. If the communication is not working correctly, please ask the Fidelio/Opera integrator whether "LRC" or "Use Ack" option have to be used. |
Then, the used devices have to be created. This is done within the "Device definitions" within the menu "Modules" -> "Kaba". Each definition line corresponds to one device. The first column defines the device name. The device name must be unique and is shown within the item tree the NETx BMS Server. The next column "Device ID" is optional. "Device Name" and "Device ID" are used to assign a web service notification to the corresponding item within the item tree. This means that either "Device Name" or "Device ID" must be the same as the Kaba software uses within the web service request. 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" and "Synchronize" have the same functionality as for all other interfaces within the NETx BMS Server. The following figure shows an example where 1 door lock is defined. In addition, the ZigBee/IP called "Hub Floor1" is also defined in order to receive events dedicated to the ZigBee/IP hub.
After having defined all devices, the NETx BMS Server has to be restarted. Afterwards, the configured devices are shown within the item tree under the sub tree "NETx\XIO\Kaba".
The retrieved information from Kaba is stored as Server Items. Each retrieved field from the web service request is stored as one server item. Regardless which fields are selected within the Messenger LENS interface, all fields are always shown within the NETx BMS Server. However, only 5 Server Items are counted to the license for each defined device. All other items are not counted to the license and are thus for free.
Data points for each room
- BuildingNumber (read only)
- LevelNumber (read only)
- RoomNumber (read only)
- Description (read only)
- GuestsCount (read only)
- GuestName (read only)
- GuestLanguage (read only)
- GuestVIP (read only)
- RoomChecked (read only)
- ClassOfService (read only)
- DoNotDisturb (read only)
- RoomStatus (read and write)
- ClearText (read only)
- GuestArrivalDate (read only)
- GuestDepartureDate (read only)
- PrinterPort (read only)
- MessageCount (read only)
- NextMessage (write only)
- MessageText (read only)
- GetMessage (write only)
- SendMessage (read and write)
- MessageLightStatus (read only)
Room status
| Code | Room status |
|---|---|
| 1 | Dirty/Vacant |
| 2 | Dirty/Occupied |
| 3 | Clean/Vacant |
| 4 | Clean/Occupied |
| 5 | Inspected/Vacant |
| 6 | Inspected/Occupied |
These are the predefined room states that are available within Fidelio/Opera. However, it is possible to specify additional room states for additional functionality. For example, further states for "Do not disturb" or "Make up room" can be defined. Using this additional room states, it is possible to send additional information from the BMS to the Fidelio/Opera system. A typical use case is to add a KNX switch for DND that sends a user-defined room status (e.g. 7 "DND) to the Fidelio/Opera system. These additional room states have to configured within Fieldio/Opera by the Fidelio/Opera integrator.
| Include Page | ||||
|---|---|---|---|---|
|