Presentation - KNX

Tutor crash course 

Part 5: KNX Protocol

KNX Protocol: hierarchical classification of bus systems 

• Field level 

• Sensor/actuator level 

• Small data throughput – time 

critical 

• Typical KNX 

• Process level 

• Centralised devices monitoring 

sensors and controlling actuators 

(e.g. building management 

station) 

• Operation level 

• Centralised computer monitoring 

devices at process level 

• Large data throughput – not so 

time critical 

System bus 

e.g. Ethernet 

Operation 

Main 

Computer 

Process 

Process 

computer/ 

Control 

Center 

Process 

computer/ 

Control 

Center 

Field 

Bus 

device 

Bus 

device 

Bus 

device 

Bus 

device 

Field bus (e.g. Profibus) 

KNX Association International KNX: The worldwide STANDARD for Home & Building Control 

Page No. 2 

August 12

KNX Protocol: classification of serial bus systems 

• Frequency Division 

Multiplexing 

• More than one device 

can access the bus at 

one given instance 

• Time Division 

Multiplexing 

• One single device 

accesses the bus at 

one given instance 

- KNX TP1 = Carrier 

Sense Multiple 

Access with 

Collision Avoidance 

Serial 

busses 

Frequency Division Multiplexing 

(FDM) 

One bus device per pair of channels 

(bidirectional) 

Several bus devices per pair of channels 

(need for similar bus access methods as 

TDM) 

Time Division Multiplexing (TDM) 

Controlled bus access 

Centralized bus allocation 

(Master/Slave) 

Decentralized bus allocation (Token 

passing, Flying master) 

Random bus access 

CSMA/CD 

CSMA/CA 


Page No. 3 

August 12

KNX Protocol: OSI - Principles 

• OSI = Open Systems Interconnection 

• Is a standard for modelling/structuring distributed 

communication systems 

• Does not dictate the development method 

• All layers in the device contribute to a part of the sent message 

– each layer in the device decodes part of a received message - 

similar to peeling layers off an onion 

• model consists of seven layers, of which some are not used in 

KNX 


Page No. 4 

August 12

KNX Protocol: types of communication 

• Connection oriented 

communication 

• communication between a maximum 

of two devices (point-to-point) 

• highly secure communication, not 

very bandwidth effective 

• Link and Transport Layer 

acknowledgements will be visible 

• in KNX: typically during 

configuration of devices (between 

ETS and device) 

• similar to talking to one single 

person and checking after each 

question whether he/she understood 

the question 


Page No. 5 

August 12

KNX Protocol: types of communication 

• Connectionless communication 

• communication one to many 

(« group or multicast ») or one to all 

(« broadcast ») 

• very bandwidth effective, not 

secure communication (one 

common confirmation of reception to 

the sent message) 

• only Link Layer acknowledgements 

will be visible on the bus 

• in KNX typically after configuration of 

devices, i.e. during runtime 

• similar to talking to a group of 

persons and continuing with next 

question if only one person confirms 

that he/she understood the question 


Page No. 6 

August 12

OSI & KNX (top down) – Application Layer 

• provides mechanisms for communication (group) objects. The 

application layer ensures that 

• an application program is informed when the value in one of its 

communication objects was updated (received telegram) or 

• that the OSI KNX stack creates a telegram when a value of a 

communication object updated by the application program (sent 

telegrams) 

• In other words : when connected to the application layer, the application 

program is unable to retrieve who was the source of the update!!! 

• provides mechanisms for management purposes. These services 

- as part of the OSI KNX stack - ensure that devices understand 

configuration commands, e.g. sent by ETS (MemoryRead, 

MemoryWrite, ….). 


Page No. 7 

August 12

OSI & KNX : Presentation and Session Layer 

• (Presentation Layer) 

• ensures that information is always presented to the application 

layer (received telegrams) or transport layer (sending telegrams) 

in the right order 

• Not needed/available in the OSI KNX stack 

• (Session Layer) 

• ensures that communication can be interrupted for a certain 

period of time and resumed (at the point where one interrupted it) 

at a later stage 

• Not needed/available in the OSI KNX stack 


Page No. 8 

August 12

OSI & KNX: Transport Layer connection oriented 

• transport layer messages will be visible next to Link Layer 

messages - sequence of events 

• opening a connection from device A (USB linked to ETS) to 

device B (device to be downloaded) : T_Connect 

• sending telegram for A to B or vice versa 

- A and B send T_Ack when properly received 

- A and B send T_Nack when not properly received - will cause a 

repetition (maximum 3 times) 

- a sequence number is incremented after each data exchange 

• closing a connection from device A to B : T_Disconnect - also 

automatically when communication partner did not react within 6 

seconds 


Page No. 9 

August 12

TL Connection Oriented 

Pos 

Sender 

TL Connect 1.1.1 to 1.1.2 

Message Seq. No. 0 

Receiver 

TL Ack Message Seq. No. 0 

TL Disconnect 1.1.1 to 1.1.2 

1.1.1 (ETS) 

1.1.2 

(Device to be programmed) 

Neg 

Sender 



Receiver 

TL Nack Message Seq. No. 0 

Rep Message Seq. No. 0 (max 3) 

1.1.1 (ETS) 


1.1.2 



Page No. 10 

August 12

TL Connection Oriented 

No 

Sender 


Receiver 


… 

Rep Message Seq. No. 0 (max 3) 

1.1.1 (ETS) 


1.1.2 



Page No. 11 

August 12

OSI & KNX: TL connectionless – Network Layer 

• Transport Layer connectionless 

• (when sending) transport layer ensures that the value of the changed 

communication object is sent by the Link Layer with the correct 

associated (sending) group address 

• (when receiving) transport layer ensures that the value of all 

communication objects is updated, to which the received group 

address is linked. 

• Network Layer (NL) 

• Ensures that each sent message contains the routing counter value 

as set in EEPROM (in case of BCU1, 10Eh) 

• Routing counter value will be decremented when passing through 

line/backbone coupler 

• Can be 0 (no routing), 1 – 6 (normal routing and decrementing, to be 

used by normal applications), 7 (route and do not decrement, to be used 

by e.g. ETS) 


Page No. 12 

August 12

OSI & KNX:TP1 Link Layer – error detection techniques 

Telegram example: BC 1041 17D0 E1 00 81 xx 

• Per character (= 8 bits) 

• One start bit before the character 

• One stop bit after the character 

• One parity bit after the character 

• = Vertical parity check 

• After all sent bytes 

• Checksum Byte : adding all sent bytes and Exor-ing the result – actual value 

not shown in above telegram example 

• = Horizontal parity check 

• Combination of vertical and horizontal parity check = cross 

check 


Page No. 13 

August 12

Cross check in KNX TP1 

Horizontal Parity 

Vertical Parity 

Character 

Checksum 

Start 

Stop 

Parity 


Page No. 14 

August 12

Bus access and collision 

Request to device to 

send 1 

Signal shape Bit coding “0” 

Listen to bus 

No and 

wait 

Signal shape Bit coding “1” 

Bus available ? 

yes 

Send 1 on bus 

Continue with next 

bit (if any) 

no 

Collision (= hearing 0) 

yes 

Interrupt and set 

repetition bit to 0 


Page No. 15 

August 12

OSI & KNX:TP1 Link Layer Control field 

Telegram example: BC 1041 17D0 E1 00 81 

• Note : all characters are sent on the bus from right to left ! 

• Control Field (8 bit) 

• Structure: 

D7 D6 D5 D4 D3 D2 D1 D0 

1 0 R 1 P P 0 0 

• Bit D0 and D1 : preamble bits, set to value 0 (double active bit, avoids that only one spike is 

interpreted as the start of a telegram) 

• Bit D2 and D3 : priority (P) 

value is determined by the setting in ETS for each communication object – parameter from 

AL to LL 

Coding selected to allow collision avoidance : Zero value overrides the 1 - in case of two 

simultaneous sending devices, the one sending a 1 but hearing a 0 will stop transmission 

Possible codings: 00b (system) – 10b (alarm) – 01b (High) – 11b (Low) 

• Bit D5 : repetition R 

- 1 : not repeated telegram 

- 0 : repeated telegram 

• Other bits (D4, D6, D7) : set to particular fixed value (i.e. if not this value, invalid LL telegram, 

not accepted by LL !) 


Page No. 16 

August 12

OSI & KNX: Link Layer (LL) acknowledgement 

LL Acknowledgement: 1 single byte XXh 

• If coding CCh = Positive Acknowledgement (LL ACK) 

• Confirmation of reception of a LL telegram addressed to a device 

• Confirmation that : 

- The received telegram was received without any errors and 

- The device indeed had the individual address contained as destination address 

in the received telegram or 

- The device indeed listens to the group address contained as destination address 

in the received telegram 

• Confirmation is sent simultaneous by all addressed devices – sender only sees one confirmation 

– if one device out of a group does not send LL Ack, sender can not detect this! 

• If coding = 0Ch Negative Acknowledgement (LL NACK) 

• Confirmation that the received telegram was received with errors 

• If coding = C0h LL Busy 

• Confirmation that the received telegram could not be processed as LL – buffers full 

• Owing to chosen coding, in the case of simultaneous sending of ACK and Nack (or Busy), Nack or 

Busy overrule ACK – in that case, sender retransmits with repetition flag set (devices having already 

processed previous non-repeated telegram, disregard repeated telegrams) 

• Across lines, line/backbone couplers take over the Acknowledgement of telegrams 


Page No. 17 

August 12

Repetition Flag 

Sender 

GA x 

GrpValueWrite Grp x, R=1, Value 1 

“GrpValueWrite” Grp x, R=0, Value 1 

Receiver 1 

GA x 

Receiver 2 

Ack 

GA x 

Ack 

Receiver n 

GA x 

Nack 

Ack 


Page No. 18 

August 12

OSI & KNX:TP1 Link Layer – further fields 

Telegram example: BC 1041 17D0 E1 00 81 xx 

• Sender address (format see next slide) 

• Individual address of the sending device 

• Zero value overrides 1 – in case of two simultaneous sending devices, the one 

sending a 1 but hearing a 0 will stop transmission (i.e. at the latest when sending 

its individual address, which should be unique). 

• Destination address (format see next slide) 

– Can be a group address or an individual address 

– Depends on the first bit in the byte following the destination address 

– When group address = 0/0 then broadcast telegram (message to all devices in the 

network) 

• N_PDU (Network Protocol Data Unit) 

– See later (slide 54) 

• Check byte 

– See before (slide 45) 


Page No. 19 

August 12

Format Individual and Group Address 

Individual Address (16 bit) = can be sender or destination address 

D15 D14 D13 D12 D11 D10 D9 D8 D7 D6 D5 D4 D3 D2 D1 D0 

Area 

Line 

Device address 

If value is 0 backbone 

If value is 0 main line 

If value is 0 coupler 

If value is 1 to 15 area 

If value is 1 to 15 line 

If value is between 1 to 64 first line segment 

If above 64: line extension, other line segment 

2 level “M/S” 

3 level “M/m/S” 

Group Address (16 bit) = can only be destination 

address 

D15 D14 D13 D12 D11 D10 D9 D8 D7 D6 D5 D4 D3 D2 D1 D0 D7 

Main Group Subgroup T 

Main Group Middle Group Sub Group 

Next byte 

Most significant bit T= type 

… 

Most significant bit not used in two level/three level group address structure (only when having 

set free address structure in ETS 4) 


Page No. 20 

August 12

Decoding of KNX Telegrams: 

summary flowchart (1) 

Control field 

1 byte 

Format see slide 48 

Sender 

Address 

2 bytes 

Format individual address 

see slide 52 

Destination 

Address 

2 bytes 

Individual or group ? see first bit 

next byte 

Format individual or group address 

see slide 52 


Page No. 21 

August 12



Address Type 

1 bit 

Group = 1 – Individual = 0 

Routing 

counter 

3 bits 

Value of routing counter 0 to 7 

Payload length 

4 bits 

Length of the useful data 


Page No. 22 

August 12



Type of TL 

communication 

2 bit 

UDP = Unnumbered Data Packet 

NDP = Numbered Data Packet 

UCB = Unnumbered Control Data 

NCD = Numbered Control Data 

00b UDP 01b NDP 10b UCD 

11b NCD 

4 bit 

always 0 

4 bit 

Seq. No 

4 bit 

always 0 

4 bit 

Seq. No 

4 bit 4 bit 

2 bit 

2 bit 

APCI + rest : see 

Manual P 28 till 

end of chapter 

APCI + rest : see 

Manual P 28 till 

end of chapter 

00b = TL Connect 

01b = TL 

Disconnect 

10b = TL Ack 

11b = TL Nack 


Page No. 23 

August 12

OSI & KNX: examples of APCIs 

• Group Value Read, Value Write, Value Response respectively used to 

• read the value of a communication object linked to a particular group address 

• write the value of a communication object linked to a particular group address 

• reply to a read request with the value of the communication object linked to the group 

address used in the read request (in BCU1 = value write for receiver !!) 

• are only visible telegram types in a running and configured KNX installation 

• Memory Write 

• write up to 12 byte in the memory of a bus device starting from the indicated memory 

address 

• Individual Address Write 

• writes the indicated individual address into the device in programming mode 

• Authorize Request 

• used in BCU2/BIM M112 devices, for which one must be authorized to be able to 

write memory 


Page No. 24 

August 12

OSI & KNX: TP1 Physical Layer 

• Is responsible for the decoding of bits (as generated normally by a 

micro-controller) into physical signals on the medium, to which 

the bus device is connected 

• In principle PhL can be exchanged without affecting the upper 

layers 

• Physical Layer also specifies e.g. cable distances, cable 

characteristics, …. 

• Two types of TP1 cable exists : green (standardised – distances 

of PhL ensured) – not green (non-standardised – distances of PhL 

not ensured) 


Page No. 25 

August 12

Summary KNX Stack 

Note: no Session or 

Presentation Layer in KNX 

Application 

Application Layer 

Transport Layer 

Grp Objects/Configuration 

Management 

Conless: AssocTable 

ConOr: TL (Dis)Connect/ 

TL (N)Ack 

Network Layer 

Link Layer 

Physical Layer 

Routing 

Error Detection 

@ Table 

CSMA/CA 

Digital Analogue 


Page No. 26 

August 12

OSI & KNX: Practical Exercises (1) 

Decode the control field in the underneath telegram 

(1) 90 1041 17D0 E2 00 80 42 

Is the underneath telegram a valid frame? 

(2) 24 1041 0001 E1 00 80 


Page No. 27 

August 12


Decode the destination address in the underneath telegram 

(3) BC 1041 50F4 E4 00 80 1C 0C 01 

What type of telegram is this? 

(4) CC 


Page No. 28 

August 12


What value does the routing counter have in the underneath frame? 

(5) BC 1041 17D0 B3 00 80 05 78 

What is the significance of the bytes after the destination address? 

(6) 94 1041 1234 30 FF 


Page No. 29 

August 12



(7) B4 1041 1234 51 43 00 


(8) BC 1041 38CA BF 00 40 49 27 6D 20 6B 6E 61 63 6B 65 

72 65 64 00 


Page No. 30 

August 12

Thank you for your 

attention and good luck at 

the exam!!

Presentation - KNX

Create successful ePaper yourself

Delete template?

Save as template?