by Maury Costantini

Tukwila, WA

The evolution of “open” protocol communication networks in the commercial building automation industry is vastly misunderstood. The purpose of open protocol is to bring consumer choice and make equipment interoperable. The reality is proprietary programming tools, modifications to protocol standards and geographic distribution restrictions have prevented consumer choice. To date, open protocols have not delivered much.

The first broadly adopted open protocol to the building automation industry was LonWorks (LON). LON is a networking platform (ANSI/IEEE 709.1) specifically created to address the needs of building automation (controls) applications. The platform is built on a protocol created by Echelon Corporation for networking devices over media such as twisted pair, power lines, fiber optics, and RF. LonWorks has fallen out of favor in recent years with the advent of BACnet. Many LonWorks users felt frustration over licensing cost models and manufacturer interoperability limitations. Essentially, the use of the User-defined Network Variable Type (UNVT) allowed LON manufacturers to maintain priority models.


The Building Automation Control Network (BACnet) is a data communication protocol developed by ASHRAE starting in 1987 and becoming widely productized in the mid-1990s. BACnet is ANSI/ASHRAE standard 135-2008 and ISO 16484-5 with the purpose of standardizing building automation device communication. The intent is to ensure multiple manufacturers have interoperable equipment. While intentions have always been good and to avoid “proprietary” technologies, the reality is BACnet has not changed much. This is not because BACnet protocol is bad. It is because it has been productized in a way to protect manufacturers’ channels.

Though BACnet is enthusiastically promoted by consulting engineers (as members of ASHRAE), BACnet rarely offers interoperable HVAC and lighting equipment or field devices. This is because each building automation manufacture has proprietary programming tools, it eliminates the intent of “open protocol” (regardless of BACnet or LonWorks). What’s more is that owner/operators usually avoid mixing manufacturer products or integrators completing the installation.

When reviewing the BACnet International FAQs you will find a question, “Is BACnet Plug and Play?” and the answer: “No. In fact there is no plug and play standard for building automation for some good reasons.” And they go on to explain in the FAQs that there are millions of permutations and it is impossible to make BACnet communication automatic. Furthermore, BACnet International explains that various manufacturers cannot program each other’s products. Which can also be said for LonWorks. So I ask again, why does protocol matter?


The best option for true choice is a building automation system that has multiple contractors in every market without purchasing or geographic restriction. Consultants and owner/operators should ask how many companies can install a product in lieu of the open protocol specification. This would give building owner/operators the option for bidding projects and services. So why doesn’t this happen? Well, it would destroy the global company and integrator business model that guarantees high-margins. This model is why manufacturers and integrators are motivated to avoid interoperability regardless of protocol.

Consultants should avoid flat specifying LonWorks, BACnet MS/TP, Tridium Niagra and other device specific requirements that are found commonly in project specifications. Instead, provide a performance specification with system requirements. Then make it mandatory for building automation companies to have multiple vendors within the project’s geography. In addition, make sure the software has an open license and a freely available plugin tool that allows owner/operators to program their building automation; or hire any contractor to do so. And don’t let technical people tell you it can’t be done because you need a specialist. This argument is demeaning. If a building operator can’t support a product, he or she should question the product being offered.

In addition to integrator hardware and software, Manufacturers need to be willing participants. Manufacturers have already been providing BACnet, LonWorks and ModBus communication protocol options. In order to ensure competition, manufacturers need to make integration files freely available for simple integration. Not all manufactures are committed to this. While open protocols can be helpful for equipment integration, they need to be unaltered and unrestricted. New entrants into the VRF market in particular have offered limited open protocol options.

Let’s move the industry forward by stopping the protocol games and focusing on providing great customer service and consumer choice.

About the author.

Maury Costantini has 23 years in the HVAC industry. His experience includes operations, engineering, sales and executive leadership for regional and global companies. He is currently Managing Partner at Octant Innovations, LLC. Octant Innovations offers a factory-engineered, building automation system for small and medium-sized buildings. Their Controls-in-a-BoxTM and inetAUTOMATIONTM products bring unmatched consumer choice while providing a simple and affordable option for HVAC and Lighting controls. You can learn more at www.