用于模拟 IoT 代理命令的 NGSI v2 端点是什么？

Question

测试南向命令时，我目前使用的是 NGSI v1 端点，如下所示：

curl -X POST \
  'http://{{iot-agent}}/v1/updateContext' \
  -H 'Content-Type: application/json' \
  -H 'fiware-service: openiot' \
  -H 'fiware-servicepath: /' \
  -d '{
    "contextElements": [
        {
            "type": "Bell",
            "isPattern": "false",
            "id": "urn:ngsi-ld:Bell:001",
            "attributes": [
                {
                    "name": "ring",
                    "type": "command",
                    "value": ""
                }
            ]
        }
    ],
    "updateAction": "UPDATE"
}'

如您所见，这是一个 NGSI v1 请求。根据 Slideshare（幻灯片 16）上的 this presentation， 不鼓励 使用 NGSI v1 - 我想用 NGSI v2 请求替换它。我相信所有物联网代理现在都支持 NGSI v2，但是我无法在文档中找到替换 NGSI v2 请求的详细信息。

所以问题是使用 NGSI v2 模拟来自 Orion 的命令的等效 cUrl 命令是什么？

Answer 1

在 this document 中，您可以看到关于如何使用 NGSIv2 发送命令的很好的参考 API:

If you take a look to the previous device example, you can find that a "ping" command was defined. Any update on this attribute “Ping” at the NGSI entity in the ContextBroker will send a command to your device. For instance, to send the "Ping" command with value "Ping request" you could use the following operation in the ContextBroker API:
 PUT /v2/entities/[ENTITY_ID]/attrs/ping

 {
   "value": "Ping request",
   "type": "command"
 }
ContextBroker API is quite flexible and allows to update an attribute in several ways. Please have a look to the NGSIv2 specification for details.

Important note: don't use operations in the NGSI API with creation semantics. Otherwise, the entity/attribute will be created locally to ContextBroker and the command will not progress to the device (and you will need to delete the created entity/attribute if you want to make it to work again). Thus, the following operations must not be used:

POST /v2/entities

PUT /v2/entities

POST /v2/op/entites with actionType append, appendStrict or replace

POST /v1/updateContext with actionType APPEND, APPEND_STRICT or REPLACE

编辑：以上均指最终客户端用于发送命令的Orion端点。 @jason-fox 已经澄清问题是指从 Orion 接收命令请求的 IOTA 端点（{{iot-agent}} 应该很明显，但我错过了那部分抱歉： )

Orion 到 IOTA 的命令通信基于注册转发机制。目前，Orion 始终使用 NGSIv1 转发更新（即使在客户端使用 NGSIv2 更新的情况下）。未来，我们设想使用 NGSIv2，但为了实现这一点，首先我们需要：

完成基于 NGSIv2 的上下文源转发规范。目前正在讨论中in this PR。欢迎反馈作为对该 PR 的评论！

在 Orion 中实现基于 Context Source Forwarding Specification 的转发

在 IOTA 中实现符合上下文源转发规范的 NGSIv2 端点。

虽然上述已经完成，但唯一的机制是当前基于 NGSIv1 的机制。但是，请注意，Orion-IOTA 交互是平台组件内部的，最终客户端可以将他们与平台（特别是 Orion 端点）的所有交互基于 NGSIv2，因此这不是一个大问题。

Answer 2

基于 NGSIv2 的上下文源转发规范现已完成，旧的 /v1 端点已被弃用。根据相关Support for NGSIv2issue的讨论，正确的发送请求如下：

curl -iX POST \
  http://localhost:4041/v2/op/update \
  -H 'Content-Type: application/json' \
  -H 'fiware-service: openiot' \
  -H 'fiware-servicepath: /' \
  -d '{
    "actionType": "update",
    "entities": [
        {
            "type": "Bell",
            "id": "urn:ngsi-ld:Bell:001",
            "ring" : {
                "type": "command",
                "value": ""
            }
        }
    ]
}'

用于模拟 IoT 代理命令的 NGSI v2 端点是什么？

What is the NGSI v2 endpoint for mimicking IoT Agent commands?

fiware

iot