How to tell a status address from a control address when nobody named them

The situation

You have opened somebody else’s project. There are six hundred group addresses. The names are Licht 12, EG_Wohnen_3, Schalten neu, and a hundred and forty are blank. You need to know which of these you can safely write to and which ones only ever report.

Getting it wrong in one direction gives you an integration that cannot control anything. Getting it wrong in the other means writing to an address that an actuator is transmitting on, which produces a bus fight — two devices asserting different values on the same address, lights flickering, and a very unpleasant afternoon.

The three sources of evidence, worst to best

The name — unusable

Status, Rückmeldung, Feedback, RM, Ist, _st, .s, and blank. Across projects there is no convention, and within a project the convention usually changes at whichever point a second person started working on it. Any rule you write from names is a rule about one integrator’s habits.

The address range — suggestive, not evidence

Most integrators do put status addresses in a particular range or at a particular offset — say, middle group 1 for control and middle group 4 for status, or a stride where every control address at offset n has a status at n+100.

This is genuinely useful, but only as a convention this project uses, derived from the project itself, and only when there is enough of it to be confident. A project organised differently is not a broken project, and a tool that scores it as one is scoring taste. Where the convention is clear it can tell you that 4/1/7 is probably status. It cannot tell you that on a project assembled over three stages by two firms.

The flags — decisive

Every communication object bound to a group address carries KNX flags, and they describe what the object is for in a way no name can:

• The object transmits and the bus cannot write to it → it is a status object. The device is reporting.
• The bus writes to it → it is a command object.
• Some objects do both. Some do neither and are inert.

Roll that up per group address: an address bound only to transmitting objects is a status address. An address bound to at least one writable object is something you can command. This is true in every language, of every certified product, and it does not care whether anyone filled in the name field.

The cases that stay ambiguous, and why that is fine

Some addresses genuinely carry both — a device writes to them and another device reports on them. Central-off addresses and some scene addresses look like this legitimately. A few are bound only to inert objects and do nothing at all.

The honest handling is to name them as ambiguous rather than force them into a column. An address that a tool has guessed is status, and which turns out to be writable, is worse than one it flagged for you to look at — because you would have looked at the flagged one.

What to do with the answer

Once direction is settled you can do the three things the project needed:

1. Name the ranges so the next person does not repeat this exercise.
2. Pair them. A control address and the status address that reports on the same output are a pair, and that pairing is what makes a working integration — and what makes an acceptance test possible at all.
3. Find the controls with no status. These are the outputs that will work perfectly and never confirm anything. See why a KNX light shows the wrong state.

What the check does with this

Upload the project and every group address comes back typed by direction, from the flags of the objects bound to it, with the ambiguous ones listed separately rather than folded in.

It also reports the addressing convention it detected in your project — the stride, the role at each offset, the naming your own ranges follow — and what its confidence in that is. Where confidence is low it says so and the structural checks do not run, because an anomaly is only an anomaly against a convention somebody actually chose.

On the reference installation that produced 668 addresses read in full, of which 234 are declared and terminated at nothing at all. On an inherited project, that list is the first hour of work you would otherwise have done by hand.