Four protocols. One platform. Zero translation layer.

Buildings do not run on a single protocol, and pretending they do is how integration budgets disappear. xSERVA is being designed to speak BACnet, KNX, MQTT, and Modbus through first-party drivers, so that every device on site — regardless of how it talks — lands in the same dashboard, the same alarm queue, and the same energy model.

Status: the protocol integration module is on the roadmap and is not available in the product today. What ships now is xSERVA access control. Everything below describes design intent, and is written in that register throughout.

Book a Demo
A small on-premises server cabinet in a building plant area, two rack-mounted units with status lights and cable management arms, the cabinet door ajar.
Where the protocol layer is designed to terminate, on the local network.
An extreme macro view of a field bus terminal strip, twisted-pair conductors landed under screw terminals with shield drains twisted neatly and a crimped ferrule catching the light.
Interoperability is decided here, at the terminal, long before it becomes a bullet on a datasheet.

Why interoperability matters

A modern commercial building typically layers HVAC controllers speaking BACnet, lighting and blinds wired for KNX, a growing fleet of MQTT-connected sensors, and legacy meters or generators still running Modbus. Historically, unifying that mix meant stacking a separate head-end for each protocol, then bolting on custom middleware just so the systems could exchange a single data point. Every bridge added a point of failure, every vendor added a support contract, and every renovation meant re-engineering the handoffs again.

The xSERVA design removes the translation layer entirely. Instead of treating BACnet, KNX, MQTT, and Modbus as four separate integrations bolted together after the fact, the platform is designed to normalize all four into one internal data model at the point of ingestion. A BACnet air-handling unit, a KNX lighting scene, an MQTT temperature sensor, and a Modbus energy meter all resolve to the same kind of point object inside xSERVA — which means monitoring, alarming, scheduling, energy analysis, and AI-driven insight all run against a single consistent dataset, not four disconnected ones. For system integrators this means faster commissioning and fewer support escalations. For building owners it means one login, one contract, and one system to audit instead of four.

Critically, the target is native support, not a superficial pass-through gateway. The design addresses each protocol at its own depth: BACnet is addressed at the object and property level, not just as a coarse point count; KNX is addressed at the group-address and datapoint-type (DPT) level, preserving the semantics of every lighting and blind actuator; MQTT is addressed at the topic and payload level, including nested and wildcard subscriptions; and Modbus is addressed at the individual register level, with correct data typing per device. A gateway that merely forwards raw values loses that depth and pushes the translation problem downstream to whoever configures the dashboard. Keeping the protocol-native detail intact all the way through the platform is what would make cross-protocol rules, alarms, and reporting trustworthy rather than approximate.

A building section showing which protocol governs which part: BACnet on plant room chillers, air handlers and controllers; KNX on floor-level lighting, blinds and room control; MQTT on the retrofitted sensor overlay for occupancy, CO2 and humidity; and Modbus on the basement incomer, submeters and generator. Each connects into xSERVA by native driver, with no gateway and no middleware in between, so one rule can span all four, a KNX occupancy state can drive a Modbus VFD, and each protocol keeps its own security model.
Design intent: each protocol addressed at its own depth rather than flattened by a pass-through gateway. Protocol integration is a roadmap module.

Explore each protocol

BACnet

The dominant standard for commercial HVAC, controllers, and building-wide device communication, with BACnet/IP, MS/TP, and BACnet/SC support inside xSERVA.

KNX

The dominant standard for lighting, blinds, and room-level automation wiring, with decentralized topology and ETS project import supported inside xSERVA.

MQTT

The dominant standard for lightweight sensor, IoT, and edge-device telemetry, with broker-based publish/subscribe messaging supported inside xSERVA.

Modbus

The dominant standard for meters, generators, and industrial equipment interfacing, with both Modbus TCP and Modbus RTU supported inside xSERVA.
Data Model

The same 18.4 °C, written four ways

This is the claim the whole platform rests on, so it is worth drawing rather than asserting. Four protocols describe one sensor reading in four incompatible vocabularies. Every capability above the driver layer — alarming, trending, the rule engine, the energy model, the API — reads the normalised object instead, which is what lets one rule span a KNX occupancy state and a Modbus drive, and why adding a fifth protocol later is a driver rather than a rewrite.

Four native addresses for the same 18.4 degrees C: a BACnet analog-input 3 present-value, a KNX group address 2/1/7 carrying datapoint type 9.001, a Modbus holding register 40031 typed float32 with word order CDAB, and an MQTT topic with a JSON payload. Each passes through its own first-party driver and resolves into one internal point object carrying a stable id, a human name, unit, type, site path, quality flag and the original source address. Notes explain that the native address is kept rather than discarded so a value can be traced back, and that reading that Modbus register as int16 yields 4819 instead of 18.4, which is why typing is per device.
Normalising is not flattening. The native address survives, which is what makes any later question about provenance answerable.

Four is the short list, not the whole landscape

BACnet, KNX, MQTT and Modbus cover most of what a commercial building actually runs, which is why they get their own pages here. They are not the whole picture. There are well over a hundred communication standards in active service across building control, metering, IoT, industrial plant, security and networking — DALI-2 and D4i on lighting, M-Bus and DLMS/COSEM on meters, OPC UA where there is industrial plant behind the building, Matter, Thread and Zigbee on the device side, ONVIF and OSDP on video and access, OCPP wherever there is EV charging.

Just as important is what is not a protocol choice at all. RS-485, Ethernet, Wi-Fi, TCP, IP and TLS are layers that the protocols above run on top of — Modbus RTU runs over RS-485, Modbus TCP runs over TCP/IP/Ethernet, and both are the same Modbus register model. A specification that asks a vendor to choose between Modbus and RS-485 is asking a question with no answer, and it is a question that gets asked often.

See the full protocol landscape, grouped by layer, with xSERVA’s status stated on every row →

Not sure which protocol matters most for your building?

See how BACnet, KNX, MQTT, and Modbus stack up against each other on topology, transport, security model, and the persona each one best fits.

Compare all four protocols →

Frequently asked questions

Does xSERVA support BACnet, KNX, MQTT, and Modbus today?

Not yet. Protocol integration is a roadmap module and is not available in the product today; what ships now is xSERVA access control. The design is for all four to be addressed by first-party drivers rather than a third-party bridging product, reached through an on-premise xSERVA Edge Gateway that keeps plant protocols on the local network. Ask us for the current status before writing protocol support into a specification.

Will xSERVA manage a building that mixes protocols, like BACnet HVAC and KNX lighting?

That is the scenario the protocol layer is being designed for: BACnet controllers, KNX lighting and blinds, MQTT sensors, and Modbus meters resolving into one data model instead of four. It is design intent, not a capability you can deploy today.

Will MQTT and Modbus devices need separate software licenses?

The intent is no — protocol support is planned as part of the core platform rather than as separately licensed add-ons, so adding MQTT sensor fleets or Modbus meters would not mean another license or another application. Commercial terms are settled per project, so confirm this with us rather than assuming it.

How do I compare BACnet, KNX, MQTT, and Modbus side by side?

See the full protocol comparison table, which lines up topology, transport, typical use case, security model, and best-fit persona for all four protocols in one view. That comparison describes the protocols themselves, which is useful regardless of which platform you deploy.

See the full FAQ →