Why a bridge is not a brain

Every owner of a serious KNX installation eventually gets the same recommendation: add a bridge. A hub, a home server, a visualisation platform, a voice assistant — something that speaks KNX on one side and something modern on the other.

The pitch is consistent across the category. Your KNX is reliable but dated. Add this, and you get a phone app, voice control, and the ability to connect devices that arrived after your walls were closed. Homey positions itself precisely this way — KNX brought into the twenty-first century. Josh.ai does the same at a much higher price point with far better natural language. A Control4 processor with a KNX driver does it inside a different ecosystem.

These are real products solving a real problem. This is not an argument that they are bad. It is an argument that they solve a different problem from the one most people describe when they say their expensive house feels dumb.

The test

Here is a way to evaluate anything in this category, and it takes one question:

After installing this, how many decisions per day does my household still have to make about the house?

Not how easily can you make them. How many.

A bridge improves the ergonomics of instruction. You can now dim the lounge by voice instead of walking to a keypad. That is a genuine improvement in the experience of issuing a command.

It does not reduce the number of commands. Usually it increases them, because you have added interfaces, and each interface accumulates its own habits. The phone, the panel, the keypad and the voice assistant now all do overlapping things, and family members diverge on which they use.

If the answer to the question above is “about the same, but they’re easier”, you have bought convenience. That may be exactly what you wanted. Just know which thing you bought.

What a bridge actually contains

Strip the marketing off anything in this category and you find three components.

A protocol adapter. It speaks KNX, plus Zigbee, Z-Wave, Matter, Wi-Fi. This is the genuinely valuable part and it is real engineering.

A state cache. It holds the current value of things — this light is at 40%, this sensor reads 21.5°C — so an interface can render them. Note current. It is a snapshot, not a history.

A rules engine. If this, then that. Triggers, conditions, actions. Sometimes with a pleasant drag-and-drop editor, sometimes with a scripting language.

That third component is where the ceiling is, and it is worth being precise about why — because “if this then that” sounds like it should be sufficient. It clearly handles a huge number of useful cases. What it cannot do is anything that requires the system to hold a view about the house as a whole.

Three things a rules engine cannot express

Anything requiring history. “Pre-heat the towel rail before this bathroom is usually occupied” requires knowing when it is usually occupied. A rules engine has a trigger and a current state. It has no usually. You can hand-code a schedule — but then you learned the pattern, not the house, and you will be maintaining that schedule by hand forever as the household changes.

Anything requiring the building as a concept. “Turn off lights in rooms nobody is in” cannot be written once. It has to be written per room, per light, per sensor, because the rules engine has no notion of a room — only of the entities your integrator happened to name. Thirty rules instead of one. Thirty rules to revisit when the study becomes a nursery.

Anything requiring a decision between conflicting goods. This is the important one. Rules engines are imperative: each rule fires independently and writes directly. When two rules disagree, the later write wins. There is no place in the architecture where anything considers both intentions and chooses.

So the vacancy rule turns the lights off while somebody is reading quietly in the annexe, because the vacancy rule does not know that a comfort consideration exists, and there is nothing above it that does.

Every owner of a heavily-automated house has a version of this story. It is not a configuration error. It is the architecture: a pile of independent writers with no adjudicator.

What the category cannot fix by getting better

Natural language is the clearest illustration, because it is where the most money and the best engineering in the category have gone.

Josh.ai is excellent. Local processing, no audio leaving the house, genuinely good at compound commands — turn off the downstairs lights and set the theatre to movie mode. If you are going to instruct your house, this is close to the best available way to do it.

But read that sentence again. If you are going to instruct your house.

A better interface for issuing commands is still an interface for issuing commands. Improving it is real progress along one axis, and that axis does not lead to a house that anticipates anything. You can make the command effortless. You cannot make it unnecessary, because nothing in the architecture is trying to.

The same holds for the recent wave of LLM-powered assistants. Putting a language model in front of a rules engine gives you a more forgiving way to phrase a request. Behind the conversation, the same three components are doing the same three things. The house did not become more aware. It became more polite.

What would have to be different

Three things, none of which is an interface.

A model of the building, not a list of entities. Rooms as spaces that contain capabilities and are observed by sensors, so behaviour can be expressed once, about a kind of space, and apply everywhere it fits.

A durable memory. A record of what happened and what the household did about it — which is what makes usually a thing the system can compute rather than a thing you have to encode.

An arbiter with explicit precedence. A single place where every intention is a proposal rather than a write, where proposals are compared, and where a lower-priority concern structurally cannot beat a higher one. Not last-write-wins. An actual decision, recorded, with reasons.

Add those and the behaviour changes category. Not “more rules, better phrased” — instead, a house that forms a view, acts on it, and can tell you why.

How to choose

Honestly, the decision is not difficult once framed properly.

Buy a bridge if your complaint is I want to control things from my phone, I want voice, or I want to add devices my KNX cannot reach. These are good reasons. Bridges are comparatively cheap, they install in a day, and they will do exactly what they say.

Do not buy a bridge if your complaint is I am tired of telling my house things, it keeps doing the wrong thing at the wrong time, or we spent a fortune and nobody uses any of it. No product in that category addresses those, and the gap between what you will hope for and what you will get is where the disappointment in this industry lives.

Casient is in the second category, which is why we have spent a page telling you when not to buy it. If your house needs a bridge, buy a bridge — you will be happier and it will cost you a tenth as much.

If what you want is for the house to stop asking, that needs a different shape of system. We have written about what that shape is in what “AI in the home” actually means.