Commissioning a KNX house without walking it twice

What walking the house actually proves

That the output is alive. You press, the light comes on, you tick it off.

That is worth doing and it is not nothing. But consider what passes that test unchanged:

• An address wired to the wrong room, where you pressed the button in the room you were standing in and something switched somewhere you were not.
• A status object nobody bound. The output works. Nothing on the bus ever says so. Six months later the app is wrong and nobody can say why.
• A dimmer that reports 0% forever. It dims beautifully. Its feedback is dead, and you will never notice by looking at the light.
• Both halves of a swapped pair, where two outputs are crossed and you tested them in the order that made both look right.

Every one of those looks correct from the corridor, and every one comes back as a callback months later, on your time.

The test already exists

A draft configuration derived from the project already knows, for each entity, which address commands it and which address is supposed to report back. That relationship is an acceptance test. It has simply never been written down.

Turned into a protocol it reads as an ordered list: send this value to this address, expect this status telegram back within this long. Tolerances where they matter — a dimmer rounds, a valve rounds — and time limits that reflect physics rather than optimism:

• 3 seconds for a status echo on anything electrical.
• 120 seconds for a blind or a shutter, because they physically travel and a position report is not late at ninety seconds.

Some steps are observe rather than write: things nothing commands, where you wait for the telegram rather than provoking it.

The most valuable part is the list of things it cannot check

This is the bit worth reading twice.

An entity with no status address cannot be verified by any protocol at all, because the bus never says whether the command worked. You can write to it and watch a light, but nothing testable happened.

Those have to be named and counted, not quietly skipped — and a tool that omits them is flattering you. A line reading

these 41 lights will switch and nothing will confirm it

is a commissioning finding worth more than the 112 checks around it. It tells you what you are handing over that nobody can ever prove, and it gives you the choice to bind those status objects now, while you still have the project open, instead of after the client has moved in.

Nothing here writes to a bus

Worth being explicit, because it is the first question anyone sensible asks.

The protocol is a document. It is produced by reading a file. Executing it is a separate and deliberate act by a person standing in the building, and the results are read back from the bus monitor’s own telegram log. No tool in this pipeline writes to a KNX bus — not during commissioning, not at any other time.

That boundary is not a limitation we are apologising for. A system that can generate a test and also execute it against a live installation is a system that can put a house into a state nobody asked for, and there is no version of that worth the convenience.

Where it pays

The protocol is a handover artefact as much as a test. It gives you something to put in front of a client that says, specifically, what was verified and what could not be — which is a considerably stronger position than “we tested it” when a dispute arrives eighteen months later.

Run it again after any change and you have a regression test on a house.

What the check does with this

Upload the project and the acceptance protocol comes back with it: the ordered steps, the expected status telegram for each, the tolerances, and the explicit list of entities that cannot be verified because nothing reports on them.

It is free, along with the health score, the coverage report, the addressing issues and the revision diff. The protocol is a document, not an action, and reading what your own project says has never been the part worth charging for.