Most comparisons of these two treat them as rivals picking a fight over the same job. That framing gets the engineering wrong, and it gets one important fact wrong too.
BACnet defines LonTalk as one of its own data link layers. Clause 11 of the BACnet standard specifies how BACnet messages ride on the LonTalk protocol. They are not two answers to one question. One is a data-sharing model that happens to bring a network with it; the other is an application-layer model that runs over whichever network you have, LonTalk included.
Once you see that, the real comparison stops being “which protocol” and becomes “which data model fits the job.”
This is grounded in ISO/IEC 14908-1 for LonWorks and ISO 16484-5 for BACnet.
Table of Contents
The one-line difference
LonWorks connects typed variables between devices. You bind an output to an input at commissioning, and after that values propagate on their own.
BACnet exposes named properties on objects. A device holds objects; something reads and writes their properties over the network.
Push versus pull, roughly — but the deeper difference is where the intelligence lives. LonWorks puts the relationship in the network configuration. BACnet puts it in whatever is doing the reading.
Architecture
BACnet uses a four-layer collapsed architecture — physical, data link, network, application — mapped onto the OSI model. The reasoning is stated in the standard: building automation networks function as local area networks, devices are static, they don’t move, and their functions don’t change day to day. Protocol overhead needed to be as small as possible.
LonWorks specifies all seven OSI layers, including its own transport, session, and presentation behaviour.
That difference explains a lot. BACnet borrows its lower layers and defines seven data link options: ISO 8802-3 Ethernet, ARCNET, MS/TP over EIA-485, point-to-point serial, LonTalk, BACnet/IP over UDP, and ZigBee. LonWorks defines its own media in Parts 2, 3, and 4 of its own standard.
Addressing
| LonWorks | BACnet | |
|---|---|---|
| Structure | Domain / subnet / node | Object identifier: type + instance |
| Device identity | 48-bit Unique_Node_ID, factory-set | Device object instance number |
| Instance space | 255 subnets × 127 nodes per domain | 22-bit instance number per object type |
| Reserved value | Subnet 0 = unknown | Instance 4194303 = uninitialised |
| Cross-boundary | No inter-domain routing at all | Network numbers routed by BACnet routers |
The LonWorks address identifies a device. The BACnet object identifier identifies a thing inside a device — combined with the Device object, it gives you a way to reference every object in the control system network.
That’s the structural difference in one line. LonWorks addressing gets you to a box. BACnet addressing gets you to a point.
The data model
LonWorks: network variables. A typed value with a 14-bit selector. Connect an output to an input by giving them the same selector and binding them through an address table entry. After that the sending application writes its variable and propagation happens without anyone asking.
BACnet: objects and properties. A device is modelled as a collection of objects. Each object has properties, and each property is marked in the standard as:
- R — required, present and readable
- W — required, present, readable and writable
- O — optional
Not every object type must be supported to conform, and many properties are optional. That flexibility is deliberate and it’s also the source of most BACnet integration pain: two conforming devices can support quite different property sets.
BACnet is explicit about extension. Implementors may define nonstandard object types and nonstandard properties, and the standard calls this the principal means of extending itself as control technology develops — innovation without waiting for a standards revision. Nonstandard object types still have to carry Object_Identifier, Object_Name, Object_Type, and Property_List.
LonWorks handles the same problem differently, through aliases and vendor-defined types, but the type library itself lives outside the standard with LonMark.
What BACnet has that LonWorks doesn’t
Command prioritisation. This is the big one, and it has no LonWorks equivalent.
A commandable property carries a Priority_Array — sixteen slots, priority 1 highest to 16 lowest. Write to the property with a priority parameter and your value lands in that slot. The object continuously monitors the array and sets the property to the highest-priority non-NULL entry.
Relinquish a command by writing NULL to your slot. Control falls back to whatever is next down the array. Write without specifying a priority and you get 16, the lowest.
Standard commandable properties are the Present_Value of Analog Output, Binary Output, Multi-state Output, Access Door, and Lighting Output — plus a long list of Value objects where it’s optional.
Think about what that gives you. Life safety can command a damper at priority 1, an operator override sits at priority 8, and the normal control loop writes at 16. Everyone writes to the same property, nobody has to know about anyone else, and when the override is released control returns automatically. The arbitration is in the protocol.
In LonWorks you build that yourself in application logic. Nothing in ISO/IEC 14908 does it for you.
One caveat the standard is blunt about: a write at a given priority overwrites whatever was there, without any regard to the identity of the previous commanding entity. Priority levels are a convention your integration has to agree on, not an access control.
Change of Value subscription. A client subscribes to a property and gets notified when it changes. Different shape from a LonWorks binding — the relationship is created at runtime by the subscriber rather than at commissioning by the tool.
What LonWorks has that BACnet doesn’t
Peer-to-peer as the default. LonWorks bindings are device-to-device with no master in the path. Interlocking between two controllers doesn’t route through a supervisor. BACnet is client/server at the application layer, and something has to do the reading.
Media that come with the standard. ISO/IEC 14908 specifies its twisted-pair channel, its power line channel, and its IP transport as parts 2, 3 and 4. Free topology wiring, link power, defined distances. BACnet inherits its media and specifies only MS/TP itself.
Link power. Devices drawing DC from the same pair that carries data, with a defined budget. Nothing comparable in BACnet.
When you run BACnet over LonTalk
Since this is the case most people don’t know exists, the constraints are worth having.
The BACnet message code on LonTalk is X'4E'. Because that code identifies the BACnet network layer, the LSAP isn’t used.
Three restrictions matter:
- An LPDU longer than 228 octets cannot be conveyed via LonTalk. That’s the tightest frame limit among BACnet’s data link options.
- LonTalk authentication is not supported in BACnet. The 48-bit challenge-response scheme is simply unavailable.
- Only UNACKD and UNACKD_RPT are permitted. Acknowledged and request/response LonTalk services are not allowed. The choice between the two, and the repeat count, is a local matter.
Any LonTalk address format works except 2B, which is reserved for multicast acknowledgements — consistent with acknowledged service being off the table. Any BACnet priority other than normal is carried using the LonTalk priority mechanism.
So BACnet-over-LonTalk gives you BACnet’s object model over LonWorks wiring, at the cost of LonTalk’s reliability services and its authentication. Reliability moves up to the BACnet layer.
Choosing
LonWorks fits when devices need to talk to each other directly, when the wiring is difficult and free topology or link power earns its keep, when the installed base is already LonWorks, or when you want device-level interlocking without a supervisor in the loop.
BACnet fits when a supervisory system is reading everything anyway, when you need command arbitration between multiple sources, when you’re integrating across many vendors in HVAC, or when the specification already says BACnet — which, in commercial buildings, it usually does.
Both, via a gateway, is the common real answer. The awkward part isn’t transport, it’s the model: mapping a typed network variable onto an object property means deciding which object type it becomes and what happens to the type information. Plan those points early, because adding them later means re-commissioning bindings.
A note on versions
The comparison above uses ISO 16484-5:2014, which is built on ANSI/ASHRAE 135-2012. The BACnet standard is under continuous maintenance and has moved on — ANSI/ASHRAE 135-2024 is current, with ISO 16484-5:2022 as the international adoption. Object model fundamentals, the priority array, and the LonTalk data link clause are long-standing, but check a current edition before relying on any specific detail for a submittal.
ISO/IEC 14908 has not moved. The 2012 edition is still the standard.
FAQ
Can BACnet and LonWorks talk to each other? Two ways. A gateway translating between the models, which is the usual approach. Or BACnet running directly over LonTalk as its data link layer, which is defined in Clause 11 of the BACnet standard.
Which is better? They solve different problems. LonWorks binds typed variables peer-to-peer and brings its own media. BACnet exposes objects and properties for a client to read and write, and has command prioritisation nothing in LonWorks matches.
Which is more widely used today? BACnet, in commercial building automation, by a wide margin — it’s what most specifications call for. LonWorks retains a large installed base, particularly in older HVAC, lighting and access control systems.
Does BACnet have anything like network variables? Not directly. COV subscription is the closest — a client subscribes and gets notified on change — but the relationship is created at runtime by the subscriber rather than bound at commissioning.
What’s the frame size limit for BACnet over LonTalk? 228 octets. An LPDU longer than that cannot be conveyed.
Can I use LonTalk authentication with BACnet? No. The standard states plainly that LonTalk authentication is not supported in BACnet.