2026-08-06
knxetsdocumentation

One project table, two systems: killing duplicate data entry

Every address is entered at least twice

A group address is born in the project table. Then it is typed into ETS. Then it is typed into the controller configuration, because the visualisation and the logic need to know it too. Then, if the client is getting proper documentation, it is typed a third time.

Each repetition is a point where the copies can drift apart, and they do. Someone moves an address during commissioning because two circuits collided. ETS gets the fix. The controller config gets the fix, a week later, from memory. The documentation does not. A year after handover there are three sources and no way to tell which one is right without going to the building and measuring.

One document is primary, the rest are generated

The alternative is to decide, once, that the project table is the primary document — and that nothing else is ever edited by hand. The ETS import file, the controller configuration and the client documentation all come out of it.

Project tableedited by handgeneratorETS import filecontroller configdocumentation
One document is edited. Everything downstream is output, and output is never corrected in place — it is regenerated.

What changes in practice

  • An address changes in one place. The next generation propagates it everywhere, in seconds.
  • Divergence between ETS and the controller stops being a thing that can happen. It is not policed by discipline; it is structurally impossible.
  • Handing the project to another engineer stops being archaeology. The table is the project, and it is readable without ETS installed.
  • The client documentation is current by construction, because it is a build artefact rather than a document somebody remembered to update.

What it costs you

Two things, and neither is software. The first is naming discipline: the table is only worth generating from if the names in it follow a scheme somebody else can read. The second is the import format, which is what turns the table into something ETS accepts.

Both are already written up, with the working code for the second.

Structuring 2 000 group addresses so they stay readableThe ETS 6 import format, with the generator

What this does not solve

Linking group addresses to the communication objects of devices is not automatable without the ETS API. The import creates the addresses; connecting them stays manual, and on a large project that is still the longest single task in ETS.

The approach also assumes the table was kept properly from the start. Imposing order retrospectively — reconstructing a table from a project that has already drifted — costs more than doing it correctly at the outset, and it is worth being honest that the saving is largest on projects that have not begun yet.

And it moves a risk rather than removing it: a mistake in the table now propagates to three places at once. That is the trade. It is a good one, because one wrong source that is visibly the source beats three sources that quietly disagree, but it is a trade.

A project run this way, with the full address exportKNX programming as a service

Discuss a Project

Discuss Project