KNX in plain English

If you own a KNX house, you own something genuinely unusual: a building whose electrical intelligence is not owned by anybody in particular. Not by Google, not by Apple, not by the company that installed it, and not by us.

That is the whole point of the standard, and it is worth understanding properly — including the parts that explain why your house, despite all of it, still needs to be told what to do.

What KNX is

KNX is a wired communications standard for buildings. Alongside your mains wiring, a separate low-voltage cable — usually a green twisted pair — runs to switches, sensors, and the distribution board. Devices on that cable talk to each other directly.

Three consequences follow, and they are the reason the standard has survived since 1990 while dozens of proprietary systems have not.

It is decentralised. There is no hub. When you press a KNX switch, the switch sends a message onto the bus and the actuator in the switchboard acts on it. No controller mediates that, so there is no box whose failure darkens the house. If every clever device in your plant room died tonight, your lights would still work tomorrow.

It is vendor-neutral. KNX is an open standard maintained by an association, not a company. An ABB actuator, a Gira switch, a Theben sensor and a Zennio panel all speak the same protocol. You are not locked to a manufacturer, and a product going end-of-life does not strand your installation.

It is wired. No batteries, no mesh, no channel congestion, no firmware update that quietly breaks a device. Latency is in milliseconds and does not vary. A wired bus is unfashionable and it is the correct engineering decision for something buried in a wall for forty years.

If someone tries to sell you a wireless system as an upgrade from KNX, they are selling you a downgrade with a nicer app.

How it actually works

Three ideas cover almost everything.

The group address. This is the core abstraction. A group address is a channel — written like 1/1/31 — that devices publish to and subscribe to. A switch publishes to it; an actuator listens to it. Neither knows the other exists. Add a second switch that publishes to the same address and it controls the same light, with no reprogramming of the actuator.

That indirection is why KNX installations age well. Things are coupled to channels rather than to each other.

The datapoint type. Every group address carries a declared data type, called a DPT. 1.001 is a switch, on or off. 5.001 is a percentage. 9.001 is a temperature in degrees. The DPT is how a device knows that the byte it just received means 21.5°C rather than the number 21.5 — and it is the single most useful piece of information in your entire project file, because it tells a machine what kind of physical quantity is travelling on each channel.

ETS. The Engineering Tool Software is how the whole thing is configured. Every device’s parameters, every group address, every binding, is set up in ETS and written to the devices. ETS is licensed, costs real money, and is the domain of professionals.

This last point is not a detail. It is the origin of most of what follows.

What KNX does better than anything else

Be clear about this, because the rest of this guide is critical and the criticism is worthless if it comes from someone who does not respect the thing.

Reliability that is boring. Correctly commissioned KNX installations run for decades with no attention. There is no category of “my lights stopped working because a cloud service was deprecated”, because there is no cloud service.

Genuine longevity. Devices from 2005 work on a bus with devices from 2025. Very little consumer technology can say that, and nothing wireless can.

Scale without degradation. A 600-address house behaves exactly like a 60-address house. The bus does not get slower or less predictable as you add to it.

Independence. Your house does not depend on a company continuing to exist, a subscription continuing to be paid, or an API continuing to be supported.

The three things it structurally cannot do

Here is where the frustration comes from. None of these are faults in your installation. They are properties of the standard, and no amount of additional KNX hardware will fix them.

1. It has no memory

The bus is a messaging system. A telegram is sent, devices act on it, and the event is gone. A presence detector reports occupancy; three minutes later it reports vacancy; nothing anywhere retains that this room was occupied for forty-one minutes on a Tuesday evening, or that it usually is.

Nothing on the bus can answer how long, how often, or does this usually precede that — because nothing is keeping score. Automation without memory can only replay; it cannot learn, because learning requires a record to learn from.

2. It has no model of the building

KNX knows about addresses. It does not know about rooms.

There is no representation anywhere in your installation of the fact that these eleven addresses are all the sitting room, that this detector observes the space that those lights illuminate, or that the door contact and the motion sensor are two views of the same hallway. That knowledge exists only in the head of your integrator and, partially, in the free-text names they typed in ETS.

This is why logic in KNX is always hand-wired to specific addresses. “Turn off the lights in unoccupied rooms” is not something you can express. You can only express “when 0/5/7 is 0 for 180 seconds, write 0 to 1/1/31” — thirty times, by hand, and again after every change.

3. It cannot resolve a disagreement

Real houses generate contradictions constantly. The vacancy logic wants the west wing off; someone is reading in the annexe. The heating schedule wants a setback; a guest is staying. On a bus, whichever telegram arrives last simply wins.

That is not a decision. It is a race, and the outcome depends on timing rather than on what anybody would want. It is the mechanism behind the single most common complaint in sophisticated homes: the lights turn off while we are still in the room.

Why adding an app does not fix it

The standard upgrade path offered today is a bridge: a hub, a visualisation server, or a voice assistant that speaks to your bus. Homey, Josh.ai, a Control4 processor with a KNX driver, and a dozen others all sit in this category.

These products are useful. They give you a phone interface, a voice command, and a way to tie KNX to devices that arrived after the walls were closed. If what you want is to dim the lounge from a sofa, buy one.

But look at what they do against the three limitations above. They add no memory — they read current state and issue commands. They add no model — they inherit your address list, sometimes with the room names attached. They do not arbitrate — they are simply another writer racing everything else, and often the most aggressive one.

A bridge makes commands easier to issue. It does not reduce the number of commands your house requires. In most installations it increases them, because now there are more ways to issue one.

That is the ceiling of the bridge approach, and it is worth knowing about before you spend money reaching it. We have written about it separately in why a bridge is not a brain.

What is actually missing

Not more hardware. Three capabilities, which have to sit above the bus because the bus cannot provide them:

A model — the house as rooms, capabilities and occupants rather than as addresses. Built once, from your ETS project plus observation of the live bus.

A memory — a durable record of what happened, so that patterns are visible and corrections can accumulate.

An arbiter — a single place where competing intentions are resolved by explicit precedence, so safety structurally outranks comfort and nothing is decided by whichever process happened to fire last.

Add those three, and the behaviour you actually want stops being something an integrator hand-codes per address and starts being something the system can reason about. That is the difference between a house you operate and a house that runs itself.

Your installation is not the problem. It is, by a distance, the best foundation in the industry to build this on — which is precisely why it is worth doing properly rather than papering over with another app.