1. Single Phase Energy Meter
   1. Why Choose a Receptor Device
   2. Receptor Device files (Templates) in the Driver SDK:

Single Phase Energy Meter

The use case in the sections that follow will involve the connection of a single phase energy meter to a V-Raptor. A typical example of this is multiple similar energy meters that measure the electricity usage in a specific area, such as an office building.

Why Choose a Receptor Device

A Receptor Device Template will be a good choice for this use case for the following reasons:

• The energy meters will be connected to the V-Raptor, and will send meta and telemetry to the Driver (i.e. they are push devices).
• These devices normally use an API key for authentication. With a Receptor Device, this can be done in the V-Raptor portal.
• There are multiple similar physical devices which need to be added to the Driver without a lot of manual configuration. Because Receptor Devices are generally used with push devices, it will be the best Device to choose for this application.
• In this application, the user will want exact control over where these devices are registered in the Driver. The Receptor Device is the best fit for this type of control, since the registration is handled completely by the developer.

The image below shows an example of a Digital Twin that represents an energy meter:

Figure 1 - Single Phase Energy Meter Digital Twin Example

The Digital Twin design for this type of energy meter would look similar to the example above, with the following endpoints:

• Account number
• Admin Charge
• Apparent Energy
• Apparent Power
• Current
• Daily Bank
• Daily Charge
• Daily Reading
• Dashboard (this will link to the dashboard which visualises the data)
• Demand Charge
• Energy Charge
• Instantaneous kWh
• Power Factor
• Reactive Energy
• Reactive Power
• Ready State
• Real Energy
• Real Power
• Tariff applied
• Tax Invoice Number
• Voltage

Some of these endpoints represent meta and telemetry sent from the physical devices (energy meters) to Commander, via the V-Raptor Driver. In the Driver, the user will configure the virtual representation of these physical devices (as Devices or Device Interfaces in the Driver) to translate this data so that it can be received by Commander.

Endpoints will be used to build the RegEx in the Digital Twin, as well as to configure the meta packets in the Device Interface (see Build a Meta Packet for a Receptor Device).

Broadly, the following needs to take place so that these energy meters can communicate with the V-Raptor and send data to be processed by Commander:

• Connect the energy meters to the V-Raptor (authentication and authorisation).
• Build gateways in the Device Interface that can be linked to live instances of Digital Twins in Commander (registration).
• Configure the Meta Packets in the Device Interface to reflect the Routing Key/RegEx in Commander.
• Configure Telemetry Packets in the Device Interface to allow telemetry from the physical devices to be received by the V-Raptor and then sent to Commander.
• Configure the Device in the Driver to add any other properties necessary for the use case.
• Add Device Metrics to monitor the status of the Device.

The sections that follow will cover these steps to ensure the quick setup and application of a Device for this use case.

To start, let’s look at the Receptor Device template in the Driver SDK:

Receptor Device files (Templates) in the Driver SDK:

All files that are required to run a Receptor Device can be found here:

Figure 2 - Receptor Device Template Files

1. Concrete Device files - [DeviceName]ReceptorDevice and [DeviceName]ReceptorDeviceOptions
2. Abstract Device files - I[DeviceName]ReceptorDevice and I[DeviceName]ReceptorDeviceOptions

In the [DeviceName]ReceptorDevice file, the following boilerplate code will already be included:

Figure 3 - Receptor Device Template boilerplate code

1. The Raptor.Device.Core SDK service is used to support all Device Templates in the Driver.
2. Raptor.DeviceManager is used to connect Devices with the Driver.
3. The comment code tells the user what the file is for. In the case of the Receptor Device file, the code provided “handles multiple external devices” (this is an indication that it is a Receptor Device Template).
4. [DeviceName]ReceptorDevice - this is a placeholder name for the Device.
5. This line contains the following:
   • ReceptorCoreDevice - this SDK service is called to add and extend the template code in the Device file.
   • I[DeviceName]ReceptorDeviceOptions - this is so that the interface options file is pulled into this Device file.
   • I[DeviceName]ReceptorDevice - this is so that the interface file is pulled into this Device file.
6. These sections can be expanded (click on the + button) to see more boilerplate code related to registering gateways, sending telemetry and more.

This guide’s first use case includes a REST Controller. An example of a configured telemetry packet with a REST Controller will be provided in the Sending Telemetry section.