Что такое конечная точка NGSI v2 для имитации команд агента IoT? - PullRequest
Новая
       6

Что такое конечная точка NGSI v2 для имитации команд агента IoT?

0 голосов
/ 27 июня 2018

При тестировании команд Southbound в настоящее время я использую конечную точку 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) использование NGSI v1 не рекомендуется - я хотел бы заменить это запросом NGSI v2. Я считаю, что все агенты IoT теперь поддерживают NGSI v2, однако мне не удалось найти подробную информацию о запросе на замену NGSI v2 в документации.

Таким образом, вопрос в том, что эквивалентна команда cUrl для имитации команды из Ориона с использованием NGSI v2?

1 Ответ

0 голосов
/ 27 июня 2018

В этом документе вы можете найти хорошую справку о том, как отправлять команды с помощью API NGSIv2:

Если вы посмотрите на предыдущий пример устройства, вы обнаружите, что была определена команда «ping». Любое обновление этого атрибута «Ping» в объекте NGSI в ContextBroker отправит команду на ваше устройство. Например, чтобы отправить команду «Ping» со значением «Ping request», вы можете использовать следующую операцию в API ContextBroker: 

 PUT /v2/entities/[ENTITY_ID]/attrs/ping

 {
   "value": "Ping request",
   "type": "command"
 }

ContextBroker API достаточно гибок и позволяет обновлять атрибут несколькими способами. Пожалуйста, обратитесь к спецификации NGSIv2 для получения подробной информации.

Важное примечание: не использует операции в NGSI API с семантикой создания. В противном случае объект / атрибут будет создан локально для ContextBroker, и команда не перейдет на устройство (и вам нужно будет удалить созданный объект / атрибут, если вы хотите, чтобы он снова работал). Таким образом, следующие операции не должны использоваться :

  • POST /v2/entities
  • PUT /v2/entities
  • POST /v2/op/entites с actionType append, appendStrict или replace
  • POST /v1/updateContext с actionType APPEND, APPEND_STRICT или REPLACE

EDIT : все вышеперечисленное относится к конечной точке Orion, используемой конечным клиентом для отправки команд . @ jason-fox уточнил, что этот вопрос относится к конечной точке IOTA, которая получает запрос команд от Ориона (это должно было быть видно по {{iot-agent}}, но я пропустил эту часть извините:)

Связь между Orion-IOTA для команд основана на механизме регистрации-пересылки. В настоящее время Orion всегда использует NGSIv1 для пересылки обновлений (даже в том случае, если клиент использует обновления NGSIv2). В будущем мы планируем использовать NGSIv2, но для этого сначала нам нужно:

  • Завершить спецификацию перенаправления источника контекста, основанную на NGSIv2. В настоящее время обсуждается в этом PR . Отзывы приветствуются в качестве комментариев к этому PR!
  • Для реализации пересылки на основе спецификации перенаправления источника контекста в Orion
  • Для реализации конечной точки NGSIv2, соответствующей спецификации перенаправления источника контекста в IOTA.

Пока вышеперечисленное завершено, единственным механизмом является текущий, основанный на NGSIv1. Однако обратите внимание, что взаимодействие Orion-IOTA является внутренним по отношению к компоненту платформы, и конечный клиент может основывать все свои взаимодействия с платформой (в частности, с конечной точкой Orion) на NGSIv2, так что это не является большой проблемой.

...