1. Building a Meta Packet in the SDK Receptor Device Template
   1. Build the Meta Packet

Building a Meta Packet in the SDK Receptor Device Template

Receptor Device Templates in the SDK allow the user to configure a meta packet that matches the Routing Key in Commander. This meta packet makes it possible for data coming from physical devices to be linked to the correct endpoints in the Digital Twin entity tree.

The Properties (Device Type, Group Name, etc) chosen when creating the Routing Key/RegEx need to match properties found in the meta packet structure in the Receptor Device Interface file. The sections that follow will show how to configure these packets.

Ensure that the gateway is associated in Commander so that this meta packet can link to the correct Digital Twin endpoints.

Build the Meta Packet

In the Device file (in this case it is [Device Name]ReceptorDevice.cs), scroll down to this section of the code:

Figure 1 - Meta Packet in Receptor Device file

1. The first section is where the meta packet is compiled. This will correspond to the first fields of the Routing Key. The autogenerated fields in this section include DeviceName, DeviceType, GatewayId, GroupName, Make and Model.
2. The second section is where device properties will be defined so that they can link to the correct endpoints in the Digital Twin entity tree.

Section 1 in more detail:

Assume that the Routing Key looks like this (as per the standard created in Build Gateways):

123532.Power:ACMeter|Kamstrup.Current

In this Routing Key, the fields follow this pattern:

• Gateway Id: The serial number of the physical device.
• Group Name: The common characteristic of devices linked to this Routing Key.
• Device Type: The purpose of devices linked to this Routing Key.
• Device Id: The name brand (product name) of the physical device.
• Property: A data point being sent from this physical device.

In the Device file, the meta packet contains fields that generally match with the fields in the Routing Key. The table below provides a comparison:

var deviceInfo = _serviceProvider.GetRequiredService<IDeviceInfo>();
deviceInfo.DeviceName = "ReceptorDevice";
deviceInfo.DeviceType = "ReceptorDriverSdkDemo";
deviceInfo.GatewayId = "";
deviceInfo.GroupName = "DriverSdkDemoDevices";
deviceInfo.Make = "MyMake";
deviceInfo.Model = "MyModel";

Make and Model (in the Device Meta Packet, see the code block above) will be the make and the model of the physical device.

The DeviceType in the Devices configuration file (DevicesOptions.json) and Device Binding (in HostBuilderExtensions.cs) needs to be the same for Device Manager to initiate the Driver’s Devices. However, DeviceType in the meta packet does not need to correspond to this name and can be altered to make more sense when constructing the Routing Key structure in Commander.

Section 2:

Properties are defined in the second part of the function:

if (!cachedInfo.IsMetaSent)
{
    // Set up the properties and send the meta
    cachedInfo.Properties.Add("Prop1", CreateProperty("double", "Prop1"));
    cachedInfo.Properties.Add("Prop2", CreateProperty("int", "Prop2"));
    try
    {
        await SendMetaAsync(cachedInfo);
    }
    catch (Exception ex)
    {
        LogError(ex, $"Exception sending Meta. {ex.Message}");
    }
}

1. “Prop1” and “Prop2”: Add the property type that would correspond to the property of the linked endpoint in the Digital Twin (see Routing Key or RegEx). Examples include:
   • Current
   • Voltage
   • ApparentEnergy
   • PowerStatus
   • PowerFactor
   • ReactiveEnergy
   • ReactivePower
   • ReadyState
   • EnergyCharge
   • RealPower
   • PowerStatus
   • ControlSignal

   Note that property names cannot include spaces, special characters, etc.

2. (“double”, “Prop1”) and (“int”, “Prop2”): Ensure that the property is configured to read the correct data type.
3. SendMetaAsync asks the method to run through the properties and ensure they are registered. If they are not registered, SendMetaAsync will register the properties not yet registered.

Properties registered here will first be created in the Digital Twin and then registered in this section according to the Digital Twin’s design. The properties need to be configured before the Driver is executed so that Commander can make sense of the telemetry being sent from the physical device.

The SDK template provides placeholder values such as “ReceptorDevice” in this section. You can replace these values with the values that match the relevant Routing Key in Commander.