【问题标题】:Azure Device Twin Keeps Previous DataAzure 设备孪生保留以前的数据
【发布时间】:2017-10-04 12:51:59
【问题描述】:

我在 Azure IOT Hub 中使用 Azure Device Twin,这个问题与 Device Twin 行为有关。

我有一个 DeviceTwin 结构如下,我使用纯 MQTT 协议向其中发布数据。

我用来发布孪生数据的主题是:$iothub/twin/PATCH/properties/reported/?$rid=c1a12cc8-4168-4e16-a1bb

我发送的有效载荷是:

{
  "deviceId": "34aa078e",  
  "properties": {
    "desired": {

    },
    "reported": {
      "notifications": {
        "notification1": {
          "primaryCode": "crprim1",          
          "statusChangeTimestamp": 1507115005615
        },
        "notification2": {
          "primaryCode": "crprim2",          
          "statusChangeTimestamp": 1507117507027
        }
      },
      "location": {

      }      
    }
  }
}

所有功能都按照 DeviceTwin 文档中的说明正常工作,但是,关于此 DeviceTwin 的行为,我有一个澄清要澄清。

当我通过 MQTT 发送包含一个新通知(名为 notificaion3)的消息有效负载以在 DeviceTwin 上进行更新时,它只需将 notification3 添加到 notifications 对象中,而不是仅将整个 notifications 内容替换为 @ 987654326@.

我发送的 MQTT 负载:

{
    "notifications": {
        "notification3": {
          "primaryCode": "crprim3",          
          "statusChangeTimestamp": 1607115005615
        }
    }
}

所以我最终会在 DeviceTwin 结构中得到关注,

{
  "deviceId": "34aa078e",  
  "properties": {
    "desired": {

    },
    "reported": {
      "notifications": {
        "notification1": {
          "primaryCode": "crprim1",          
          "statusChangeTimestamp": 1507115005615
        },
        "notification2": {
          "primaryCode": "crprim2",          
          "statusChangeTimestamp": 1507117507027
        },
        "notification3": {
          "primaryCode": "crprim3",          
          "statusChangeTimestamp": 1607115005615
        }
      },
      "location": {

      }      
    }
  }
}

而不是跟随,

{
  "deviceId": "34aa078e",  
  "properties": {
    "desired": {

    },
    "reported": {
      "notifications": {        
        "notification3": {
          "primaryCode": "crprim3",          
          "statusChangeTimestamp": 1607115005615
        }
      },
      "location": {

      }      
    }
  }
}

但设备孪生应该包含给定设备的最新快照,并且不应该保留以前的数据(相对于对象级别)。 这是 Azure Device Twin 的常见行为吗?或者它是某种错误?

【问题讨论】:

    标签: azure azure-iot-hub


    【解决方案1】:

    您基于上述描述的设备孪生行为不正确。您应该会看到所有通知属性 (1,2,3)。

    您可以使用 MQTTBox Client、iotdevtool.com、Azure IoT Hub Tester 等第三方工具查看设备孪生行为。

    以下屏幕 sn-ps 在我的 Azure IoT 中心区域显示此测试:

    第 1 步:将 notification1notification2 添加到 device2 孪生报告的 notifications 属性中:

    第 2 步:获取 device2 twin 并将 notification3 添加到报告的 notifications 属性中:

    第 3 步:获取 device2 孪生以查看所有 通知 属性

    【讨论】:

    • 是的,你是对的,在这种情况下我可以看到所有三个通知 - 我在上面的“所以我最终将在 DeviceTwin 结构中遵循”部分中明确说明了这一点。实际上我真正的问题是,这是设备双胞胎的预期和正确行为 - 保留历史数据......
    • 您的通知设备孪生状态应针对此“通知”进行更改:{ "id":3, "primaryCode": "crprim3", "statusChangeTimestamp": 1607115005615 }
    【解决方案2】:

    这不是错误。有关 Azure Device Twin 的这种行为的详细信息,您可以参考this document

    根据您的描述,您希望持续更新一个被举报的属性。这里我们称之为“notification1”。所以你的 MQTT 负载应该是这样的:

    {
        "notifications": {
            "notification1": {
              "primaryCode": "crprim3",          
              "statusChangeTimestamp": 1607115005615
            }
        }
    }
    

    不是这个:

    {
        "notifications": {
            "notification3": {
              "primaryCode": "crprim3",          
              "statusChangeTimestamp": 1607115005615
            }
        }
    }
    

    保持属性名称不变,只更新其值。

    要删除其他冗余属性,您可以将其值设置为 NULL,如下所示:

    {
        "notifications": {
            "notification2": null,
            "notification3": null
        }
    }
    

    【讨论】:

    • 我认为我们在这里有一个困惑。我想要的是在我发送通知3 后保留它。但是在这种情况下,当我在设备孪生中有 notification1 和 notification2 时,一旦我发送名为 notification3 的新通知,设备孪生就会拥有所有三个通知。所以,我想知道这是否是正确的行为。我试图将其与 AWS - Device Shadow 进行比较,其中它们只保留最新值,这意味着在这种情况下,最后它只会有通知 3。 Tnx。
    • @gbids 当您使用不同的属性名称(notification3)设备孪生时,将其视为新添加的属性,并且此操作会部分更新“通知”,因此您将在此处获得所有三个通知。
    • 你是对的。我基本上是想看看我们是否可以获得与 Azure 的 AWS Device Shadow / Thing 相同的行为。但是,似乎没有。
    • @gbids 如果您只保留一个通知,您可以删除外部“通知”并只使用“通知”:{“primaryCode”:“crprim3”,“statusChangeTimestamp”:1607115005615}。然后你可以更新它的值,它会保留最新的数据。
    猜你喜欢
    • 1970-01-01
    • 2022-01-05
    • 1970-01-01
    • 1970-01-01
    • 2021-09-17
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多