Two group addresses with the same name: which one did you mean?

KNX will not stop you

Group address names are documentation. The bus routes on the address, never the name, so 1/1/12 and 1/4/12 can both be called Küche Licht forever and nothing in ETS will raise it.

That is exactly why it is worth finding. A defect that produces an error gets fixed. A defect that produces two identical rows in a dropdown gets chosen between, usually correctly, until the one time it isn’t.

How they get created

Rarely by carelessness in a single sitting. The three common routes:

• Stages. Ground floor was commissioned in 2019, the extension in 2023, and both have a Flur Licht. Neither person was wrong at the time.
• Copy-and-extend. An existing structure is duplicated for a new floor and the names come along with it.
• Control and status. Küche Licht for the switching address and Küche Licht for the feedback — the most common pair of all, and arguably the most dangerous, because the two behave completely differently when written to.

Why it costs more than it looks

In the group monitor. You are tracing a fault, you filter by name, and you get two addresses. Now you are doing the elimination by hand, at the exact moment you were trying to save time.

In a visualisation or an integration. Whatever imports the project has to disambiguate, and most tools do it by taking the first match or by appending a number. Both are silent. You find out when a client says the kitchen switch turns on the hall.

In the handover document. A schedule with two identical entries is a schedule that has to be checked against the project, which defeats the point of having written it.

In your own head, in two years. The reason to fix this is not tidiness. It is that you will be the one reading it.

Fixing it

Rename, and rename on a rule rather than ad hoc, because a unique name that is unique by accident does not survive the next stage. The rules that hold up:

• Include the space at the granularity your project distinguishes — Küche is not enough in a house with two kitchens, and floor prefixes solve more than they cost.
• Include the direction where control and status share an object name. Whatever suffix you use, use one. See telling status from control if the project you inherited did not.
• Rename in ETS, not in a downstream tool. The project file is the record; anything you fix elsewhere gets overwritten by the next export.

None of this requires re-downloading a device. Names live in the project, not in the hardware, so this is one of the very few defects on any commissioning list that costs nothing but the time to type.

What the check does with this

Upload the project and duplicate names come back as a specific finding — every name that appears more than once, with all of the addresses that share it, so you can see immediately whether you are looking at a control/status pair or two genuinely different outputs on two different floors.

It sits alongside the other addressing issues that are fixable by you, in ETS, in minutes, before anybody hands anything over: unnamed ranges, addresses with no datapoint type, addresses sitting outside the named range they belong to, and addresses whose role does not match the position your own convention puts it at.

The rule the check follows is that every one of those has to be actionable. A finding you cannot do anything about belongs in a score, not on a list.