Skip to main content

Symptom: Energy readings like nvoEnergySumNR and nvoEnergyA would suddenly jump to zero or some huge number like 150 million kWh, then return to the correct reading. Additional symptoms can be nvoDemand resetting to zero and then back to a high value, and nvoDemPerMin changing to zero then back to its default value. Other readings like power, voltage, current, and frequency were unaffected. A replacement meter exhibited the same symptoms. Moving the meter to a new physical location on a different circuit resulted in the same problem.

Investigation: This was particularly bizarre, because energy readings normally change very slowly as the consumed energy accumulates over time. At first we thought perhaps the monitoring device was responsible, so we connected a LonScanner® protocol analyzer, which verified the incorrect readings were appearing on the network. However, we noticed two other interesting facts. First, the incorrect readings were in packets that sometimes had an incorrect data length for an energy SNVT (either two bytes or 17 bytes instead of the expected four bytes). Second, the WattNode® meter reports new readings every five seconds, but the incorrect readings were occurring in-between good five second readings. So in other words, the WattNode would report a set of new readings including a correct energy value, then 2-3 seconds later, an incorrect energy reading would appear.

Finally, we came to suspect that some other device on the network was sending out network variable updates using the same Node address as the WattNode meter. Since network variable update messages for bound variables do not include information on the SNVT type, the monitoring device would try to interpret the data as energy, even if it was some totally different type of information. We verified that an address conflict was the problem by changing the Node address of the WattNode meter, which eliminated the problem.

Solution: Change the Node address of the affected meter to eliminate the address conflict.


Keywords: address collision, duplicate address, subnet, erratic readings, energy reset