KNX telegram format and example analysis

1. KNX protocol layering (simplified OSI model)

The KNX protocol is primarily based ona simplified version of the OSI model, consisting of four layers:

2. Communication mode

(1) Multicast (Group Communication)

• Purpose: Devices send data to a group address, and all devices subscribed to that group address receive and process the data.
• Characteristics: Efficient one-to-many communication, suitable for lighting control, scene triggering, etc.
• Example: 组地址 1/2/3: Upon receiving a turn-on command, all lights bound to this address execute the operation.

(2) Point-to-Point

• Usage: Devices communicate directly through physical addresses (such as configuration and diagnosis).
• Features: The target physical address needs to be explicitly specified for device initialization or maintenance.
• Example: A central control device0.0.1requests temperature data from a sensor1.1.10.

3. Message Type

KNX messages are divided intostandard frames (L_Data) And Extended Frame (L_Data Extended):

4. Address Structure

(1) Individual Address

• format: 区域(4bit).线(4bit).设备(8bit)→ 2 bytes.
• Example: 1.2.3 → 0x12 0x03(binary0001 0010 0000 0011).
• Purpose: uniquely identifies devices for point-to-point communication or device configuration.

(2) Group Address

• format: 主组(5bit)/中间组(3bit)/子组(8bit) Or 主组(5bit)/子组(11bit)→ 2 bytes.
• Example:
• 3/2/1 → 0xE3 0x21(Binary1110 0011 0010 0001).
• 5/2047 → 0xA5 0xFF(Binary1010 0101 1111 1111).
• Usage: Logical grouping, device subscription group address to achieve one-to-many communication.

5. Data Representation (APDU)

(1) DPT (Data Point Type)

KNX defines data semantics through theDPT standard, with the format being主类型.子类型(such asDPT 1.001indicates a Boolean switch:

(2) APDU structure

• TPCI (Transport Control): 1 byte, marking the message type (such as data request, confirmation).
• APCI (Application Control): 1 byte, defining the operation type (read, write, response).
• Data payload: Actual data encoded according to DPT.

Example:

• Switch write command:TPCI=0x00（写）, APCI=0x80（DPT 1.001）, data=0x01（开）.
• Temperature read request:TPCI=0x40（读）, APCI=0x00（无数据）.

6. Communication service

(1) Polling

• The master device actively requests data from the slave device (such as querying sensor status).
• Message Example: 控制字段=0xBC, 目标地址=传感器物理地址, APCI=读请求.

(2) Acknowledge

• The receiver needs to reply with an acknowledgment frame (ACK) to ensure reliability.
• Example: After receiving a control command, the device returnsACK报文（0xB0）.

(3) Retry Mechanism

• If no ACK is received, the sender retransmits the message after a specified timeout (usually up to 3 times).

7. Security Mechanism

• Traditional Mode: No encryption, relies on physical layer security (such as bus access control).
• KNX Secure: Adds data encryption (AES-128) and authentication to prevent tampering and eavesdropping.
• Secure Message Example: Add encryption payload and MAC (Message Authentication Code) on the basis of standard frames.

8. Actual debugging suggestions

1. Packet capture tool: Use Wireshark +KNX pluginto analyze bus traffic and filter specific group addresses.
2. Error troubleshooting:

• Checksum error: Check the XOR result of the message.
• Address conflict: Ensure that the physical address and group address are unique.

1. ETS configuration: Bind DPT types in ETS projects to avoid data parsing errors.

In the KNX protocol, message types are mainly determined byControl fieldAndTPCI (Transport Control Information)distinguishes between different message types applicable to various scenarios (such as control commands, data requests, responses, etc.). The following provides detailed descriptions and examples of common KNX message types:

1. Standard frame (L_Data Standard)

• Control field: 0xBC
• Data length: ≤ 15 bytes
• Applicable scenarios: Regular control commands (switching, percentage, status reading, etc.).

Example: Switch control

BC 11 0A E1 03 01 01 80

• Control field 0xBC: Standard frame, normal priority.
• Source address 0x110A(1.1.10).
• Destination address 0xE103(group address 1/2/3).
• Data 0x01: switch status (on).
• Checksum 0x80: XOR calculation result.

2. Extended frame (L_Data Extended)

• Control field: 0xBF
• Data length: ≤ 255 bytes
• Applicable Scenario: Big Data Transmission (such as strings, logs, complex configurations).

Example: Sending String Information

BF 23 05 E2 51 0E 10 4B 4E 58 20 54 65 73 74 00 00 00 5C

• Control Field 0xBF: Extended Frame, Low Priority.
• Source Address 0x2305(2.3.5).
• Destination Address 0xE251(Group Address 2/5/1).
• Data Length 0x0E: 14 bytes of data.
• Data 0x10 4B 4E 58 20 54 65 73 74 00 00 00:
• DPT 16.001 (string), with content"KNX Test"(ASCII encoding).
• Checksum 0x5C: calculation omitted.

3. Acknowledgment frame (ACK/NACK)

• Control field: 0xB0(ACK) or0xB1(NACK)
• Structure: no data part, only control field and checksum.
• Applicable scenarios: receiver replies with acknowledgment or rejection.

Example: ACK Confirmation

B0 00 00 00 00 00 00 B0

• Control Field 0xB0: Acknowledgment Frame (ACK).
• Checksum 0xB0: Only the self-XOR result is0xB0.

4. Polling Request

• Control Field: 0xBC(Standard Frame)
• TPCI: 0x40(Read Request)
• Applicable Scenario: The master device actively requests data from the slave device.

Example: Reading Temperature Sensor Data

BC 00 01 12 34 01 40 00 2D

• Source address 0x0001(Central control device 0.0.1).
• Destination address 0x1234(Physical address of sensor 1.2.52).
• Data length 0x01: 1 byte of data.
• TPCI+APCI 0x40: Read request (no data payload).
• Checksum 0x2D: Calculation omitted.

5. Response frame (Response)

• TPCI: 0x80(Write response) or0xC0(Read Response)
• Applicable Scenario: The device responds with requested data or status.

Example: Temperature sensor returns data

BC 12 34 00 01 02 06 00 5C

• Source Address 0x1234(sensor address 1.2.52).
• Destination Address 0x0001(central control device 0.0.1).
• Data Length 0x02: 2 bytes of data.
• Data 0x0600: temperature value (DPT 9.001, 24.0°C).
• Checksum and 0x5C: Calculation omitted.

6. Broadcast Frame

• Destination Address: 0x0000(All-zero Address)
• Applicable Scenario: A device sends a global command (such as system reset) to all nodes on the bus.

Example: Global Reset Command

BC 00 01 00 00 01 FF 01

• Source Address 0x0001(Central Control Device).
• Destination Address 0x0000: Broadcast Address.
• Data 0xFF: Reset command (custom code).

7. Security telegram (KNX Secure)

• Control field: 0xBC Or 0xBF(combined with encryption flag)
• Structure: Encryption payload and MAC (Message Authentication Code) are added on the basis of the standard frame.
• Applicable scenarios: Prevent data tampering or eavesdropping.

Example (simplified encrypted telegram)

BC 11 0A E1 03 10 01 80 [加密负载] [MAC] 2A

• Data part: Plaintext data0x01is encrypted into longer bytes.
• MACis used for verifying data integrity (such as AES-128 computation).

Key comparison table

Considerations

1. TPCI and APCI:

• TPCI (Transmission Control) marks the message type (read, write, response).
• APCI (Application Control) defines specific operations (such as DPT type).

1. Address filtering: The device only processes messages with matching target addresses (physical addresses or subscribed group addresses).
2. Checksum: It is always the exclusive-OR (XOR) value of all preceding bytes.

I hope these examples will help you understand how to write different KNX message types! In actual development, it is recommended to combine official protocol documentation and ETS tools for verification.

The following examples illustrate:

Example 1: Switch Control (Standard Frame)

Scenario: A device with physical address1.1.10sends a light-on command to group address1/2/3.
Message:

BC 11 0A E1 03 01 01 80

• Control Field 0xBC: Standard Frame, Normal Priority.
• Source Address 0x110A: Device Address1.1.10.
• Destination Address 0xE103: Group Address1/2/3 (E1indicates the group address type.
• Data length 0x01: 1 byte of data.
• Data 0x01: switch status (0x01= on,0x00= off).
• Checksum 0x80: BC XOR 11 XOR 0A XOR E1 XOR 03 XOR 01 XOR 01 = 80.

Example 2: temperature sensor data (extended frame)

Scenario: sensor2.3.5reports temperature22.5°CTo group address2/5/1.
message:

BF 23 05 E2 51 02 06 00 5C

• control field 0xBF: extended frame, low priority.
• Source address 0x2305: device address2.3.5.
• Destination address 0xE251: group address2/5/1.
• Data length 0x02: 2 bytes of data.
• Data 0x0600:
• DPT 9.001 (temperature), encoded as0x0600 → 22.5°C(Floating-point format).
• Checksum and 0x5C: Calculation omitted.

Example 3: Scene Control (Multi-byte Data)

Scene: Central Control Device0.0.1triggers scene3(Group Address5/0/3).
Message:

BC 00 01 E5 03 03 03 00 00 6F

• Control Field 0xBC: Standard Frame.
• Source Address 0x0001: Central Control Address0.0.1.
• Destination Address 0xE503: Group Address5/0/3.
• Data Length 0x03: 3 bytes of data.
• Data 0x030000: Scene Number 3, additional parameters.
• Checksum 0x6F: calculation method omitted.

Key Point

1. Address Encoding:

• Physical address:区域(4bit).线(4bit).设备(8bit)→ 2 bytes (e.g.1.1.10 → 0x11 0x0A).
• Group address:主组(5bit)/中间组(3bit)/子组(8bit)→ 2 bytes (e.g.1/2/3 → 0xE1 0x03, with the high-order bit1110indicating the group address).

1. Data encoding:

• switch: 1 byte (0x00= off,0x01= on).
• Temperature: 2-byte floating point (e.g. DPT 9.001).
• Percentage: 1 byte (with0x00= 0% and0xFF= 100%).

1. Checksum and: Perform an XOR operation on all preceding bytes (as inBC XOR 11 XOR 0A XOR E1 XOR 03 XOR 01 XOR 01 = 80).

Practical application advice:

• Use ETS (KNX Engineering Tool Software) to configure devices, eliminating the need for manual packet assembly.
• Message examples are primarily intended for understanding the underlying protocol, and packet capture tools (such as Wireshark + KNX plugin) can be used during debugging.
• For in-depth learning, refer to the official KNX documentation "KNX Standard" or the book "KNX for IoT".