A KNX installation running smoothly is a beautiful thing: every device communicates precisely when it needs to, group addresses carry the right signals, and the bus stays quiet between commands. But when something goes wrong and a device starts sending telegrams repeatedly without stopping, that calm disappears fast. Bus load climbs, other devices become sluggish or unresponsive, and tracking down the source of the problem can feel like searching for a needle in a very noisy haystack. Understanding how to identify KNX devices causing repeated telegram transmissions is one of the most valuable diagnostic skills any professional installer can have.
A KNX telegram storm, where one or more devices flood the bus with continuous or near-continuous transmissions, can have several root causes, and the symptoms often look similar regardless of what is actually triggering them. This guide walks through the diagnostic process step by step, from understanding why it happens to resolving and preventing it from recurring.
What causes repeated telegram transmissions in KNX
Repeated telegram transmissions happen when a KNX device sends the same message to the bus far more frequently than intended, often in a tight loop. The KNX bus has a defined bandwidth (typically around 9,600 bits per second on TP installations), and when one device monopolizes that bandwidth, the entire installation suffers.
The most common triggers include misconfigured group addresses, where a device is set to respond to its own feedback signal and creates a feedback loop. A sensor with an incorrectly set cyclic transmission interval can also bombard the bus at intervals of just a few seconds rather than minutes. Hardware faults, such as a failing actuator or a sensor with a damaged input, can cause a device to interpret noise as a valid trigger and transmit endlessly. In some cases, a poorly written ETS application or an incompatible firmware version introduces logic errors that produce unintended cyclic behavior.
How to use ETS diagnostics to pinpoint the culprit device
ETS (Engineering Tool Software) is the first and most powerful place to start when investigating a KNX bus overload. Its built-in bus monitor captures every telegram traveling on the line in real time, giving a direct view of what is happening and, crucially, which physical address is responsible.
Open ETS and navigate to the Diagnostics panel, then activate the Bus Monitor. Within seconds of a telegram storm being active, the source address will stand out clearly: it will appear repeatedly in the log, often dozens of times per second. Note the physical address of the offending device, then cross-reference it with the project’s device list to identify exactly which component and location it corresponds to. Once identified, temporarily disconnecting that device from the bus (by removing it from the line or cutting its bus connection) will immediately confirm whether it is the source: if the storm stops, the culprit is found.
ETS also allows filtering by physical address or group address, which is useful when the log is moving too quickly to read. Setting a filter to the suspected address makes the pattern immediately visible and helps confirm the transmission frequency.
Alternative tools for KNX bus traffic analysis
While ETS is the standard diagnostic environment, several third-party tools offer complementary capabilities that can make bus traffic analysis faster or more visual, particularly useful on large or complex installations.
Tools like KNX Virtual, Weinzierl’s KNX IP Interface combined with Wireshark, or dedicated KNX analyzers from manufacturers such as MDT provide detailed packet-level views of bus activity. Some of these tools can log traffic over extended periods, which is valuable when the telegram storm is intermittent rather than constant. A device that only misbehaves at night, triggered by a time-based automation or a temperature threshold, may not be visible during a daytime site visit, but a logged capture will reveal it.
Standalone KNX bus analyzers are particularly helpful when ETS access to the full project is limited. They connect directly to the TP line and display all traffic without needing a project file, making them a practical addition to any installer’s toolkit.
Common KNX device types most likely to cause telegram floods
Not all KNX devices carry the same risk of causing repeated transmissions. Based on installation experience, certain device categories appear more frequently as the source of telegram storms.
- Binary inputs and sensors with cyclic transmission enabled and short intervals set incorrectly
- Weather stations configured to send continuous value updates rather than change-of-value telegrams
- Actuators with status feedback that inadvertently trigger their own control group address
- Third-party gateway devices translating between protocols, where mapping errors create looped responses
Push-button interfaces and presence detectors are also worth checking, particularly if they have been reconfigured after initial commissioning. Any device that has recently had its application or parameters updated is a logical starting point, since a configuration change is often what triggers the behavior in the first place.
Resolving and preventing telegram storms after identification
Once the source device is identified, resolution usually involves one of three actions: correcting the device’s parameters in ETS and recommissioning it, updating its firmware if a known bug is responsible, or replacing the device if a hardware fault is the cause. For feedback loop issues, reviewing the group address structure and ensuring no device is subscribed to both the control and status addresses of the same object is essential.
Prevention is equally important. During commissioning, it is good practice to monitor bus load using ETS diagnostics after each major device group is added to the installation. This establishes a baseline and makes anomalies immediately visible. Setting realistic cyclic transmission intervals (typically no shorter than 60 seconds for most sensor values) and using change-of-value transmission wherever possible keeps background traffic to a minimum.
Documentation also plays a role: keeping a clear record of group address assignments and device configurations makes future troubleshooting significantly faster. When a telegram storm occurs months after commissioning, a well-maintained project file in ETS is often the fastest path to resolution.
How xxter supports professionals in KNX troubleshooting
For professional installers working with KNX installations, having the right platform in place makes diagnostics and ongoing management considerably more straightforward. xxter’s controller sits at the heart of a KNX installation and provides a reliable, always-on connection to the bus, which means that when bus behavior becomes abnormal, the system is already in place to support investigation and response.
- The xxter controller integrates with KNX TP, IP, and supported protocols, giving installers a stable reference point for bus activity — explore the full xxter KNX controller product information for technical specifications
- xxter’s scripting and trigger functionality allows automated responses to be built around abnormal conditions, such as alerting when a group address receives an unusually high volume of telegrams — manage and configure these responses directly via the xxter online management portal
Beyond troubleshooting, xxter’s Smart Energy Manager adds another layer of intelligence to KNX installations by actively managing energy consumption based on live data, ensuring that even as installations grow more complex, they remain efficient and cost-effective. For installers looking to expand what they can offer clients, it is a natural addition to any KNX project.
If repeated telegram transmissions are causing problems in a current project, or if there are questions about how xxter can support more resilient KNX installations, get in touch with xxter directly to discuss the options.
Preguntas frecuentes
How do I know if my KNX bus load is critically high before a full telegram storm develops?
ETS Diagnostics includes a bus load indicator that shows real-time traffic as a percentage of total bandwidth. A healthy KNX TP installation should typically sit well below 30% under normal operation — sustained loads above 50% are a warning sign, and anything approaching 100% indicates a serious problem. Making it a habit to check bus load periodically, especially after adding new devices or updating configurations, lets you catch creeping issues before they escalate into a full storm.
Can a telegram storm on one KNX line affect devices on other lines in the same installation?
Yes, indirectly. If the installation uses a KNX IP backbone or line couplers, a storm on one TP line can generate excessive traffic on the IP network or overload the coupler’s routing capacity, causing delays or dropped telegrams on connected lines. Line couplers with filtering tables can help contain the damage by restricting which group addresses are forwarded between lines, which is another reason why a well-configured coupler filter table is an important part of any multi-line installation.
What is the safest way to disconnect a suspected device from the bus without disrupting the rest of the installation?
The safest approach is to physically disconnect only the bus wires (the yellow and red TP wires) from the terminal of the suspected device, leaving its power supply intact if it has a separate one. This isolates it from the KNX bus without cutting power to connected loads such as lights or blinds that the actuator may be controlling. Always inform the building occupant before doing this, as it will temporarily disable the KNX control of whatever that device manages.
What cyclic transmission interval should I use for different sensor types to avoid contributing to bus overload?
As a general rule, most environmental sensors such as temperature, humidity, and CO2 transmitters work well with cyclic intervals of 5 to 15 minutes, combined with change-of-value transmission set to trigger on meaningful threshold changes. Energy meters and power monitoring devices can often be set to 1–5 minute cycles depending on how granular the data needs to be. Avoid setting any cyclic interval below 60 seconds unless there is a specific, justified reason — short intervals across many devices accumulate quickly and consume a disproportionate share of available bus bandwidth.
Is it possible for a KNX telegram storm to cause permanent damage to devices on the bus?
In most cases, a telegram storm causes performance degradation rather than permanent hardware damage — devices become unresponsive or slow, but recover once the overload is resolved. However, prolonged overload conditions can stress bus couplers and IP routers, and in rare cases, devices with limited internal buffers may enter fault states that require a power cycle or recommissioning to clear. Resolving the source quickly is always the priority, both to restore normal operation and to minimise any risk of secondary issues.
How can I prevent a reconfigured or newly commissioned device from immediately causing a telegram storm?
After downloading a new or updated application to any device, connect to the bus monitor in ETS before closing the session and observe the traffic for at least 60 seconds. Check that the device’s physical address appears only when expected — for example, in response to a manual trigger — and not in a repeating pattern. It is also worth reviewing the device’s cyclic transmission parameters and feedback group address assignments in ETS before downloading, catching potential loop configurations at the parameter level rather than discovering them live on the bus.
Can xxter's scripting functionality be used to automatically isolate a misbehaving device during a telegram storm?
While xxter cannot physically disconnect a device from the bus, its scripting and trigger engine can be used to detect abnormal telegram volumes on specific group addresses and respond automatically — for example, by sending a disable or lock command to a device that supports it, triggering an alert to the installer, or logging the event for later review. This kind of automated watchdog logic is particularly valuable for remote or unattended installations where a telegram storm might otherwise go unnoticed for hours.