Intermittent Off Line with VTN 2.0b

by | Jan 11, 2017 | Trouble Shooting Open ADR 2.0b-Group

In Open ADR 2.0b there are a number of factors which can cause a failure to connect to the VTN Alarm. Intermittent failures are not uncommon therefore we must examine the QOS (quality of service) to determine if the failures will affect the GRIDlink’s ability to respond to an Event.

This trend screen is a good example of frequent connection failures which do not affect Event participation.



In this example the connection between the GRIDlink and the VTN fails about 50 times in a 12 hour period indicated by the binary values in RED. What is important to note is the BLUE analog values which show the lowest value of 6 at 00:05 and 07:36. This means the GRIDlink was not able to connect to the VTN for about 4 minutes. See definition below.

There is a requirement in the 2.0b specification for End Nodes that have connection failures to increase the “wait period” duration before retrys. This serves to reduce the Server load should there be a problem. This also causes failures to appear to be longer than was experienced in 1.0 or 2.0a.

Once an Event is called the payload is stored and executed unless the Event is cancelled or the customer Opts out. Intermittent connection failures will not affect the Event.


OpenADR 2.0b ini file

Check to make sure log_level is not higher than INFO

# ————————— 2.0b Options ————- #

Load Averages

GRIDview View / Status

Check load averages which should be <3.0

Unit Uptime: 10:50pm up 2 days, 10:20, load average: 1.96, 2.00, 1.97

High Data Summary

GRIDview View / Data Summary

Check for tags with high data summary counts

Device / Tags

Increase scan delay where practical

Status Updates

GRIDview Device / Settings

Status Updates can be as low as 1 minute for debugging but  should be:

Status Updates 10 minutes


  1. QOS (quality of service) is a 10 minute running average of the number of successful signals received out of the 10 requests. If the all of the last 10 polls were successful, a score of 10 would result. If  one poll was unsuccessful then the QOS would be 9 and so on. In 2.0b the GRIDlink would require a QOS value of 0 and remain there for a long period before it would be accurate to say the device is Off Line otherwise a number less than 10 is usually attributed to intermittent network issues
  2. Reboots are datalogged. Frequent rebooting is an indication of insufficient power to the GRIDlink. Naturally the GRIDlink will lose its connection to the VTN while rebooting.
  3. GRIDview Off Line Events monitors the connection between the GRIDlink and the GRIDview cloud server. The connection is far more robust than the VTN. If there is a low QOS with the VTN at the same time the GRIDlink is Off Line with GRIDview then this is most likely due to a network problem or a power outage.