Introduction to EIB/KNX

The “European Installation Bus” (EIB) is the standard adopted by the  KNX specification for the interconnection of home appliances in a decentralized network.

In a building we can find many devices for the control of illumination, temperature, doors and blinds, etc. Overall, these devices can be classified in two broad groups of “sensors” and “actuators”. Each of these devices communicates with the other devices by sending and receiving “telegrams” (data packets) to/from the bus.

Physically, the bus can be implemented on several media:

• A twisted pair (TP) cable, running along the power line.
• Wireless communication.
• The existinig power line itself (PL)

Topology of an EIB network over TP

An EIB network is structured in several levels:

• A line segment can have up to 64 devices (called APT) attached. Every line segment has its own power supply, providing power to the devices connected to the segment.
• A line can have up to 4 line segments attached to it.
• An area is made up of a main line, that can have up to 15 more lines connected to it by means of “line couplers”.
• Finally, a backbone line can have up to 15 areas connected to it.

Addressing of the devices

In a EIB bus, every device is identified by means of a unique physical address, and one or more group addresses.

The physical address is 16 bits long and has the format AAAA-LLLL-CCCCCCCC,where:

• AAAA identifies an area (from 1 to 15)
• LLLL identifies a line inside a given area (from 1 to 15)
• CCCCCCCC identifies a device inside a line

The value AAAA=0 is used for devices directly connected to the backbone line

The value LLLL=0 is used for devices directly connected to the main line of a given area.

Finally, the value CCCCCCCC=0 identifies a line coupler or area coupler

Filtering of telegrams by line couplers

When a line coupler is configured, it is given a table with the addresses of devices directly connected to the line.

When the line coupler receives a telegram, it checks if the destination address is in the table. If it is not, the telegram is sent to the other lines. Otherwise it is sent only to the line being served by the line coupler

Structure of an IMI telegram

Inside the bus, the telegrams interchanged by devices are structured as IMI (Internal Message Interface):

Control / Origin / Destination / Counter / Length / Data / Checksum

• Control: 8 bits
• Origin: 16 bits
• Destination : 16 bits plus 1 bit (0: physical address, PA; 1: group address, GA)
• Counter : 3 bits
• Length : 4 bits. Number of bytes in the data field
• Data: de 1 a 15 bytes.  Payload
• Checksum: 8 bits to detect transmission errors.

 Connectivity to the bus from outside

TP-UART

The way external applications connect to the bus has evolved over time. Historically, TP-UART (Twisted Pair – Universal Asynchronous Receiver/Transmitter) transceivers have been used. These transceivers convert the signals employed in the twisted pairs to bytes in an RS-232 serial port. However, the TP-UART does not perform data processing, and relies on an external driver to implement the protocols.

BCU

Later, BCU (Bus Coupling Unit) devices where developed. These BCUs also expose the bus to the outside world by means of a RS-232 serial port, and besides they incorporate a micro-processor that handles the IMI communication protocol in the TP side, and an external protocol (EMI, External Message Interface) in the RS232 side.

There are two types of BCU, named BCU1 and BCU2.

The BCU1 couplers are older, and have some limitations. They have an small amount of memory, and employ a PEI16 type of serial port. PEI16 is an asynchronous protocol with a critical timing kind of handshake. This handshake can only be implemented in a personal computer by means of an specialized low-level driver.

To overcome the limitaions of the  BCU1 couplers, the newer BCU2 couplers were developed. These couplers implement more memory, and a RS-232 interface of type PEI10/FT1.2, that is not based on critical timing as the PEI16.

USB, EIBnet/IP

Finally, new devices that implement USB and ethernet interfaces were developed

The IP connectivity is done by sending/receiving UDP packets to the multicast address 224.0.23.12:3671

It is also possible to establish a one-to-one connection against the IP address of the gateway device connected to the bus.

cEMI protocol

The structure of telegrams exchanged between the bus and the outside world (EMI, External Message Interface), has suffered also an evolution, from the initial EMI1, EMI2 specifications (dependant on the physical media) to cEMI (Common External Message Interface).

The structure of a cEMI frame is:

+---------+--------+--------+--------+--------+---------+---------+--------+---------+

| Header  |  Msg   |Add.Info| Ctrl 1 | Ctrl 2 | Source  | Dest.   |  Data  |   APDU  |

|         | Code   | Length |        |        | Address | Address | Length |         |

+---------+--------+--------+--------+--------+---------+---------+--------+---------+

  6 bytes   1 byte   1 byte   1 byte   1 byte   2 bytes   2 bytes   1 byte   2 bytes

 

    Header          = See below the structure of a cEMI header

    Message Code    = See below. On Appendix A is the list of all existing EMI and cEMI codes

    Add.Info Length = 0x00 - no additional info

    Control Field 1 =

    Control Field 2 =

    Source Address  = 0x0000 - filledin by router/gatewaywith its sourceaddress whichis

                      part of the KNX subnet

    Dest. Address   = KNX group or individual address (2 byte)

    Data Length     = Number of bytes of datain the APDU excluding the TPCI/APCIbits

    APDU            = Application Protocol Data Unit - the actual payload including transport

                      protocol control information (TPCI), application protocol control

                      information (APCI) and data passed as an argument from higher layers of

                      the KNX communication stack

The Header structure is:

Header Length (1 byte) = 0x06

KNXnet version (1.0)   = 0x10

Service typedescriptor (2 bytes)

Total length (2 bytes)

 

Existing service type descriptors:

        SEARCH_REQUEST 0x0201

        SEARCH_RESPONSE 0x0202

        DESCRIPTION_REQUEST 0x0203

        DESCRIPTION_RESPONSE 0x0204

        CONNECTION_REQUEST 0x0205

        CONNECTION_RESPONSE 0x0206

        CONNECTIONSTATE_REQUEST 0x0207

        CONNECTIONSTATE_RESPONSE 0x0208

        DISCONNECT_REQUEST 0x0209

        DISCONNECT_RESPONSE 0x020A

        TUNNEL_REQUEST 0x0420

        TUNNEL_RESPONSE 0x0421

        DEVICE_CONFIGURATION_REQUEST 0x0310

        DEVICE_CONFIGURATION_ACK 0x0311

        ROUTING_INDICATION 0x0530

cEMI message codes are:

FROM NETWORK LAYER TO DATA LINK LAYER

    Data Link Layer  Message

    Primitive    Code

    ---------------  -------

    L_Raw.req          0x10     

    L_Data.req         0x11  Data Service. Primitive usedfor transmitting a data frame

    L_Poll_Data.req    0x13  Poll Data Service  

 

FROM DATA LINK LAYER TO NETWORK LAYER

    Data Link Layer  Message

    Primitive    Code

    ---------------  -------

    L_Poll_Data.con    0x25  Poll Data Service  

    L_Data.ind         0x29  Data Service. Primitive usedfor receiving a data frame

    L_Busmon.ind       0x2B  Bus Monitor Service    

    L_Raw.ind          0x2D     

    L_Data.con         0x2E  Data Service. Primitive usedfor localconfirmation that a frame was sent

                             (does not indicate a successful receive though)

    L_Raw.con          0x2F

The two control bytes structure is:

Control Field 1

 

 Bit  |

------+---------------------------------------------------------------

  7   | Frame Type  - 0x0for extended frame

      |               0x1for standard frame

------+---------------------------------------------------------------

  6   | Reserved

      |

------+---------------------------------------------------------------

  5   | Repeat Flag - 0x0 repeat frame on mediumin caseof an error

      |               0x1do not repeat

------+---------------------------------------------------------------

  4   | System Broadcast - 0x0 system broadcast

      |                    0x1 broadcast

------+---------------------------------------------------------------

  3   | Priority    - 0x0 system

      |               0x1 normal

------+               0x2 urgent

  2   |               0x3 low

      |

------+---------------------------------------------------------------

  1   | Acknowledge Request - 0x0 no ACK requested

      | (L_Data.req)          0x1 ACK requested

------+---------------------------------------------------------------

  0   | Confirm      - 0x0 no error

      | (L_Data.con) - 0x1 error

------+---------------------------------------------------------------

 

Control Field 2

 

 Bit  |

------+---------------------------------------------------------------

  7   | Destination Address Type - 0x0 individual address

      |                          - 0x1 group address

------+---------------------------------------------------------------

 6-4  | Hop Count (0-7)

------+---------------------------------------------------------------

 3-0  | Extended Frame Format - 0x0 standard frame

------+---------------------------------------------------------------

Appendix A – EMI1/EMI2/cEMI message codes

                           IMI1 EMI1 EMI2  cEMI  default comment

                                     /IMI2      dest.   

L_Busmon.ind               29   49   2B     2B   PEI

L_Raw_Data.req                       10     10   LL

L_Raw_Data.con                              2F   

L_Raw_Data.ind                              2D   

L_Data.req                 11   11   11     11   LL

L_Data.con                 2E   4E   2E     2E   NL      EMI1/IMI1: TL

L_Data.ind                 29   49   29     29   NL      EMI1/IMI1: TL

L_Poll_Data.req                      13     13   LL

L_Poll_Data.con                      25     25   NL

N_Data_Individual.req                13          LL

N_Data_Individual.con                4E          TCL

N_Data_Individual.ind                49          TCL

N_Data_Group.req                     22          NL

N_Data_Group.con                     3E          TLG

N_Data_Group.ind                     3A          TLG

N_Data_Broadcast.req                 2C          NL

N_Data_Broadcast.con                 4F          TLC

N_Data_Broadcast.ind                 4D          TLC

N_Poll_Data.req                      23          NL

N_Poll_Data.con                      35          TLG

T_Connect.req              23   23   43          TLC      EMI1/IMI1: TL

T_Connect.con                        86          MG      

T_Connect.ind              33   43   85          MG      

T_Disconnect.req           24   24   44          TLC      EMI1/IMI1: TL

T_Disconnect.con                     88          MG      

T_Disconnect.ind           34   44   87          MG      

T_Data_Connected.req       21   21   41          TLC      EMI1/IMI1: TL

T_Data_Connected.con                 8E          MG      

T_Data_Connected.ind       39   49   89          MG      

T_Data_Group.req           22   22   32          TLG      EMI1/IMI1: TL

T_Data_Group.con           3E   4E   7E          ALG

T_Data_Group.ind           3A   4A   7A          ALG

T_Data_Broadcast.req       2B   2B   4C          TLC

T_Data_Broadcast.con                 8F          MG

T_Data_Broadcast.ind       38   48   8D          MG

T_Data_Individual.req      2A   2A   4A          TLC

T_Data_Individual.con      3F   4F   9C          MG

T_Data_Individual.ind      32   42   94          MG

T_Poll_Data.req                      33          TLG

T_Poll_Data.con                      75          ALG

M_Connect.req                                  

M_Connect.con                                  

M_Connect.ind                        D5          User     PEIif User is not running

M_Disconnect.req                               

M_Disconnect.con                               

M_Disconnect.ind                     D7          User     PEIif User is not running

M_User_Data_Connected.req  31   31   82          MG

M_User_Data_Connected.con            D1          User     PEIif User is not running

M_User_Data_Connected.ind  59   49   D2          User     PEIif User is not running

A_Data_Group.req                     72          ALG

A_Data_Group.con                     EE          User     PEIif User is not running

A_Data_Group.ind                     EA          User     PEIif User is not running

M_User_Data_Individual.req           81          MG

M_User_Data_Individual.con           DE          User     PEIif User is not running

M_User_Data_Individual.ind           D9          User     PEIif User is not running

A_Poll_Data.req                      73          ALG

A_Poll_Data.con                      E5          User     PEIif User is not running

M_InterfaceObj_Data.req              9A          MG

M_InterfaceObj_Data.con              DC          User     PEIif User is not running

M_InterfaceObj_Data.ind              D4          User     PEIif User is not running

U_Value_Read.req           35   35   74          ALG

U_Value_Read.con           55   45   E4          User

U_Flags_Read.req           37   37   7C          ALG

U_Flags_Read.con           57   47   EC          User

U_Event.ind                5D   4D   E7          User

U_Value_Write.req          36   36   71          ALG

U_User_data                         >D0          User

PC_SetValue.req            46   46   A6          MG      In BCU2 not posted to MG but handledin PEI module

PC_GetValue.req            4C   4C   AC          MG      In BCU2 not posted to MG but handledin PEI module

PC_GetValue.con            4B   4B   AB          PEI

PEI_Identify.req                     A7          -

PEI_Identify.con                     A8          PEI

PEI_Switch.req                       A9          -

TM_Timer.ind                         C1         User

—