Fiware - Orion Context Broker subscription not sent to STH, "conditions was supposed to be an array"

Question

When trying to use STH to be able to store and retrieve data sent to OCB, I have a problem making the subscription.

My problem is that the subscription creation goes well. When I create the subscription as following:

POST /v1/contextSubscriptions HTTP/1.1
Host: <cb_host>:1026
Content-Type: application/json
Fiware-Service: myService
Fiware-ServicePath: /myServicePath
Cache-Control: no-cache

{
  "entities": [
    {
      "type": "cameraSimple",
      "isPattern": "true",
      "id": "sensor03"
    }
  ],
  "attributes": [ 
    "class" 
    ],
  "reference": "http://<cb_host>:8666/notify",
  "duration": "P1M",
  "notifyConditions": [
    {
      "type": "ONCHANGE",
      "condValues": [
        "class"
        ]
    }
  ],
    "throttling": "PT5S"
}

I receive following answer:

{
  "subscribeResponse": {
    "subscriptionId": "588b4f38e2066a50fa98df9b",
    "duration": "P1M",
    "throttling": "PT5S"
  }
}

but on the Fiware server, i see an error about the conditions in the terminal running the containers, and another one about the attributes:

orion               | ERROR@14:06:10  safeMongo.cpp[302]: Runtime Error (field 'conditions' was supposed to be an array but type=4 in BSONObj <{ _id: ObjectId('588b4f96e2066a50fa98df9c'), expiration: 1488116886, reference: "http://<cb_host>:8666/notify", custom: false, throttling: 5, servicePath: "/myServicePath", status: "active", entities: [ { id: "sensor03", isPattern: "true", type: "cameraSimple", isTypePattern: false } ], attrs: [ "class" ], metadata: [], blacklist: false, conditions: [ "class" ], expression: { q: "", mq: "", geometry: "", coords: "", georel: "" }, format: "JSON" }> from caller mongoSubCacheItemInsert:221)
orion               | ERROR@13:48:10  safeMongo.cpp[302]: Runtime Error (field 'attrs' was supposed to be an array but type=4 in BSONObj <{ _id: ObjectId('588b4f96e2066a50fa98df9c'), expiration: 1488116886, reference: "http://<cb_host>:8666/notify", custom: false, throttling: 5, servicePath: "/myServicePath", status: "active", entities: [ { id: "sensor03", isPattern: "true", type: "cameraSimple", isTypePattern: false } ], attrs: [ "class" ], metadata: [], blacklist: false, conditions: [ "class" ], expression: { q: "", mq: "", geometry: "", coords: "", georel: "" }, format: "JSON" }> from caller mongoSubCacheItemInsert:215)

Also, when updating a value on my entity,

PUT /v2/entities/sensor03/attrs/class/value HTTP/1.1
Host: <cb_host>:1026
Accept: application/json
Fiware-Service: myService
Fiware-ServicePath: /myServicePath
Cache-Control: no-cache

"monitor"

I get nothing when querying the STH:

GET /STH/v1/contextEntities/type/myDevice/id/sensor03/attributes/class?lastN=10 HTTP/1.1
Host: <cb_host>:8666
Accept: application/json
Fiware-Service: myService
Fiware-ServicePath: /myServicePath
Cache-Control: no-cache

returns:

{
  "contextResponses": [
    {
      "contextElement": {
        "attributes": [
          {
            "name": "class",
            "values": []
          }
        ],
        "id": "sensor03",
        "isPattern": false,
        "type": "myDevice"
      },
      "statusCode": {
        "code": "200",
        "reasonPhrase": "OK"
      }
    }
  ]
}

Note:

I use NGSI V1, as I suspect V2 is not yet supported for STH receiving NGSI V2 notifications regarding this issue. Also i didn't find any documentation regarding "Getting historical raw context information" with NGSI V2, e.g on this page

I use Docker-machine with a single Debian 8 VM running on Fiware-Lab with following images:

mongodb:
    image: mongo:2.6
    hostname: mongodb
    container_name: mongodb
    command: --smallfiles

orion:
    image: fiware/orion:develop
    hostname: orion
    container_name: orion
    links:
      - mongodb
    expose:
      - "1026"
    ports:
      - "1026:1026"
    command: -dbhost mongodb

fiware-sth-comet:   
    image: telefonicaiot/fiware-sth-comet   
    links:
      - mongodb   
    ports:
      - "8666:8666"   
    environment:
      - STH_HOST=0.0.0.0
      - DB_URI=mongodb:27017

EDIT 1: After removing the "develop" of Orion Docker image I am now running verison "1.6.0-next" of Orion, and I don't have any more the runtime error. Still, I can't get any historical value of the attributes of the entity. I must be doing some error in the request, but I don't know where.

Now my docker-compose file looks like this:

mongo:
  image: mongo:3.2
  command: --nojournal

orion:
    image: fiware/orion
    links:
        - mongo
    ports:
        - "1026:1026"
    command: -dbhost mongo

fiware-sth-comet:
  image: telefonicaiot/fiware-sth-comet
  links:
    - mongo
  ports:
    - "8666:8666"
  environment:
    - STH_HOST=0.0.0.0
    - DB_URI=mongo:27017

cygnus:
  image: fiware/cygnus-ngsi
  links:
    -mongo

EDIT 2: Following @GermánTorodelValle advice, I try to simulate a notification to the STH container like the CB would send:

curl -X POST -H "Accept: application/json" -H "Content-Type: application/json" -H "Fiware-Service: myService" -H "Fiware-ServicePath: /myServicePath" -d '{
"subscriptionId" : "57a9ce8ae997e37e85a4be39",
"originator" : "orion.contextBroker.instance",
"contextResponses" : [
    {
        "contextElement" : {
            "attributes" : [
                {
                    "name" : "class",
                    "type" : "Text",
                    "value" : "monitor"
                }
            ],
            "type" : "cameraSimple",
            "isPattern" : "false",
            "id" : "sensor03"
        },
        "statusCode" : {
            "code" : "200",
            "reasonPhrase" : "OK"
        }
    }
]
}' "http://172.17.0.1:8666/notify"

The log on STH container is as following:

time=2017-02-02T13:50:36.809Z | lvl=ERROR | corr=39638217-c300-48c0-9122-bff6164d5298 | trans=39638217-c300-48c0-9122-bff6164d5298 | op=OPER_STH_POST | from=n/a | srv=myService | subsrv=/myServicePath | comp=STH | msg=Error when getting the raw data collection for storing:MongoError: db already exists with different case already have: [sth_myservice] trying to create [sth_myService]
time=2017-02-02T13:50:36.810Z | lvl=WARN | corr=c322ddc8-2140-484b-a123-4e5b9b60742e | trans=c322ddc8-2140-484b-a123-4e5b9b60742e | op=OPER_STH_POST | from=n/a | srv=myService | subsrv=/myServicePath | comp=STH | msg=POST /notify, event={"request":"1486043436805:3577e9b29ee6:1:iym1stlz:10018","timestamp":1486043436810,"tags":["handler","error"],"data":{"msec":3.6443320512771606,"error":"db already exists with different case already have: [sth_myservice] trying to create [sth_myService]","data":{"name":"MongoError","message":"db already exists with different case already have: [sth_myservice] trying to create [sth_myService]","ok":0,"errmsg":"db already exists with different case already have: [sth_myservice] trying to create [sth_myService]","code":13297,"isBoom":true,"isServer":true,"data":null,"output":{"statusCode":500,"payload":{"statusCode":500,"error":"Internal Server Error","message":"An internal server error occurred"},"headers":{}}}},"internal":true}
time=2017-02-02T13:50:36.812Z | lvl=ERROR | corr=6c864793-c7ef-462a-a43d-75cdae8d20a3 | trans=6c864793-c7ef-462a-a43d-75cdae8d20a3 | op=OPER_STH_POST | from=n/a | srv=myService | subsrv=/myServicePath | comp=STH | msg=POST /notify, event={"request":"1486043436805:3577e9b29ee6:1:iym1stlz:10018","timestamp":1486043436811,"tags":["internal","error"],"data":{"name":"MongoError","message":"db already exists with different case already have: [sth_myservice] trying to create [sth_myService]","ok":0,"errmsg":"db already exists with different case already have: [sth_myservice] trying to create [sth_myService]","code":13297,"isBoom":true,"isServer":true,"data":null,"output":{"statusCode":500,"payload":{"statusCode":500,"error":"Internal Server Error","message":"An internal server error occurred"},"headers":{"content-type":"application/json; charset=utf-8","cache-control":"no-cache","content-length":96}}},"internal":true}
time=2017-02-02T13:50:38.143Z | lvl=INFO | corr=n/a | trans=n/a | op=OPER_STH_SERVER_LOG | from=n/a | srv=n/a | subsrv=n/a | comp=STH | msg=Everything OK, 0 requests attended in the last 60s interval

A bit off-topic, but, regarding "I use NGSI V1, as I suspect V2 is not yet supported for STH receiving NGSI V2 notifications", note that you can use NGSIv2 subscriptions (i.e. `POST /v2/subscriptions`) with NGSIv1 format in notifications. Have a look to https://fiware-orion.readthedocs.io/en/master/user/ngsiv2_implementation_notes/index.html#legacy-attribute-format-in-notifications for more detail — fgalan, Jan 27 '17 at 19:22
Moreover, `image: fiware/orion:develop` could lead to an old Orion version, as develop was deprecated as main branch time ago (months). I'd recommend you to use `image: fiware/orion:latest` instead. It would be great if after that you could edit your question post to include the exact OCB version (i.e. the result of `GET /version` on the OCB service port). — fgalan, Jan 27 '17 at 19:25
Finally, the `Runtime Error` log traces you mention are probably due to a little bug (fixed time ago) that caused to log as error situations that actually aren't. If you use latest OCB version (as suggested in my comment above) these error traces will probably disappear. — fgalan, Jan 27 '17 at 19:26
Thanks @fgalan, I got rid of the Runtime Error by setting latest OCB in compose file. Before it was "version": "1.3.0-next". I edited the question to include the actual OCB version as you suggested. — lukas, Jan 30 '17 at 09:39
After reading the logs, notice that for some reason (probably a previous test) there is a database already created with the name "sth_myservice" and consequently we cannot use (it's a MongoDB restriction) the service with a different capitalization such as in: "myService", as I did in my notification example based on the provided info :) You have 2 options here: 1) delete the previous database ("sth_myservice) if you have no important data there and re-send the notification and 2) adapt my example changing "myService" by "myservice" as the service name. I hope it works ;) — Germán Toro del Valle, Feb 06 '17 at 10:53
Thanks @GermánTorodelValle, that was it. I dropped the db and now it works fine. — lukas, Feb 06 '17 at 14:47

Germán Toro del Valle · Accepted Answer · 2017-02-06T14:27:36.883

1

Since the question is so self-contained and complete (thank you very much for that, @lukas), let me just remark 2 aspects as a summary and answer:

The STH only support NGSI v1 notifications so please subscribe the STH to the Context Broker instance using NGSI v1.
The MongoDB database imposes as a restriction that 2 databases cannot have the same name but distinct capitalization (see https://docs.mongodb.com/manual/reference/limits/#naming-restrictions), consequently you cannot use 2 distinct service names which only vary their capitalization with the STH since the database name is generated from the service name. This is, you cannot use myservice and myService as services for whose the STH is going to aggregate data. Include some additional character on any of them and everything should be fine.

Thank you very much! ;)

edited Feb 06 '17 at 14:27

answered Jan 30 '17 at 12:22

Germán Toro del Valle

105
6

Ok, so I believe it is a problem when registering the subscription. In STH container, I get no log when updating the entity attribute, although I get following message in Orion log: `Notification Successfully Sent to :8666/notify`. Or do I need to sent it to STH-container's ip (internal) address? I run all GE in the same VM but in different docker containers. Also, when trying to retrieve the historical data, I get following error: `Error when getting the raw data collection for retrieval (the collection may not exist)`. – lukas Jan 30 '17 at 14:13
1

First off, sorry for adding my comment as an answer, I thought I was commenting... :( Right, it seems an issue with the connection between the CB and the STH. In fact, I would suggest you to send a notification (simulate one) to the STH to check that it registers the raw and aggregated data and then we'll try to fix the connection (which as you mentioned should be an IP accessibility issue). Thank! (If you need me to tell you how to send a notification to the STH, just let me know... ;)) – Germán Toro del Valle Jan 30 '17 at 17:20
1

The message `Notification Successfully Sent to :8666/notify` use to mean that Orion has correctly delivered the notificationo (in this case, to STH). However, please follow @GermánTorodelValle's advice in order to increase log level at STH and see what could be going on... – fgalan Jan 31 '17 at 20:25
Thanks for help. @GermánTorodelValle, if you could be so nice and tell me how to do that, that would be nice. By the way, I tried to run accumulator server to see if my notifications work correctly and it works well. I had to do the workaround to change "localhost" by "172.17.0.1" when switching on the server, and also in the notification url of the subscription, as stated in this question: http://stackoverflow.com/questions/36624433/subscriptions-dont-seem-to-work-using-dockerized-fiware-orion – lukas Feb 01 '17 at 22:08
1

Absolutely, my pleasure :) You can find the curl command you can use to send a notification to your STH instance simulating the ones the CB may send here: http://pastebin.com/z5pmNGxa Notice that I was not able to find the type of your `class` attribute and I included a placeholder. On the other hand, I included random values for the `subscriptionId` and `originator`. None of them are used by the STH but I thought it would be nicer to send a proper NGSI v1 notification. Thanks! – Germán Toro del Valle Feb 02 '17 at 08:04
@GermánTorodelValle, Thanks, I updated the question with the log result. Seems like STH tries to create a DB that already exists. – lukas Feb 02 '17 at 14:08

Fiware - Orion Context Broker subscription not sent to STH, "conditions was supposed to be an array"

1 Answers1