KNX protocol
KNX integration: building automation inside one local interface
The bus stays a bus. HoumeOS adds the rules, the rights and the history.
What is ready today, what is waiting for the driver, and what documentation we need from your KNX installation.
In short
KNX is a wired protocol for building automation: devices are commanded through group addresses, and access from the LAN usually goes through a KNXnet/IP interface. HoumeOS describes KNX as a transport in the integration catalog and provides guides with a real TCP check of the address. The driver that reads and writes the group addresses is still to come — we do not present it as ready.
What KNX is and where it appears in HoumeOS
KNX does not work with "devices with an account". It works with group addresses: every signal — a blind position, a light status, a set temperature — is an address on the bus that someone sends and someone listens to. The platform does not speak KNX out of the box; it speaks MQTT through the home/v1 contract, and KNX arrives as a transport that is translated into it.
- The group addresses remain the only language of the bus — nothing is duplicated into a cloud
- From a LAN machine the access is usually through a KNXnet/IP interface
- Translated signals enter the same device model as every other device
What is ready today
The integration catalog describes KNX as a wired transport next to Modbus, ONVIF, Matter, Zigbee and REST. For every transport the panel shows the direction, the medium and whether the required dependency is present — that is not a marketing line but a real record on the server. The editor keeps the label, the address and the note on the server, not on the tablet.
- Guides for address and port with a real TCP check whether anything answers at all
- Step-by-step pairing: network type → device → test request → result
- A device registry with an honest state: offline, online, unknown
- Rules, scenes, modes, rights and roles, history for 7/31/13 months
What is still to come: the driver
The missing element is the driver. It has to read the group addresses that describe your installation, write them as state into home/v1 and take the commands back to the bus. That is a small, precisely defined part and it is the next step on the roadmap. Until it is written and verified against a real KNX interface, we do not say "we support KNX".
What documentation we need from the site
A KNX installation needs its project: the list of group addresses with their data, which ones are inputs and which are outputs, which fields and scales are used, and how the interface to the LAN looks like. With that documentation the driver is work on a site, and guessing addresses is not. The concrete device and interface models are confirmed during a survey of the installation.
Why local, and not through the manufacturer cloud
On the cloud path every command leaves the house, passes a foreign server and comes back. With a local server the rules run in your home: the internet goes down, and the blinds, the lights and the heating keep moving on schedule. The bridge token and the role-based rights stay inside the LAN, and the journal shows which command was executed and which was not.
What works today and what is coming
We do not present upcoming work as available. This list matches the roadmap.
Works today
- KNX is described in the integration catalog as a wired transport with its required dependency
- Guides with address, port and a real TCP check of the answer
- The integration editor — settings live on the server, not on the tablet
- A shared device model: rights, roles, journal and history, ready for translated signals
Coming soon
- A driver that reads and writes group addresses and translates them into home/v1
- A confirmation for every command to the bus and a clear state when the bus is silent
Later
- An IP interface or gateway supplied and configured by us
- Ready profiles by brand and model — confirmed during a site survey
- BACnet and M-Bus in the same transport model
Frequently asked questions
Does HoumeOS support KNX today?
Honestly: KNX is described in the catalog and the panel provides guides with a real TCP check of the address, but the driver that reads and writes the group addresses on the bus is still to come. We do not present an upcoming integration as available. For a specific building we are ready to write the driver together with your KNX partner, if we have the project of the installation.
What do you need from the KNX installation?
The project of the installation: the list of group addresses with their data, the direction of every signal, the fields and scales in use, and a description of the interface to the local network. We also need access for a survey, to confirm the device and interface models. Without that documentation the integration is guessing, and that is not how we work.
Do we need a cloud account or the manufacturer app?
No. HoumeOS is local: a server in your network, an HTTP+SSE facade and the home/v1 contract. Commands and states never leave the LAN, and when the internet drops the rules and schedules keep running. For KNX the goal is the same — the bus stays local, and the interface points at our server.
What does control look like after the integration?
Like any other device in the system: name, room, rights, state and history. Blinds and lights arriving over KNX take part in the same scenes and modes as the climate, the boiler and the irrigation. On the wall panel there are not seven apps — there is one interface that knows which device comes from which transport.
How long does a KNX integration take?
The work goes in stages, not in promises about days. First a survey and the project of the installation, then the list of the group addresses you need, then the driver and an on-site check with the real interface. Every stage ends with a visible result inside the system, which is why we do not say "ready" until a device has changed state from the kiosk.
We show the system on a live screen
The demo starts from your question: which devices, which protocols, which scenarios.