BACnet gets compared to a lot of other protocols on the market, including LonWorks, Modbus, and KNX. Over the next few articles, we’re explaining how each of these protocols are different, and how they stack up against each other. In this post, we’ll dig into LonWorks.
LonWorks is the proprietary protocol from Motorola/Echelon that regulates the content of devices’ communication. It’s part of the LonMark standard, which also includes a LonTalk protocol to dictate how devices communicate with each other.
Think of it this way: LonTalk defines who can talk to who (A can talk to B, but cannot talk directly to C or D), and the content of the messages between A and B is regulated by LonWorks (A can ask questions but cannot give answers). LonMark is the standard that encapsulates all of this.
LonWorks is what gets compared to BACnet the most frequently.
You might remember that BACnet emerged because of the problem with proprietary protocols. But, LonWorks isn’t like the locked-down protocols of pre-1987. It can be interworked with BACnet relatively easily — provided you design and integrate the two in a way that addresses the customer’s needs, as Gerry G. Hull writes. Meaning, in a way that doesn’t lock the customer in with a solution they don’t want, and that they can’t get out of.
While many see LonWorks as somewhat outdated, it does still have a dedicated fanbase. Building Energy Resilience notes that, unlike BACnet, Lon was designed as “both a data protocol and an electrical standard for digital communications.” It supports all different building automation systems, using peer-to-peer and master-slave communications. It’s an international standard (ANSI/CEA 709.1 and IEEE 1473-L), according to Facilities Net. Most importantly, any device carrying the Lon stamp of approval is verified: it has to be certified as working properly with other Lon devices, according to Facilities Net.
Want to know more? Check out our Ultimate BACnet FAQ.
