The language of your installation

Ordered roughly from the wall inwards.

---

Terms in your documentation

Bus

The dedicated low-voltage cable your KNX devices communicate over — typically green twisted pair, run alongside but separate from mains. Everything on it hears everything else. What it cannot do: remember. The bus carries messages; it stores nothing.

Telegram

A single message on the bus. A few bytes: where it is going, what type of value it carries, and the value. Lifespan measured in milliseconds.

Group address

The channel a telegram is addressed to, written 1/1/31. Devices publish to addresses and subscribe to them, never to each other. This indirection is why KNX installations survive being modified — adding a second switch to an existing light means pointing it at the same address, with no change to the actuator.

Your house probably has several hundred. Ours has 629.

Datapoint type (DPT)

The declared data type of a group address. 1.001 is a switch; 5.001 a percentage; 9.001 a temperature. The DPT is how a receiving device knows what the bytes mean.

For anyone trying to reason about a house automatically, the DPT is the single most valuable field in the entire project, because it says what kind of physical quantity travels on each channel — the difference between a number and a temperature.

Actuator

The device in your switchboard that actually switches or dims the load. Relay actuators switch; dimming actuators dim; blind actuators drive motors. Almost always DIN-rail mounted in the board rather than at the light.

Status object / feedback object

A group address on which a device reports its actual state, as distinct from the address on which it receives commands.

This distinction matters more than anything else in this glossary. Without status objects, your system is issuing commands blind — it has no idea whether they worked. In the houses we have surveyed, status objects are commonly present for only some loads, which is why “the lights sometimes don’t respond and nothing notices” is such a common complaint.

If you read one thing off your project file, read which loads have feedback and which do not.

Flags

Per-object settings — Communication, Read, Write, Transmit, Update — controlling what a device does with an address. Mostly an installer concern, but they are how you tell a reporting object from a commanding one when the names lie.

ETS

Engineering Tool Software. The licensed application used to configure every device and address. Professional-only in practice.

What this means for you: every change to what your house fundamentally does requires a person with ETS, a licence and the project file. This is the root cause of most owner frustration, and it is not something a competing product can simply remove without also removing the reliability that made KNX worth buying.

.knxproj

Your ETS project file. A zipped set of XML documents describing every device, address, datapoint type, parameter and binding in the building.

Treat it as an asset, not an archive: it is the most complete structured description of your house in existence, usually more current than the architectural drawings. Make sure you have a copy. A surprising number of owners do not, and reconstructing one is expensive.

DALI

A separate lighting-specific protocol, common in high-end installations for addressable fixtures, usually bridged to KNX by a gateway. Where KNX switches a circuit, DALI addresses individual luminaires — which is why constant-light regulation and fine scene control usually live here.

Frequently under-used: DALI gateways commonly ship with capability configured and then disabled at commissioning because nobody had time to tune it.

Scene

A stored set of output states, recalled by a single command. Implemented in the actuators themselves in KNX, which is why scenes still work when every clever box is unplugged.

What it cannot do: change. A scene is a photograph of one configuration, taken once, replayed indefinitely. See the scene is the problem.

Logic module

A KNX device or software block providing conditions, timers and gates — the closest the standard itself comes to decision-making.

What it cannot do: remember or arbitrate. Logic modules evaluate current inputs. Two of them wanting different things resolve by whichever writes last.

Visualisation / home server

A screen-facing layer presenting the bus as an interface — Gira HomeServer, a Zennio panel, a Control4 processor with a KNX driver, a Homey. Valuable for control, and architecturally a viewer and writer, not a decision-maker.

Bridge

Any device translating between KNX and something else — Zigbee, Matter, Wi-Fi, voice. Very useful for extending reach. See why a bridge is not a brain.

---

Terms that belong to the layer above

These describe the layer that sits on top of a correctly commissioned bus. They are not KNX terms, and you will not find them in your documentation.

Model / registry

A representation of the building as spaces, devices and capabilities, rather than as a list of addresses. We align spaces to Brick and devices to SAREF — two existing ontologies — so that a behaviour written once is portable between houses instead of hand-wired to one.

Aggregator

A component that combines several weak signals into a durable inference. Occupancy is the obvious case: several detectors, door contacts, and time-since-last-motion combined into a view of whether a space is occupied, rather than whether one PIR is currently triggered.

This is the difference between lights that go off while you are reading and lights that do not.

Policy

A small, single-purpose component that observes the model and proposes an action, with the evidence for it. Distinct from a rule in that it does not act — it argues. Dozens run concurrently and disagree constantly, which is intended.

Proposal

What a policy emits. An intended action, a precedence tier, and the evidence behind it. Proposals compete; they do not execute.

Arbiter

The single component that resolves competing proposals by explicit precedence. The property that matters is that it is the only path to action, so nothing can reach the bus without having won an argument on the record.

Precedence tier

The ranking the arbiter uses. Ours: safety and statutory, security, health and habitability, explicit human instruction, comfort, efficiency. A lower tier cannot beat a higher one — structurally, not by convention.

Decision log

An append-only record of every decision: the winning policy, the proposals it beat, the evidence used, the tier that decided it, and whether execution succeeded.

The test of any autonomous system is whether it can answer why did you do that last Tuesday. If there is no decision log, there is no answer, and nothing is accumulating that could be learned from.

Overrule rate

How often a person reversed the system’s action within a short window. The honest measure of whether a house is right about what its occupants want.

Any vendor in this category could compute it. Ask whether they publish it. Ours is on the evidence page, including the months it got worse.