IoT Edge模块如何在边缘运行时向已注册设备路由消息

基础场景说明 #

基于IoT Edge官方模块开发教程的延伸场景：在原有SimulatedTemperatureSensor模块的运行环境中，额外注册了名为myAwesomeDevice的控制台类设备，该设备可生成结构类似的温度遥测消息，当前已配置自定义路由把该设备发送的消息转发到本地处理模块的BrokeredEndpoint，现在需要实现边缘端运行的模块反向给myAwesomeDevice推送处理后的温度展示数据。

方案合理性判断 #

你当前尝试通过直接消息机制实现需求的方向是完全可行的，核心是要区分两端的职责分工，不存在技术层面的限制。

方案一：直接方法（Direct Method）实现 #

这是你当前正在尝试的路径，适配对消息时效性有要求的场景，核心是明确两端的职责分工：

• SetMethodHandlerAsync接口的调用位置是接收消息的myAwesomeDevice端，而非发起消息的边缘模块端，不要在模块端挂载该回调。
• 发起端（边缘处理模块）：不需要注册方法监听逻辑，只需要调用IoT Hub SDK提供的InvokeDeviceMethodAsync接口，指定目标设备为myAwesomeDevice，把需要展示的温度数据作为方法请求的载荷传入，即可完成消息发起。
• 接收端（myAwesomeDevice）：在设备初始化阶段通过SetMethodHandlerAsync挂载对应的处理回调，当模块发起的直接方法请求到达设备时，回调函数会被自动触发，读取载荷中的温度数据后就可以在控制台完成展示。

方案二：云到设备（C2D）下行消息实现 #

如果不需要直接方法的即时响应能力，只是异步推送数据给设备展示，可以采用更轻量的C2D消息模式：

• 边缘端模块不需要特殊的接口调用，直接用常规的SendMessageAsync发遥测消息的逻辑即可，Edge Hub会自动把匹配目标设备的消息投递到对应设备的内置消息队列。
• 接收端（myAwesomeDevice）按照常规的C2D消息接收逻辑，注册消息接收处理器，就可以持续收到模块推送的展示数据。

配置校验注意事项 #

• 必须在IoT Hub端把myAwesomeDevice配置为当前IoT Edge网关的下游叶子设备，不能作为独立直连IoT Hub的设备存在，否则所有下行消息都会从公有云侧路由，不会经过本地Edge Hub完成低延迟投递。
• 默认Edge Hub的安全策略允许同网关下的模块和下游叶子设备双向通信，不需要额外开放权限；如果是自定义了严格的访问控制规则，需要确认模块有向目标设备发送消息、发起直接方法的权限。
• 如果采用直接方法实现双向交互，不需要在Edge Hub的自定义路由规则中添加额外配置——直接方法走的是Edge Hub独立的管理通道，和用户自定义的遥测消息路由通道相互独立。

内容的提问来源于stack exchange，提问作者zachcdr