CESARBR / knot-fog-connector-fiware

KNoT fog connector with FIWARE
MIT License
0 stars 3 forks source link

Support commands via Orion NGSI API v2 #1

Open netoax opened 5 years ago

netoax commented 5 years ago

The current version of this connector library is only supporting commands to devices through the Orion API v1. However, we need to support this capability by using the last version of Orion API since the first one can be deprecated in the future.

Now, both getData and setData commands are sent when the respective attribute is updated on context broker as follows:

curl --location --request POST "localhost:1026/v1/updateContext" \
  --header "fiware-service: knot" \
  --header "fiware-servicepath: /device/KNOT05" \
  --header "Content-Type: application/json" \
  --data "{
    \"contextElements\": [
        {
            \"type\": \"sensor\",
            \"isPattern\": \"false\",
            \"id\": \"1\",
            \"attributes\": [
                {
                    \"name\": \"setData\",
                    \"type\": \"command\",
                    \"value\": \"true\"
                }
            ]
        }
    ],
    \"updateAction\": \"UPDATE\"
} "

On the other hand, to send these commands with the newer API version we need to register the attributes as they were provided by any IoT Agent. After registering them, we send the command through a PATCH request and a more RESTful url such as http://localhost:1026/v2/entities/<sensor_id>/attrs. Example:

curl -iX PATCH \
  'http://localhost:1026/v2/entities/1/attrs' \
  -H 'Content-Type: application/json' \
  -H 'fiware-service: knot' \
  -H 'fiware-servicepath: /device/1571699c3578716d' \
  -d '{
    "setData": {
        "type" : "command",
        "value" : "true"
    }
}'

The commands are being received by the connector but without the command values. The main purpose of this issue is to investigate what we need to do in order to receive them.

lcbm commented 5 years ago

After some investigation, I came across this Stack Overflow Question which the user @fgalan suggests adding ?type=sensor at the end of the request url, due to reasons he mentions in the post. Its worth mentioning that this solution was added to FIWARE's Official documentation (see additional comments).

By following this advice, I was able to change the value of an actual physical device's (KNoT-Thing v01.03) sensor through the Orion NGSI API v2 using this documentation and this docker-compose.yml (see FIWARE's IoT Agent UL Docker documentation for more information on using environment variables and Docker).

Steps to reproduce:

  1. Start containers w/ $ docker-compose -f "docker-compose.yml" up -d --build
  2. Start your local knot-fog-connector w/ $ npm run start
  3. Send commands via Orion
    curl -iX PATCH \
    'http://localhost:1026/v2/entities/1/attrs?type=sensor' \
    -H 'Content-Type: application/json' \
    -H 'fiware-service: knot' \
    -H 'fiware-servicepath: /device/<device-id>' \
    -d '{
    "setData": {
        "type" : "command",
        "value" : "true"
    }
    }'
  4. Check command status
    curl -iX GET \
    'http://localhost:1026/v2/entities/1?options=keyValues' \
    -H 'fiware-service: knot' \
    -H 'fiware-servicepath: /device/<device-id>'

    note: in case you don't use ?type=sensor on step 3, you might still get a setData_info": "true", "setData_status": "OK" (which means the command was executed successfully). Despite this, the physical device's sensor (in this case, a LED) didn't actually respond to the command (it remained turned OFF). By adding ?type=sensor, it successfully changed values on Orion and in the device itself (LED turned ON).

You can find below, some logs from different containers. fiware-iot-agent_container_log.txt knot-fog-connector_log.txt mosquitto_container_log.txt

lcbm commented 4 years ago

@joaoaneto, I feel like this issue should closed. Could you take a moment to review it?