2026-08-06
knxetsdocumentation

How to structure 2 000 KNX group addresses so they are still readable after four years

Two hundred addresses forgive anything. Two thousand do not.

On a small apartment you can name group addresses however you like. Everything fits on one screen, and the person who wrote it is the person who maintains it.

Past roughly a thousand addresses that stops being true. Open an ETS project someone else left behind and you usually find the same landfill: Licht_1, Licht_2, neue Gruppe, a handful of addresses nobody dares touch. The installation still works. Changing anything in it costs a day of reverse engineering.

The structure is not cosmetic. It decides whether the project survives its author.

Three ways to organise, two of which break

  • By room. Reads well on day one and breaks the first time a wall moves. Rooms get merged, split and renamed; the addresses stay where they were and stop matching reality.
  • By device. Ties the address space to hardware. Replace a dimmer with a different model and the numbering no longer describes anything.
  • By function and floor. Rooms change, hardware gets replaced, but "lighting on the first floor" stays "lighting on the first floor" for the life of the building. This is the only one of the three that scales.

What fifteen main groups look like on 860 m²

A real installation: basement plus two floors, 148 KNX devices, three bus lines. Fifteen main groups carry the whole thing.

  • 0 — General: time, date, global lighting off, winter mode
  • 1–4 — Lighting, one main group per floor plus one for the facade
  • 5 — Shutters
  • 6 — Ventilation
  • 7 — Presence detectors
  • 8–9 — HVAC, split by floor
  • 10–12 — Underfloor heating, one main group per floor
  • 13 — Climate sensors: humidity, CO₂, TVOC, PM2.5, temperature
  • 14 — Pushbuttons and their LEDs

The point is predictability, not beauty

This is the part that actually matters. Inside every lighting main group the middle groups repeat in the same order: /0 switching, /1 switch status, /2 dimming, /3 brightness value, /4 brightness status, /5 detector block.

The consequence is that one luminaire keeps the same last number across the whole row:

1/0/11 L 0.05-88 On/Off ← command 1/1/11 L 0.05-88 On/Off St ← status 1/2/11 L 0.05-88 Dim 1/3/11 L 0.05-88 Vol 1/4/11 L 0.05-88 Vol St

Knowing the command address, an engineer computes the status address in his head. He does not open the project, does not search, does not ask the person who commissioned it. On a service call at nine in the evening that difference is the whole job.

Why statuses get their own middle group

The tempting alternative is to put the status on the address next to the command — 1/0/11 switches, 1/0/12 reports back. It looks compact and it is a mistake.

Statuses are the chatty part of the bus. Actuators send them on every change, and on a large installation that is a constant stream. Kept in their own middle group, the whole class can be filtered out of a bus trace in one click, which is what you want when you are chasing a fault. Interleaved with commands, every trace becomes twice as long and half as readable.

Leave room

In this project 2 020 group addresses are allocated and 1 579 are actually named. The 441 free ones are not sloppiness — they are the gaps left inside each middle group so that the next luminaire, the next sensor, the next zone lands in its proper place instead of at the end of the list.

Four years in, every extension has fitted into the existing scheme. Nothing had to be renamed.

Checklist for your own project

  • Main groups follow function and floor, never rooms or device models.
  • Middle groups repeat in the same order inside every main group.
  • Statuses live in their own middle groups, not next to the commands.
  • The last number identifies the same physical object across the whole row.
  • Every address has a datapoint type set — an empty type is a future bug.
  • Gaps are left inside groups, not appended at the end.
  • The naming survives being read by somebody who was not there.

See it for yourself

The full address tree from this installation is published, anonymised, on the case page — searchable by name, address and datapoint type, and downloadable as CSV. Judge the naming yourself.

The 860 m² case, with the full group address treeKNX programming as a service

Discuss a Project

Discuss Project