Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable send commands from Orion to Device #1464

Closed
jason-fox opened this issue Sep 21, 2023 · 6 comments
Closed

Unable send commands from Orion to Device #1464

jason-fox opened this issue Sep 21, 2023 · 6 comments

Comments

@jason-fox
Copy link
Contributor

jason-fox commented Sep 21, 2023

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
Copy link
Contributor Author

jason-fox commented Sep 21, 2023

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
Copy link
Member

AlvaroVega commented Sep 21, 2023

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
Copy link
Member

This issue should be transfer to orion repository.

@mapedraza
Copy link
Collaborator

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

@AlvaroVega
Copy link
Member

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

@fgalan
Copy link
Member

fgalan commented Sep 27, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants