LonWorks

LonWorks is still in thousands of buildings – and integrating it into a modern Niagara installation is a specialty that gets rarer every year. Software Pile brings Lon devices into N4 stations so legacy field networks keep working alongside newer BACnet and IP systems.

LonWorks Integration Work

  • LonMark and legacy Lon device integration through Niagara’s Lon driver
  • Network variable (SNVT) mapping into typed Niagara points with proper units
  • Mixed-network installations: Lon field devices under Niagara alongside BACnet and Modbus
  • Migration planning where aging Lon infrastructure is being phased toward newer protocols without a rip-and-replace

Keeping Legacy Networks Useful

Replacing a working Lon network is expensive and disruptive. More often the right move is integration: bring Lon into Niagara now, modernize the front end and reporting, and phase field devices over time. We plan that path so nothing goes dark mid-transition.

Tell us about your Lon devices and your Niagara version. We will scope integration and, if you want it, a migration path.

What Is LonWorks?

LonWorks is a control networking technology, originally from Echelon, that was widely deployed in building automation from the 1990s onward. It uses the LonTalk protocol and defines standard data types so devices from different manufacturers can interoperate on the same network. A great deal of installed HVAC, lighting and access equipment still runs on it.

It is no longer what new installations are specified with — that is generally BACnet — but “legacy” here means “still running the building”, not “switched off”.

What Is a SNVT?

A SNVT (Standard Network Variable Type, usually pronounced “sniv-it”) is a defined data type used to exchange values between LonWorks devices — a temperature, a setpoint, a switch state — with agreed units and scaling. Standardising the types is what allows devices from different vendors to understand each other.

When integrating a LonWorks network into Niagara, mapping SNVTs correctly to Niagara points is most of the work, and getting units or scaling wrong is the most common source of values that look plausible but are not.

Is LonWorks Obsolete?

New specification has largely moved to BACnet, and the supply of new LonWorks devices has narrowed considerably. But a large installed base remains in service, and ripping out working field devices is rarely justifiable on its own.

The realistic position for most owners is a mixed estate: LonWorks equipment that still does its job, newer BACnet equipment alongside it, and a need for a single coherent view across both. That is precisely the problem Niagara was built to solve.

How Does LonWorks Integrate with Niagara?

Niagara acts as the integration layer, presenting LonWorks devices as station points alongside everything else, so graphics, schedules, alarms, histories and reports work uniformly regardless of what protocol a value arrived on. The engineering work is in the details:

  • Mapping SNVTs to Niagara points with correct units, scaling and enumerations.
  • Handling device addressing and network management on the Lon side.
  • Deciding what is polled and how often — over-polling a legacy network degrades it.
  • Dealing with vendor-specific device profiles that go beyond the standard types.
  • Making offline and fault behaviour explicit, so a dead device reads as a fault rather than a stale value.

Planning a Migration Away from LonWorks

Where replacement is genuinely warranted — unobtainable spares, a major refurbishment, or devices that no longer meet requirements — the sensible pattern is gradual. Niagara can front both the old and new networks simultaneously, so equipment is replaced in phases as budget and access allow, without a single disruptive cutover and without the graphics, reports and alarms changing underneath the operators each time.

That also lets you avoid the trap of replacing working equipment first because it is easy to reach, rather than replacing the equipment that is actually causing problems.

Related services: BAS and protocol integration services · custom driver development.

Channel Types, Wiring Limits and Termination

Most installed Lon in buildings is TP/FT-10: 78.125 kbps, transformer isolated, polarity insensitive and free topology. Free topology is why it was quick to install and why it is hard to survey later, because a segment can be wired as a bus, a star, a loop or any mixture of the three, and the cable rarely follows the drawing. The limits that matter are total wire length and node count per segment rather than distance from a panel: 500 meters of total wire with no more than 400 meters between any two nodes in free topology, or up to 2700 meters as a doubly terminated bus on the cable it was specified for and considerably less on Cat5. Either way a segment carries 64 nodes. A physical layer repeater restores both budgets; a router does not extend a segment, it creates a second channel and decides what crosses between them.

Termination is the most common physical fault and the least obvious one. Free topology needs exactly one terminator, 52.3 ohms across the pair; a doubly terminated bus needs one of 105 ohms at each end and nothing in between. Two terminators on a free topology segment, or none anywhere, does not take the network down. It raises the error rate, so most packets still get through and the network reads as a set of flaky devices rather than as a wiring fault. The evidence sits in the channel statistics rather than in any point value: transmission errors, missed messages and CRC errors climbing over time while every device individually reports healthy.

The other channel types still turn up and behave differently enough to matter. Link power (LPT-10) carries device power on the same pair from a link power supply, so a whole segment going dark points at the supply rather than at the devices. TP/XF-1250 at 1.25 Mbps is almost always a backbone between routers, with much tighter length rules than the field segments hanging off it. PL-20 puts packets on the building mains at roughly 5.4 kbps and shares that path with every other load in the building, which is why the achievable update rate on a power line segment has to be measured rather than assumed.

  • TP/FT-10: 78.125 kbps, free topology, 64 nodes per segment, 500 m total wire, 400 m node to node, one 52.3 ohm terminator.
  • TP/FT-10 as a doubly terminated bus: up to 2700 m on the cable it was specified for, one 105 ohm terminator at each end.
  • TP/XF-1250: 1.25 Mbps, doubly terminated bus only, normally a router to router backbone.
  • PL-20: power line, about 5.4 kbps, sharing the mains with every other load.
  • IP-852 (CEA-852, ISO/IEC 14908-4): LonTalk packets carried over UDP, conventionally port 1628.

Who Manages the Network, and How Niagara Attaches

The station needs a physical way onto the network. On a JACE that is normally a Lon option module in a free expansion slot, attaching the controller directly to an FT-10 segment. The alternative is an IP-852 channel, where a router bridges the twisted pair segment onto UDP and the station joins as a member. An IP-852 channel has one configuration server holding the membership list, and every member including the Niagara side points at it, so replacing or re-addressing the device that hosts it leaves members still listed but no longer exchanging packets. The Lon driver is also licensed with its own device count in the station license, counted separately from the BACnet and Modbus limits, which is worth checking before the device list is fixed rather than after.

Before any of that, decide who manages the network. Niagara can own it, assigning domain, subnet and node addresses, commissioning devices and writing bindings; or it can join a network whose addressing an existing LNS based database such as LonMaker or NL220 still manages, in which case Niagara reads and writes network variables and leaves addressing alone. What does not work is both. Two tools that each believe they own the address table produce duplicate subnet and node assignments and devices that drop off with no obvious cause, and the symptom usually appears days later, the next time the other tool writes to the network. If a database exists, find out who still has it and whether it matches the building before choosing.

Either way the station needs each device's interface definition. A XIF file from the manufacturer describes the network variables, configuration properties and program ID without touching the device. The alternative is reading the interface out of a self documenting device over the wire, which is slower, consumes channel bandwidth during the read, and fails on devices whose self documentation was stripped to save Neuron memory. XIF files are matched by program ID, so a device that was field updated to a different application will not match the file you were handed.

Type Resolution: Scaling, Invalid Values and Resource Files

Scaling is data, not convention. Each type in the resource file carries a raw encoding plus three constants, and the engineering value is (A * 10^B) * raw + C. That is why two types that both present a temperature are not interchangeable: SNVT_temp_p is a signed 16 bit count of hundredths of a degree C, valid to 327.66 because the top code is reserved, while SNVT_temp counts tenths and reaches into the thousands. A discharge air temperature published as SNVT_temp_p is fine; a flue gas temperature is not, and it will sit pinned at the top of the range looking like a stuck sensor rather than an out of range value. Structured types add another way to be wrong: SNVT_switch is two fields, a percentage in 0.5 percent steps and a state, and a state of -1 means invalid rather than off.

Most types also reserve their top raw code to mean not available, which a driver that simply applies the scaling turns into a real number at the end of the range. The mapping therefore has to decide, per point, whether that code becomes a Niagara fault, a null, or a value. Doing it at the mapping rather than on a graphic matters because histories, alarm extensions and any control logic read the point, so a 327.67 that only looks wrong on a screen is still averaged into the trend.

Standard types resolve through the standard resource file set. Vendor defined types (UNVTs) and configuration properties (UCPTs) need that vendor's resource files installed alongside it, or the point resolves to raw bytes and unlabeled numbers. Resource files are versioned and keyed to the manufacturer ID carried inside the device's program ID, so a newer catalog does not describe an older device's private types and the mismatch fails quietly rather than with an error. Keep the file set that matches the equipment on site with the station, not only on the laptop of whoever did the integration.

Bindings, Commissioning and Telling Failures Apart

Bound network variables and polled reads are different kinds of traffic and they fail in different ways. A binding is a connection written into the devices themselves, so a device sends an update to the addresses in its own table when the value changes and the channel stays quiet in between. Polling puts every read on the wire on the station's schedule whether anything changed or not. The case worth looking for is a point that already arrives as a bound update and is also being polled, which doubles the traffic and buys nothing; it shows up most often where a network was originally engineered with bindings and later picked up by a tool that polls by default.

Setting a device's address takes it through an unconfigured state. Between the old domain, subnet and node being cleared and the new values taking, the device is not communicating, and depending on how the tool performs the write its binding table can go with them. Equipment that was running on those bindings stops running, not just stops reporting, which is why commissioning is planned work rather than something done device by device through the day.

  • Device answers a Neuron ID query and winks but exchanges no data: powered and healthy, but not in the station's domain. The addressing is wrong, not the wiring.
  • Device reports as unconfigured or applicationless: its configuration or application image is gone and it needs recommissioning, not replacement.
  • Pressing the service pin produces nothing on the wire: the question moves back to power, wiring and termination.
  • A value that is plausible but never changes: an input with no receive heartbeat holds its last update indefinitely, so a dead source reads as a working point. Configuring SCPTmaxRcvTime turns that silence into a fault state you can see.
  • Channel error counters climbing while individual devices look healthy: a physical layer problem, usually termination or an over-length segment.

Frequently Asked Questions

What has to be in place before a Lon integration can start?

The standard LonMark resource file set has to be present on the platform running the station, because every standard type name and enumeration resolves through it, and without it even ordinary SNVTs come up as raw values. The other prerequisite is a device inventory that reflects what is installed rather than what was drawn, since networks of this age have usually been extended, partly decommissioned, or both. Almost everything else is worked out during the integration rather than before it.

Is LonWorks the same thing as LonTalk and LonMark?

They are three different things that get used interchangeably. LonWorks is the overall technology, LonTalk is the protocol it speaks, standardized as ANSI/CEA-709.1 and ISO/IEC 14908-1, and LonMark is the interoperability association that defines functional profiles and certifies devices against them. The practical difference is that a LonMark certified device implements a published profile with defined standard network variables, so its interface is predictable before you ever see the device, while an uncertified device speaks the same protocol but may present most of its useful values as vendor specific types.

Will the Lon devices keep working if the Niagara station goes offline?

Control that runs device to device through bindings keeps running, because those connections live in the devices and do not pass through the station. What stops is anything the station supplies: schedules, optimized start, global setpoints written down to the field, alarm routing, histories, and any input whose source is a Niagara point. Where the station is the source of a bound input that has a receive heartbeat configured, that input reverts to its configured default when updates stop, so it is worth knowing what those defaults are before you need them.

Can devices be commissioned while the building is occupied?

Some can and some cannot, and the deciding question is not the device type, it is what stops working while that device is quiet. A device whose points only feed reporting and graphics can be done live; one that holds a control loop, or that other devices are bound to, needs its equipment off or forced to a known state first. In practice the device list splits into a live list and a scheduled list, and the split comes from reading each device's bindings rather than from a general rule.

Can a Lon device be replaced later without redoing the mapping?

Yes, if the replacement carries the same program ID and is commissioned into the same subnet and node address with its bindings restored, the station sees the same interface and the points come back as they were. A replacement running a newer application has a different program ID, which means a different XIF, possibly a different network variable order, and re-mapping of whatever moved. That is the argument for holding spares of the exact model rather than the current equivalent, and for recording the program ID of every device at handover.

Do vendor specific points come across?

Usually, and the constraint is availability rather than capability. The vendor resource files are the gating item, and for equipment whose manufacturer has been acquired or has discontinued the line they can be difficult to obtain at all. The fallback is to map the raw value and apply the scaling by hand from whatever documentation exists, which works but has to be written down somewhere, because nothing in the station will later explain where those numbers came from.

What does the customer have to provide or decide?

The largest decision is which points come across at all. A single Lon controller can expose dozens of network variables and configuration properties, most of which nobody will ever look at, and bringing all of them in inflates the licensed device count, the history database and the traffic on the segment. Someone who knows the plant has to say which values are operationally meaningful and which exist only because the vendor exposed them. Beyond that: physical access to the panels and plant rooms, and whatever device documentation, XIF files and vendor resource files still exist on site.