Select Page

Intermittent Off Line with 2.0b VTN

by | Oct 20, 2022 | VTN Troubleshooting-Group

In Open ADR 2.0b there are a number of factors which can cause a failure to connect to the VTN. 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 retries. 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.

GRIDlink Settings

There are setting in GRIDview that could lead to intermittent connections. Check the following:

Log Level

GRIDview Device / Files

Select dras_client.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

Solution – 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

Intermittent failures can result from:

  1. Network issues, particularly wireless communication.
  2. VTN not responding to requests within time parameters.

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


are data-logged. Frequent rebooting maybe an indication of insufficient power to the GRIDlink.

GRIDview Off Line Events

monitors the connection between the GRIDlink and the GRIDview cloud server. 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.