Do you have an idea or suggestion based on your experience with Azure IoT Edge?

Example/Tutorial for transparent gateways

It appears all current examples(C/C#) only covers cases for opaque gateways. Is it possible provide an example or tutorial for the trasparent gateway case? In case of transparent gateways, two queries below
1. What should be provided as connection string for command: iotedgectl setup --connection-string "XX"?
2. For modules, lib user is expected to give connection string of downstream devices. How is this provided?

10 votes
Sign in
(thinking…)
Sign in with: Microsoft
Signed in as (Sign out)

We’ll send you updates on this idea

Kiran Pradeep shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

4 comments

Sign in
(thinking…)
Sign in with: Microsoft
Signed in as (Sign out)
Submitting...
  • Kiran Pradeep commented  ·   ·  Flag as inappropriate

    @Chipalo Thanks. Please close this thread. As suggested, I will just add the connection string into the module doing the translation.

  • AdminChipalo (Product Owner, Microsoft Azure) commented  ·   ·  Flag as inappropriate

    1. Deleting it is probably good to avoid confusion. I could also just close it if you don't want to delete it. There's another feature requests for a BLE sample and that's where we plan on showing identity translation.

    2. Your approach could work. I've always just thought of including the connection string info in the twin of the module doing the identity translation.

  • Kiran Pradeep commented  ·   ·  Flag as inappropriate

    @Chipalo Thanks for the updated articles. At the time of writing the query, we only had transparent and opaque gateways. Now we have identity translation and that is the real world use case I am looking for. We have multiple downstream devices who don't speak MQTT/AMQP/HTTP and what our solution really need is a code sample for identity-translation. Our gateway is smart enough to understand the native protocol used by the downstream devices. I don't want to use protocol translation way which will bring in same restrictions V1 had(https://github.com/Azure/iot-edge/issues/402). Should I delete this request for transparent gateway code sample?

    2. Thanks for the pointer to read connection string from a module twin. From your reply, my understanding is that, for the time being, the gateway device is expected to have an identity-store like module whose twin will have all the connection strings of edge devices. This identity store could pass down the connection string to further modules who do both works of understanding native protocol and providing identity. Kindly correct me if that is wrong.

  • AdminChipalo (Product Owner, Microsoft Azure) commented  ·   ·  Flag as inappropriate

    We've added a conceptual gateway article to explicitly classify the different types of gateways. Before there were two very different types of transparent gateways. One where the downstream device holds its own identity (now called transparent gateway) and one where a module on the gateway holds the downstream device's identity (now called identity translation). The old opaque pattern is called protocol translation. In terms of documentation...
    Gateway concepts -
    https://docs.microsoft.com/en-us/azure/iot-edge/iot-edge-as-gateway
    Transparent how-to - https://docs.microsoft.com/en-us/azure/iot-edge/how-to-create-transparent-gateway
    Protocol translation - We need to create a how-to for this; however you are correct that the Modbus module is an example of an opaque gateway (https://github.com/Azure/iot-edge-modbus).
    Identity translation - We need to provide an example of this. The plan is to create a SensorTag module that shows this functionality for a device speaking BLE.

    In regards to your two specific questions...
    1. The device connection string used for iotedgectl setup is the device connection string for that of the iot edge device being used as a gateway.
    2. 100% correct, code in the module is supposed to connect using the connection string of the downstream device. Right now you have to hard code that connection string into the code of the module or read it out of the module twin. The second option makes it more secure and more configurable. Before GA, we'll let you acquire the connection string for the down stream device from the device provisioning service and store it on the edge device securely.

Feedback and Knowledge Base