In one point of view, the application can be thought as an editor of gateway configuration. This configuration can be stored either in the memory of a gateway or in a file. This chapter briefly introduces the main parts of the user interface.

1.1 Main Window Overview

1. Communication control – basic control of communication with the gateway.

2. Application status – shows the state that the application is currently in.

3. Gateway – an editor of gateway configuration.

4. Teach-in telegram – the last teach-in telegram received by the connected gateway.

5. Channel configuration – an editor of the selected Rx or Tx channel.

6. Data interpretation – displays the value registers of the selected Rx or Tx channel.

7. Telegram log – records incoming and outgoing telegrams.

Fig. 1 Main window overview

Note: The main window can operate under two modes – online and offline. The online mode occurs when there is a gateway connected and communication is running. In the online mode, overall configuration changes are being written directly to the gateway, the volatile data (e.g. V1…V6, Teach-in telegram, Telegram Log, etc.) is available and transmitting channels can be controlled (Tx data can be sent). In the offline mode, the application behaves only like an editor of the configuration data and the main window works the same way as the editor window (see chapter 1.2).

1.2 Editor Window Overview

1. Editor status – shows the state that the editor is currently in.

2. Gateway – an editor of gateway configuration.

3. Teach-in telegram – the last teach-in telegram received by the connected gateway.

4. Channel configuration – an editor of the selected Rx or Tx channel.

Fig. 2 Editor window overview

Note: The volatile data displayed (e.g. V1…V6, Signal, etc.) are meaningless in the editor window except the Teach-in telegram where the data are being taken from the main window. This behavior enables the teach-in data received by the connected gateway to be used within the editor window. Other data representing volatile registers are set to their default values (zeros).

One of the possible uses of the editor window is opening or creating a template configuration file. Such a file can include example configurations or reusable pieces of configuration. Items (channels) can be copied between the windows, as shown in Fig. 3.

Fig. 3 Copying channels between windows.

2 Communication with Gateway

To communicate with the gateway, the application uses the COM port and Modbus RTU protocol. The application always behaves like a MASTER (always starts the communication) and the gateway only responds to queries.

The gateway has three communication ports: USB, RS485 and RS232 port. Although the USB port is designated for configuring the gateway, the use of the RS485 or RS232 port is also possible thanks to a single communication interface.

Fig. 4 Common connections

2.1 Driver

Accessing a gateway via the USB interface needs a driver to be installed on your computer that causes a USB device appears as an additional COM port. Such a driver is called Virtual COM Port (VCP) driver, this is because the serial port is simulated by software.

The gateway’s USB interface is implemented using an integrated circuit from FTDI. The operating system usually performs the driver installation automatically when a gateway is first connected. Alternatively, the driver can be downloaded from the manufacturer's website and installed manually (http://www.ftdichip.com/Drivers/VCP.htm).

The operating system assigns a unique COM port during the installation. Please, pay attention what COM port is assigned to the connected gateway. If we use more than one gateway on a computer, each gateway has different port assigned because the port is assigned to a particular FTDI chip. The COM ports can be customized in the Device Manager (http://plugable.com/2011/07/04/how-to-change-the-com-port-for-a-usb-serial-adapter-on-windows-7/).

For the RS485 and RS232 ports, a USB-to-serial converter is usually needed. If this is the case, the driver and virtual COM port is related to the converter and does not depend on the connected gateway.

2.2 Communication Settings

All communication settings are available through the Communication/Communication Settings… menu option, or pressing the F11 key.

The first and most important setting we must consider is the selection of COM port. Because the application cannot search out the connected gateway automatically, the COM port must be selected manually. This may be tricky if there are many COM ports available on the computer and we do not know the right one. For that situation, the following procedure can be used to determine the port:

1. Connect the gateway to the computer (or disconnect if it has been already connected)

2. Using the F5 key update the list of available ports

3. Check out what COM port appears in the list (or disappears)

Fig. 5 Communication settings overview

2.2.1 USB

The only problem we are facing here is the selection of COM port because the remaining settings are fixed for the USB port. Simply tick the checkbox “Use the USB settings” and press “Connect”.

2.2.2 RS485 and RS232

The COM port is not associated with the gateway, rather it is associated with the device that is used to access the serial network (e.g. a USB-to-serial converter). Compared to the USB connection, it is also necessary to set parameters of the serial network that is the gateway connected to (Serial port settings) and the address of the gateway within the network (Modbus settings – SlaveAddress). Uncheck the checkbox to enable these settings.

2.3 Starting the Communication

Connect a gateway through USB, RS485 or RS232 interface to your computer, perform communication settings (if necessary), and click the “Connect” button to establish a connection between the application and gateway. If everything is all right, the message “Connected – answer OK” is shown.

Fig. 6 Communication works properly

Otherwise, if communication does not work properly, a red-highlighted error message is shown. Check the communication settings and physical connection and try again.

Fig. 7 Communication error

2.4 Getting the Data

The application gets the data automatically after connected. First, the configuration registers are read then the application switches to the state where the volatile registers are being looped. The division into the configuration and volatile registers is discussed in the following table. The range corresponds to addresses that are actually read by the application.

Tab. 1 Configuration versus volatile registers

Configuration data – it is supposed only the MASTER can change these data Loaded after the “Connect” command executed, then if necessary.
Area Name	Range	Description
RxID	400…799	Configuration of Rx channels
TxID	5000…6199	Configuration of Tx channels
RxLabels	10000…13999	Descriptions of Rx channels
TxLabels	14000…19999	Descriptions of Tx channels
Volatile data – these data may change without the participation of MASTER Being updated periodically after configuration reading done.
RxTelegramQueue	900…939	FIFO memory of recently received Rx telegrams
TxTelegramQueue	960…983	FIFO memory of recently sent Tx telegrams
ServiceRegisters	1000…1069	Data and settings concerning the gateway itself
RxValues	0…399	Last received data
RxRawData	2000…2399	Last received data in raw format

3 Main Window – Detailed Overview

3.1 Menu Options

3.1.1 File

Tab. 2 Menu – File options

Item		Meaning
	New	Creates an empty, unsaved configuration file and opens it in the editor window.
	Open	Opens an existing configuration file. Then the file content can be written to the connected gateway or shown in the editor window.
	Open in Editor	Opens an existing configuration file directly in the editor window.
	Save	Saves changes to the open configuration file.
	Save As	Saves the open configuration file as another file.
	Close	Forces the application to close.

3.1.2 Edit

Tab. 3 Menu – Edit options

Item		Meaning
	Undo	Takes back the last change made upon the gateway configuration data.
	Redo	Takes back the last undo action.
	Copy	Copies the selected Rx or Tx channels to the clipboard.
	Paste	Writes the copied Rx or Tx channels, if there are any. The writing starts at the first selected channel of the current selection.
	Cut	Copies and deletes the selected Rx or Tx channels.
	Delete	Deletes the selected Rx or Tx channels.

3.1.3 Communication

Tab. 4 Menu – Communication options

Item		Meaning
	Connect	Starts the communication with gateway. (Enters the online editor mode)
	Disconnect	Terminates the communication with gateway. (Leaves the online editor mode)
	Communication Settings	Shows the settings of communication with the gateway.

3.1.4 Tools

Tab. 5 Menu – Tools options

Item		Meaning
	Firmware Loader	Opens a utility for the firmware update. (see chapter 5)
	Clear Gateway	Deletes all Rx and Tx channels.

3.1.5 Help

Tab. 6 Menu – Help options

Item		Meaning
	View Help	Shows the manual.
	About	Shows information about the application.
	View Changelog	Briefly informs about differences between the current and recent versions.

3.2 Gateway Window

This window, together with the Channel window, can be considered an editor of gateway configuration. It is used to display and edit the configuration stored either in a connected gateway or in a file. The following sections explains the meaning of individual parts.

3.2.1 Device List Tab

This view is of particular use to manage those EnOcean elements that are able of bidirectional communication or require multiple channels to be used. It allows to operate both on receiving and transmitting channels.

There is a tree list in the tab where the channels are sorted into groups called “Device”. The channels having the same EnOcean identification number stored are assumed to belong to the same device (the ID corresponds to sender ID for Rx channels and destination ID for Tx channels).

Obsah obrázku snímek obrazovky

Popis byl vytvořen automaticky

Fig. 8 Device List Tab

3.2.2 Rx Channels Tab

This window is to manage the receiving channels. The configuration and incoming data are merged in one datagrid. The individual columns are listed and further described in the table below. The configuration registers can be changed by editing the corresponding field in the datagrid, as seen in the “Editable” column. The table also shows which registers each column is related to.

Tab. 7 Rx Channels tab – the meaning of columns (n is a channel number from 0 to 39)

Header	Description	Editable	Holding Registers
Ch.	Channel number		n
Label	A description up to 40 characters, without diacritics		10000…10099 + 100n
SenderID	Sender ID (a device that sent the telegram) (Format: “ID3-ID2-ID1-ID0”, hexadecimal)		400…403 + 10n
EEP	EnOcean Equipment Profile, this setting allows the gateway to extract the values from raw data (Format: “RORG-FUNC-TYPE”, hexadecimal)		404…406 + 10n
Icon	A pictogram representing the EEP
V1…V6	The last received data (Format: decimal number or interpretation string)		0…5 + 10n
Signal	Signal strength in dBm		6 + 10n
Counter	Counter of received telegrams		7 + 10n
Elapsed	Time elapsed since the last telegram was received		8 + 10n
Status	Channel status (Format: “Error (Error)”, decimal (string))		9 + 10n

Obsah obrázku snímek obrazovky

Popis byl vytvořen automaticky

Fig. 9 Rx Channels Tab

3.2.3 Rx Channels Raw Tab

In this tab, the raw data of Rx channels can be watched (registers 2000 to 2399). The individual columns are listed and further described in the table below. There are not any editable columns. As far as the mapping of registers concerned, it is necessary to mention that the mapping varies across different RORG settings, this issue is also covered in the table.

Tab. 8 Rx Channels Raw tab – the meaning of columns (n is a channel number from 0 to 39)

Header	Description	Editable	Holding Registers
Ch.	Channel number		n
Label	A description up to 40 characters, without diacritics		10000…10099 + 100n
SenderID	Sender ID (a device that sent the telegram) (Format: “ID3-ID2-ID1-ID0”, hexadecimal)		2000…2003 + 10n¹⁾ 2000…2001 + 10n²⁾
RORG	Radio Organization (radio telegram type), received value (Format: “RORG”, hexadecimal)		2004 + 10n¹⁾ 2002 + 10n²⁾
Data	Raw data received (Format for 1BS, RPS: “DB0 00 00 00”, for 4BS: “DB0 DB1 DB2 DB3”, for VLD telegram e.g. of 5 data bytes: “DB0 DB1 DB2 DB3 DB4 00 00 00 00 00 00 00”; hexadecimal)		2005…2008 + 10n¹⁾ 2003…2008 + 10n²⁾
Status	Channel status (for 4BS, 1BS, VLD, the same value as 9 + 10n) or the status byte received in the telegram (for RPS) (Format: “Error (Error)”, decimal (string))		2009 + 10n^{1) 2)}

1) For RORG = 0xA5, 0xD5, 0xF6 (4BS, 1BS, RPS telegrams)

2) For RORG = 0xD2 (VLD telegram)

Note: The mapping depends on the RORG as configured in the register 404 + 10n, not on the RORG received together with a data telegram (and displayed in the RORG column).

Obsah obrázku snímek obrazovky

Popis byl vytvořen automaticky

Fig. 10 Rx Channels Raw Tab

3.2.4 Tx Channels Tab

This window is to manage the transmitting channels (registers 5000 to 6199). The datagrid involves both configuration and outgoing data. The individual columns are listed and further described in the table below. The configuration registers can be changed by editing the corresponding field in the datagrid, as seen in the “Editable” column. The table also shows which registers each column is related to.

Tab. 9 Tx Channels tab – the meaning of columns (n is a channel number from 0 to 59)

Header	Description	Editable	Holding Registers
Ch.	Channel number		n
Label	A description up to 40 characters, without diacritics		14000…14099 + 100n
SenderID	Sender ID (a device that sends the telegram = the gateway), both Chip ID or Base ID can be used – see chapter 6.2 for explanation of this setting (Format: “ID3-ID2-ID1-ID0”, hexadecimal)		5000…5003 + 20n
DestinationID	Destination ID (a device that is supposed to receive the telegram) (Format: “ID3-ID2-ID1-ID0”, hexadecimal)		5004…5007 + 20n
EEP	EnOcean Equipment Profile, this setting allows the gateway to compile the values to raw data (Format: “RORG-FUNC-TYPE”, hexadecimal)		5008…5010 + 20n
Icon	A pictogram representing the EEP
V1…V7	The data to be sent (Format: decimal number or interpretation string)		5011…5017 + 20n
LearnButton	Switches between the teach-in and data telegram (works only for certain EEPs, see the gateway manual)		5018 + 20n
ResponseOption	Specifies when the telegram to be sent		5019 + 20n
Send	Button for immediate transmit, it is the same as setting the response option to “SendNow”		5019 + 20n

Tab. 10 Explanation of the response option enumeration

Identifier = corresponding value	Command description	Purpose
NotSet = 0	Do nothing.
SendNow = 1	Send this telegram immediately and set ResponseOption = NotSet.
ResponseOnReceivedOnce = 2	Send this telegram when a telegram from the target device received (target given by the DestinationID) and set ResponseOption = NotSet.	Bidirectional communication
ResponseOnReceivedAlways = 3	Send this telegram on every telegram from the target device received (target given by the DestinationID).	Bidirectional communication
UteResponseOnce = 4	Send UTE response on the next UTE query, fill in the DestinationID and EEP registers and set ResponseOption = NotSet.	Adding of a device that implements the Universal Bidirectional Teach-in procedure (UTE).
SendThisNowAndNextAfter{100+50(m-1)}ms = m (where m is from 101 to 111)	Send this telegram, then the next after the specified interval and set ResponseOption = NotSet. (e.g. send channel 1 -> wait 250ms -> send channel 2).	Simulating the RPS communication.

Fig. 11 Tx Channels Tab

3.2.5 Gateway Settings Tab

This tab visualizes the so-called service registers (registers 1000 to 1099), these are the registers concerning the settings and state information of the gateway itself.

Overview:

1. An editor of the configurable service registers

2. A listing of all service registers

The changes made in the editor must be confirmed with the “Save” button to store the new values. To restore the default values, use “Restore Defaults“ -> “Save“.

Fig. 12 Gateway Settings Tab

Fig. 13 Explanation of the Repeater enumeration

3.3 Channel Window

3.3.1 Teach-in Telegram

Teach-in data is displayed in this box that was received with the last teach-in telegram. The registers from 1012 to 1021 are utilized to get the data. The teach-in data can be used to configure channels.

Tab. 11 Teach-in telegram – the meaning of fields

Header	Description	Holding Registers
ID	Sender ID (a device that sent the telegram = a device to be tought-in) (Format: “ID3-ID2-ID1-ID0”, hexadecimal)	1012…1015
EEP	EnOcean Equipment Profile (Format: “RORG-FUNC-TYPE”, hexadecimal)	1016…1018
Manufacturer	Manufacturer ID	1019
Signal	Signal strength in dBm	1020
Counter	Number of telegrams received from the same device	1021

Fig. 14 Teach-in telegram

3.3.2 Channel Configuration

This box is different for Rx and Tx channels. There are two states:

1. Display mode: Configuration of the currently selected channel is shown.

2. Editor mode: Appears when there is an unsaved change made to the content of the box. It happens either by editing the content or by receiving a new teach-in telegram. The display is locked and channel selection only affects the channel number where the content is to be saved.

Fig. 15 Channel configuration – having unsaved changes

3.3.3 Data Interpretation

Displays the value registers of the selected channel in three formats: interpretation string, decimal and hexadecimal. A description explaining each value is also shown. “None” means that the value is not used.

Fig. 16 Data interpretation

The value descriptions are also available through tooltips in “Device List”, “Rx Channels” and “Tx Channels” tab.

Fig. 17 The tooltips explaining a value

3.4 Telegram Log Window

The telegram log records incoming and outgoing radio telegrams. This is achieved by utilizing the FIFO memory of received and sent telegrams that is located within the address range 900…939 and 960…983, respectively. Individual columns of the datagrid are listed and further described in the table below. The table also shows which registers each column is related to.

Tab. 12 Telegram Log – the meaning of columns

Header	Description	Holding Registers
Header	Description	Rx	Tx
	Row index
Ch.	Channel number	900	960
Dir.	Direction
Time	Estimated event time³⁾
SenderID	Sender ID (a device that sent the telegram) (Format: “ID3-ID2-ID1-ID0”, hexadecimal)	911...914	961…964
DestinationID	Destination ID (a device that is the telegram for), only Tx (Format: “ID3-ID2-ID1-ID0”, hexadecimal)		965…968
EEP	EnOcean Equipment Profile (Format: “RORG-FUNC-TYPE”, hexadecimal)	915…917	969…971
Values	The data received/sent (Format: decimal numbers)	901…906	972…978
Lrn	LearnButton), only Tx		979
Signal	Signal strength in dBm, only Rx	907
Counter	Counter of telegrams, only Rx	908
Elapsed	Time elapsed since the last telegram, only Rx	909
Status	Channel status, only Rx (Format: “Error”, string)	910
RawData	Raw data received, only Rx (Format for 1BS, RPS: “DB0 00 00 00”, for 4BS: “DB0 DB1 DB2 DB3”, for VLD telegram of 5 data bytes: “DB0 DB1 DB2 DB3 DB4 00 00 00 00 00 00 00”; hexadecimal)	935…938¹⁾ 933…938²⁾
QLogIndex	The order of the event	921	982
QIsFull	The value of 1 indicates that the queue is out of memory, thereby some records have been lost.	920	982
QStopwatch	A time in milliseconds measured from the log event occurred to the read of this register.	919	981
QCount	Number of telegrams to read.	918	980
Date	Event date

1) RORG = 0xA5, 0xD5, 0xF6 (4BS, 1BS, RPS telegrams)

2) RORG = 0xD2 (VLD telegram)

3) The event time is obtained using a value read from the register 919/981. The value is subtracted from the system time recorded at the time close before a data query was sent to read the queue.

Fig. 18 Telegram Log

3.4.1 Context Menu

Tab. 13 Telegram Log – context menu

Item		Meaning
	Export Log	Allows saving of the current log to file. Supported data formats: XML
	Clear Log	Discards the current log.
	Autoscroll	If checked, the data grid is scrolled down automatically whenever a new record is logged in.

4 How to Configure Channels

4.1 Assignment of Sensor – Rx Channel Only Used

4.2 Assignment of Actuator – Both Rx and Tx Channel Used

4.3 Simulating an Element – Tx Channel Only Used

5 Firmware Update

A firmware update utility called “Firmware Loader” is provided.

5.1 Uploading Program into Gateway

1. Connect a device through USB, RS485 or RS232 interface to computer; perform communication settings, if necessary; from the main menu select “Tools/Firmware Loader”.

2. Select a program file (Fig. 19 – 3).

3. Start uploading of the program (Fig. 19 – 5).

4. After the uploading finished, the device is forced to reboot and communication is lost. Then, within a few seconds, reprogramming should perform.

5. Communication is renewed and programming result code is returned (see Tab. 14).

6. Check firmware version (Fig. 19 – 2).

Fig. 19 Firmware Loader – main window overview

Tab. 14 Result codes

Code	Meaning
0x1100	Start – without reprogramming
0x1101	Start – checksum test failed
0x1102	Start – programs are the same
0x1103	Start – reprogramming performed successfully
0xFFFF	Command performed successfully
0xEEE1	Error – Undefined position
0xEEE2	Error – Undefined command

6 Miscellaneous

6.1 Backup of Gateway Configuration

The overall configuration of the gateway can be exported to a file for later recovery or reuse.

To save configuration:

1. Connect a gateway and let the configuration to be loaded.

2. Use the Save command (Ctrl+S or File/Save).

3. Select a file path and enter a file name in the dialog shown.

4. Confirm “Save”.

To load configuration:

1. Connect a gateway and start the communication.

2. Use the Open command (Ctrl+O or File/Open).

3. Select a file and confirm “Open”.

4. If the file has opened correctly, a prompt dialog is shown.

5. Select “Yes” to confirm the gateway configuration is to be overwritten.

6.2 Chip ID vs. Base ID

There is a setting called Sender ID concerning transmitting channels. The Sender ID identifies the device that transmits a telegram, in the case of Tx channels, the transmitting device is the gateway itself. Only the Chip ID or one of 128 possible Base IDs are allowed as Sender ID. This chapter should clarify what is the difference between the Chip ID and Base ID and which one to use.

The Chip ID is a unique identifier and is different for each gateway. It is an ID of the module implementing the EnOcean communication interface. Based on that fact, the Chip ID is referred to as Gateway ID in the application. The Base ID is an ID from the certain range of IDs allowed to be a Base ID and it is not unique.

The advantage of the Chip ID is the uniqueness, one device cannot be mistaken for another. But this makes the replacement of one gateway for another difficult because the teach-in procedure must be repeated with every device that stores the Sender ID of the current gateway, such devices may be switches, dimmers, valve actuators and so on. It is especially when these devices are hard to reach or there is many of them. Above stated problem can be solved using a Base ID when configuring Tx channels. For the EnOcean / Modbus RTU gateway, it can be an ID from FF-FF-FF-01 to FF-FF-FF-80.

Another application of the Base ID may be when we want the gateway to simulate one or more EnOcean elements (e.g. temperature sensor). For the preceding problem, we would probably use one Base ID common to all channels; however, in this case, the gateway must be able to transmit under different Sender IDs. It follows that a different Base ID must be used for each virtual transmitter.

Revision history

Tab. 15 Document revision history

Date	Version	Modifications made
2019-05-31	2.0	Initial release

Contents

1.1 Main Window Overview

2 Communication with Gateway