KNX to BMS Integration: OPC UA, BACnet and KNXnet/IP Gateways
Commercial buildings above 5,000 m² require a building management system to provide centralised monitoring, alarming and reporting across KNX, HVAC, energy and fire alarm subsystems. Choosing the right integration path between KNX and the BMS determines reliability, data richness, and long-term maintainability of the facility.
Why BMS integration matters for commercial buildings
In commercial buildings above approximately 5,000 m², the facility management (FM) team cannot efficiently operate separate control systems for KNX building automation, HVAC BACnet controllers, energy Modbus meters, fire alarm panels, and access control. Each subsystem has its own software interface, alarm log, and engineering tool — meaning faults go unnoticed across system boundaries, energy waste is invisible, and maintenance scheduling is fragmented.
A building management system (BMS) provides a single pane of glass for the FM team: one software interface showing live values from all subsystems, unified alarm management with escalation, centralised trend logging for energy reports, and a single work order workflow for maintenance. Connecting KNX to the BMS is therefore a fundamental part of any serious commercial KNX installation.
Typical BMS integration scope for a 10,000 m² commercial office
- 300–800 KNX points: energy meters, HVAC temperatures, occupancy, equipment status, alarms
- HVAC BACnet/IP: AHU and FCU controllers, chiller plant, BMS-to-controller setpoint writes
- Energy Modbus: MID-certified sub-meters per distribution board
- Fire alarm dry contacts: EN 54-2 panel output to KNX binary input, then to BMS Priority 1 alarm
- Access control OPC DA: door status and forced-entry alarms integrated into BMS alarm log
Integration paths overview
Four principal integration paths exist for connecting KNX to a BMS, each with different hardware requirements, configuration effort, and suitability for different BMS platforms:
| Path | Hardware | BMS requirement | Best for |
|---|---|---|---|
| Direct KNXnet/IP | KNX IP router (Weinzierl 770, MDT) | Native KNX driver in BMS | BMS with built-in KNXnet/IP support |
| BACnet/IP gateway | Intesis IN701KNX300000, LOYTEC LKNX-100 | Any BACnet/IP client | Honeywell Niagara N4, Schneider EcoStruxure |
| OPC UA gateway | Lingg & Janke KNX Virtual, HMS Anybus | OPC UA client | Modern BMS platforms, Siemens Desigo CC |
| Modbus TCP bridge | Weinzierl KNX ENO 634 | Modbus TCP master | SCADA systems with strong Modbus support |
KNXnet/IP tunnelling direct to BMS
Where the BMS software includes a native KNX driver — such as Siemens Desigo CC with the KNX plugin or specific Honeywell configurations — the BMS server connects directly to the KNX network as a KNXnet/IP tunnelling client. A KNX IP router (Weinzierl 770 or MDT KNX IP Router) installed on the KNX TP network acts as the gateway between the LAN and the KNX twisted-pair bus.
The BMS server establishes a tunnelling connection to the KNX IP router on UDP port 3671. The BMS can then send read requests to any KNX group address and receive unsolicited updates (write telegrams) from KNX devices. The KNX IP router multicast group 224.0.23.12 carries all KNX group address traffic on the LAN segment — BMS platforms can optionally join this multicast group to receive all telegrams without explicit polling.
KNXnet/IP tunnelling connection limits
Max simultaneous tunnelling connections per KNX IP router: 4
Each BMS driver instance = 1 tunnelling connection
ETS6 commissioning software = 1 additional connection
For large projects with high telegram traffic:
Use KNXnet/IP routing (BMS as routing participant)
Routing: unlimited participants, multicast-based
Requires BMS to support KNXnet/IP routing mode
Weinzierl 770 supports both tunnelling (4 connections)
and routing mode — select routing for >1,000 GAs
Multiple KNX areas: large buildings with multiple KNX areas (e.g. one TP line per floor) each require their own KNX IP router. The BMS connects a separate driver instance to each KNX IP router. All KNX IP routers should be on a dedicated BMS VLAN, isolated from general office LAN traffic, with multicast properly configured on managed switches (IGMP snooping enabled).
OPC UA gateway integration
OPC UA (IEC 62541) is the preferred modern integration standard for building automation. An OPC UA gateway reads KNX group address values and exposes them as structured OPC UA nodes that any OPC UA client — including all major BMS platforms — can subscribe to.
Lingg and Janke KNX Virtual is a software OPC UA server that runs on Windows or Linux. It imports the ETS6 project file directly, creating a structured OPC UA node for each group address with the correct data type, unit (from DPT EU definition), and description. The free tier supports up to 50 group addresses; beyond that a per-point license applies. The BMS connects as an OPC UA client on the default endpoint opc.tcp://[host]:4840.
OPC UA advantages over BACnet/IP
- Structured address space: nodes carry DPT type, engineering unit, description
- Subscription-based: BMS receives change notifications, no polling overhead
- X.509 certificate security: mutual authentication between client and server
- Vendor-neutral: any OPC UA client works, no proprietary driver needed
- Namespaces: multiple KNX areas organised in logical folder hierarchy
HMS Anybus Communicator KNX
DIN-rail hardware OPC UA gateway — no PC server required. Connects to KNX TP via KNX connector, publishes OPC UA server on Ethernet port. Configured via web browser: upload ETS6 group address CSV, assign OPC UA node names. Suitable for sites where running a dedicated server PC is impractical. Supports up to 512 KNX group addresses.
BACnet/IP gateway configuration
The Intesis IN701KNX300000 is a DIN-rail BACnet/IP to KNX gateway supporting up to 3,000 KNX group addresses mapped to BACnet objects. Configuration is performed via the Intesis MAPS software: import the ETS6 group address CSV export, assign each GA to a BACnet object type (Analog Value, Binary Value, Analog Input) and instance number, then set the BACnet device ID and IP address.
The BMS reads BACnet objects via BACnet/IP on UDP port 47808, the standard BACnet port. All major BACnet-capable BMS platforms support this: Honeywell Niagara N4 (Fox connector), Siemens Desigo PX (field controller with BACnet/IP module), and Schneider EcoStruxure Building Operation. The LOYTEC LKNX-100 is an alternative gateway with built-in web server for live diagnostics and supports KNXnet/IP routing alongside BACnet/IP for large installations.
BACnet alarm configuration for KNX binary points
KNX binary GA (DPT 1.001) mapped to BACnet Binary Value object
Example: GA 2/5/0 "Fire_Alarm_Zone_1" → BV instance 250
In Intesis MAPS: enable Intrinsic Alarming on BV object
Alarm value: ACTIVE (present-value = 1)
Notification Class: 1 (Priority 1 in BMS)
To-Offnormal delay: 0s (immediate)
To-Normal delay: 5s (debounce)
BMS subscribes to COV (change of value) on the BV object
Alarm appears in BMS alarm log with timestamp, priority,
acknowledge status and escalation rules
Data point selection strategy
Not all KNX group addresses should be integrated into the BMS. Bringing every GA into the BMS wastes point licenses, fills trend databases with irrelevant data, and creates alarm floods from points the FM team cannot act on. A structured tier approach ensures the BMS contains only operationally meaningful data.
| Tier | Point types | BMS action |
|---|---|---|
| Tier 1 — Mandatory | Energy meter power (kW) and kWh, HVAC setpoint and actual temperatures, occupancy status, equipment run status, alarm inputs (fire, SPD fault, UPS fault) | Trend log, alarm, report |
| Tier 2 — Operational | Lighting zone on/off status, blind position (0–100%), fan speed status, door open/close (monitored doors only) | Trend log, no alarm |
| Tier 3 — Exclude | Individual button press GAs, scene activation GAs, KNX internal logic flags, commissioning diagnostic GAs | Do not import to BMS |
Typical point count for a 5,000 m² commercial office: 300–800 Tier 1 and Tier 2 points. Tier 3 (button presses, scenes) typically represents 3–5 times more group addresses in ETS6 but contributes zero operational value in the BMS. Filtering at ETS6 export stage — using ETS6 group address naming conventions and export filters — prevents Tier 3 GAs from entering the BMS import file.
ETS6 export workflow for BMS import
ETS6 provides a structured group address export that allows BMS engineers and gateway configuration tools to import hundreds of data points without manual entry. The export is accessed from ETS6 via File — Export — Group Addresses, with output options of CSV (for gateway tools) or OPC DA XML (for Siemens Desigo CC OPS module import).
The CSV export includes for each group address: the address (e.g. 5/3/1), the DPT type (e.g. 9.001 for 2-byte float in degrees Celsius), the name, and the description field. The Intesis MAPS gateway configuration tool accepts this CSV directly — selecting the relevant rows and assigning BACnet object types takes minutes rather than hours of manual entry for 500 points.
ETS6 naming discipline is essential for BMS import quality
The ETS6 group address name becomes the BMS point name. Cryptic names like "GA_001" or "Obj_KNX_5_3_1" create unmanageable BMS databases. Use a consistent naming convention from commissioning: "Floor2_Office3_Temp_Setpoint_degC" or "DB3_HVAC_AHU1_RunStatus". Good ETS6 naming practice during commissioning eliminates BMS rename work that can take several days on a large project.
Alarm routing from KNX to BMS
KNX binary group addresses (DPT 1.001) connected to physical alarm inputs — fire alarm dry contacts, SPD fault outputs, UPS fault relays, door forced-open contacts — are mapped to BMS alarm points. The BMS alarm management engine classifies alarms by priority, routes notifications to the correct personnel, enforces acknowledgement workflow, and maintains an auditable alarm log.
EN 54-2 fire alarm integration path
EN 54-2 fire alarm panel dry contact output
→ KNX binary input module (MDT SCN-B8230.02)
→ KNX GA 1/9/0 "Fire_Alarm_Zone_1" (DPT 1.001)
→ BACnet/IP gateway Binary Value object BV-900
→ BMS alarm: Priority 1, mandatory acknowledge
→ BMS action: audible alert, email FM duty manager
→ BMS log: fire log (separate from general alarm log)
Acknowledgement: engineer logs in to BMS on site
Reads alarm, verifies zone, acknowledges with reason
Fire log entry retained for 5 years (EN 54-2 requirement)
Trend logging and energy data retention
The BMS stores KNX point values as time-series data in a SQL Server database. Retention periods and logging intervals are configured per point type, balancing data resolution against storage requirements and report usefulness.
Energy data (kW, kWh)
- Interval: 15 minutes (96 records per day per point)
- Retention: 5 years minimum (ISO 50001 requirement)
- Deadband: 0.1 kW to prevent log flooding on stable loads
- Reports: daily, monthly, annual energy by circuit
- Export: CSV for utility bill verification and ISO 50001 review
Temperature and HVAC data
- Interval: 5 minutes (288 records per day per point)
- Retention: 90 days rolling
- Deadband: 0.2°C to ignore sensor noise
- Use: comfort complaints investigation, HVAC fault diagnosis
- HVAC runtime hours: derived from run status binary trend
Need KNX panels ready for BMS integration?
We build KNX panels with BACnet/IP and OPC UA gateways pre-configured, ETS6 exports prepared for BMS import, and KNXnet/IP routing set up for large multi-area installations — delivered with full as-built documentation.
Request a quote →