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

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

• Troubleshoot Azure IoT Edge | Microsoft Learn
• Operate Azure IoT Edge devices offline | Microsoft Learn
• Understand Azure IoT Hub cloud-to-device messaging | Microsoft Learn

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.

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.