What your ETS project already knows

Ask an integrator for your ETS project and you will be handed a .knxproj file. Most owners file it with the electrical certificates and never open it again. It is understood to be a wiring record — the artefact you need when something breaks or when the next contractor takes over.

That undersells it considerably. A .knxproj is a zipped set of XML documents describing every device in the building, every group address, every datapoint type, every flag, and every association between them. It is the most complete structured description of a house that exists anywhere, and in most installations it is more accurate than the architectural drawings, because unlike the drawings it was updated when things changed.

The problem is that it describes the house in the language of the bus, not the language of the building.

What the file contains, concretely

Four things matter for our purposes.

Group addresses and their datapoint types. 1/1/31 with DPT 1.001 is a binary switch object. 3/2/0 with DPT 1.001 is a zone enable. 0/5/7 carrying DPT 1.018 is occupancy. The DPT is the critical part: it tells you not just that an address exists but what kind of physical quantity travels on it, which is the difference between a number and a temperature.

Device catalogue entries. Manufacturer, product, application programme, and the parameter set as commissioned. This is how you learn that the actuator on channel 7 is configured for staircase lighting with a 3-minute timer, which explains behaviour that would otherwise look like a fault.

Associations. Which communication object on which device is bound to which group address, and with which flags — Communication, Read, Write, Transmit, Update. The flags tell you which objects report state and which merely accept commands.

The topology and the free-text names. Areas, lines, and the names a human typed: EG Wohnzimmer Deckenleuchte, Bath 2 Towel Rail, Sitting Rm Lights ctrl.

That last category is the one everybody dismisses and the one that carries the most information about the building. It is also, predictably, the messiest.

Why it is hard to read

If group addresses were named consistently, this would be a parsing exercise. They never are.

A house of any age has been through multiple hands. The original commissioning used German product defaults. The 2019 extension used a different integrator’s house style. Someone renamed half of Level 1 during a lighting refit and stopped halfway. Addresses exist for a pool that was filled in. Three addresses named Spare do something. One address named Test 2 controls the front gate.

Concretely, in the reference installation behind this site — 629 group addresses, commissioned across roughly a decade — we found:

• Four distinct naming conventions, none applied completely
• Status objects present for about two-thirds of switched loads, absent for the rest, meaning the system is blind to whether a third of its own commands worked
• A dozen addresses whose names referenced rooms that no longer exist by that name
• Several DPT mismatches that were harmless in practice because nothing ever read the object

This is not a criticism of the installers. It is the normal, healthy sediment of a building that has been lived in. But it is why “just parse the project file” is a sentence written by people who have not tried.

From addresses to a model

The output we want is not a cleaner address list. It is a structural model: a set of spaces (rooms, zones, thresholds, the building itself), a set of devices with capabilities (this thing can dim, that thing can report temperature, this one reports occupancy for that space), and the relationships between them.

We align spaces to Brick and devices to SAREF, for one unglamorous reason: those ontologies already encode the distinctions that matter — that a space contains points, that a sensor observes a property, that a command differs from a state — and inventing a private vocabulary for each house guarantees that nothing learned in one house can ever transfer to another.

Getting from one to the other takes four passes.

Pass one: structural. Everything unambiguous from the XML alone. DPTs give capability types. Flags separate commanding objects from reporting ones. Associations group objects into functional units. This is deterministic and needs no judgement.

Pass two: linguistic. Names are classified — room tokens, load tokens, floor tokens, function tokens — across the several languages and abbreviation styles a project accumulates. This is where a language model genuinely helps: EG, GF, Ground, Lvl 0 and Erdgeschoss are the same floor, and no regular expression you write will keep up with the next house.

Pass three: correlational. We watch the bus. Which addresses change together, in what order, on what delay. This is how a load named Test 2 reveals itself: it fires at 07:12 every weekday, forty seconds before the driveway camera sees a car. Names lie. Behaviour does not.

Pass four: human. Everything unresolved is presented to the installer as a small number of concrete questions — these eleven addresses appear to belong to one room; which room is it? — rather than a 629-row spreadsheet nobody will complete.

That last pass is the one people try to skip, and it is the one that decides whether the result is trustworthy. An ingestion that guesses silently is worse than no ingestion at all, because it moves the errors somewhere you cannot see them.

What the model makes possible

Once the house is a model rather than an address list, a set of problems stop being bespoke programming and start being properties of the system.

Which rooms are actually occupied, as opposed to which detectors are currently triggered. Occupancy is inferred across a space from several signals with persistence, not read from one PIR with a three-minute timer.

What is wired but never commissioned. Almost every house we have surveyed contains capability that was installed and forgotten — constant-light regulation configured in the DALI gateway and never enabled, presence detectors reporting lux that nothing subscribes to, a relay channel wired to a pump that no logic has ever operated. Owners have paid for this hardware. Often the assessment’s most immediate value is a list of it.

Where the system is blind. A model makes absent status objects visible as gaps rather than as silence, which turns “the lights sometimes don’t respond” from a ghost story into a wiring schedule.

Why this is the first thing, not a later thing

There is a strong temptation to start with the demonstrable part — the assistant, the app, the thing that impresses people in a showroom — and treat ingestion as plumbing to be done later.

That order does not work. Every policy worth running is a statement about spaces and capabilities: hold this zone rather than chase it, pre-heat that rail before the room is occupied, do not run the all-off while a guest is in the annexe. Without a model, each of those has to be hand-wired to specific addresses in a specific house — which is precisely the bespoke integrator programming the whole exercise is meant to escape.

The model is the product. Everything visible is downstream of it.

It also explains an architectural decision that surprises people: the ingestion toolchain does not ship on the appliance in your house. It runs as an installer-side service, and the box receives only the finished model as a signed bundle. Your house should not contain a general-purpose interpreter for arbitrary project files, and the tool that reads .knxproj files is not a tool that needs to be sitting on your network for the next fifteen years.

Your ETS project already knows what your house is. It has known all along. It has just never been asked in a language it could answer.