Issue in sending the data from transparent IoT Edge Gateway to child IoT Device

Athira Gopinath(UST,IN) 141 Reputation points
2026-05-20T10:57:55.7966667+00:00

As part of an R&D activity, we are trying to add a child device to a Transparent Gateway (IoT Edge Device). The addition of the child device (IoT Device) to the IoT Edge Device was successful, and the logs also indicate that EdgeHub is connected to the IoT device. However, when data is sent from the Edge Module to the child device, the child device is not receiving any data. We are sharing the EdgeHub logs for reference. Additionally, we would like to understand the capabilities of the child device in scenarios where there is no network connectivity, specifically whether communication between the Edge Module and the child device will still function.

IoTDevice.txt

edgehub.txt

Could anyone please suggest a possible solution or provide guidance for this issue?

Azure IoT Edge
Azure IoT Edge

An Azure service that is used to deploy cloud workloads to run on internet of things (IoT) edge devices via standard containers.

3 answers

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-05-20T10:58:24.48+00:00

    In a transparent gateway topology, the IoT Edge device (gateway) only forwards traffic between each device and IoT Hub. It does not natively provide direct module-to-child-device messaging over the local network.

    Key points for the current behavior:

    1. Transparent gateway message flow
      • Downstream/child devices connect to the gateway’s edgeHub using MQTT or AMQP, but all messages are logically between the child device and IoT Hub.
      • Capabilities supported for a child IoT device behind a transparent gateway include:
        • Device-to-cloud (D2C) messages
        • Cloud-to-device (C2D) messages
        • Direct methods
        • Device twins
      • File upload is not supported for child IoT devices behind a gateway.
      • There is no built-in path for an Edge module to send messages directly to a child device as if it were a local broker. To reach the child device, the module must use IoT Hub primitives (for example, invoke a direct method or send a C2D message via IoT Hub), which are then routed through the gateway.
    2. Why the child device is not receiving data from the Edge module
      • If the Edge module is sending messages to edgeHub expecting them to be delivered directly to the child device (for example, via local topic addressing), this is not supported by the transparent gateway pattern.
      • Instead, the module should:
        • Send messages to IoT Hub targeting the child device (for example, C2D messages or direct methods), and
        • Ensure the child device SDK is listening for C2D messages or direct method calls.
      • The gateway’s role is to proxy authentication and transport; it does not automatically translate module outputs into child-device inputs.
    3. Offline behavior and child device capabilities
      • After the IoT Edge gateway has connected to IoT Hub at least once, it can operate offline for extended periods. Downstream (child) devices can also continue working when the gateway has intermittent or no internet connectivity.
      • In offline scenarios:
        • The gateway persists messages and twin updates that cannot be delivered to IoT Hub.
        • Device-to-cloud messages from child devices can continue to be sent to the gateway; they are stored and forwarded when connectivity returns.
      • However, C2D messages and direct methods originate from IoT Hub. When the gateway is offline from IoT Hub, new C2D messages or direct method invocations cannot be delivered to the child device because there is no cloud connection to source them.
      • The transparent gateway pattern does not define a direct, cloud-independent channel from Edge modules to child devices. Any interaction that depends on IoT Hub (C2D, direct methods, twin updates) will be limited when the gateway is disconnected from IoT Hub.
    4. Practical guidance
      • For communication from an Edge module to a child device:
        • Use IoT Hub C2D messages or direct methods, not a local-only path.
        • Ensure the child device is registered as a child of the gateway in IoT Hub and is connected to the gateway using MQTT/AMQP with the correct hostname and ports.
      • For offline scenarios:
        • Design the solution so that child devices can operate autonomously when the gateway is offline (for example, local logic, buffering of telemetry).
        • Treat module-to-child-device interactions as cloud-mediated; they will not function fully when the gateway cannot reach IoT Hub.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

  2. Sander van de Velde | MVP 37,081 Reputation points MVP
    2026-05-20T21:22:29.6233333+00:00

    Hello @Athira Gopinath(UST,IN) ,

    welcome to this Azure community forum.

    In the past, I have worked with the transparent gateway ability and blogged about how to set this up .

    A transparent gateway is not part of the communication between cloud and 'leaf' device, it's just reusage of that single secured communication pipe, instead of having all devices connecting on their own.

    Next to that, I wrote this blog post regarding using a PLC to connect as a child device.

    I remember there I used direct methods to exchange messages between modules and devices.

    Regarding the (temporary) offline scenario between edge and cloud, for as far as I know this will not affect communication between edge and child devices on the local network because this is on par with inter-module communication (also not affected).

    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.

    Was this answer helpful?

    0 comments
  3. Karnam Venkata Rajeswari 5,255 Reputation points Microsoft External Staff Moderator
    2026-05-31T17:28:28.2433333+00:00

    Hello @Athira Gopinath(UST,IN) ,

    Welcome to Microsoft Q&A .Thank you for reaching out to us.

     The described behavior is expected in a Transparent Gateway setup. While the downstream (child) device is connected successfully through the IoT Edge gateway, direct messaging from an IoT Edge module to a child device is not supported by design, either online or offline. Supported communication relies on IoT Hub–mediated mechanisms such as Cloud‑to‑Device messages or direct methods.

    An Azure IoT Edge device is configured in Transparent Gateway mode, with a downstream IoT device properly registered and connected. EdgeHub logs confirm successful authentication and stable connectivity between the child device and the gateway.

    An IoT Edge module is publishing messages intended for the child device, but the messages are not received. Clarification is also requested on whether module‑to‑child communication continues when connectivity to IoT Hub is unavailable.

    In a Transparent Gateway topology:

    • The gateway functions as a secure proxy between devices and IoT Hub
    • Child devices communicate with IoT Hub through the gateway using MQTT or AMQP
    • Device‑level features are IoT Hub–mediated, not locally brokered

    Please note that-

    • EdgeHub does not support direct addressing of downstream devices from Edge modules
    • EdgeHub acts as a broker only for:
      • Module‑to‑module communication
      • Module‑to‑cloud communication
    • Downstream devices are not exposed as routable endpoints inside EdgeHub

    As a result, the absence of message delivery to the child device is expected by design, not caused by routing, certificate, or network issues.

    The issue originates from a communication model mismatch:

    • Edge modules publish messages into EdgeHub
    • EdgeHub routes messages only to:
      • Other Edge modules
      • IoT Hub (upstream)

    EdgeHub does not provide:

    • Module‑to‑child device delivery
    • Local device‑level message fan‑out
    • Device‑targeted endpoints for Edge modules

    Any attempt to treat the child device as a local messaging endpoint from a module will therefore not succeed.

    Please check the following supported communication patterns

    1. Device ↔ Cloud (via Gateway) Fully supported through IoT Hub mediation:
      • Device‑to‑Cloud (D2C) telemetry
      • Cloud‑to‑Device (C2D) messages
      • Direct methods
      • Device twin updates
    2. Module ↔ Module (Local Edge)
      1. Supported entirely within the Edge runtime
      2. Continues to function even when cloud connectivity is unavailable
    3. Module → Child Device (Design Limitation)
      1. Direct local messaging is not supported
      2. Communication must be redesigned using supported patterns:
        • Module → IoT Hub → C2D or Direct Method, or
        • A local Edge design where another module consumes data and interacts with external systems separately
      There is no native module‑to‑child routing mechanism in EdgeHub.

    Offline Behavior Clarification

    When IoT Hub connectivity is unavailable , continues to Work

    • Child devices remain connected locally to the gateway
    • Module‑to‑module communication continues
    • Device‑to‑cloud telemetry is buffered at the gateway and forwarded when connectivity resumes

    If not Available Offline

    • Cloud‑to‑Device messages
    • Direct methods
    • Device twin updates
    • Any functionality requiring IoT Hub as the source

    EdgeHub buffering applies only to upstream traffic, not to unsupported module‑to‑device messaging scenarios.

    Please check if the following steps help -

    1. Validating Child Device Connectivity
      1. Confirm child device is registered under the correct parent identity
      2. Verify successful authentication in EdgeHub logs
    2. Verifying Gateway Configuration
      1. Ensure GatewayHostName is correctly set in the device connection string
      2. Confirm MQTT or AMQP protocol usage
      3. Validate shared root CA certificate trust
    3. Validating Module Message Flow
      1. Confirm modules publish to valid EdgeHub outputs
      2. Verify messages are routed upstream or to other modules as intended
    4. Validating Cloud‑Mediated Messaging
      1. Send a Cloud‑to‑Device message or invoke a direct method
      2. Confirm successful reception on the child device
    5. Offline Validation
      1. Disconnect gateway from IoT Hub
      2. Confirm telemetry buffering and continued module‑to‑module communication
      3. Observe that C2D messages are not delivered while offline

    The following references might be helpful , please check them out

    Please let us know if the response was helpful

     

    Thank you

     

    Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the response was helpful. This will be benefitting other community members who face the same issue.

     

     

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.