BACnet was designed to allow communication of building automation and control systems for applications such as heating, ventilating, and air-conditioning control (HVAC), lighting control, access control, and fire detection systems and their associated equipment. The BACnet protocol provides mechanisms for computerized building automation devices to exchange information, regardless of the particular building service they perform.
The development of the BACnet protocol began in June, 1987, in Nashville, Tennessee, at the inaugural meeting of the Standard Project Committee (SPC). The committee worked at reaching consensus using working groups to divide up the task of creating a standard. The working groups focused on specific areas and provided information and recommendations to the main committee. The first three working groups were the Data Type and Attribute Working Group, Primitive Data Format Working Group, and the Application Services Working Group.
BACnet became ASHRAE/ANSI Standard 135 in 1995, and ISO 16484-5 in 2003. The Method of Test for Conformance to BACnet was published in 2003 as BSR/ASHRAE Standard 135.1. BACnet is under continuous maintenance by the ASHRAE Standing Standard Project Committee 135.
BACnet had an almost immediate impact on the HVAC controls industry. In 1996 Alerton announced a complete BACnet product line for HVAC controls, from the operator's workstation down to small VAV controllers. Automated Logic Corporation and Delta Controls soon followed suit. As of August 6, 2015, 842 Vendor IDs have been issued and are distributed internationally. Those vendor identifiers can be viewed at the BACnet website.
H. Michael (Mike) Newman, Manager of the Computer Section of the Utilities and Energy Management Department at Cornell University, served as the BACnet committee chairman until June, 2000, when he was succeeded by his vice-chair of 13 years, Steven (Steve) Bushby from NIST. During Steve Bushby's four-year term as committee chair the BACnet standard was republished twice, in 2001 and 2004, each time with new capabilities added to the standard. The 2001 version featured, among other things, extensions to support fire / life-safety systems. In June, 2004, 17 years after the first BACnet meeting and back in Nashville, William (Bill) Swan (a.k.a. "BACnet Bill") from Alerton began his four-year stint as committee chair. During his term the number of committee working groups grew to 11, pursuing areas such as support for lighting, access control, energy utility/building integration and wireless communications. In June 2008, in Salt Lake City, Dave Robin from Automated Logic Corporation took over the reins as the new committee chair after serving 4 years as vice chair. During Dave's term, 22 addenda were published for the 135-2008 standard and republished as 135-2010. Several addenda were published for 135-2010 and will be republished as 135-2012. In June 2012, in San Antonio, Carl Neilson from Delta Controls took over the reins as the new committee chair after serving 4 years as vice chair. During Carl's term, 12 addenda were published for the 135-2012 standard and it will be republished as 135-2016. In June 2015, Carl stepped down as chair. Bernhard Isler, from Siemens, became chair after serving 3 years as vice chair and 3 years as secretary.
In January 2006 the BACnet Manufacturers Association and the BACnet Interest Group of North America combined their operation in a new organization called BACnet International.
The BACnet protocol defines a number of services that are used to communicate between building devices. The protocol services include Who-Is, I-Am, Who-Has, I-Have, which are used for Device and Object discovery. Services such as Read-Property and Write-Property are used for data sharing. The BACnet protocol defines a number of Objects that are acted upon by the services. The objects include Analog Input, Analog Output, Analog Value, Binary Input, Binary Output, Binary Value, Multi-State Input, Multi-State Output, Calendar, Event-Enrollment, File, Notification-Class, Group, Loop, Program, Schedule, Command, and Device.
The standard specifies 54 types of objects:
- Access Credential
- Access Door
- Access Point
- Access Rights
- Access User
- Access Zone
- Alert Enrollment
- Analog Input: Sensor input
- Analog Output: Control output
- Analog Value: Setpoint or other analog control system parameter
- Binary Input: Switch input
- Binary Output: Relay output
- Binary Value: Control system parameter
- Bit String Value
- Calendar: A list of dates, such as holidays or special events, for scheduling
- Channel Object
- Character String Value
- Command: Writes multiple values to multiple objects in multiple devices to accomplish a specific purpose, such as day-mode to night-mode, or emergency mode
- Credential Data Input
- Date Pattern Value
- Date Value
- Date Time Pattern Value
- Date Time Value
- Device: Properties tell what objects and services the device supports, and other device-specific information such as vendor, firmware revision, etc.
- Event Enrollment: Describes an event that might be an error condition (e.g., "Input out of range") or an alarm that other devices to know about. It can directly tell one device or use a Notification Class object to tell multiple devices
- Event Log
- File: Allows read and write access to data files supported by the device
- Global Group
- Group: Provides access to multiple properties of multiple objects in a read single operation
- Integer Value
- Large Analog Value
- Life Safety Point
- Life Safety Zone
- Lighting Output: for lighting features such as blink warning, fade time, low/high trim etc.
- Load Control
- Loop: Provides standardized access to a "PID control loop"
- Multi-state Input: Represents the status of a multiple-state process, such as a refrigerator's On, Off, and Defrost cycles
- Multi-state Output: Represents the desired state of a multiple-state process (such as It's Time to Cool, It's Cold Enough and it's Time to Defrost)
- Multi-state Value
- Network Security
- Notification Class: Contains a list of devices to be informed if an Event Enrollment object determines that a warning or alarm message needs to be sent
- Notification Forwarder
- Octet String Value
- Positive Integer Value
- Program: Allows a program running in the device to be started, stopped, loaded and unloaded, and reports the present status of the program
- Pulse Converter
- Schedule: Defines a weekly schedule of operations (performed by writing to specified list of objects with exceptions such as holidays. Can use a Calendar object for the exceptions
- Time Pattern Value
- Time Value
- Trend Log
- Trend Log Multiple
BACnet Testing Laboratories was established by BACnet International to test products as per BACnet standard and support compliance testing and interoperability testing activities and consists of BTL Manager and the BTL-WG. The general activities of the BTL are:
- Publish the BTL Implementation Guidelines document
- Certifying the products as per BACnet guidelines
- Support the activities of the BTL-WG,
- Maintaining the BTL test packages for technical support for use of pre-testing
- Approves Testing Laboratories for BTL Testing
The BTL also provides testing services through its managed BACnet laboratory. BACnet International and BTL have reached an agreement with SoftDEL Systems to establish and maintain a test lab for BACnet products. SoftDEL is headquartered in Pune, India where the test facility operates BTL. The BTL Manager and BTL working group of BACnet International will administer the test lab. This BACnet lab is ISO 17025 accredited 
- LonWorks, a popular rival protocol.
- KNX is a worldwide standard for home and building control(ISO/IEC 14543-3). BACNET Interest Group Europe is Associated Partner
- "Standard 135-2012-- BACnet--A Data Communication Protocol for Building Automation and Control Networks (ANSI Approved)". 2012.
- BACnet protocol June, 1987, in Nashville, Tennessee
- "BACnet test lab at SoftDEL" 4 April 2006
- "SoftDEL BACnet Testing Laboratory achieves ISO accreditation." 6 Apr 2010