KNX in plain English

KNX is a wired system that runs the lights, blinds and heating in your house. It is reliable, and no single company owns it. But the devices on it do not decide anything together. Each one follows its own settings. That is why a well-built KNX house can still feel dumb, and why adding an app on top does not change much.

What KNX is

KNX is a standard for buildings. A separate low-voltage cable, often green, runs beside your mains wiring to the switches, sensors and the switchboard. Devices on that cable send messages to each other directly.

Three things follow from that.

There is no hub. When you press a KNX switch, it sends a message on the wire. The box in the switchboard that switches the light acts on it. No central controller sits in between, so there is no central controller.

No single company owns it. KNX is an open standard run by an association. An ABB switching box, a Gira switch, a Theben sensor and a Zennio panel can all work together. You are not locked to one maker.

It is wired. A wired cable is not fashionable. It is a sensible choice for something buried in a wall for decades. (A wireless version of KNX exists too, but most serious homes use the cable.)

How it works

Three ideas cover most of it.

The group address. This is a numbered channel, written like 1/1/31. A switch sends to it. The box that switches the light listens to it. Neither needs to know about the other. Add a second switch to the same channel and it controls the same light. That is why KNX houses age well.

The message. Each message on the wire carries an address, a type of action (read, write or reply) and a few bytes of data. It does not say what the data means. The setup file says that.

ETS. This is the installer’s software. Every setting, every channel and every link is made in ETS and loaded into the devices. There are cut-down versions, but most changes still need your installer.

What KNX does very well

• It is dull in the best way. Well-built KNX runs for years with no attention. It does not depend on a cloud service that can be switched off.
• It lasts. Devices from many years apart can share one cable.
• It does not depend on a subscription. Your lights work without anyone’s server.

Three things it does not do

None of these is a fault in your installation. They are how the standard is built.

1. It does not keep a history

A presence sensor says “someone is here”. Three minutes later it says “nobody is here”. The wire does not keep either message. Nothing on it can answer “how long was that room used?” or “what happened just before the light went out?”

2. The devices do not know your rooms

The devices only see channels. They do not know that these eleven channels all belong to the sitting room. ETS can hold room names, and your installer may have filled them in. But the devices on the wire never use them.

So a rule like “turn off the lights in empty rooms” cannot be written once. It is written as “when 0/5/7 is 0 for 180 seconds, write 0 to 1/1/31”. Then it is written again for every room, by hand, and again after every change.

3. Nothing decides when two things disagree

KNX has no application-level decision-maker across devices. Some devices have priority settings. Logic modules can be set up with care. But nothing looks at the whole house and picks a winner.

A scene shows the same limit. A scene is a saved snapshot of how the lights were set one day. Press a button and the dimmers, blinds and amplifier go to their saved settings, and the settings are stored in the devices themselves. That is quick, and it keeps working with no central controller. But the snapshot is usually made by the installer on a commissioning afternoon, and it is then replayed for years. It does not change when your family does, and it cannot choose between two clashing requests. More scenes just make a longer menu to choose from.

So the vacancy rule may switch off the lights while someone reads quietly in the next room. The timer wants one thing. The person wants another. A common complaint is: “the lights turn off while we are still in the room.”

Why an app does not fix it

The usual next step is a bridge. That is a hub, a home server or a voice assistant that talks to your KNX. Homey, Josh.ai and a Control4 processor are examples.

They are useful. They give you a phone screen, a voice command, and a way to connect devices that arrived after the walls were closed. If you want to dim the lounge from the sofa, that may be all you need.

But a bridge does not give the house a memory or a map of its rooms. It does not decide between two requests. It is one more place to send commands from. We cover this in why a bridge is not a brain.

What Casient adds

Casient is early. It runs in one real KNX home so far, and pilots are under way. It adds three things above the wire.

• Rooms. The house is described as rooms and the things in them, not just addresses.
• A clash rule. When two requests clash, the room’s own behaviour is checked first, and the log says why.
• A log. For each decision, the log says which rule ran, what it overrode, and what started it.

Your KNX stays in charge of the switching. Wall switches and scenes still run on the wire. What you commissioned stays on the wire.

Rules are written and approved by your installer. Room behaviours come from the ORBS cards, an open draft standard. Your installer picks and approves them.

Next steps

If you want to know what each word in your paperwork means, read the language of your installation. If you want to know what “AI” means in a home product, read what “AI in the home” actually means. If you are curious what is already inside your own project file, read what your ETS project already knows. Installers can find fix-it notes at KNX notes.

Send this to your installer, or ask them:

• How does the system decide between two requests?
• Can you run a free Readback on our project?

For installers

Installers: run a free Readback