KNX vs Wirenboard: European Standard vs Open-Source Linux Controller
KNX is a distributed, controller-free bus protocol standardised across Europe. Wirenboard is a centralised Debian Linux controller with an RS-485 Modbus backbone, MQTT broker, and JavaScript rule engine. The two systems represent fundamentally different philosophies — and in many projects, the right answer is to deploy both.
Core philosophy
KNX is designed around intelligence at the edge. Each device — actuator, sensor, push-button — runs its own firmware and communicates directly with other devices via group address telegrams on the 2-wire TP bus. No controller is needed to keep the lights on. Removing or replacing a KNX router or programming PC has no effect on device operation.
Wirenboard is the opposite: intelligence is centralised in a DIN-rail Linux computer (WB-MAP or WB-7xx series) running Debian GNU/Linux. Field devices — relay boards, analogue I/O, 1-Wire temperature sensors — are dumb Modbus RTU slaves connected over RS-485. All automation logic runs as JavaScript rules (wb-rules engine) or Node-RED flows on the central controller. If the controller fails, all automation stops.
KNX philosophy
- Distributed — intelligence at every device
- No central controller or server
- Open standard, ISO/IEC 14543-3
- Deterministic telegram delivery on TP bus
- ETS6 offline commissioning tool
- 500+ hardware manufacturers worldwide
Wirenboard philosophy
- Centralised — all logic on Linux controller
- Dumb Modbus RTU field devices
- Open hardware, open source software
- MQTT broker as internal message bus
- wb-rules JavaScript engine + Node-RED
- Wirenboard (Moscow) — Eastern European market
Hardware ecosystem
KNX field devices connect to a shared 2-wire bus. The ecosystem spans lighting actuators, blind actuators, fan-coil controllers, push-button interfaces, room thermostats, DALI gateways and energy meters from 500+ certified manufacturers. Device selection is competitive — any MDT, ABB, Gira, Theben, Jung, or Schneider device can replace any other without rewiring.
Wirenboard field devices are typically Wirenboard-branded DIN-rail Modbus RTU modules (WB-MR6C relay boards, WB-MAO analogue outputs, WB-MIO digital I/O, WB-MSW multi-sensor units) connected over RS-485 at 9,600 or 115,200 baud. Any third-party Modbus RTU device — industrial inverters, energy meters, HVAC controllers — can be added with a custom Modbus template.
| Device type | KNX | Wirenboard |
|---|---|---|
| Relay / switching actuator | MDT AKU, ABB SA/S, Theben RM — DIN-rail, 4–16ch | WB-MR6C, WB-MR14 — Modbus RTU, 6–14ch relay |
| Dimming actuator | MDT AKD, ABB DG/S, Schneider MTN — DALI/1-10V/phase | Not available natively — requires 0-10V or DMX module |
| Blind / shutter actuator | MDT JAL, ABB JA/S, Gira 1039 — 4–8 channel TP | Not available — requires external relay module + logic |
| Room thermostat | MDT SCN-RTR, ABB FCA, Berker S.1 — ETS configured | WB-MSW wall sensor — Modbus, temp + CO2 + humidity |
| Push-button interface | Gira, MDT, Jung, Merten — 2–8 button, bus-powered | WB-MRGBW for LED, no standard keypad equivalent |
| Energy meter | MDT SMI-8-MID, ABB B23 — MID certified, KNX native | WB-MAP12E — 12-channel Modbus MID energy meter |
| 1-Wire / temperature | Not supported on KNX TP natively | Native 1-Wire support — Dallas DS18B20 directly |
Programming approach
KNX is programmed with ETS6. The engineer assigns group addresses to device communication objects — no programming language is required for standard switching, dimming and HVAC control. Complex logic (timer programs, multi-condition scenes, HVAC optimisation) requires an additional logic module (MDT SCN-Logic, Gira HomeServer) or a KNX IP controller.
Wirenboard logic is written as JavaScript in the wb-rules engine (a duktape-based JS interpreter) or built visually in Node-RED. Rules can subscribe to MQTT topics, write Modbus register values, set timers, and call external HTTP APIs. Grafana dashboards visualise historical data from the built-in InfluxDB. Any standard Linux tool — Python scripts, cron jobs, Mosquitto pub/sub — can be used alongside wb-rules.
wb-rules JavaScript example — occupancy-driven HVAC setpoint
// wb-rules: lower setpoint when room unoccupied for 15 min
defineRule("hvac_eco_mode", {
whenChanged: "/devices/wb-msw-v3_22/controls/Motion",
then: function(newValue, devName, cellName) {
if (newValue == 0) {
// No motion — start 15-min countdown
startTimer("eco_timer", 15 * 60 * 1000, function() {
dev["modbus_hvac/setpoint_temp"] = 18; // Eco setpoint
log.info("HVAC: eco mode activated");
});
} else {
// Motion detected — restore comfort setpoint
stopTimer("eco_timer");
dev["modbus_hvac/setpoint_temp"] = 22;
}
}
});Skill lock-in vs vendor lock-in
Wirenboard hardware and software are open source — no vendor licence, no proprietary tool. But the system requires Linux skills to maintain, debug and extend. If the original integrator who wrote the wb-rules JavaScript leaves, finding a replacement requires a developer comfortable with Debian, MQTT, JavaScript and Modbus — a narrower skillset than the global pool of KNX ETS6 integrators.
Protocol coverage
| Protocol | KNX | Wirenboard |
|---|---|---|
| KNX TP | Native — the primary bus | Via KNX TCP gateway (e.g. Weinzierl IP/USB) |
| KNX/IP | Native — KNXnet/IP routing and tunnelling | Via KNX TCP gateway only |
| Modbus RTU (RS-485) | Via KNX-Modbus gateway (Weinzierl, MDT) | Native — RS-485 port, 9,600–115,200 baud |
| Modbus TCP | Via KNX-Modbus TCP gateway | Native — wb-rules Modbus TCP client |
| MQTT | Via KNX IP gateway with MQTT bridge | Native — Mosquitto broker on controller |
| 1-Wire (Dallas) | Not supported natively | Native — direct DS18B20 connection |
| DALI | Native via KNX-DALI gateway (any brand) | Partial — DALI USB dongle available, limited |
| BACnet/IP | Via KNX-BACnet gateway (Intesis, Loytec) | Via third-party BACnet library on Linux |
| HTTP/REST API | Via KNX IP controller (e.g. Gira X1) | Native — wb-rules fetch(), any REST API |
| CAN bus | Not supported | Native CAN interface on WB-MAP12H |
Use case fit by application type
| Application | KNX | Wirenboard | Hybrid |
|---|---|---|---|
| Factory floor I/O monitoring | Poor — few industrial KNX devices | Excellent — native Modbus RTU, RS-485 | N/A |
| Warehouse lighting control | Good — KNX DALI + motion sensors | Fair — requires relay modules + custom logic | KNX lighting + WB energy metering |
| Premium smart apartment | Excellent — full room automation | Fair — limited push-button and dimming | KNX room + WB Modbus HVAC |
| Hotel room automation | Excellent — card reader, FCU, blinds, DALI | Poor — no hotel-specific ecosystem | N/A |
| Hospital building services | Good — DALI emergency, HVAC integration | Fair — Modbus HVAC, REST nurse call | KNX + WB BMS layer |
| Energy sub-metering (multi-tenant) | Good — MID meters with KNX bus | Excellent — WB-MAP12E, Grafana, InfluxDB | KNX room + WB metering dashboard |
| Industrial process control | Poor — not designed for this | Good — Modbus RTU, CAN, 1-Wire | N/A |
| Data centre environment | Poor — no DCIM integration | Good — Modbus sensors, REST/SNMP | N/A |
Hybrid architecture: Wirenboard as BMS + KNX for room automation
The strongest real-world use of both systems is a hybrid: Wirenboard handles building services (HVAC Modbus, energy metering, solar inverter polling, alarm system I/O) while KNX manages room-level automation (lighting actuators, blind actuators, room thermostats, push-buttons, DALI). A KNX TCP/IP gateway bridges both layers — wb-rules can read and write KNX group addresses over KNXnet/IP.
Hybrid topology — residential building with Modbus HVAC and KNX rooms
Wirenboard WB-MAP (Debian Linux, central DIN-rail controller)
│
├── RS-485 Modbus RTU backbone (9,600 baud)
│ ├── WB-MAP12E — 12-channel energy sub-metering
│ ├── Daikin VRV — Modbus adapter BRP069A61
│ ├── SMA Sunny Boy — Modbus TCP solar inverter
│ └── WB-MSW-V3 — CO2 / humidity / temperature sensor
│
├── MQTT broker (Mosquitto) — internal message bus
│ ├── Node-RED — visualisation and REST API flows
│ └── Grafana + InfluxDB — energy dashboards
│
└── KNXnet/IP gateway (Weinzierl 730, UDP 47808)
│ KNX TP bus (9,600 baud, 2-wire)
├── MDT AKU-1616 — 16-channel lighting actuator
├── MDT JAL-0800 — 8-channel blind actuator
├── MDT SCN-RTR — room thermostats (×8)
└── Gira push-button interfaces
wb-rules KNX integration example:
// Read KNX room temperature → publish to MQTT
knxRead("1/0/1", function(value) {
dev["knx_room1/temp"] = value; // → MQTT topic
});
// Write KNX setpoint when Modbus HVAC changes mode
knxWrite("1/0/2", eco_active ? 18.0 : 22.0, "DPT_Value_Temp");What Wirenboard adds to KNX
- Grafana energy dashboards with historical trending
- Modbus HVAC integration without a KNX-Modbus gateway
- REST API and webhook automation (tariff switching, DR events)
- 1-Wire temperature sensors in plant rooms
- CAN bus for industrial equipment
What KNX adds to Wirenboard
- Room-level actuators without custom relay wiring
- DALI lighting control with certified KNX-DALI gateways
- Push-button interfaces with multi-function bus programming
- Hotel card reader and fan-coil unit ecosystem
- Fail-safe operation if Wirenboard controller reboots
Need a hybrid KNX panel for a project with Modbus HVAC?
We design and manufacture KNX distribution panels with KNX-Modbus and KNXnet/IP gateway integration — compatible with Wirenboard, Home Assistant, and BMS platforms. Delivered tested with full commissioning documentation.
Request a quote →