BREMA for KNX MCP4KNX

Firmware that turns the TUL into an MCP server on your LAN, so an agent can commission KNX devices — addresses, tables, parameters — without ETS, knxd or a vendor cloud.

 runs on: TUL

Most KNX gateways relay group telegrams: they talk to devices somebody else configured with ETS. This firmware speaks the connection-oriented management services ETS itself uses. It gives a device its individual address, reads and writes memory and properties, drives the Load State Machines, installs address and association tables, restarts the device so the change takes effect, and hands the result to Home Assistant.

The stick answers MCP over plain HTTP on your LAN — there is nothing to install beside it, no proxy and no cloud account. The tools an agent is offered are generated from the firmware’s own registry, so they cannot drift from what the device can actually do.

It is the KNX incarnation of BREMA (Busware Rule Engine Model Assistant), where what a device means lives as data in the stick’s filesystem rather than compiled into the firmware. The project is documented in the open at github.com/tostmann/BREMA — that repository holds the documentation, not the firmware sources.

Features

• Commissioning, not just relaying — individual address, memory and properties, Load State Machines, address and association tables, device restart, parameter changes.
• A table install is one operation. Opening the load session, writing the table in chunks each verified by read-back, closing it and restarting the device is a single verb execution that nothing can interrupt half-way, and whose close runs even when a write fails. A device left mid-download resolves no group address at all, and a power cycle does not reliably recover it.
• Mutating verbs default to a dry run. The dry run performs every read and withholds only the write, so its report is truthful about whether the real thing would work. Reaching the bus takes an explicit decision.
• Danger classes per verb, reported by the stick itself: read-only, local state, changes a physical device, changes the stick’s own security state.
• Delivery verdicts instead of fire-and-forget — sent, link-acknowledged, application-acknowledged, application error, timeout, no bus.
• Memory writes are allow-listed, never addressed at runtime. A wrong write does not switch the wrong light; it can leave a device needing ETS to recover.
• Reads an installation it did not build — a passive survey of everything it hears, plus an active sweep that finds the devices on a line and reads the identity that maps each to its product file.

Requirements

• A TUL — ESP32-C6 with the NCN5130 TP1 transceiver. The flasher reads the stick and writes the firmware together with a pass issued for that individual device, so this runs on busware TUL hardware only: the KNX pins differ per product, and an image driving the wrong ones would drive somebody’s bus.
• An MCP-capable client. A MQTT broker is optional — everything else works without one.
• For KNX semantics, the manufacturer’s .knxprod product file: it is the only place a ComObject number or a parameter address means anything.

Getting started

Flash it in the browser at install.busware.de/TUL/mcp/ and provision Wi-Fi in the same USB session over Improv — credentials are never compiled in. The stick then serves its own page at http://busware-knx-<id>.local/, showing its addresses, its hardware identity and the ready-made command:

claude mcp add --transport http busware-knx http://busware-knx-<id>.local/mcp

Point an agent at it and describe what you want commissioned.

Documentation

Everything below lives in the BREMA repository:

• BREMA for KNX — what the KNX firmware does and how to get it.
• Orchestrating KNX with an LLM (German) — a real commissioning session end to end, including the wrong turns, which are the more instructive half.
• Der BREMA-Fachartikel (German) — the long-form treatment: architecture, the gated onboarding loop, worked examples on real radio devices, and a reproducible four-model LLM comparison.

Limits

KNX is the first published backend. Zigbee, EnOcean and HomeMatic run on the same engine but are not released — only what has run on real hardware is offered for download.

The ground-truth service that keeps a model from inventing device facts is in use for the radio backends and is not openly available yet. For KNX the equivalent index over the product catalogue is planned; until then the product file stays your input, and the firmware says so rather than inventing the mapping.