If you manage a facility that has been around for more than ten years, there is a near-certainty that it contains equipment communicating over at least three different protocols. Your HVAC contractor specified BACnet when they commissioned the building automation system. The electrician who wired the panel meters used Modbus. The lighting controls vendor installed Zigbee sensors last year when you upgraded the fixtures. None of them consulted each other.
Protocol fragmentation is not a failure of planning — it is the natural outcome of a market where different system categories standardized independently, decades apart. Understanding the protocols your building actually uses is the foundation for any unified monitoring strategy. This guide covers the four protocols we encounter most often in mid-market facility deployments, explained for a facilities audience rather than a software engineering one.
BACnet: The Language of Building Automation
BACnet stands for Building Automation and Control Networks. It was developed by ASHRAE (the American Society of Heating, Refrigerating and Air-Conditioning Engineers) and published as a standard in 1995, with subsequent revisions through the 2010s. It is the dominant protocol in commercial HVAC, chillers, air handlers, and building management systems (BMS). If your facility has a dedicated building automation system, it almost certainly uses BACnet at its core.
BACnet's central concept is the "object." Every piece of equipment or control point in a BACnet system is represented as an object with a standard set of properties. A temperature sensor is an Analog Input object with a Present Value property. A damper actuator is a Binary Output object. A schedule that controls when a zone is occupied is a Schedule object. This standardized data model is what makes BACnet useful: any BACnet-compliant device from any vendor uses the same object types and property names, so a building automation workstation from one manufacturer can read data from a controller from another manufacturer.
In practice, BACnet interoperability is imperfect. Vendors implement required features correctly but add proprietary extensions that only their own software can access. The "core" BACnet data is interoperable; the advanced diagnostic data that vendor-specific dashboards show is not. This is one reason why even BACnet-heavy facilities end up with multiple dashboards: the core status data is accessible, but the rich diagnostic and configuration data requires the vendor's proprietary client.
BACnet in your facility: Look for it on HVAC equipment, VAV boxes, AHUs, chillers, cooling towers, and any dedicated BMS controller. Most commercial BAS equipment installed after 2000 supports BACnet/IP (BACnet over Ethernet/TCP) in addition to or instead of the older BACnet MS/TP (RS-485 serial).
Modbus: The Industrial Workhorse
Modbus predates BACnet by nearly two decades. It was developed by Modicon (now Schneider Electric) in 1979 for communicating with programmable logic controllers (PLCs). Forty-five years later, Modbus is still one of the most widely deployed industrial communication protocols in the world — largely because it is simple, robust, and license-free.
Unlike BACnet's rich object model, Modbus is deliberately minimal. It defines a small set of function codes for reading and writing data in four register tables: coils (binary outputs), discrete inputs (binary inputs), holding registers (read/write 16-bit values), and input registers (read-only 16-bit values). Everything a device knows about itself — temperature readings, motor speed, power consumption, fault codes — is mapped to one of these register addresses. Reading a Modbus device means knowing which register address holds which value, which requires the device's register map documentation.
This simplicity is both Modbus's strength and its limitation. Strength: any microcontroller with a serial port can implement Modbus; deployment cost is extremely low. Limitation: Modbus has no built-in device discovery, no standard naming conventions, and no self-description. You cannot plug a Modbus device into a network and ask it what it is — you need its documentation to know what its register addresses mean.
Modbus in your facility: Power meters, energy monitoring equipment, pump controllers, compressor drives, conveyor motor controllers, and many HVAC components use Modbus RTU (serial RS-485) or Modbus TCP (over Ethernet). Any equipment installed before 2010 with a serial port on the back panel is very likely running Modbus RTU. Modbus TCP runs on standard Ethernet infrastructure.
Zigbee: Wireless Sensing for Buildings
Zigbee is a wireless mesh protocol built on the IEEE 802.15.4 radio standard. It was designed specifically for low-power wireless sensor networks: devices that run on batteries for months or years, transmit small amounts of data infrequently, and form a self-organizing mesh that extends range beyond what a single radio could cover. The Zigbee Alliance (now the Connectivity Standards Alliance) manages the protocol specification.
Zigbee operates in the 2.4 GHz band (standard across North American deployments), with regional variations at 868 MHz and 915 MHz used in other markets. A Zigbee network has three device roles: coordinator (one per network, manages network formation), routers (mains-powered devices that relay traffic for other devices), and end devices (typically battery-powered sensors that sleep between readings). The mesh topology is inherent to Zigbee's design — routers automatically relay traffic for nearby end devices, extending the network's effective range through multi-hop routing.
Zigbee's application profiles — Zigbee Home Automation, Zigbee Building Automation, Zigbee 3.0 — define standard device types (temperature sensor, thermostat, occupancy sensor, light switch) so that devices from different manufacturers can interoperate within the same network. This interoperability is better than BACnet's in practice, largely because the application profiles are more narrowly scoped.
Zigbee in your facility: Wireless temperature and humidity sensors, occupancy sensors, lighting controls, and smart thermostats commonly use Zigbee. If your lighting control system was installed in the last decade, it likely has Zigbee sensors at the switch or fixture level. Battery-powered sensors throughout the building that report wirelessly are almost certainly either Zigbee or Z-Wave.
LoRaWAN: Long-Range, Low-Power for Large Facilities
LoRaWAN is the protocol layer on top of LoRa (Long Range) radio modulation. Where Zigbee optimizes for short-range mesh (individual hops of 10–30 meters indoors), LoRaWAN is designed for long-range point-to-multipoint: individual sensors can communicate directly with a LoRaWAN gateway at distances of 1–5 km in open terrain, or 100–500 meters in a building with concrete and steel structure. That range changes the deployment math considerably for large warehouses and multi-building campuses.
LoRaWAN operates in unlicensed sub-GHz bands (915 MHz in North America, 868 MHz in Europe), which gives it better wall and obstacle penetration than 2.4 GHz Zigbee. The trade-off is data rate: LoRaWAN supports very low data rates (250 bps to 50 kbps depending on spreading factor), which limits it to infrequent, small-payload sensor readings. It is well-suited for cold-chain temperature monitoring, water leak detection, and asset tracking — any application where you need wide area coverage, battery operation, and small, infrequent data packets.
LoRaWAN in your facility: Cold-chain temperature monitoring across large warehouse footprints, outdoor parking or perimeter sensors, water leak detection in hard-to-reach areas, and any sensor application that requires coverage through multiple concrete walls or across outdoor distances.
Protocol Comparison: A Practical Reference
| Protocol | Typical use case | Physical layer | Range (indoors) | Data rate | Self-describing? |
|---|---|---|---|---|---|
| BACnet/IP | HVAC, BAS, AHUs | Ethernet / TCP/IP | Unlimited (IP network) | High | Partially |
| Modbus RTU | Power meters, PLCs, drives | RS-485 serial | Up to 1,200 m (wire) | Low-medium | No |
| Modbus TCP | Power meters, industrial I/O | Ethernet / TCP/IP | Unlimited (IP network) | Medium | No |
| Zigbee 3.0 | Wireless sensors, lighting | 802.15.4 (2.4 GHz) | 10–30 m per hop | Low-medium | Yes (profiles) |
| LoRaWAN | Cold chain, outdoor sensors | LoRa sub-GHz | 100–500 m | Very low | Partially |
The Integration Layer Problem
Understanding each protocol individually is useful. The harder operational question is: how do you get data from all of them into a single place where you can actually use it?
This is where facility IoT projects typically stall. Each protocol requires a different integration adapter. BACnet needs a BACnet/IP stack and an understanding of the object model. Modbus needs the register map for each device (which is different for every manufacturer). Zigbee needs a Zigbee coordinator that can enumerate devices and subscribe to their data. LoRaWAN needs a LoRaWAN network server and device provisioning.
Building custom integrations for each protocol is technically feasible — it is also the reason that mid-market facilities typically spend 6–12 months and $60,000–$200,000 on integration projects before they get a unified dashboard. The integration layer is not a software feature you can download; it is an engineering project that requires protocol expertise across all four domains simultaneously.
The alternative architecture is a protocol bridge that ships pre-built support for all four protocols in hardware form. A gateway node with native BACnet, Modbus, Zigbee, and LoRaWAN interfaces does not require a custom integration project for each system. It requires installation and configuration — which still takes time and expertise, but measured in hours rather than months. That is the fundamental design decision behind how we built Meshkindle's hardware layer, and it is why protocol fluency in hardware is the prerequisite for unified facility monitoring that actually gets deployed in practice.
The integration problem is not that the protocols are incompatible in principle — it is that nobody has done the work of bridging them in one place, at the facility level, before the data leaves the building. That is the work the mesh gateway layer exists to do.
If you are planning a facility IoT deployment and want to understand which protocols your existing equipment uses before specifying a gateway, the most practical approach is to pull the installation manuals for your HVAC controllers, panel meters, and lighting controllers. Look for the "communications" or "connectivity" section. The protocol name will be listed there along with the physical interface (RS-485, Ethernet, or wireless). That audit will tell you exactly what your protocol bridge needs to support — and whether you need all four or just two or three.
