What Is the BACnet NetworkPort Object?
The NetworkPort object, defined in Clause 12.56 of ANSI/ASHRAE 135-2024, models one network interface of a BACnet device: a BACnet/IP port, an MS/TP (Master-Slave/Token-Passing) trunk, a BACnet SC connection. A device carries one NetworkPort object per interface, and the object exposes that interface’s addressing and datalink settings as ordinary readable and writable BACnet properties.
Its reason for existing is runtime configuration. Before the NetworkPort object, changing a device’s IP address or a BACnet BBMD’s broadcast table meant finding the vendor’s own tool, the right cable, and sometimes the right decade of laptop. The NetworkPort object standardizes those settings so any BACnet client can read and change them over the network the device is already on.
Where You’d Hit This in the Field
Commissioning is the everyday case: a technician re-addressing a controller reads and writes IP_Address, IP_Subnet_Mask, and IP_Default_Gateway over BACnet instead of hunting for a serial tool that may no longer exist. The scale case is infrastructure: a campus BMS (Building Management System) that can read every BBMD’s Broadcast Distribution Table over the network, and eventually edit it the same way, removes a per-vendor tooling dependency from the whole estate. And on a BACnet SC network, the NetworkPort object is the configuration surface, full stop: hub URIs, certificate file references, and connection status all live there. (Scenarios illustrative.)
What the Spec Defines
One object, per-type property groups. Every NetworkPort carries a common core: Network_Type (ipv4, ipv6, mstp, ethernet, secure-connect), Network_Number and how it was learned, APDU_Length, Link_Speed, and the health properties. The rest of the object depends on the interface: an IPv4 port implements the IP_* group (address, mask, gateway, UDP port, DHCP settings), an MS/TP port exposes Max_Master and Max_Info_Frames, a BBMD exposes the BBMD_* tables (the Foreign Device Table is populated by registration, not by write), and a BACnet SC port carries the SC_* group: hub URIs, reconnect timers, the hub-function enable, and per-connection status.
The staged-changes model. Network settings are the one thing you cannot safely change mid-conversation, so the spec doesn’t. Writes to NetworkPort configuration properties are staged, not applied: the port keeps running on its old settings, Changes_Pending flips to TRUE, and the edits take effect only when a ReinitializeDevice request with ACTIVATE_CHANGES commits them (the same choice that activates a staged BACnet SC certificate). Writing the Command property with discard-changes throws the staged edits away instead. Stage, verify, commit: the pattern a network engineer would have designed.
The wildcard port. Instance 4194303 is the wildcard: reading Network Port 4194303 with ReadProperty returns the port that received the request. A client can always ask “which interface am I talking to you through?” without knowing the device’s port numbering in advance.
What the CAS BACnet Stack Supports Today
The CAS BACnet Stack implements the NetworkPort object with its property groups across the datalinks (BACnet/IP, IPv6, MS/TP, BBMD, and BACnet SC) and the staged-changes model, exposed for read in the shipping 5.x release. It has been through our full test suite and is running on customer sites today.
Two write-path items are 6.x work, and we say so plainly: BDT edits landing end to end through standard WriteProperty, and automatic fallback from the primary to the failover BACnet SC hub URI. If your design leans on either today, talk to us about timing before you scope it.
In the field, the free CAS BACnet Explorer reads any device’s NetworkPort objects, which turns “what IP settings, MS/TP limits, and BBMD tables is this thing actually running” into a browse instead of an interrogation.
How 6.x Expands This
6.x is where the NetworkPort object’s write story lands for the stack: staged configuration writes committed with ACTIVATE_CHANGES, BDT edits over standard WriteProperty, and BACnet SC hub failover. It is part of the larger 6.x expansion in which the stack supports every BACnet profile Annex L defines, with the BIBBs and services behind each one; the network-management BIBBs that require a device to expose this object are in that set.
Where This Lives in the BACnet Spec
The NetworkPort object touches a specific set of objects, services, BIBBs, and profiles. Each links to its reference page.
Object types
- Network Port (Clause 12.56): the object itself, with the full property tables per interface type.
- Device (Clause 12.11): the object that owns the ports.
Services
- ReadProperty and WriteProperty: how settings are read and staged.
- ReinitializeDevice:
ACTIVATE_CHANGES, the commit step.
BIBBs (see the BIBBs reference for how the codes read)
- NM-BBMDC-B: BBMD configuration, exposed through this object’s
BBMD_*group. - NM-RC-B: router configuration, likewise surfaced here.
NM-CC-A: the client-side network-configuration BIBB a workstation claims to edit these properties.
Profiles
- B-BBMD, B-RTR, and B-SCHUB: the stackable infrastructure profiles whose configuration surface is this object.
- B-BC: the building controller that typically hosts the ports underneath them.
Where to Go Next
- Reference pages: the NetworkPort object with the full property tables, and the BACnet BBMD page for the tables it exposes.
- Building a device that should be configurable without a vendor tool? Request the CAS BACnet Stack developer kit.
- Have a specific BACnet need? Talk to us about your project.