What LonWorks Is
LonWorks is a distributed control networking technology that exchanges typed data between devices over a peer-to-peer LonTalk network. The protocol stack is standardized as ISO/IEC 14908 and is built around the Neuron application model, where each device exposes a set of typed network variables that can be bound to compatible variables on other devices during commissioning.
Its primary practical advantage over flat field buses is semantic typing. Every value on the wire carries a Standard Network Variable Type that defines its encoding, range, resolution, and engineering unit. Two devices that agree on a Standard Network Variable Type can exchange a temperature, a setpoint, or an occupancy state without an integrator picking a register convention by hand.
LonWorks is most common in commercial building automation, especially in HVAC, lighting, and access-control retrofits in North America and Europe. It also appears in transportation, industrial control, and street-lighting deployments, although those are less common in retrofit gateway work today.
For field troubleshooting see the LonWorks Troubleshooting Guide. For mapping-side detail see the LonWorks SNVT Reference and XIF Mapping Guide.
History
LonWorks was introduced by Echelon Corporation in 1990 as a distributed control platform for embedded networked devices. The design centered on the Neuron chip — a microcontroller with the LonTalk stack built in — and on a commissioning model where network behavior, bindings, and service choices were configured at installation time rather than hard-coded into device firmware.
The LonTalk protocol was published as an ANSI standard (ANSI/CEA-709.1) in 1999 and adopted into the ISO/IEC 14908 family in 2008. Echelon’s LonWorks business was acquired by Adesto Technologies in 2018, and Adesto was acquired by Renesas Electronics in 2020. Day-to-day tooling for LonWorks engineering (IzoT CT, the OpenLDV stack, LonMaker successors) is now maintained under Renesas.
That history still matters in modern retrofit projects. LonWorks can model real building intent cleanly, but only when the original commissioning artifacts survived. A live bus is not enough if the XIF files, binding records, SNVT expectations, or Neuron identity records have been lost.
Core Concepts
- Network variables. The primary data exchange unit. Each device exposes inputs (
nvi*) and outputs (nvo*) that other devices can read or write. - Bindings. A commissioning-time association between an output variable on one device and one or more compatible input variables on others. The binding lives in the network database, not in either device’s firmware.
- Standard Network Variable Types. Typed schemas that define encoding, range, resolution, and engineering units. See LonWorks SNVTs.
- Neuron IDs. A 48-bit hardware identifier burned into each Neuron chip at manufacture, used for commissioning and uniqueness. Not used for routine routing.
- Domain, subnet, and node addressing. Logical addresses used for everyday traffic, assigned during commissioning. A domain partitions the network; subnets group nodes; the node ID identifies a device within a subnet.
- XIF files. Per-device interface definitions that name every network variable, its direction, and its Standard Network Variable Type. See LonWorks XIF Files.
- LonTalk message services. Unacknowledged, repeated unacknowledged, acknowledged, and request-response delivery patterns. The service choice affects bus load, retry behavior, and binding semantics.
- Physical layer. Most installed networks run on FT-10 free-topology twisted pair at 78 kbit/s. See LonWorks FT-10.
LonWorks-Specific Information
LonWorks is deeper than a register-based field bus because the engineering model — variables, types, bindings, addresses, and Program IDs — is the source of truth, not a flat address table.
Network Variables And Bindings
Each LonWorks device declares its interface as a set of network variable inputs and outputs. A binding connects one output to one or more inputs. The binding is performed by a network management tool against the network database, then committed to each device’s binding table. Once bound, the source device pushes updates to bound consumers whenever the value changes, without further commissioning action.
This is structurally different from polled register-based protocols. A gateway integrating LonWorks data does not always pick which values to read — in some cases the gateway must be bound as a receiver so that values arrive when the source device decides to send them.
For the file-level interface that drives gateway mapping, see LonWorks XIF Files.
Standard Network Variable Types And Engineering Units
The data carried on a network variable is governed by a Standard Network Variable Type, which fixes both encoding and engineering unit. SNVT_temp_p is degrees Celsius. SNVT_press is kilopascals. SNVT_flow is litres per second. The protocol does not offer imperial variants. Unit conversion to the destination system happens in the gateway point map or in the BMS, not in the source variable.
For the type table and scaling rules, see LonWorks SNVTs.
Neuron IDs And Logical Addressing
The 48-bit Neuron ID is the bootstrap identity for a device. It is used for first-time discovery, for binding, and for replacement workflows where a new device must inherit the role of a failed one. Day-to-day traffic does not carry Neuron IDs; it uses the domain, subnet, and node logical address assigned during commissioning.
That distinction matters when replacing a device. The Neuron ID is hardware-bound and cannot be reused on a replacement, so the network database has to be updated to associate the existing logical address with the new Neuron ID.
Configuration Properties (SCPTs and UCPTs)
Beyond network variables, LonWorks devices expose configuration properties. Standard Configuration Property Types are defined by LonMark (for example SCPTminRnge, SCPTmaxRnge, SCPTalarmLimits). User Configuration Property Types are defined by the device manufacturer. Some devices expose runtime values through configuration properties rather than network variables, which is why a missing point can sometimes be found in the property section of the XIF rather than the variable section.
Program IDs
Each LonWorks device interface is identified by a 12-byte Program ID, declared in the XIF and used by network management tools to recognize the interface and check compatibility. A change to a FieldServer LonWorks configuration that affects the interface can change the Program ID and trigger re-binding workflows in the network management tool. This is one of the more common sources of “the replacement looks identical but will not bind” problems on retrofit jobs.
Common Variants
| Variant | Where It Fits | Why It Matters |
|---|---|---|
| LonWorks FT-10 | Free-topology twisted pair at 78 kbit/s | The physical layer used on almost every installed LonWorks HVAC trunk |
| LonWorks SNVTs | Typed variable and unit model | Defines the engineering meaning and metric-unit constraint of every data point |
| LonWorks XIF Files | Interface definition and commissioning data | Hard prerequisite for dependable mapping and gateway configuration |
Other transports including TP/XF-1250 (1.25 Mbit/s twisted pair), power-line PL-20, and IP tunneling per CEA-852 exist but are rarely seen on retrofit gateway projects in the building-automation domain.
Project Startup Questions
LonWorks projects depend on engineering artifacts more than most field buses. Confirm these gates before quoting configuration time:
- Is the XIF file available for every device profile on the network?
- Are Neuron IDs known for every device that needs to be discovered, bound, or replaced?
- Is the domain, subnet, and node addressing of the existing trunk documented?
- Is the original network management database (LonMaker, IzoT CT, or vendor equivalent) still accessible?
- Are the required Standard Network Variable Types compatible with the destination system’s engineering-unit expectations?
- Is the physical layer confirmed as FT-10 free-topology, FT-10 doubly-terminated bus, or something else?
A missing answer on any of these is a startup blocker, not a midstream issue.
How To Get The Points List
LonWorks point lists come from interface definitions and commissioning records rather than from a flat register table.
Preferred sources:
- XIF files for each device profile on the network
- LonMaker, IzoT CT, or vendor-tool export of network variables and bindings
- A Neuron ID inventory tied to controllers, panels, or trunks
- Domain, subnet, and node records from the installed network database
- The existing supervisory mapping if a previous gateway or BMS already referenced these devices
If the site has controller names but no XIF files, the point list is incomplete and the project is not yet ready for configuration. See LonWorks XIF Files for the four practical methods to obtain a XIF.
Devices that Support LonWorks
Common LonWorks device families seen on Chipkin retrofit work:
| Family | Typical Use |
|---|---|
| Echelon i.LON SmartServer | IP-attached LonWorks router and data server |
| Honeywell Excel 500 / Excel Web | Legacy HVAC controllers |
| Trane Tracer LonTalk family | HVAC controllers in older Trane plants |
| Distech Controls EC-BOS / ECL | LON building controllers |
| Siemens LON TEC, Apogee LON | HVAC zone and air-handling controllers |
| Johnson Controls Metasys L-Tec | LON nodes in mixed Metasys/LON sites |
| Loytec L-VIS, L-INX, L-IOB | LON-IP routers and field devices |
| LonPoint modules | Echelon I/O modules in older plants |
This is not a discovery list — it is a recognition guide for what tends to show up in installed-base retrofit work.
Common Integration Targets
- BACnet/IP for retrofit normalization into modern BMS workflows
- BACnet MS/TP where the destination supervisory layer is still serial
- Modbus TCP for integration with PLC and SCADA layers
- Modbus RTU for serial-only destinations
- MQTT for cloud telemetry off a legacy LonWorks trunk
Tools & Diagnostics
| Tool | Type | Description |
|---|---|---|
| QuickServer | Chipkin protocol gateway | Maps LonWorks network variables to BACnet, Modbus, MQTT, and 220-plus other downstream protocols |
| LonWorks XIF -> QuickServer Converter | Chipkin interactive tool | Browser-based meta-configurator: drop a XIF, get a ready-to-load FieldServer Bridge CSV for BACnet/IP or Modbus/TCP |
| FieldServer Toolbox | Chipkin diagnostics | Used to verify gateway exposure and connectivity once LonWorks mapping is in place |
| NodeUtil | Discovery and XIF extraction | Echelon-supplied tool for discovering nodes and extracting XIF files directly from the Neuron chip |
| LonMaker / IzoT CT | Network management | Commissioning, binding, and database export; LonMaker is the legacy tool, IzoT CT the current Renesas tool |
| LonScanner Protocol Analyzer | Protocol analyzer | Captures and decodes live LonTalk traffic when wiring or service-type behavior is in question |
Field Procedures
LonWorks retrofit jobs depend on a handful of repeatable field procedures more than they depend on protocol theory. The articles below capture the Chipkin field workflow for the steps that most often block a project before mapping begins.
| Procedure | When You Need It |
|---|---|
| Finding the Neuron ID of a LonWorks Device | Before commissioning, replacement, or binding any new node |
| Using NodeUtil to Discover LonWorks Devices and Extract XIF Files | When the site cannot supply XIF files for the installed devices |
| LonWorks Domain, Subnet, and Node Addressing Guide | When reading or editing FieldServer configurations against an existing trunk |
| Replacing a Bound FieldServer in LonMaker | When swapping or updating a FieldServer without rebuilding bindings |
| LonWorks Program ID Explained | When a configuration change does not take effect after a device replace |
| Resetting LonWorks Bindings on a FieldServer | When stale lonvars.cfg or fserver.xif state blocks a commissioning step |
| Interpreting a LonWorks XIF File | When the XIF is in hand but the variable list still has to be turned into a points list |
Frequently Asked Questions
What is the difference between a Neuron ID and a domain-subnet-node address?
The Neuron ID is a 48-bit hardware identifier burned into the Neuron chip at manufacture and used for commissioning. The domain-subnet-node address is a logical address assigned during commissioning and used for routine traffic. A device replacement keeps the logical address and acquires a new Neuron ID.
What is binding, and why does it matter for gateway integration?
Binding is the commissioning-time link between an output network variable on one device and one or more compatible input variables on others. Once bound, the source device sends updates to its bound consumers when the value changes. A gateway integrating LonWorks data sometimes has to be bound as a consumer rather than configured as a poller.
Why is SNVT_press always in kilopascals even when the BMS wants PSI?
Standard Network Variable Types fix the engineering unit as part of the protocol contract. There is no PSI variant of SNVT_press. Unit conversion to PSI is performed in the gateway point map or in the destination BMS, not in the source variable.
What is a XIF file and why do projects stall without it?
A XIF file is the per-device interface definition that lists every network variable, its direction, and its Standard Network Variable Type. Without it, the gateway is being configured against guesses. See LonWorks XIF Files for the four ways to obtain a XIF.
Why does my LonWorks retrofit need its original commissioning database?
Because bindings live in the network database, not in either device’s firmware. Without the database, the gateway can read variables but cannot reliably reproduce the original push-update behavior that the BMS expects.
Reference Documents
- ISO/IEC 14908-1 Standard Overview — formal standards entry for the LonTalk protocol stack.
- LonMark International — Standard Network Variable Type definitions and interoperability profiles.
- Renesas LonWorks resources — current vendor home for LonWorks engineering tools and Neuron silicon.
- Real Time Automation LonWorks overview — accessible overview of the LonTalk model, Neuron architecture, and addressing.
- Wikipedia: LonWorks — useful overview for terminology, history, and standards lineage.
