Lonworks - Do I need Lonmaker to integrate a gateway
LonWorks - Do I Need LonMaker to Integrate a Gateway?
LonWorks (ANSI/CTA-709.1 / ISO/IEC 14908) networks are commonly encountered in building automation and industrial control environments where long service life and multi-vendor interoperability are required. When integrating LonWorks devices into IP-based supervisory systems (BACnet/IP, Modbus/TCP, SCADA, cloud analytics, etc.), a frequent question is whether a technician must use LonMaker (or similar network management tools) to commission and bind the integration gateway.
The short answer is: not always. Whether LonMaker is required depends on the integration approach, the device type, the network management state of the existing installation, and whether the solution depends on network-variable binding versus explicit messaging.
This article explains the practical difference between “traditional” LonWorks commissioning/binding and a gateway configuration approach where a gateway can communicate with LonWorks devices without requiring a field technician to perform LonWorks tool-based commissioning.
LonWorks Commissioning and Binding: What It Typically Means
In many LonWorks deployments, devices exchange data using Network Variables (NVs) and are “bound” so that a producing device knows which consuming device(s) should receive updates, and how. Binding and commissioning are normally performed using a network management tool such as LonMaker, and the process often involves:
- Discovering devices and verifying their Neuron ID and/or domain/subnet/node addressing
- Creating or importing device definitions (XIFs) and confirming available NVs
- Configuring devices and routers to match the network’s addressing and channel parameters
- Creating bindings between NV producers and consumers
- Commissioning the system and validating data exchange behavior
This is a valid and often necessary workflow when you are building or modifying a LonWorks system. However, it is not always desirable when the goal is only to extract data or bridge devices into another protocol with minimal impact to an existing installation.
Gateway Integration Without LonMaker: How It Works in Practice
Chipkin can configure LonWorks gateways so they can communicate with LonWorks devices without requiring on-site commissioning and binding. This is especially useful in retrofit scenarios where:
- The site does not have LonWorks tools available (or licenses are not maintained)
- The field technician is not LonWorks-trained
- The integration must be completed quickly with minimal disruption
- Only a subset of device data is required for the supervisory system
For example, when configuring a LonWorks-to-BACnet gateway for generator monitoring (e.g., Cummins generator applications), the gateway can be delivered pre-configured such that the field technician can install it by connecting power and the LonWorks network cable. In this workflow, the technician does not need LonMaker or advanced LonWorks skills to commission the gateway in the field.
The key technical requirement is typically that we must know how to address the LonWorks device(s) we are targeting. In many cases, it is sufficient to provide the device addressing information used on the network (for example, domain/subnet/node details or an equivalent identifier depending on network configuration and device type).
What Information Is Needed to Pre-Configure a LonWorks Gateway?
The minimum information required depends on the installation and the device. In practice, integrations commonly rely on some combination of:
- Device addressing (such as domain/subnet/node) or the identifier used by the site
- Device interface definition (XIF or documented NV/point list)
- Network characteristics (channel type and relevant parameters)
- Data requirements (which points are required, update rates, scaling, and units)
If the site does not know the required addressing or device details, we can support discovery. In some scenarios, Chipkin can loan a field technician a laptop with a software tool to discover the necessary information (subject to project scope and practical site constraints). The objective is to enable a predictable installation workflow while minimizing the need for LonWorks commissioning expertise on site.
That said, there are deployments where full commissioning and binding is still the correct approach—particularly when the gateway must act as a first-class LonWorks node participating in NV bindings or when the site’s network management policy requires formal tool-based commissioning records.
Explicit vs Implicit Messaging
LonWorks gateways can be configured to use LonTalk explicit messaging and/or implicit messaging. The difference matters for how data is exchanged and whether binding is required:
- Implicit messaging is typically associated with network variable updates and bound communication. This can require commissioning/binding steps so producers and consumers are correctly linked.
- Explicit messaging can be used to query or command devices more directly, depending on device support and the integration design. This approach can reduce the dependency on binding workflows in certain retrofit cases.
The correct method depends on the LonWorks device profile, the system architecture, and what the supervisory system expects (polling vs event-driven updates, required latency, and network load constraints).
LonWorks Integration Services and Gateways
For LonWorks gateway options, integration services, and protocol conversion solutions, refer to our LonWorks landing page: https://store.chipkin.com/products/protocol-conversions/lonworks-integration-gateways-services
If you are unsure whether your project requires LonMaker-based commissioning, the most efficient starting point is to identify the LonWorks device models in use, the points required, and whether the site has existing binding and network management practices that must be preserved.
Frequently Asked Questions (FAQ)
Do I always need LonMaker to integrate a LonWorks gateway?
No. Some integrations can be completed with a pre-configured gateway that communicates with LonWorks devices without requiring the field technician to commission and bind the gateway using LonMaker. Whether LonMaker is required depends on the device capabilities and the integration method (implicit NV binding versus explicit messaging).
What is the practical advantage of avoiding LonMaker on site?
It reduces installation complexity and eliminates the need for LonWorks tool licensing and specialized technician training. This is particularly valuable in retrofit environments where the goal is to add monitoring or protocol conversion with minimal operational disruption.
What information do you need to configure a gateway without commissioning?
At minimum, we typically need reliable device addressing information and a clear list of points required for the integration. Device definitions (such as XIF files) and network characteristics further improve accuracy and reduce commissioning risk.
When would LonMaker still be required?
LonMaker (or another LonWorks network management tool) may be required when the gateway must participate in NV bindings, when network management policies mandate formal commissioning, or when the integration must modify existing LonWorks bindings or device configuration in a managed network.
What is the difference between explicit and implicit messaging for gateways?
Implicit messaging typically aligns with bound network variable updates and may require binding. Explicit messaging can enable more direct query/response interactions in certain architectures. The appropriate method depends on the device and the integration requirements.
Can Chipkin help if the site does not know LonWorks addresses?
In many cases, yes. Discovery workflows may be possible depending on the site environment and project scope. If critical identifiers are missing, it is often still possible to obtain them with appropriate tools during a structured commissioning step.