Docs menu
Building protocols compared.
Reference for the discovery, control, and orchestration protocols found in building portfolios: what each was designed for, how devices are discovered, and how they compare on transport, security, and scale.
Landscape reference, not a support matrix.
This page explains protocols you will encounter in a building portfolio so integration decisions can be made with the tradeoffs visible. It does not describe which protocols CMS Buildings connects to.
- For shipped connector support, see API & Connection Nodes — that page is the authority
- Protocols documented here may be reached today through a gateway or edge normalization layer rather than a native node
- Standards status is stated per protocol so ratified standards and emerging approaches are never conflated
Feature comparison across five protocols.
The dimensions that drive architecture decisions: what the protocol is for, how discovery works, how data is modeled, and where it runs out of headroom.
This table describes the industry protocol landscape — it is not a list of protocols CMS Buildings connects to. For what the platform supports today, see API & Connection Nodes.
| Feature | SRP / DNS-SD | CNS/CP | BACnet | Modbus | Thread |
|---|---|---|---|---|---|
| Primary use case | Service discovery & naming | Secure system orchestration | Building automation control | Simple data acquisition | Low-power wireless mesh |
| Discovery model | Unicast DNS Update (dynamic) | Connection Profiles (context) | Who-Is / I-Am broadcast, or DNS-SD | None — manual configuration | SRP / DNS-SD native |
| Data model | DNS records (PTR, SRV, TXT) | Named profiles & metadata | Object-oriented (analog / binary) | Flat registers (coils / holding) | IPv6 packets |
| Transport | UDP / TCP (DNS) | Agnostic (overlay) | UDP/IP, RS-485, Ethernet | TCP/IP, RS-485, RTU | IEEE 802.15.4 (6LoWPAN) |
| Security | DTLS / SIG(0) | Built-in secure profiles | BACnet/SC (TLS 1.3) | None native — relies on network | DTLS / network layer |
| Scalability | High (DNS hierarchy) | Very high (federated) | Medium (broadcast limits) | Low (bus limits) | High (mesh) |
| Standards status | RFC 9665 (IETF) | Emerging — not standards-body ratified | ISO 16484-5 | De facto industry standard | IEEE 802.15.4 / Thread Group |
BACnet.
The dominant global standard for building automation and control (ISO 16484-5), connecting HVAC, lighting, fire, and security systems.
- Object-oriented data model — every device exposes standardized objects such as Analog Input and Binary Output, each with defined properties
- Discovery uses a built-in Who-Is / I-Am broadcast service scoped to the local subnet
- Core transport is UDP broadcast on port 47808, or master-slave token passing (MS/TP) over RS-485
- BACnet/IT profiles explicitly integrate DNS-SD for resolution across larger routed networks
- BACnet/SC (Secure Connect) adds TLS 1.3, addressing the historic lack of transport security
BACnet's strength is semantics: it defines what a device means, not just what bytes it emits. Its constraint is that the semantics stop at the BACnet network boundary, and its broadcast-based discovery scales poorly across large routed or wireless networks.
Modbus.
The most widely deployed protocol for simple industrial devices — meters, variable-frequency drives, and sensors — owing almost entirely to its simplicity.
- Master-slave architecture over a flat register map of holding registers and coils
- No native service discovery of any kind — addresses and register maps are configured by hand, per device
- Runs over TCP/IP, RS-485, and RTU serial framing
- No native security; confidentiality and integrity depend entirely on the surrounding network
Modbus is a data transport mechanism rather than a semantic model: a register number carries no inherent meaning. In modern architectures Modbus devices are typically fronted by a gateway that republishes their data with richer context.
KNX and DALI.
Specialized standards for lighting and shading control. KNX (ISO/IEC 14543) uses a decentralized peer-to-peer topology over twisted pair or IP; DALI addresses digital lighting control loops.
- Both require substantial commissioning effort to assign addresses and build group associations
- KNX telegrams are meaningful only to KNX-aware devices and tooling
- Highly capable within lighting and shading; effectively siloed outside it
- Integration with other building systems has traditionally required a bespoke gateway
The integration gap here is structural rather than technical. A capability boundary — a lighting system exposing what it can do without exposing how it does it — is what allows a security system to consume lighting state without parsing KNX telegrams.
Thread.
A low-power wireless mesh built on IEEE 802.15.4 and 6LoWPAN that bridges constrained sensors and IP networks without a proprietary hub.
- Devices are IPv6-addressable end to end — no protocol translation at a vendor bridge
- Mesh topology gives resilience and range without mains power at every node
- SRP and DNS-SD are natively supported, so devices advertise services onto the building network directly
- Security is handled at the network layer and with DTLS
Thread is the reason the field layer is changing: it makes self-registering, battery-powered sensors practical at portfolio scale. See Service Discovery for how SRP registration actually works.