FIWARE - Orion 上下文代理作为上下文提供者

Question

我很难理解上下文提供程序在 Orion 上下文代理中的工作方式。 我按照 Jason Fox 编写的分步指南中的示例进行操作。但是，我仍然不完全了解后台发生的情况以及上下文代理如何从注册中准确创建 POST。这是我想要做的：

我确实有一个气象站，可以为社区提供传感器数据。

{
  "id": "urn:ngsi-ld:WeatherStation:001",
  "type": "Device:WeatherStation",
  "temperature": {
    "type": "Number",
    "value": 20.5,
    "metadata": {}
  },
  "windspeed": {
    "type": "Number",
    "value": 60.0,
    "metadata": {}
  }
}

现在我喜欢 WeatherStation 成为所有建筑物的上下文提供者。

{
  "id": "urn:ngsi-ld:building:001",
  "type": "Building"
}

这是我尝试使用的注册。

{
  "id": null,
  "description": "Random Weather Conditions",
  "provider": {
    "http": {
      "url": "http://localhost:1026/v2"
    },
    "supportedForwardingMode": "all"
  },
  "dataProvided": {
    "entities": [
      {
        "id": "null",
        "idPattern": ".*",
        "type": "Building",
        "typePattern": null
      }
    ],
    "attrs": [
      "temperature",
      "windspeed"
    ],
    "expression": null
  },
  "status": "active",
  "expires": null,
  "forwardingInformation": null
}

上下文代理接受实体和注册，没有任何错误。

因为我有一个多租户设置，所以我使用一个fiware_service 来表示整个社区，但以后每栋建筑都会有一个单独的fiware_servicepath。因此，气象站具有与建筑物不同的服务路径。尽管我也尝试将它们放在同一条路径上。

现在我对所有实体使用相同的标题。

{
  "fiware-service": "filip",
  "fiware-servicepath": "/testing"
}

这里是上下文代理的日志（版本：3.1.0）：

INFO@2021-09-23T19:17:17.944Z  logTracing.cpp[212]: Request forwarded (regId: 614cd2b511c25270060d873a): POST http://localhost:1026/v2/op/query, request payload (87 bytes): {"entities":[{"idPattern":".*","type":"Building"}],"attrs":["temperature","windspeed"]}, response payload (2 bytes): [], response code: 200


INFO@2021-09-23T19:17:17.944Z  logTracing.cpp[130]: Request received: POST /v2/op/query?options=normalized%2Ccount&limit=1000, request payload (55 bytes): {"entities": [{"idPattern": ".*", "type": "Building"}]}, response code: 200

日志说它收到请求并按预期转发。但是，据我了解，这只会再次指向同一个建筑实体。因此，它在某种程度上是一个循环转发。我也无法告诉任何有关请求标头的信息。

我不明白来自建筑物的转发请求如何实际向气象站查询信息。当我查询我的建筑物时，我仍然只收到没有自己属性的实体：

{
  "id": "urn:ngsi-ld:building:001",
  "type": "Building"
}

我也尝试更改注册的网址，但没有成功。

1. 当前的实现真的可以实现这种情况吗？这将非常有用
2. 是否有任何示例包括标题？

我知道我可以简单地使用参考，但这会给用户带来更多的工作。

感谢您对此的任何帮助。

Answer 1

这很混乱，但您可以通过订阅来实现。将气象站作为上下文代理中的单独实体保存，并轮询或将更新推送到实体中。只要数据发生变化并发出两个 NGSI 请求，订阅就会触发：

• 查找所有具有servicedBy=WeatherStationX 关系的实体
• 对所有实体运行 upsert 以向每个实体添加属性：

{
   "temperature" : {
      "type" : "Property",
      "value" : 7,
      "unitCode": "CEL",
      "observedAt": "XXXXX",
      "providedBy": "WeatherStation1"
   }
}

observedAt 来自气象站的有效载荷或通知时间戳。

在现有的 IoT 代理中，配置 link attribute 允许设备将测量结果传播到第二个实体（例如，此温度计实体正在测量关联建筑实体的温度）

{
     "entity_type": "Device",
     "resource":    "/iot/d",
     "protocol":    "PDI-IoTA-UltraLight",
..etc
     "attributes": [
        {"object_id": "l", "name": "temperature", "type":"Float",
          "metadata":{
              "unitCode":{"type": "Text", "value" :"CEL"}
          }
        }
     ],
     "static_attributes": [
        {
          "name": "controlledAsset",
          "type": "Relationship",
          "value": "urn:ngsi-ld:Building:001",
          "link": {
             "attributes": ["temperature"],
             "name": "providedBy",
             "type": "Building"
          }
        }
     ]
  }

目前逻辑只是一对一的直接链接，但可以提出 PR 来检查数组并在 upsert 中更新多个实体 - 相关的代码部分是 here