Azure IoT Hub设备离线时C2D消息反馈误报Success问题咨询

1. 为何设备未实际消费消息时，IoT Hub仍返回Success？ #

IoT Hub返回的Success状态并非代表设备已接收/消费消息，而是指IoT Hub已成功完成消息的入队或缓存操作。
对于MQTT设备，孪生的connectionState依赖设备心跳判断状态，默认心跳间隔较长，设备离线后不会立即更新为Disconnected。此时IoT Hub仍认为设备在线，会尝试投递消息；即使设备实际已断电，只要Hub未检测到TCP连接断开（未触发超时），就会将消息存入设备的离线消息队列，并将此操作判定为“成功完成投递准备”，因此返回Success反馈。只有当消息过期且设备仍未上线时，Hub才会生成Expired的反馈。

2. 是否有内置机制返回离线时消息的Expired/Rejected状态？ #

有，但需依赖消息的过期时间设置：
当你为C2D消息指定ExpiryTimeUtc后，若设备在过期时间内始终未上线，IoT Hub会在消息过期后，向反馈接收器发送Expired状态的反馈。
注意：你当前数秒内收到的Success是消息入队成功的反馈，而非设备接收确认；Expired反馈需等待到ExpiryTimeUtc时间点才会触发，无法实时返回。IoT Hub没有内置的“实时检测设备离线并立即返回未送达”的机制，因为connectionState仅作开发参考，不具备实时性。

3. 保障命令交付或检测离线设备的推荐方案？ #

推荐以下几种方案：

• 消息过期+反馈监听：设置合理的ExpiryTimeUtc（如1分钟），通过反馈接收器监听Expired状态，以此判断消息未送达；
• 直接方法（Direct Method）：直接方法采用请求-响应模式，若设备离线，IoT Hub会立即返回504 Gateway Timeout错误，可实时判断设备状态；但该方式不支持离线缓存，适合需要实时响应的命令；
• 设备生命周期事件：通过Event Grid订阅IoT Hub的deviceDisconnected事件，实时获取设备离线状态，发送消息前先判断设备是否在线；需注意事件存在数秒到数十秒的延迟；
• 自定义ACK机制：设备接收并处理C2D消息后，主动发送遥测消息作为确认信号，云端通过监听遥测来验证消息已被消费；此方式可实现端到端的交付确认，但需要额外开发设备端逻辑。

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