telefonicaid / iotagent-node-lib

Module to enable IoT Agent developers to build custom agents for their devices that can easily connect to NGSI Context Brokers
https://iotagent-node-lib.rtfd.io/
GNU Affero General Public License v3.0
60 stars 85 forks source link

Unable send commands from Orion to Device #1464

Closed jason-fox closed 11 months ago

jason-fox commented 11 months ago

IoT Agent Node Lib version the issue has been seen with

3.2.0

Bound or port used (API interaction)

Southbound (Devices data API), Northbound (Provision API and NGSI Interactions)

NGSI version

NGSIv2

Are you running a container?

Yes, I am using a container (Docker, Kubernetes...)

Image type

normal

Expected behaviour you didn't see

This is a result of #1421 -specifically the removal of the intial Entity.

When I create a Group

 {
     "apikey":      "3020035",
     "cbroker":     "http://orion:1026",
     "entity_type": "Bell",
     "resource":    "/iot/d",
     "protocol":    "PDI-IoTA-UltraLight",
     "transport":   "HTTP",
 },

and provision an actuator:

{
      "device_id": "bell001",
      "entity_name": "Bell:001",
      "entity_type": "Bell",
      "endpoint": "http://iot-sensors:1041/iot/bell001",
      "commands": [ 
        {
          "name": "ring",
          "type": "command"
        }
      ],
      "static_attributes": [
          {"name": "refStore", "type": "Relationship","value": "urn:ngsi-ld:Store:001"}
      ]
    },

No Entity is created in the context broker.

Unexpected behaviour you saw

Sincent he initial insert of an Entity has been removed, so

curl -L 'http://localhost:1026/v2/entities/Bell:001?options=keyValues' \
-H 'fiware-service: openiot' \
-H 'fiware-servicepath: /'

is just returning:

{
    "id": "Bell:001",
    "type": "Bell",
    "ring": ""
}

However, I cannot PUT or PATCH an Entity with Orion

curl -L -X PUT 'http://localhost:1026/v2/entities/Bell:001/attrs/ring' \
-H 'fiware-service: openiot' \
-H 'fiware-servicepath: /' \
-H 'Content-Type: application/json' \
-d '{
      "type" : "command",
      "value" : ""
}'

is returning:

{
    "error": "NotFound",
    "description": "The requested entity has not been found. Check type and id"
}

Steps to reproduce the problem

No response

Configs

  orion:
    labels:
      org.fiware: 'tutorial'
    image: quay.io/fiware/orion:3.10.1
    hostname: orion
    container_name: fiware-orion
    depends_on:
      - mongo-db
    networks:
      - default
    expose:
      - 1026
    ports:
      - 1026:1206
    command: -dbhost mongo-db -logLevel DEBUG
    healthcheck:
      test: curl --fail -s http://orion:1026/version || exit 1
      interval: 5s

  # IoT-Agent is configured for the UltraLight Protocol
  iot-agent:
    labels:
      org.fiware: 'tutorial'
    image: quay.io/fiware/iotagent-ul:2.4.0-distroless
    hostname: iot-agent
    container_name: fiware-iot-agent
    depends_on:
      - mongo-db
    networks:
      - default
    ports:
      - "${IOTA_NORTH_PORT}:${IOTA_NORTH_PORT}" # localhost:4041
      - "${IOTA_SOUTH_PORT}:${IOTA_SOUTH_PORT}" # localhost:7896
    environment:
      - IOTA_CB_HOST=orion # name of the context broker to update context
      - IOTA_CB_PORT=${ORION_PORT} # port the context broker listens on to update context
      - IOTA_NORTH_PORT=${IOTA_NORTH_PORT}
      - IOTA_REGISTRY_TYPE=mongodb #Whether to hold IoT device info in memory or in a database
      - IOTA_LOG_LEVEL=INFO # The log level of the IoT Agent
      - IOTA_TIMESTAMP=true # Supply timestamp information with each measurement
      - IOTA_CB_NGSI_VERSION=v2 # use NGSIv2 when sending updates for active attributes
      - IOTA_AUTOCAST=true # Ensure Ultralight number values are read as numbers not strings
      - IOTA_MONGO_HOST=mongo-db # The host name of MongoDB
      - IOTA_MONGO_PORT=${MONGO_DB_PORT} # The port mongoDB is listening on
      - IOTA_MONGO_DB=iotagentul # The name of the database used in mongoDB
      - IOTA_HTTP_PORT=${IOTA_SOUTH_PORT} # The port used for device traffic over HTTP
      - IOTA_PROVIDER_URL=http://iot-agent:${IOTA_NORTH_PORT}
    healthcheck:
      interval: 5s

Log output

No response

jason-fox commented 11 months ago

Hmmm, the more I look into this, the more I think it is an Orion/NGSI-v2 bug. This issue is NGSI-v2 only since it isn't an issue for any NGSI-LD brokers.

Specifically, if I have a registration on Entity:XXX for attribute ZZZ, then a local instance shouldn't be necessary within Orion. It is really, really weird that Orion allows me to GET the device, but I can't actuate the device with a PUT/PATCH because "it doesn't exist" because it damn well does exist - I can see it with a GET. What doesn't exist at this point is local state data in Orion itself.

Orion should be updated to allow the forwarding of a patch on an attr if an attr is registered regardless of whether data is held within the CB. Then this issue disappears - Orion would work like any NGSI-LD broker already does.

AlvaroVega commented 11 months ago

IMHO this could be a bug for orion, but not an iotagent bug. Your flow works fine when I include '?type=Belll'

curl -L -X PUT 'http://localhost:10026/v2/entities/Bell:001/attrs/ring?type=Bell' -H 'fiware-service: smartcity' -H 'fiware-servicepath: /' -H 'Content-Type: application/json' -d '{
      "type" : "command",
      "value" : "2"
}'
AlvaroVega commented 11 months ago

This issue should be transfer to orion repository.

mapedraza commented 11 months ago

This bug impacts both Orion and IoTAs. I just created an issue in the Orion repo: https://github.com/telefonicaid/fiware-orion/issues/4430 describing the problem related with the CPrs and registrations.

AlvaroVega commented 11 months ago

If no PR or fix in iotas are expected this issue should be closed here.

fgalan commented 11 months ago

I understand that documentation improvements (to explain that an entity needs to be provisioned while https://github.com/telefonicaid/fiware-orion/issues/4430 stills in order the commands mechanism to work) is part of #1465. In that case, I agree in closing this issue.