How to choose a KNX supervision server

Every KNX project reaches the same fork. The bus is designed, the devices are chosen, and then someone has to decide what sits above it: the thing that turns a set of group addresses into something a client can actually operate. Get that decision wrong and you find out two years later, when the client asks for something the platform cannot do.

What follows are the questions worth asking before you commit, in the order they usually start to matter. None of them have a universally right answer — they have an answer that is right for the project in front of you.

1. What does it speak natively, and what needs a gateway?

Almost every platform claims multi-protocol support. The distinction that matters is whether a protocol is integrated in the server or reached through an external interface you have to buy, mount, power and maintain.

Ask specifically about Modbus and BACnet. A server with KNX, Modbus and BACnet gateways built in costs nothing extra in cabinet space; one that needs a separate interface per protocol adds hardware, a power supply and another thing that can fail. Ask, too, whether the server can act as a Modbus slave and not only a master — you need it the day a general contractor wants the building exposed to their BMS.

2. How is it licensed?

This is where projects get expensive quietly. Some platforms license per group address, per user, per app installation, per connected device, or per year. Each of those is a number that grows after the quote is signed.

Work out the total for a real project, not the entry price: a 400-address villa with six family members, four tablets and a caretaker's phone is a different number under a per-address model than under a flat one. And check whether push notifications are metered, because alarm and door events generate a lot of them.

3. DIN rail or on-wall?

A DIN rail server lives in the cabinet and stays out of sight: it suits complex projects, several subsystems and anything where the cabinet is the natural centre of gravity. An on-wall unit that combines server and touch interface removes a piece of hardware and a point of failure, which suits residential projects that want one high-end control point.

The question is not which is better but where the project's centre is. A villa with one main living area and a small cabinet is a different shape from a five-storey office with three risers.

4. What happens when the internet goes down?

Ask where the logic actually runs. If the server is on site and the app talks to it over the local network, an internet outage costs you remote access and nothing else — the building keeps working. If scenes, schedules or voice control depend on a cloud round-trip, an outage at the provider becomes an outage at your client's house, and you are the one who gets the call.

Ask the follow-up too: which features specifically require the cloud. Remote video from cameras and intercoms usually does, for bandwidth reasons, and that is reasonable. Turning on a light should not.

5. How do you get back in after handover?

You will need to change something remotely. Find out whether remote ETS programming is possible, how it is secured, and whether it needs port forwarding on the client's router — because a client's IT department, or a carrier-grade NAT, will eventually make port forwarding impossible.

A VPN gateway provided by the manufacturer avoids that conversation entirely. Ask whether it is included or a paid module, and what happens to it if you stop paying.

6. Who configures it, and how long does it take to learn?

The configuration tool is where your margin lives. A platform that takes three days to learn and four hours to commission beats one that takes an afternoon to learn and three days to commission, every time, on the second project.

Ask for a trial licence and build a small real project before you specify it on a site. Look specifically at how the visualization is designed: whether you are laying out screens by hand for every room, or whether the structure comes from the ETS project and you are refining it.

7. Does it do anything with energy data, or just display it?

Metering has become standard and most platforms will draw you a chart. The useful question is what happens next. Can the system convert kilowatt-hours into local currency so the client understands the number? Can it shed non-critical loads before the main breaker trips? Can it export logged data for tenant billing or an energy audit?

A chart is a feature. Load shedding that prevents a blackout is a reason the client recommends you.

8. What does support look like on a Friday afternoon?

The honest test of a manufacturer is not the datasheet, it is what happens when you are on site, the client is watching, and something does not work. Find out whether you reach an engineer or a ticket queue, whether there is a phone number, and whether documentation exists in a language your team reads.

Ask the manufacturer's other installers rather than the manufacturer. At a KNX trade event you will get a straight answer in thirty seconds.

9. How long will this hardware be supported?

KNX installations outlive most consumer electronics. Ask how long the current generation has been shipping, what the update cadence looks like, and what happened to the previous generation when this one launched. A platform that abandons hardware every four years is a platform that will make you re-sell a project you already sold.

There is no scoring sheet at the end of this. The point is that the platform decision is a commercial decision as much as a technical one: it sets your commissioning time, your margin, your exposure when something breaks, and what you will be able to say yes to in three years.

If you want to test these questions against a specific project, send us the device list and the subsystems — we will tell you what it needs, including when the answer is that it needs something else.