Why BACnet/IP Is Still the Right Target
BACnet/IP has been the dominant protocol for building automation system (BAS) integration since ASHRAE formally adopted ANSI/ASHRAE 135-1995. Thirty years later, it still defines how a temperature setpoint gets written from a workstation to a VAV controller, how an energy meter reports demand to a building dashboard, and how a facility engineer pulls a trend log at 2 a.m. to debug why the third-floor AHU is short-cycling. Any wireless mesh deployment that cannot speak BACnet/IP natively is a second-class citizen in that building — it will require a custom middleware tier, and that tier will eventually break.
We designed the MK-GW gateway to present itself as a BACnet/IP device from day one. That means the gateway has its own Device Object, a configurable Device Instance number, and a list of BACnet objects that map directly to the mesh sensor network below it. When the BMS polls the gateway, it sees what looks like a conventional BACnet field panel — not a REST API endpoint that needs translation.
The BACnet Object Model and Sensor Mapping
Every piece of data from a mesh node maps to a BACnet object of the appropriate type. Temperature readings from a Thread-based humidity/temperature node become Analog Input objects. Occupancy state from an mmWave node becomes a Binary Input object. A lighting level setpoint becomes an Analog Output that, when written by the BMS, propagates back down through the mesh to the DALI-2 driver on a BT Mesh luminaire node.
The mapping layer runs on the gateway itself — no external server required. Each object carries the mandatory BACnet properties: Present_Value, Status_Flags, Reliability, Units, and COV_Increment for analog inputs (we default COV_Increment to 0.5 for temperature and 1% for humidity, which keeps polling overhead manageable without missing meaningful changes). The gateway's Device Object registers all child objects with the correct Object_Identifier ranges so the BMS can discover the full point list via a ReadPropertyMultiple request to the Device Object's Object_List property.
BBMD and Subnetting Considerations
BACnet/IP broadcasts — specifically Who-Is and I-Am messages — do not cross IP subnet boundaries by default. In a multi-floor building where the BMS is on a dedicated 192.168.10.0/24 network and IoT devices are on a segregated 192.168.50.0/24, you need a BACnet Broadcast Management Device (BBMD) to forward broadcasts between subnets. Either the existing BMS server can serve as BBMD, or the MK-GW gateway can run a BBMD instance itself — useful when the facility's IT team doesn't want to touch the BMS configuration.
A common commissioning failure we see: the gateway registers correctly on its local subnet, but the BMS on a different VLAN never discovers it because no BBMD is configured and no Foreign Device Table entry is established. The fix is either to configure the gateway's BDT (BBMD Distribution Table) entries to point at the BMS server's BBMD, or to register the gateway as a Foreign Device with the existing BBMD. Both paths work; the choice depends on network ownership policies at the site.
BACnet/SC: The Future State Worth Planning For
BACnet Secure Connect (BACnet/SC), introduced in Addendum bj to ASHRAE 135, replaces UDP broadcast with a WebSocket-based secure transport over TLS 1.3. It eliminates the BBMD dependency entirely — nodes connect to a BACnet/SC Hub and use certificate-based authentication. The MK-GW-1000 gateway ships with TLS 1.3 support and the certificate provisioning infrastructure to support BACnet/SC enrollment when the BMS is upgraded to support it.
We are not saying BACnet/SC is a drop-in replacement for BACnet/IP today. Most installed BMS platforms — including the Niagara-based controllers still common in mid-size commercial buildings — do not yet support BACnet/SC as a controller-side transport. The path forward is a hybrid gateway that can speak both: BACnet/IP for existing infrastructure, BACnet/SC for new installations or upgraded head-end systems. That is what the MK-GW firmware implements.
A Representative Commissioning Scenario
Consider a mid-size office building in the Greater Boston area — eight floors, built in 2003, running a Johnson Controls-style BAS on BACnet/IP over a dedicated VLAN. The existing automation covers AHU control and main chiller loop; it has no occupancy or zone-level temperature sensing. A facility manager wants occupancy-driven HVAC setbacks without replacing the existing BAS or rewiring zones.
The deployment: 48 MK-NODE-TH Thread nodes for zone temperature and humidity, 36 MK-NODE-OCC occupancy nodes, and 3 MK-GW-1000 gateways (one per three floors, with a fourth in warm-standby). Gateway Device Instances are assigned from the facility's existing BACnet Device Instance registry — the BMS vendor had reserved a 100-unit block for future expansion. Each gateway exposes 28 Analog Input objects (temperature and humidity per zone) and 12 Binary Input objects (occupancy per zone). Total point count per gateway: 40 objects.
The BMS poll cycle is set to 30 seconds for temperature and 5-second COV subscription for occupancy state changes — occupancy transitions need to propagate quickly to trigger VAV setback. That COV subscription is handled natively in BACnet/IP without requiring a proprietary driver on the BMS side. The commissioning engineer on the BMS side simply added the gateway's Device Instance to the BMS point scan list; the BAS treated the gateway identically to a wired field controller.
Points Mapping and Naming Conventions
BACnet object naming is where integrations get messy. Most BMS platforms display Object_Name strings directly in the operator workstation, so a name like AI-003 is useless to a facility engineer troubleshooting at midnight. The gateway lets you configure human-readable Object_Names during commissioning — either through the MeshOS dashboard's bulk-import CSV (which maps mesh node UUIDs to BACnet object names and floor/zone tags) or via a BACnet WriteProperty to the Object_Name property itself.
Our naming convention recommendation: <floor>-<zone>-<function>, for example F03-Z07-TEMP for third-floor zone seven temperature. That format fits within the 63-character BACnet string limit and sorts cleanly in workstation point browsers. Avoid embedding unit strings in the name — use the Units property for that, and set it correctly (degrees Celsius vs Fahrenheit matters when a BMS trend report calculates degree-day totals for energy reporting).
Polling Intervals and BMS Load
One integration failure mode that is easy to overlook: overwhelming the BMS polling engine by presenting too many points on a short poll cycle. A BMS with 20,000 existing points and a 30-second poll cycle is already managing a significant transaction load. Adding 500 new BACnet objects from mesh sensors at a 5-second poll cycle will stress the BMS polling scheduler and may cause scan overruns — where the poll cycle completes slower than the configured interval, causing stale data in the operator workstation.
The practical mitigation: use COV subscriptions for state-change-critical points (occupancy binary inputs, alarm conditions), and use longer poll intervals — 60 to 300 seconds — for slowly-changing analog values like ambient temperature or humidity. Most zone temperature data does not need 30-second resolution for HVAC setback logic; the VAV controller's own 10-second control loop is the binding constraint, not the BMS trend log. Reserve short intervals for points that drive real-time control decisions.
What the Gateway Is Not
We want to be clear about the scope boundary: the MK-GW operating as a BACnet/IP device is a data-presentation layer, not a BACnet controller. It does not execute BACnet programs or manage BACnet schedules. If the facility wants to execute a setpoint schedule — say, pre-cool the building to 68°F before occupancy at 8 a.m. — that schedule lives in the BMS, and the BMS writes the setpoint to the gateway's Analog Output object, which the gateway then propagates to the mesh. The gateway is not replacing the BMS controller logic; it is extending the BMS's reach into the wireless sensor tier.
That boundary matters for scoping commissioning work. The BACnet integration itself — network discovery, object registration, COV subscriptions — is typically a half-day task for an experienced BAS commissioning engineer. The heavier work is the mesh deployment itself: gateway placement, RF site survey, node provisioning, and the firmware OTA that loads the correct BACnet configuration file onto each gateway.
For sites where the existing BMS runs Modbus TCP rather than BACnet/IP — common in industrial facilities or older manufacturing-adjacent buildings — the MK-GW also supports Modbus TCP in server mode, with configurable register maps. That is a separate integration path and covered in our Modbus TCP integration guide in the Resources section.