Location:
<WorkspaceDirectory>\DataFiles\nxaTelegramDefinitions.35.dat
Within this configuration files, the KNX datapoints i.e. the KNX group addresses are specified. The structure of the definition file is as follows:
'Syntax of the Telegram Definition Table:
'log.KNX Address; IP Address; Priority; Data Size; EIS Type; Signed/Unsigned; Unit; Description; Path; Control Data; Alias; Read on Reconnect; Read Cyclically Interval;
' Persistent;Historical;Synchronize;IN Converter;OUT Converter
1/0;BROADCAST;LOW;1BIT;EIS1;;;Telegram Demo EIS1;;;;F;0;F;F;F;;
2/0;BROADCAST;LOW;4BIT;EIS2;;;Telegram Demo EIS2;;;;F;0;F;F;F;;
3/0;BROADCAST;LOW;3BYTE;EIS3;;;Telegram Demo EIS4;;;;F;0;F;F;F;;
4/0;BROADCAST;LOW;3BYTE;EIS4;;;Telegram Demo EIS4;;;;F;0;F;F;F;;
5/1;BROADCAST;LOW;2BYTE;EIS5;;°C;Telegram Demo EIS5 1;;;;F;0;F;F;F;;
5/21;BROADCAST;LOW;2BYTE;EIS5;;mA;Telegram Demo EIS5 2;;;;F;0;F;F;F;;
Each line – except comment lines that start with ' – defines a single KNX group address.
! This definition file can also be generated using the NETxKNXConvertETS App which generates the KNX datapoint definitions from an exported ETS project. For more information see Section 3.4.1.
<tr> <td>1</td> <td>log.KNX Address</td> <td></td> <td> It defines the logical KNX group address of the datapoint. The KNX group address can be specified either in three level form (e.g. 0/2/1) or in tow level form (e.g. 0/513). </td> </tr>
<tr> <td>2</td> <td>IP Address</td> <td></td> <td> It specifies the IP address of the KNXnet/IP device to which the specified KNX group address is assigned. Thus, it defines KNXnet/IP device that is used to send and receive KNX telegrams that are originated to this group address. The name "BROADCAST" defines a KNX datapoint which is sent to all defined gateways. </td> </tr>
! The logical KNX group address together with the IP address of the KNXnet/IP device define the effective address of the KNX datapoint. This effective address is internally used by the server. Using this addressing scheme, it is possible to use the same KNX group address for multiple KNX datapoints as long as they are assigned to different KNXnet/IP devices. This means that behind each gateway an independent ETS address space can exist. Theoretically up to 1000 ETS projects with the same address space are possible within the system.
<tr> <td>3</td> <td>Priority</td> <td></td> <td> It defines the KNX priority that is used to send KNX group telegrams. Possible values are SYSTEM, HIGH, ALARM and LOW. The standard value "LOW" should be used in general. </td> </tr>
! Columns 4 to 7 define how to interpret the received data of a KNX datapoint. At least two of these attributes has to defined to specify the semantic of a datapoint. All possible combinations are listed in the data type table (cf. Section 4.9.2).
<tr> <td>4</td> <td>Data Size</td> <td></td> <td>It defines the size of the datapoint. Possible values are: 1BIT, 2BIT, 4BIT, 1BYTE, 2BYTE, 3BYTE, 4BYTE, 10BYTE, 14BYTE. </td> </tr>
<tr> <td>5</td> <td>EIS Type</td> <td></td> <td> Using this column, the data types is specify by defining the EIB Interworking Standard (EIS) type. </td> </tr>
<tr> <td>6</td> <td>Signed/Unsigned</td> <td></td> <td> This attribute specifies whether the data type is a signed or unsigned one. </td> </tr>
<tr> <td>7</td> <td>Unit</td> <td></td> <td> It defines engineering units of the KNX datapoint.
It has to be selected from the list. </td> </tr>
<tr> <td>8</td> <td>Description</td> <td></td> <td> This attribute can be used to specify a human-readable text that further describes the datapoint. </td> </tr>
<tr> <td>9</td> <td>(deprecated) Path</td> <td></td> <td> This attribute is used for the automatic PDA visualization to create a tree structure like "Home/Level1/living room". </td> </tr>
<tr> <td>10</td> <td>(deprecated) Control Data</td> <td></td> <td> This attribute is used for additional input data for the automatic PDA visualization. </td> </tr>
<tr> <td>11</td> <td>(deprecated) Alias</td> <td></td> <td> This attribute can be used to define an alias name for this KNX datapoint. This alias is shown within the server item tree under the sub tree
"Alias" (cf. Section 1.3.2). </td> </tr>
<tr> <td>12</td> <td>Read on Reconnect</td> <td></td> <td> This attribute is used to define whether a KNX Read telegram shall be sent when the corresponding KNXnet/IP gateway reconnects or when the server is started. If this functionality is activated, the read flag has to be set within the corresponding KNX device using ETS. </td> </tr>
<tr> <td>13</td> <td>Read Cyclically Interval</td> <td></td> <td> This attributed is used to define whether cyclic KNX Read telegrams be sent to retrieve the current value of the datapoint. If this functionality is activated, the read flag has to be set within the corresponding KNX device using ETS. Note that cyclically reading KNX datapoints consumes bandwidth within the KNX lines. The allowed maximum Value is 65535 s with is identical to 18,20 h. </td> </tr>
<tr> <td>14</td> <td>Persistent</td> <td></td> <td> This parameter specifies whether the value of the datapoint is persistent (restored from the database after server start up ) or not. </td> </tr>
<tr> <td>15</td> <td>Historical</td> <td></td> <td> This parameter specifies whether historical values of the datapoint are stored within the database or not. </td> </tr>
<tr> <td>16</td> <td>Synchronize</td> <td></td> <td> If this parameter is set to "True (T)", the value is synchronized between the main and backup server (if present). This will work only if synchronize is enabled in the NMESH configuration of the NETx BMS Core Server. </td> </tr>
<tr> <td>17</td> <td>IN Converter</td> <td></td> <td> At this parameter you are able to define a LUA function, which can be used for INcoming conversion.
E.g. InConv() </td> </tr>
<tr> <td>18</td> <td>OUT Converter</td> <td></td> <td> At this parameter you are able to
define a LUA function, which can be used for OUTgoing conversion.
E.g. OutConv() </td> </tr>
There is a own chapter with small overview of LUA functions implemented for the conversion (cf. Section 4.6.3).
General
Content
Integrations