1. What Is a KNX Telegram?
A KNX telegram is a structured message transmitted between KNX devices over the bus. It contains information required for the KNX system to transport, identify and interpret the communication. Depending on the communication medium and telegram type, the exact frame structure can contain several fields such as control information, addresses, data and error-checking information.
A simplified representation is:
KNX DEVICE
│
▼
Telegram
│
├── Control information
├── Source address
├── Destination address
├── Data
└── Error checking
│
▼
KNX BUSFor an integrator, however, the most important information during everyday troubleshooting is usually:
Source → Destination → DPT → Value → Acknowledgement/response
2. Why Telegram Analysis Is Important
A KNX installation can have hundreds or thousands of communication objects, making it difficult to determine why a particular function is not working. Telegram monitoring provides a direct view of what is actually happening on the bus instead of relying only on device status or visual symptoms. This makes it particularly valuable during commissioning and troubleshooting.
Telegram analysis can help answer questions such as:
- Did the push button send the command?
- Which group address was transmitted?
- What value was sent?
- Did the actuator respond?
- Is another device sending an unexpected command?
- Is the wrong DPT being used?
- Is the telegram reaching the required line?
3. ETS Group Monitor vs Bus Monitor
ETS provides monitoring functions that can be used for different troubleshooting purposes. Group Monitor is particularly useful for observing group-address communication at the application level, while Bus Monitor provides a more detailed view of bus communication. Choosing the appropriate monitor depends on whether you are investigating a functional problem or analysing the underlying KNX bus traffic.
Group Monitor
Useful for:
- Group-address communication
- Values
- DPT interpretation
- Switching commands
- Status feedback
- Commissioning
Bus Monitor
Useful for:
- Detailed telegram analysis
- Individual-address communication
- Bus-level diagnostics
- Detailed frame information
For everyday commissioning, Group Monitor is often the first place to start.
4. Understanding Source and Destination Addresses
One of the most useful pieces of information in a KNX telegram is the address information. The source address identifies the KNX device that transmitted the telegram, while the destination address identifies the intended recipient or group address depending on the communication being observed. Understanding these addresses allows the engineer to trace a function back to its source.
For example:
Source:
1.1.25
Destination:
2/1/10This can mean:
Device 1.1.25
│
│ Telegram
▼
Group Address 2/1/10If a light is switching unexpectedly, identifying the source address can be the first step toward finding the device responsible.
5. Understanding Group Address Communication
Most KNX control functions are based on group communication. A device sends a telegram to a group address, and one or more devices that have been linked to that address can react to it. The group address therefore acts as the logical communication path between the sender and receivers.
Example:
Push Button
1.1.10
│
│ ON
▼
1/1/5
│
┌───┴────┐
▼ ▼
Light A Light BThe Group Monitor can show that:
1.1.10 → 1/1/5 → ON
This immediately tells the engineer that the button transmitted the expected command.
6. Reading the DPT and Value
The destination address alone does not tell you what the telegram means. The DPT and value provide the information required to interpret the data. This is especially important for values such as temperature, percentage, brightness, HVAC setpoints and energy measurements.
For example:
| DPT | Example Value | Meaning |
|---|---|---|
| DPT 1.001 | 1 | ON |
| DPT 1.001 | 0 | OFF |
| DPT 5.001 | 50% | 50% |
| DPT 9.001 | 23.5 °C | Temperature |
| DPT 10.xxx | Time | Time information |
Suppose Group Monitor shows:
Destination: 2/3/10
DPT: 9.001
Value: 23.5 °CThe engineer can immediately identify the telegram as a temperature value.
7. Understanding Write, Read and Response Telegrams
KNX communication is not limited to sending commands. Devices can also request information and respond with current values. Understanding the difference between Write, Read and Response communication can be useful when investigating status feedback and missing values.
A simplified sequence is:
Device A
│
│ Read Request
▼
Group Address
│
▼
Device B
│
│ Response
▼
Device AFor example, a visualisation system may request the current state of a device and the actuator can respond with its present value.
If the read request is visible but no response appears, the engineer has a useful clue for further investigation.
8. Telegram Sequence for a Simple Lighting Command
Consider a push button controlling a KNX lighting actuator. When the button is pressed, the expected sequence can be observed through ETS Group Monitor. This allows the integrator to determine whether the problem occurs at the sensor, group-address configuration, bus communication or actuator.
Example:
Push Button
│
│ 1/1/10 = ON
▼
Group Address
│
▼
Lighting Actuator
│
│ Status
▼
1/1/11 = ONExpected monitoring:
1.1.20 → 1/1/10 → ON
1.1.30 → 1/1/11 → ONIf the first telegram appears but the second does not, investigate the actuator configuration and status-feedback arrangement.
9. Using Telegram Analysis to Find Unexpected Commands
One of the most valuable applications of Group Monitor is identifying unexpected telegrams. If a light, HVAC system or other function activates without an obvious user command, monitoring can reveal which device transmitted the command.
For example:
Unexpected:
1.1.47 → 1/2/15 → ONThe engineer can then identify:
1.1.47 → Physical KNX Device
and investigate:
- Device programming
- Logic functions
- Sensor configuration
- Scene control
- Time schedules
- Automation logic
- External integrations
This is much more effective than repeatedly replacing actuators or sensors without identifying the actual source.
10. Troubleshooting a Missing Telegram
When pressing a KNX button produces no response, the first question should be:
Did the button actually transmit a telegram?
Open ETS Group Monitor and activate the button.
Case A — Telegram appears
1.1.10 → 1/1/5 → ONThe button is transmitting, so investigate:
- Group-address assignment
- Receiving object
- Actuator programming
- DPT compatibility
- Bus communication downstream
Case B — No telegram appears
Investigate:
- Device programming
- Physical address
- Communication object
- Button configuration
- Bus voltage
- Device status
- Bus connection
This simple distinction can significantly reduce troubleshooting time.
11. Troubleshooting Wrong Values
A KNX device may communicate correctly but still produce an incorrect result because the transmitted value is not what the receiving device expects. This can happen because of an incorrect DPT, scaling, object configuration or integration mapping. Telegram monitoring allows the engineer to see the actual transmitted value.
For example:
Expected:
50%
Received:
0%Or:
Expected:
22.5 °C
Received:
225 °CThe second type of problem can indicate an interpretation or data-format issue.
Check:
- Sending object
- DPT
- Group address
- Receiving object
- Device parameters
- Integration mapping
12. Telegram Analysis for KNX IP and Couplers
In larger KNX installations, a telegram may have to pass through line couplers, area couplers or KNX IP routers. If a telegram works within one line but not across another line or area, topology and filtering should be investigated. The filter table and routing configuration can determine whether a telegram is propagated.
Simplified:
Line 1
│
▼
Coupler
│
▼
Backbone
│
▼
Coupler
│
▼
Line 2If:
Line 1 → Line 1
works but:
Line 1 → Line 2
does not, investigate:
- Coupler configuration
- Filter table
- Group-address structure
- IP routing
- Multicast
- Backbone configuration
13. Practical KNX Telegram Troubleshooting Workflow
A systematic workflow prevents engineers from changing multiple parameters at once. Start with the sender, then follow the telegram through the group address and finally verify the receiving device. For larger systems, continue the investigation through the relevant couplers and IP backbone.
Step 1 — Reproduce the problem
Operate the button, sensor or automation function.
Step 2 — Open Group Monitor
Observe the communication.
Step 3 — Identify the source
Determine which device transmitted the telegram.
Step 4 — Identify the destination
Check the group address.
Step 5 — Check DPT and value
Verify that the data is correct.
Step 6 — Check the receiver
Confirm that the receiving communication object is linked.
Step 7 — Check status feedback
Determine whether the receiving device transmitted the expected response.
Step 8 — Check topology
If required, investigate couplers and IP routing.
14. KNX Telegram Analysis Checklist
Telegram monitoring should become a standard part of KNX commissioning and troubleshooting. Rather than guessing whether a device or parameter is responsible for a problem, the engineer can use the actual bus communication as evidence. A disciplined monitoring process also creates a useful record for future maintenance.
Before troubleshooting
- Identify the affected function.
- Identify the expected group address.
- Identify the sending device.
- Identify the receiving device.
- Check the communication objects.
- Confirm the expected DPT.
During monitoring
- Check source address.
- Check destination/group address.
- Check telegram type.
- Check DPT.
- Check transmitted value.
- Check response/status telegram.
- Check timing and sequence.
- Check repeated or unexpected telegrams.
For larger installations
- Check line couplers.
- Check filter tables.
- Check KNX IP routers.
- Check multicast.
- Check backbone communication.
Conclusion
KNX telegram analysis is one of the most powerful troubleshooting techniques available to a KNX integrator. Instead of relying only on what a button, sensor or actuator appears to be doing, ETS monitoring allows the engineer to see the communication taking place on the KNX system.
The most useful sequence to remember is:
Source → Destination → DPT → Value → Receiver → Response
If a function is not working, determine first whether the expected telegram exists. If it does, follow the telegram through the group address and receiving object. If it does not, investigate the sending device and its configuration.
For larger installations, extend the investigation to:
Line Coupler → Filter Table → KNX IP Router → IP Backbone
Don’t guess what the KNX system is doing—watch the telegram and find out.
