Frequently Asked Questions
If you have any questions that aren't covered here, please email firstname.lastname@example.org.
OpenADR / Event Operation
How would utilities control individual sites or resources?
Within events, it is possible to target them at a particular set of GroupIDs or ResourceIDs. The actual assignment of those GroupIDs and ResourceIDs to end devices or loads is done outside of OpenADR. So, the way this is typically done would be:
- Periodically, VTN managers and VEN managers would swap information on which resources are assigned which IDs, and which resources are in which group. We have seen this done with a custom API or even just through a weekly email.
- When calling an event, VTN managers will specify a target. Targets can be any combination of VEN IDs, Group IDs and Resource IDs.
- The VENs parse that target and determine which sites that they are controlling are relevant
GroupIDs might be used to specify resource types, geographic regions, etc.
NOVA will pass through the event details to the customer's existing device controls system, which is the best place for the logic that takes the Group IDs and Resource IDs and determines which devices to control.
How do we send reporting / telemetry data to the utility?
Any time series data being measured (e.g. kW, kWh, on/off, Voltages, etc.) may be sent through the reporting function. Using the reporting callback functions provided in the plugin, provide the information to Plaid and it will format it into the correct OpenADR reporting format and send to the VTN.
Does OpenADR support the concept of recurring events? E.g. an event which occurs weekly on Monday between 16:00 and 18:00 and never expires
The protocol does not, each event is individual. However, some VTNs have a scheduling feature that may accomplish this and publish events on a recurring basis.
Is it valid to create an event with a single signal containing one interval which does not cover the duration of the event? e.g. event duration = 60 mins, interval duration = 5 mins?
This is not technically valid with the OpenADR spec, and certified production VTNs should not allow something like this. However, there is nothing in the message structure to stop this from happening.
Can I spin up an instance of Plaid a few times a day to get messages and then shut it back down to conserve resources?
Plaid is supposed to maintain state, so should not be used this way.
Can I run multiple instances of Plaid on a single VM?
We have tested up to 1,200 instances on the same VM, so there shouldn't be an issue. 10-20 instances should be able to run on an AWS T3 (micro, or even nano) without using credits.
What if Plaid goes down?
Plaid can be restarted if required and will immediately re-register with the VTN, gather the necessary information to recreate it's state and notify the external system as needed.
What language must the plugin be written in?
The standard implementation is in C++, which most of our customers tweak and deploy. It is technically possible to build the plugin outside of Plaid.
There are hundreds of utilities in the country, how should I manage hundreds of instances of Plaid?
While there are hundreds of utilities, for now there are at most dozens of load shifting programs and some significant fraction of those use OpenADR, so VENs can be managed on an individual basis. We look forward to the ecosystem growing significantly, and we will introduce more scalable options for managing multiple VENs as it becomes required by our customers.
How does Plaid connect to a VTN?
If Plaid is running and able to form a connection to the internet, and the configuration is updated properly, it will form the connection automatically. Behind the scenes, it is using the eiRegisterParty service defined in OpenADR. There is sometimes some out of band communication required, such as sharing venIDs, before the connection can be finalized. Plaid will retry the connection automatically until it is made successfully.