Every Switch In Your Home Has A Number. Most Owners Never See The System Behind It.

Every light switch, blind motor, sensor and keypad in a KNX installation talks to the others using a number. Not a device name, not a room label on a drawing. A number, sitting on a shared bus that every product on the project can read.

Get that numbering scheme right at design stage and the system stays legible for as long as the building stands. Get it wrong, or let it happen by accident, and every fault-find ten years from now starts with someone squinting at a bus monitor full of numbers that don't tell them anything. This is the part of a KNX project nobody points to on a walkthrough, and it deserves more attention than it gets.

What a group address is

According to KNX Association's own technical documentation, a group address has a width of 16 bits. That gives the entire address space a maximum of 65,536 possible values, and the address 0 is reserved by the system for broadcast telegrams, so it can never be assigned to a device. Every group address you see in a project, whatever it looks like on screen, is really just a 16-bit number underneath.

ETS gives you three ways to display and structure that number:

Free-level style shows it as one flat number, with no internal grouping. Two-level style splits it into a main group and a subgroup. Three-level style, the default since ETS2 and still what most residential and commercial projects use, splits it into a main group, a middle group and a subgroup, most commonly written as something like 1/3/5.

In the standard three-level structure, that gives you up to 32 main groups, 8 middle groups within each, and 256 subgroups within each of those. The style you pick only changes how ETS displays the address. The underlying 16-bit value is identical either way. What changes is how much sense a human can make of it at a glance.

The decision that matters most: room-based or function-based

Within the three-level structure, integrators generally structure a project one of two ways, and the choice shapes how the whole system reads for the rest of its life.

A room-based structure uses the main group for a floor or area, and the middle group for the room itself. Every function in that room, lighting, blinds, climate, sits together under one middle group. It's fast to program and fast to test, because everything for a room is visible in one place. This is the structure most residential projects end up with, and it's the one I default to on houses.

A function-based structure flips that around. The main group refers to a function type (lighting, HVAC, blinds), and the middle group separates the function itself (switching, dimming, value, feedback). A single dimmer circuit might sit across four related addresses, one per function, rather than one address per room. This suits large commercial projects with high circuit counts better than it suits a home, because it optimises for consistency across thousands of similar objects rather than for a person reading a room at a time.

Where the room-based approach runs into its own ceiling

Here's the part that catches people out on larger properties: a three-level structure only gives you 8 middle groups per main group. On a house with a study, two living areas, a kitchen, a scullery, four bedrooms and a home office, you're already past eight rooms on one floor. Add a guest wing or staff quarters, which is normal on the kind of property I work on around Joburg, and you will run out of middle groups before you run out of rooms.

The fix is straightforward. Split the property across additional main groups, by floor, by wing or by building, before a single device gets commissioned. It's a five-minute decision on paper at design stage. Worked out after 200 devices are already linked to addresses, it's an afternoon of relinking group objects that were never built to move.

Consistency is what makes the system readable later

The other half of this is naming. KNX integrators lean on a shared set of abbreviations in group address descriptions: SW for switching, DIM for dimming, FB for feedback, BA for blind actuator, HA for heating actuator, and so on. It looks like a small thing until you're staring at a bus monitor during a fault-find and every line of traffic tells you exactly what circuit, what function and what room it belongs to, instead of a string of numbers you have to cross-reference against a spreadsheet that may or may not still exist.

It also pays off during the build itself. A consistent structure lets ETS auto-fill the next available address as you link objects, and lets you select several group objects at once and assign them all in a few clicks instead of one at a time. None of this is about elegance for its own sake. It's the difference between commissioning a room in twenty minutes and commissioning it in two hours.

Why this belongs at design stage, not on-site with a laptop

This is the same argument I make about topology and wiring: the decisions that are cheap to make on paper before anything is installed become expensive, or sometimes impossible, to unwind once a system is live. A group address structure decided early in the project saves a future integrator, whether that's me in ten years or someone else entirely, from having to reverse-engineer a system that was never documented in a way anyone could follow.

That's the whole case for open, non-proprietary systems like KNX in the first place. The standard only stays serviceable by any competent integrator if the project underneath it was structured to be read by one.

If you're scoping a project and want the addressing scheme planned properly from the start, get in touch.

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

Just a conversation about what the project needs.