The Echelon i.LON® SmartServer is a powerful embedded server that can communicate with LonWorks ®, BACnet ®, and Modbus ® devices. It can log data, bind variables, maintain the time of day. It provides a web interface as well as Ethernet and LonTalk ®. It has options for IP-852, internal programmability, and operation as a standalone LNS server.
There are several important things to note when using the i.LON with a WattNode meter.
The i.LON includes a real-time clock and the ability to synchronize with an SNTP server. NTP or SNTP are protocols for keeping computers and other devices time sychronized on the network. See http://www.ntp.org/ for details.
- We recommend setting up the SNTP feature on the i.LON (see the user’s guide).
- Once this has been configured, we recommend binding it to all connected WattNodes. Bind Real Time Clock/nvoRtTimeDate to the WattNode’s NodeObject/nviTimeSet.
- We recommend updating the time on the WattNode somewhat infrequently, because time updates can cause demand measurement resynchronization, which may slightly affect the readings. There are two ways to configure the update rate for nvoRtTimeDate:
- Recommended: Within LonMaker, set the SCPTupdateRate for nvoRtTimeDate to the desired update interval. The maximum interval is 6553.4 seconds, or 1.8 hours.
- Use the i.LON web interface to configure the data point properties: “Max. Send Time (Heartbeat)” and “Min. Send Time (Throttle)”. If you use this approach, “Max. Receive Time (Offline)” isn’t relevant (leave at 0) and leave “Use Send on Delta” unchecked. Since the date/time change continuously, if we enabled “Send on Delta”, we would continuously send updates, which we do not want.
By default, if you are only updating a single WattNode meter, LNS will probably choose “Acknowledged” service. If you are updating more than one, LNS will probably select “Subnet Broadcast” service repeated four times.
Both of these are overkill for updating the clock, because the WattNode tracks the time quite accurately and really only needs an update once per week. Therefore, you may want to switch to “Unacknowledged” or “Subnet Broadcast” with only one or two repeats. This will cut down on network traffic.
The i.LON includes the ability to log data from one or more WattNodes. This will work with any WattNode LonWorks, BACnet, or Modbus models. The i.LON logging does not utilize the WattNode Logger for LonWorks internal logging feature; only the WattNode Plug-in for LNS can read data from the WattNode Logger internal log.
Logging with Bound SNVTs
When logging, you can bind WattNode output network variables (nvo) to i.LON input network variables (nvi) you create, commonly under the “Data Logger” functional profile block. You can then configure the i.LON data logger to log these bound variables whenever the WattNode outputs a new value “Log on Updates”. You can then specify a “Min. Delta Time” to limit the logging rate (so if the WattNode outputs new data every five seconds, you can log the data less frequently).
Furthermore, you can configure the “Min. Delta Value” so that new values are only logged if the value changes by a large enough amount.
For nvoDemand, we highly recommend using binding and “Log on Updates”.
There is a problem with trying to poll nvoDemand. The i.LON synchronizes its polling to the hour. For example, if you are polling every fifteen minutes, the i.LON will read nvoDemand at 1:00, 1:15, 1:30, 1:45, 2:00, etc. The WattNode also updates nvoDemand internally at these same times and also tries to stay synchronized to the hour. This results in duplicated and skipped readings. For example:
Note how in some cases, the polled value is correct and in others, the previous value is used because the pol request arrived just before the new demand reading was ready, so the old value was reported instead. Because of this issue, we want to only use bound updates “Log on Updates”.
Binding Service Type
LonWorks supports several different types of network variable connection services: Acknowledged, unacknowledged, repeated. It also allows priority and authentication.
If you are logging values that are important, we strongly recommend using “Ackd” or “Acknowledged” service to ensure values are not missed if there is a collision on the network.