Issue
The database updates were successful, but one or more nodes were not updated because the node(s) rejected the update, for example due to an authentication failure. A device encountered an operational or messaging error while its configuration was being updated.
Environment
LonMaker
NL220
Vista
LNS
Cause
This usually means that there is a configuration mismatch between the node and the LNS database. The LNS will continue to try to update the nodes in the background if the UpdateInterval property of the System object is set to a non-zero value, and you can force a retry with the RetryUpdates method.
This seems to have two origins – either in the LNS tool which commissioning or creating group bindings, etc., or in the System Plug-in while trying to download a programmable controller.
It has been observed when creating group bindings when most of the controllers were offline in an onnet connected network.
It has been observed while creating and downloading a network in NL220. All of the correct steps of creating a node, importing a Menta file, updating the network, and downloading were followed. During a download, an error occurs: “A device encountered an operational or messaging error while its configuration was being updated” (Subsystem: NS, #4031). After which an additional dummy device was created and inherited the neuron ID of the controller originally being downloaded.
It has been observed on an engineering PC using a NIC USB running under Windows Vista which had been reverted to Windows XP.
Commissioning a router in a brand new NL220 Smart Channel results in this error.
Resolution
This error occurs because LonMaker/LNS does not receive the device's response in a timely manner during the commissioning process. A new property (AppDevice::Delay) was introduced in LNS Turbo to resolve this issue. This Delay value will be added to any delays calculated by LNS based on the network topology. When this property contains the default value of 0, LNS will not calculate an extra delay for the device.
For earlier versions of LNS, the workaround is to increase the channel delay. Please note that this solution will affect all devices on that channel.
Also note that the AppDevice::Delay property is not exposed in the LonMaker Turbo Edition. To modify this property, you must use another LNS application, such as the LNS Object Browser (lnsobjectbrowser.exe located in your LonWorks\bin folder).
You can keep track of which devices are up to date using commissioning events, and by reading the CommissionStatus property of each AppDevice object. If you are receiving persistent update failures on a device, you should re-commission the device with the Commission method.
In some cases, switching to a PC using an Echelon LTA cleared the problem.
It has been observed that in NL220, an incorrect Device Template was assigned to the Controller during the commission process. The workaround was found by deleting the controller, updating Vista, and then deleting the offending template (in this case Lonm401 assigned to a Xenta 282). The controller then was able to be added with the correct Template.
In another case, the controller had to be decommissioned, the controller had to be deleted (including the IO modules if they exist), the TAC network tree inside the system plug-in was deleted, and then the Vista database was updated. A new controller was then added to the page and the commissioning process was started over. All bindings are lost in this process.
