Related
Update 2
The issues might be the use of the the Orion-LD (1.0.0), when i use the 0.8.0 all the example is working.
https://github.com/kosgobakis/orion-ldSubcription
My setup is:
The Things Network (LoraWAN)
IoT Agent for LoraWAN supporting TTN and NGSI-LD GitHub
Orion-LD
Quantumleap + cratedb
Minimal web server to provide JSONLD
Provision of the sensor to the IoT Agent
curl -iL -X POST \
localhost:4041/iot/devices \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'fiware-service: openiot' \
-H 'fiware-servicepath: /' \
-d '{
"devices": [
{
"device_id": "eui-70b3d57ed004a537",
"entity_name": "urn:ngsi-ld:TemperatureSensor:temperaturesensor001",
"entity_type": "LoraDevice",
"timezone": "Europe/Athens",
"attributes": [
{
"object_id": "temperature_3",
"name": "temperatureCh3",
"type": "Float",
"metadata": {"unitCode": {"type": "Property","value": "CEL"}}
},
{
"object_id": "temperature_5",
"name": "temperatureCh5",
"type": "Float",
"metadata": {"unitCode": {"type": "Property","value": "CEL"}}
}
],
"internal_attributes": {
"lorawan": {
"application_server": {
"host": "eu1.cloud.thethings.network",
"username": "XXXX#ttn",
"password": "XXXX",
"provider": "TTN"
},
"dev_eui": "XXXXX",
"app_eui": "XXXXXX",
"application_id": "XXXXXX#ttn",
"application_key": "XXXXXX",
"data_model": "application_server"
}
},
"protocol": "LORAJSON"
}
]
}'
I successfully receive data from the TTN Network (Simulation of sensor at TTN->IoTAgent->Orion-LD)
curl -X GET 'http://localhost:1026/ngsi-ld/v1/entities/?type=LoraDevice' \
-H 'fiware-service: openiot' \
-H 'fiware-servicepath: /' \
-H 'Link: <http://context/ngsi-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"' \
-H 'Accept: application/json' |jq .
[
{
"id": "urn:ngsi-ld:TemperatureSensor:temperaturesensor001",
"type": "LoraDevice",
"temperatureCh3": {
"type": "Property",
"value": 27.2,
"observedAt": "2022-01-04T18:54:14.447Z",
"unitCode": "CEL"
},
"temperatureCh5": {
"type": "Property",
"value": 25.5,
"observedAt": "2022-01-04T18:54:14.447Z",
"unitCode": "CEL"
}
}
]
I use the following curl to create a new subscription to the Orion-LD
curl -L -X POST 'http://localhost:1026/ngsi-ld/v1/subscriptions/' \
-H 'Content-Type: application/ld+json' \
-H 'NGSILD-Tenant: openiot' \
--data-raw '{
"description": "Notify me of all changes",
"type": "Subscription",
"entities": [{"type": "LoraDevice"}],
"notification": {
"attributes": ["temperatureCh3"],
"format": "normalized",
"endpoint": {
"uri": "http://quantumleap:8668/v2/notify",
"accept": "application/json"
}
},
"#context": "http://context/ngsi-context.jsonld"
}'
and verify that i have create the subscription
curl -X GET 'http://localhost:1026/ngsi-ld/v1/subscriptions/' \
-H 'NGSILD-Tenant: openiot'|jq .
{
"id": "urn:ngsi-ld:Subscription:61d53fc5fb688acae04cd92f",
"type": "Subscription",
"description": "Notify me of all changes",
"entities": [
{
"type": "LoraDevice"
}
],
"notification": {
"attributes": [
"temperatureCh3"
],
"format": "normalized",
"endpoint": {
"uri": "http://quantumleap:8668/v2/notify",
"accept": "application/json"
}
},
"#context": "http://context/ngsi-context.jsonld"
}
]
Send new measurement (Orion-LD log: Servicing NGSI-LD request 006: POST /ngsi-ld/v1/entityOperations/upsert/), check that the Orion-LD has the new data, but no notification send to the quantumleap
[
{
"id": "urn:ngsi-ld:TemperatureSensor:temperaturesensor001",
"type": "LoraDevice",
"temperatureCh3": {
"type": "Property",
"value": 27.3,
"observedAt": "2022-01-05T06:53:17.572Z",
"unitCode": "CEL"
},
"temperatureCh5": {
"type": "Property",
"value": 25.5,
"observedAt": "2022-01-05T06:53:17.572Z",
"unitCode": "CEL"
}
}
]
I have spend some time changing the subscription request but with no success.
Is something wrong with my subscription request?
Using MongoDB Compass here is the context of the DB
orion-openiot.entities
{
"_id": {
"id": "urn:ngsi-ld:TemperatureSensor:temperaturesensor001",
"type": "https://ngsi-ld-tutorials.readthedocs.io/en/latest/datamodels.html#loraSensors",
"servicePath": "/"
},
"attrNames": ["https://ngsi-ld-tutorials.readthedocs.io/en/latest/datamodels.html#temperature1", "https://ngsi-ld-tutorials.readthedocs.io/en/latest/datamodels.html#temperature2"],
"attrs": {
"https://ngsi-ld-tutorials=readthedocs=io/en/latest/datamodels=html#temperature1": {
"value": 27.3,
"type": "Property",
"md": {
"unitCode": {
"value": "CEL"
},
"observedAt": {
"value": 1641365597.572
}
},
"mdNames": ["unitCode", "observedAt"],
"creDate": 1641365539.6579854,
"modDate": 1641365597.5791261
},
"https://ngsi-ld-tutorials=readthedocs=io/en/latest/datamodels=html#temperature2": {
"value": 25.5,
"type": "Property",
"md": {
"unitCode": {
"value": "CEL"
},
"observedAt": {
"value": 1641365597.572
}
},
"mdNames": ["unitCode", "observedAt"],
"creDate": 1641365539.6579854,
"modDate": 1641365597.5791261
}
},
"creDate": 1641365441.9127274,
"modDate": 1641365597.5791261,
"lastCorrelator": ""
}
orion-openiot.csubs
{
"_id": "urn:ngsi-ld:Subscription:61d53fc5fb688acae04cd92f",
"expiration": 2147483647,
"reference": "http://quantumleap:8668/v2/notify",
"custom": false,
"mimeType": "application/json",
"throttling": 0,
"servicePath": "/",
"description": "Notify me of all changes",
"status": "active",
"entities": [{
"id": "",
"isPattern": "",
"type": "https://ngsi-ld-tutorials.readthedocs.io/en/latest/datamodels.html#loraSensors",
"isTypePattern": false
}],
"attrs": ["https://ngsi-ld-tutorials.readthedocs.io/en/latest/datamodels.html#temperature1"],
"metadata": [],
"blacklist": false,
"ldContext": "http://context/ngsi-context.jsonld",
"createdAt": 1641365445.068897,
"modifiedAt": 1641365445.068897,
"conditions": [],
"expression": {
"q": "",
"mq": "",
"geometry": "",
"coords": "",
"georel": "",
"geoproperty": ""
},
"format": "normalized"
}
Update 1
I run the latest version of the IoTAgent
{"libVersion":"2.18.0-next","port":"4041","baseRoot":"/"}
and a minimal web server to provide JSONLD (http://context/xxxx.jsonld)
When created a minimal jsonld file like you suggested.
The IoT Agent send the following POST to Orion-LD
{
"url": "http://orion:1026/ngsi-ld/v1/entityOperations/upsert/?options=update",
"method": "POST",
"headers": {
"fiware-service": "openiot",
"fiware-servicepath": "/",
"Content-Type": "application/ld+json",
"NGSILD-Tenant": "openiot",
"NGSILD-Path": "/"
},
"json": [
{
"#context": "http://context/minimal.jsonld",
"temperatureCh3": {
"type": "Property",
"value": 436.8,
"unitCode": "CEL",
"observedAt": "2022-01-07T15:24:28.273Z"
},
"temperatureCh5": {
"type": "Property",
"value": 25.5,
"unitCode": "CEL",
"observedAt": "2022-01-07T15:24:28.273Z"
},
"id": "urn:ngsi-ld:TemperatureSensor:temperaturesensor001",
"type": "LoraDevice"
}
]
}
When i run
curl -G -X GET 'http://localhost:1026/ngsi-ld/v1/entities/urn:ngsi-ld:TemperatureSensor:temperaturesensor001' \
-H 'fiware-service: openiot' \
-H 'Link: <http://context/minimal.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"' \
-H 'Accept: application/ld+json' | jq .
{
"#context": "http://context/minimal.jsonld",
"id": "urn:ngsi-ld:TemperatureSensor:temperaturesensor001",
"type": "LoraDevice",
"temperatureCh3": {
"value": 436.8,
"type": "Property",
"unitCode": "CEL",
"observedAt": "2022-01-07T15:24:28.273Z"
},
"temperatureCh5": {
"value": 25.5,
"type": "Property",
"unitCode": "CEL",
"observedAt": "2022-01-07T15:24:28.273Z"
}
}
And when i do not supply the correct jsonld file
curl -L -X GET \
'http://localhost:1026/ngsi-ld/v1/entities/urn:ngsi-ld:TemperatureSensor:temperaturesensor001' \
-H 'fiware-service: openiot' \
-H 'Link: <https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.4.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"' \
-H 'Accept: application/ld+json'| jq .
i get the full URI
{
"#context": "https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.4.jsonld",
"id": "urn:ngsi-ld:TemperatureSensor:temperaturesensor001",
"type": "https://example.com/LoraDevice",
"https://example.com/ch3": {
"value": 436.8,
"type": "Property",
"unitCode": "CEL",
"observedAt": "2022-01-07T15:24:28.273Z"
},
"https://example.com/ch5": {
"value": 25.5,
"type": "Property",
"unitCode": "CEL",
"observedAt": "2022-01-07T15:24:28.273Z"
}
}
The first thing to check is whether the IoT Agent version you are using is supporting NGSI-LD:
curl -X GET \
'http://localhost:4041/iot/about'
Should return:
{
"libVersion": "2.6.0-next",
"port": "4041",
"baseRoot": "/",
"version": "1.6.0-next"
}
The lib-version needs to be 2.15.0 or higher to expose NGSI-LD support. If necessary you can rebuild a latest from the Dockerfile in the IoTagent-LoRaWAN repo to make sure you have all the latest bug fixes from the IoT Agent node lib.
But I think the missing link here is the local #context file you need to provide to supply NGSI-LD data (and indeed any JSON-LD data). This file defines your world in terms of IRIs.
Your LoRaWAN IoT Agent config.js will need an entry to some file on a public server like:
{
contextBroker: {
host: '192.168.1.1',
port: '1026',
ngsiVersion: 'ld',
jsonLdContext: 'http://path/to/your/context.json-ld'
},
Or IOTA_CB_NGSI_VERSION and IOTA_JSON_LD_CONTEXT supplied by environment variables. The file path/to/your/context.json-ld will need to hold key-value entries like:
{
"#context": {
"type": "#type",
"id": "#id",
"ngsi-ld": "https://uri.etsi.org/ngsi-ld/",
"example": "https://example.com/",
"LoraDevice": "example:LoraDevice",
"temperatureCh3": "https://example.com/ch3",
"temperatureCh5": "https://example.com/ch5"
}
}
i.e. one entry for each entity type and one entry for each attribute.
It looks like your #context file is referring to https://fiware.github.io/data-models/context.jsonld which doesn't hold IRI values for your new property names.
When you are provisioning the subscription:
curl -X GET 'http://localhost:1026/ngsi-ld/v1/subscriptions/' \
-H 'NGSILD-Tenant: openiot'|jq .
{
"id": "urn:ngsi-ld:Subscription:61d53fc5fb688acae04cd92f",
"type": "Subscription",
"description": "Notify me of all changes",
"entities": [
{
"type": "LoraDevice"
}
],
"notification": {
"attributes": [
"temperatureCh3"
],
"format": "normalized",
"endpoint": {
"uri": "http://quantumleap:8668/v2/notify",
"accept": "application/json"
}
},
"#context": "http://path/to/your/context.json-ld"
}
]
The attribute names defined in http://path/to/your/context.json-ld are expanded to IRIs. If no matching entry is found then the default context https://uri.etsi.org/ngsi-ld/default-context/ is used (as defined by the #vocab element) , which is not what you want. Define temperatureCh3 and LoraDevice properly and the subscription will work.
As a check, try retrieving an entity without supplying any of your terms in the #context
curl -L -X GET \
'http://localhost:1026/ngsi-ld/v1/entities/urn:ngsi-ld:TemperatureSensor:temperaturesensor001' \
-H 'Link: <https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.4.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"' \
-H 'Accept: application/ld+json'
All attributes (which are not defined in the core #context) should now return using IRIs - if short names are returned, then the relevant mapping is missing.
I tried to reproduce the problem, pushed a new functest to Orion-LD's develop branch for this purpose:
https://github.com/FIWARE/context.Orion-LD/pull/983
I'm unable to reproduce, so, could you please take a look at the functest I implemented (free from iot-agents, QLs, etc - just the broker, a notification receiver, and curl commands) and propose changes. See if we're able to reproduce the error. Cause if not, if I can't reproduce, then I can't fix ...
Here you can see the functest: https://github.com/FIWARE/context.Orion-LD/pull/983/files#diff-921fc6ab850278cc281e7662f6170be2e3474f95a800000779c1dd9c6c377dd6R1
I'm trying to register a Context Provider as source for several KPIs.
So far, it seems registering might be working, as GET http://{{orion}}/v2/registrations returns something similar to what I set in creation:
{
// each registering a new id is returned: "id": "60991a887032541f4539a71d",
"description": "City Inhabitants",
"dataProvided": {
"entities": [
{
"id": "city.inhabitants"
//,"type": "KeyPerformanceIndicator"
}
]
},
"provider": {
"http": {
"url": "http://myhost/v2/inhabitants"
}
//, "legacyForwarding": false //perhaps there's a bug, cause although unset or set to false, broker still returns true.
}
}
However GET http://{{orion}}/v2/entities/city.inhabitants results in:
{
"error": "BadRequest",
"description": "Service not found. Check your URL as probably it is wrong."
}
GET http://{{orion}}/v2/entities?type=KeyPerformanceIndicator returns [] and context-provider is not being invoked any way.
I'm coding a Node.js application from scratch, to better understand what's going on https://github.com/FIWARE/tutorials.Context-Providers, and using tutorial containers as actual Fiware Broker, so all stores/shelf/products are working but not my KPI.
Using the tutorial application where a microservice is listening on the http://context-provider:3000/random/weatherConditions POST endpoint.
The following registration:
curl -L -X POST 'http://localhost:1026/v2/registrations' \
-H 'Content-Type: application/json' \
--data-raw '{
"description": "Get Weather data for KPI 1",
"dataProvided": {
"entities": [
{
"id" : "urn:ngsi-ld:KPI:010",
"type": "KeyPerformanceIndicator"
}
],
"attrs": [
"temperature", "relativeHumidity"
]
},
"provider": {
"http": {
"url": "http://context-provider:3000/random/weatherConditions"
},
"legacyForwarding": false
},
"status": "active"
}'
Will forward and retrieve data for the following request:
curl -L -X GET 'http://localhost:1026/v2/entities/urn:ngsi-ld:KPI:010'
or
curl -L -X GET 'http://localhost:1026/v2/entities/?type=KeyPerformanceIndicator'
Returns:
{
"id": "urn:ngsi-ld:KPI:010",
"type": "KeyPerformanceIndicator",
"temperature": {
"type": "Number",
"value": 11,
"metadata": {}
},
"relativeHumidity": {
"type": "Number",
"value": 39,
"metadata": {}
}
}
The context broker is forwarding the request to the http://context-provider:3000/random/weatherConditions POST end-point with the following payload:
{
"entities": [
{
"id": "urn:ngsi-ld:KPI:010",
"type": "KeyPerformanceIndicator"
}
],
"attrs": [
"temperature",
"relativeHumidity"
]
}
I have a camera and I want to send it a command to take a snapshot. My setup is Orion <--> iotagent-json <--> mosquitto <--> device.
However, when I try to issue a command the iotagent does not receive anything.
The request I used for provisioning the device (to the agent):
curl -X POST \
http://localhost1:4041/iot/devices \
-H 'Content-Type: application/json' \
-H 'fiware-service: actuatoriot' \
-H 'fiware-servicepath: /' \
-d '{
"devices": [
{
"device_id": "actuatorCamera002",
"entity_name": "urn:ngsi-ld:ActuatorCamera:002",
"entity_type": "Actuator",
"protocol": "PDI-IoTA-UltraLight",
"transport": "MQTT",
"timezone": "Europe/Berlin",
"commands": [
{ "object_id": "screen", "name": "Screen", "type": "command"}
]
}
]
}'
The device created on Agent:
{
"device_id":"actuatorCamera002",
"service":"actuatoriot",
"service_path":"/",
"entity_name":"urn:ngsi-ld:ActuatorCamera:002",
"entity_type":"Actuator",
"transport":"MQTT",
"attributes":[
],
"lazy":[
],
"commands":[
{
"object_id":"screen",
"name":"Screen",
"type":"command"
}
],
"static_attributes":[
],
"protocol":"PDI-IoTA-UltraLight"
}
The entity created on Orion:
{
"id": "urn:ngsi-ld:ActuatorCamera:002",
"type": "Actuator",
"Screen_info": {
"type": "commandResult",
"value": "aaa",
"metadata": {}
},
"Screen_status": {
"type": "commandStatus",
"value": "UNKNOWN",
"metadata": {}
},
"TimeInstant": {
"type": "ISO8601",
"value": " ",
"metadata": {}
}
}
I have tried sending PATCH requests on the entity values but nothing seems to be getting pushed to the iotagent-json.
(I have been using the iotagent and Orion for sensor measurements and everything works fine.)
EDIT:
GET v2/registrations
[
{
"id": "5d3af2188d657958a5cefec1",
"expires": "2019-08-25T12:29:12.00Z",
"dataProvided": {
"entities": [
{
"id": "urn:ngsi-ld:ActuatorCamera:002",
"type": "Actuator"
}
],
"attrs": [
"Screen"
]
},
"provider": {
"http": {
"url": "http://localhost:4041"
},
"supportedForwardingMode": "all",
"legacyForwarding": true
},
"status": "active"
}
]
Thanks to fgalan's comment I was able to find out I was using a wrong command name when issuing the PATCH.
The correct request for issuing a command was:
curl -X PATCH \
http://<contextBrokerIp>:1026/v2/entities/urn:ngsi-ld:ActuatorCamera:002/attrs \
-H 'fiware-service: actuatoriot' \
-H 'fiware-servicepath: /' \
-d '{
"Screen": {
"type" : "command",
"value" : ""
}
}'
I'd like to know details about character set and character code that can be used in an attribute name. I tried to create an entity that has an attribute name "日本語". I was able to create it in case of NGSIv1 but not in case of NGSIv2.
In case of NGSIv1 API,
Request:
(curl localhost:1026/v1/updateContext -sS --header 'Content-Type: application/json' \
--header 'Accept: application/json' -d #- <<EOF) | jq .
{
"contextElements": [
{
"type": "Test",
"isPattern": "false",
"id": "Testv1",
"attributes": [
{
"name": "japanese",
"type": "Integer",
"value": "1"
},
{
"name": "日本語",
"type": "Integer",
"value": "2"
}
]
}
],
"updateAction": "APPEND"
}
EOF
Response:
{
"contextResponses": [
{
"contextElement": {
"type": "Test",
"isPattern": "false",
"id": "Testv1",
"attributes": [
{
"name": "japanese",
"type": "Integer",
"value": ""
},
{
"name": "日本語",
"type": "Integer",
"value": ""
}
]
},
"statusCode": {
"code": "200",
"reasonPhrase": "OK"
}
}
]
}
In case of NGSIv2 API,
Request:
(curl localhost:1026/v2/entities -s -S -H 'Content-Type: application/json' \
-d #- <<EOF) | jq .
{
"id": "Test1",
"type": "Test",
"japanese": {
"value": 1,
"type": "Integer"
},
"日本語": {
"value": 2,
"type": "Integer"
}
}
EOF
Response:
{
"error": "BadRequest",
"description": "Invalid characters in attribute name"
}
The relevant sections in NGSIv2 specification regarding allowed characters are "Field syntax restrictions", "Attribute names restrictions" and "Metadata names restrictions".
In particular, related with the topic of this question:
Allowed characters are the ones in the plain ASCII set, except the following ones: control characters, whitespace, &, ?, / and #.
Note also
In addition to the above rules, given NGSIv2 server implementations could add additional syntactical restrictions in those or other fields, e.g., to avoid cross script injection attacks.
which, in the case of Orion it's specified as part of its documentation here.
EDIT 2
curl --include \
--header 'Content-Type: application/json' \
--request POST \
--data-binary '{
"description": "Day subscription",
"subject": {
"entities": [
{
"idPattern": "es-leon-.*",
"type": "Event"
}
],
"condition": {
"attrs": [
"Title",
"dFlag"
],
"expression": {
"q": "dFlag>0"
}
}
},
"notification": {
"http": {
"url" : "http://localhost:5050/notify"
},
"attrs": [
"Title",
"dFlag"
],
"attrsFormat":"legacy"
}
}' \
'http://localhost:1026/v2/subscriptions'
In Orion the subscription register ok (thanks for the tips in the comments) but I'm having the same issue as said in here even though I use "attrsFormat":"legacy"
I'm making something wrong? why orion is not using ngsiv1 to send the notification to cygnus?
The cygnus error trace.
Cygnus shows orion is responding this:
{
"subscriptionId": "574315e77775f31b8d3da719",
"data": [{
"id": "es-leon-0",
"type": "Event",
"Title": {
"type": "none",
"value": "pepe",
"metadata": {}
},
"dFlag": {
"type": "text",
"value": "1",
"metadata": {}
}
}]
}
When it has to respond the lines below to be in ngsiv1:
{
"subscriptionId": "5743178d7775f31b8d3da71a",
"originator": "localhost",
"contextResponses": [{
"contextElement": {
"type": "Event",
"isPattern": "false",
"id": "es-leon-0",
"attributes": [{
"name": "Title",
"type": "text",
"value": "pep"
}, {
"name": "dFlag",
"type": "text",
"value": "1"
}]
},
"statusCode": {
"code": "200",
"reasonPhrase": "OK"
}
}]
}
Original Question
As said in other question :
EDIT: note also that you can use NGSIv2 to create/update entities at
Orion and have notifications in NGSIv1 if you:
Create the subscription using NGSIv1 operations
Create the subscription using NGSIv2 operations with attrsFormat equal to legacy.
Have a look to more detailed information here.
So I made up this subscription:
curl --include \
--header 'Content-Type: application/json' \
--request POST \
--data-binary '{
"description": "Day subscription",
"subject": {
"entities": [
{
"idPattern": "es-leon-.*",
"type": "Event"
}
],
"condition": {
"attributes": [
"Title",
"dFlag"
],
"expression": {
"q": "dFlag > 0"
}
}
},
"notification": {
"callback": "http://localhost:5050/notify",
"attributes": [
"Title",
"dFlag"
]
}
}' \
'http://localhost:1026/v1/subscriptions'
but orion don't let me register it throwing this error:
HTTP/1.1 400 Bad Request
Connection: Keep-Alive
Content-Length: 67
Content-Type: application/json
Fiware-Correlator: 2ecdfc74-1c2f-11e6-82d7-000d3a23bf27
Date: Tue, 17 May 2016 12:59:25 GMT
{"error":"BadRequest","description":"no condition attrs specified"}
Is this the way to use legacy attributes so it can work with cygnus with NGSIv2?
Thanks for the help.
EDIT 1:
Following the answer the subscription should be like this: Right?
curl --include \
--header 'Content-Type: application/json' \
--request POST \
--data-binary '{
"description": "Day subscription",
"subject": {
"entities": [
{
"idPattern": "es-leon-.*",
"type": "Event"
}
],
"condition": {
"attributes": [
"Title",
"dFlag"
],
"expression": {
"q": "dFlag > 0"
}
}
},
"notification": {
"http": {
"url" : "http://localhost:5050/notify"
},
"attributes": [
"Title",
"dFlag"
],
"attrsFormat":"legacy"
}
}' \
'http://localhost:1026/v2/subscriptions'
But I'm still getting an error:
HTTP/1.1 100 Continue
HTTP/1.1 400 Bad Request
Connection: Keep-Alive
Content-Length: 67
Content-Type: application/json
Fiware-Correlator: 60a0a1d2-1ddf-11e6-8bd6-000d3a23bf27
Date: Thu, 19 May 2016 16:33:11 GMT
{"error":"BadRequest","description":"no condition attrs specified"}
Use attrs instead of attributes (both in subject.conditions and in notification).
In addition, note that callback is no longer used. You have to use:
"notification": {
"http": {
"url": "http://localhost:5050/notify"
},
..
}
In addition, if you want notifications to use NGSIv1 format you should include attrsFormat field with value legacy in notification as described in the documentation.
Finally, note that the rigth operation URL is /v2/subscriptions, not /v1/subscriptions as shown in your example.
EDIT 1: considering the new payload in EDIT 1 section in the question, note that:
You should use attrs inside condition, not attributes (the error message is complaining about that)
You should use attrs inside notification, not attributes
You should use "q": "dFlag>0" (i.e. no whitespaces in the query string). Look to the example in the NGSIv2 specification:
Eg:
"expression": {
"q": "temperature>40"
}
EDIT 2: Orion versions previous to 1.2 use attrsFormat outside notification field. Thus, if you are using Orion 1.1, try to use "attrsFormat": "legacy" as first level field in the subscription payload JSON.