1

I want to create a 'hierarchy' of edge devices and using therefore the gateway mechanism. For the moment the gateway is just a transparant gateway, which passes the messages to the IoT Hub. (https://learn.microsoft.com/en-us/azure/iot-edge/how-to-create-transparent-gateway-linux).

Situation: I have two edge devices, say 'Sensor' and 'Gateway'. How do I specify the route in the deployment that the output of Sensor needs to go to the Gateway before going upstream to the IoT Hub?

Sensor route: "route": "FROM /messages/* INTO ???"

Gateway route: "route": "FROM /messages/* INTO $upstream"

  • It sounds like you want to go from a transparent gateway to an identity translation gateway (as defined [here](https://learn.microsoft.com/en-us/azure/iot-edge/iot-edge-as-gateway)). But when you say "two edge devices", you don't mean that both sensor and gateway are running IoT Edge runtime do you? I'm guessing your sensor is using an Azure IoT SDK to talk to the gateway, and the gateway is the one running IoT Edge? What sort of processing needs to happen to the message in the gateway before it goes on to IoT Hub? – Damon Barry Aug 02 '18 at 23:43
  • They both running IoT Edge runtime, because I want to setup a kind of hierarchy. The final purpose is to have for example 5 incoming sensors in the sensor edge device where we can do some calculations on the edge. The output goes to the gateway, where again we can do some calculations on the edge with input form other similar sensor edge devices. Or is there another way to connect edge devices with each other? – Arne Vlietinck Aug 03 '18 at 08:11

1 Answers1

0

For the current release of v2 IoT Edge (1.0, released in late June 2018), you can't chain edge devices together into a hierarchy. It's a needed feature for many scenarios, but not one we support yet (I'm on the Azure IoT Edge team). We plan to enable it, but I don't have a timeline.

The most immediate problem is this: The IoT Edge runtime builds a SAS-based connection string which it uses to establish a connection to the cloud on behalf of a device. The runtime only knows how to build a connection string that contains the hostname of your IoT hub:

HostName=<hub>;DeviceId=<device>;SharedAccessKey=<secret>

To connect to another edge device instead of your IoT hub, the connection string would need an additional piece of information--the hostname of the other edge device:

HostName=<hub>;DeviceId=<device>;SharedAccessKey=<secret>;GatewayHostName=<edge>

Because of the connection string, the edge device can only communicate with IoT Hub in the cloud, not the IoT Hub-like interface of another edge device.

That's an easy enough problem to solve, however beyond that we don't yet know if there are other blocking issues. Also there's work to be done to ensure the whole experience of creating edge hierarchies works and makes sense.

Damon Barry
  • 261
  • 1
  • 4