Your KNX Line Has a Speed Limit, and Most Projects Never Check It

KNX twisted pair runs at 9600 baud. That is not a typo, and it is not a flaw. Weinzierl, who build KNX interfaces, describe the medium as base band signalling at 9600 baud and rate it at up to 50 telegrams per second.

It works because a home is not a video stream. A keypad press is a handful of bytes. The trouble starts when a project quietly asks one line to carry far more than a handful.

Nobody agrees on the exact number

Published figures differ. Weinzierl says up to 50 telegrams per second. Ivory Egg says over 50, and notes that each line and each area has its own allowance. netX Automation, in its support notes, says 20 to 40 per second on a single TP line, depending on telegram size.

I read that spread as a reminder that telegram length matters, not as a dispute. When I plan a line, I use the low end of the range and treat anything above it as a bonus.

Why 100% is the wrong target

netX gives a worked example for a large project. 2,400 data points each sending every 120 seconds comes to 20 telegrams per second. They count that as a full bus on the conservative maths, with a real risk of lost telegrams. Split the same points across four IP interfaces and each TP side sees 10 per second, about half load. Their guidance is to aim for roughly 50% so spikes have somewhere to go.

That example is a big commercial job, not a house. But the principle carries down. In a home the average load is almost never the problem. The spike is.

Take a "good night" scene that writes to 30 group addresses. If a line manages somewhere between 20 and 50 telegrams per second, that one button can occupy most of a second on its own. That is my arithmetic from the published rates, not a measured result, and the real answer depends on the devices. But it shows why I care about what a scene sends and not only how many devices are on the line.

What chatters

Anything that sends on a timer is a candidate. Temperature, lux and wind sensors, energy meters, and status objects that echo every change all add up. A sensor that sends every few seconds when every few minutes would do is the usual culprit.

Integrations deserve a look too. Home Assistant's KNX integration has a state updater that periodically reads state addresses from the bus, with sync strategies you configure, such as every set number of minutes. Each read is a telegram, and the device answering it sends another. Home Assistant also has a rate limit option for outgoing telegrams per second. Its documentation says 0 disables the limit, and recommends that. I would still know what is being read, and how often, before I trust it.

How to actually look

ETS will show you, and I wish more people opened it.

The Group Monitor does not need exclusive access to the bus, so you can keep working while it records. The Bus Monitor does need it, which blocks things like address checks and line scans while it runs. The information tab on the monitors reports average bus load, average telegrams per second, and counts for repeated, busy, unconfirmed and negatively confirmed telegrams.

The group diagnostics wizard goes further for TP. It shows current, maximum and average bus load over a 10 second sliding window, and lists the five most active senders, leaving out any under 2% of traffic. BUSY, NAK and repetition counts are only available in Bus Monitor mode.

If repeats and busy counts are climbing, the line is telling you something.

Two caveats from the KNX support pages. The older Online Error Diagnostics article describes that tool as deprecated, so check what your version of ETS offers. And one user on the KNX support forum reports that the ETS 6 Group Monitor becomes sluggish under heavy bus traffic, with no reply from KNX in the thread. Close the monitor when you are done.

What I would ask before you sign

If you are getting a KNX quote, three questions are worth asking. What does the busiest second on each line look like, not the average? Which devices send on a timer, and how often? And what else is reading from the bus all day, such as a visualisation or an integration?

A good integrator has thought about this. If the answer is "it should be fine", ask to see the numbers.

If you already have a system that feels slow, or a keypad that sometimes answers late, a few minutes with a monitor will tell you more than guessing. Just a conversation about what the project needs: wayne@knxlogic.co.za | 082 564 3982 | www.knxlogic.co.za

Sources: Weinzierl Engineering, KNX System Media (weinzierl.de); Ivory Egg, A guide to using KNX over IP (ivoryegg.co.uk); netX Automation, How does the KNX bandwidth limit affect my project (netxautomation.atlassian.net); KNX Association support: Bus Monitor, Group Monitor and ETS Bus Activity Monitor; Groups Diagnostics (Detailed); Online Error Diagnostics; community post on ETS 6 Group Monitor under high bus traffic (support.knx.org); Home Assistant KNX integration documentation (home-assistant.io).