Not Every Device On Your Bus Gets To Hear Everything. That's The Point.

Most people who ask me about KNX topology ask about lines. How many devices fit on one, how far a run can go, that kind of thing. Almost nobody asks about the small grey module sitting quietly between two lines, doing two jobs at once. That's the line coupler, and it's worth understanding properly, because it's also where KNX just changed how installers are allowed to work.

What a coupler actually does

A line coupler sits between a main line and a subordinate line (or, one level up, between an area line and the lines under it). It does two separate things.

First, electrical separation. Inside the coupler, the two sides are physically split and linked only through a transformer. That's real electrical isolation between circuits, not just a logical grouping on a diagram, and it's part of why KNX installations stay safe and serviceable across a large building.

Second, traffic control. Every coupler holds a filter table in its own memory. When a telegram tries to cross from one line to another, the coupler checks the group address against that table before deciding whether to let it through. Without this, every switch press and every sensor update on every line would flood the entire bus. With it, a line only carries the traffic that's actually relevant to it, plus whatever genuinely needs to leave.

Three modes, and only one of them is normal

A coupler can run in one of three modes, and the mode can be set separately for traffic going out to the main line and traffic coming back in.

Block stops everything, full stop, filter table ignored. Route lets everything through, also ignoring the filter table entirely. Filter, the standard and correct mode for a working installation, only lets a telegram cross if its group address is actually in the table.

Route mode has its uses on a bench during commissioning, when you want to see everything moving while you're debugging. Left on in a finished installation, it quietly undoes the entire reason lines exist in the first place, every line ends up carrying every telegram from every other line, and the bus load problem the coupler was installed to solve comes right back.

Where the filter table actually comes from

Here's the part most people get wrong: nobody sits down and manually decides what goes in a coupler's filter table. ETS calculates it for you, from the project itself.

If a group address only ever links a switch and a light that are both sitting on the same line, that traffic never needs to leave the line, so it isn't added to any filter table. If that same group address links a device on line 1.1 to a device on line 15.15, ETS works out every coupler the telegram has to pass through to get there, in this case the line coupler on 1.1, the backbone coupler on 1.0, the backbone coupler on 15.0, and the line coupler on 15.15, and writes that group address into all four filter tables automatically. Add a second device on a different line to the same group address later, and ETS updates the tables again on its own.

It's worth knowing there's a hardware generation gap here too. Older couplers only had 3.5KB of filter table memory, enough to filter main groups 0 through 13 individually, but main groups 14 and 15 could only be blocked or routed as a whole block, not filtered address by address. That's one of the reasons ETS3 capped projects at main group 0 to 15. ETS5 deliberately opened the full range up to main group 31, but an older coupler still on site can't filter that extended range any more finely than it could filter 14 and 15, it just blocks or routes the lot. Worth checking before you assume fine-grained filtering is happening on an installation with older coupler stock in it.

What just changed, and why it matters for your gateway

For years, when a visualisation system or gateway needed to see group addresses from a line it didn't have a device on, the fix was manual: punch the group address through with "Pass through Line Coupler," or hand-add it to the filter table directly. It worked, but it also meant a group address could end up visible on every line in the building because of an edit nobody documented and nobody remembers six months later.

KNX Association has now deprecated that entirely from ETS 6.3.0 onward. Manual filter table entries and "Pass through Line Coupler" are being phased out, officially, because they're a genuine security risk and they erode the one thing a well-built KNX project is supposed to give you: a clear, traceable picture of what talks to what.

The replacement is more disciplined, and honestly it's how this should have worked from the start. Model the gateway as an actual bus interface in the project and drag the group addresses it needs directly onto its tunneling interface, so the requirement lives inside the project data and ETS calculates the filter tables correctly on its own. Or, where that's not practical, add a proper dummy device on the same line as the gateway, with real group objects configured for exactly what it needs. Either way, the need is visible in the project file, not buried in a manual override.

This is exactly the mechanism that decides how much of your bus a tool like 1Home, or any KNX-to-Home-Assistant gateway, can actually see. I model these properly as interfaces at the design stage for that reason, not as an afterthought once the electrician's already on site. KNX Association's own guidance is blunt about the alternative too: parking a visualisation gateway on the area line and letting it collect from everywhere, without modelling why, is exactly the kind of shortcut that makes a project unreadable a few years later.

None of this shows up in a walkthrough. Nobody's ever going to ask to see a filter table. But it's the difference between a system where every cross-line connection has a reason you can find in five seconds, and one where some random group address just quietly shows up everywhere and nobody on site can tell you why.

Just a conversation about what the project needs.

wayne@knxlogic.co.za | 082 564 3982 | www.knxlogic.co.za