How to manage downstream devices when using an IoT Edge Gateway?

Question

I have many downstream devices that don't have internet access and use an IoT Edge Gateway to connect to IoT Hub. I want them to have a Device Identity in IoT Hub and have the Edge device as their parent. But how can I create their device identity, since DPS is not available for downstream devices?

During my research, I discovered the following possibilities:

• Manual creation via portal is not an option because it's too many devices
• In the Identity Translation Lite sample they use an Azure Function to create the device identity, but this seems a bit hacky.
• Creating the device identity in the Edge Module would be possible, but it would be a security problem because the edge module would need exceedingly high permissions.

What is the best way of doing this? Is there a way to use DPS?

How would I achieve this if my downstream devices are no "real" IoT devices and need protocol translation?

Answer 1

Hello @Andreas F,

welcome to this moderated Azure community forum.

The short answer is that you have to automate a lot of the taks needed be yourself. There is no full automated support for a transparent proxy. Regarding protocol translation, you only need to register the edge but you need to create custom code.

You are describing multiple challenges:

1. How to work with child devices in the IoT Hub
2. How can these devices be registered at scale (and maybe registered as child device)
3. How about using protocol translation instead of a transparent gateway?
4. not mentioned, identity translation

Regarding the first challenge, you say your IoT Edge device is already connected.

This means you then need to configure the Azure IoT Edge devices as a part, so it can run as a transparent gateway (see link for a demonstration).

This means each child:

• must be registered in the IoT Hub
• each child device registration need to appointed a parent
• each child device needs access to the public certificate so it can make use of (, access) the edge routing
• each child device needs a modified connection string

If you have this running, each child device can send telemetry to the IoT hub, unaware it is sent over secure connection provided by the edge.

For the second challenge, registering these child devices in a DPS in bulk is partially offered using the SDKs.

There is no support for the relationship between parent and child devices as part of the device provisioning process. So, you can only arrange this AFTER the child devices are created within the IoT Hub, so after a first initial deployment attempt.

Unfortunately, child devices only know the connection string to the iothub/edge.

So, you are probably better of with a bulk registration in the IoT Hub for the child devices, following the registration of the edge device (because then you know which IoT Hub is appointed).

Challenge three, protocol translation, means adding some Azure IoT Edge module logic that is capable of receiving 'child' device messages and routing them to the cloud as if these are sent by the edge device.

This means each message has a system property telling the message is generated by the edge but the body probably holds the device id of the 'child' device.

This has nothing to do with any child device or parent device.

Only the edge device is registered in the DPS and IoT Hub.

Challenge four is making use of identity translation.

Here, you create DeviceClients inside your custom module, acting as proxies for your downstream devices and connected to the device registrations in the cloud. The mapping and exchange of device secrets could be done eg. with desired properties (notice there is a limit to the device twin section size).

Be aware:

The IoT Edge runtime does not include protocol or identity translation capabilities.

Both translation must be programmed with custom code. I'm not aware of any solutions in the Azure IoT Edge module marketplace.

The easiest solution seems protocol translation. The registration is simple (only one edge device) and the cloud communication is still done over the secure edge communication.

---

If the response helped, do "Accept Answer". If it doesn't work, please let us know the progress. All community members with similar issues will benefit by doing so. Your contribution is highly appreciated.