integration issue

[Neeraj-Nec]

Hi ,

I am integrating IOT agent from FogFlow using orion broker . In this scenario IOT agent send the data to the Orion broker and FogFlow have subscribe to the Orion broker to get the data . FogFlow is getting the following data in the notification .

{
	"@context": "https://fiware.github.io/data-models/context.jsonld",
	"id": "urn:ngsi-ld:Device:water001",
	"type": "Device",
	"heartRate": {
		"type": "Property",
		"value": {
			"@type": "Intangible",
			"@value": null
		},
		"unitCode": "5K"
	},
	"status": {
		"type": "Property",
		"value": {
			"@type": "Intangible",
			"@value": null
		}
	},
	"location": {
		"type": "GeoProperty",
		"value": {
			"type": "Point",
			"coordinates": [0, 0]
		}
	},
	"controlledAsset": {
		"type": "Relationship",
		"object": "urn:ngsi-ld:Building:barn001"
	},
	"category": {
		"type": "Property",
		"value": "sensor"
	},
	"supportedProtocol": {
		"type": "Property",
		"value": "ul20"
	},
	"on_status": {
		"type": "Property",
		"value": {
			"@type": "commandStatus",
			"@value": "UNKNOWN"
		}
	},
	"on_info": {
		"type": "Property",
		"value": {
			"@type": "commandResult",
			"@value": " "
		}
	},
	"off_status": {
		"type": "Property",
		"value": {
			"@type": "commandStatus",
			"@value": "UNKNOWN"
		}
	},
	"off_info": {
		"type": "Property",
		"value": {
			"@type": "commandResult",
			"@value": " "
		}
	},
	"on": {
		"type": "command",
		"value": ""
	},
	"off": {
		"type": "command",
		"value": ""
	}
}

This data has @type and @value at some places. I am confused whether this data is correct or not , because if we use same data to create entity i am getting error of "NOT A VALID JSON" Scorpio broker .

[kzangeli]

You get the values like:

"value": {
    "@type": "Intangible",
    "@value": null
}

only because the attributes were created that way. And yes, the "value" field can contain anything, as long as it is valid JSON.

You say Scorpio doesn't accept this as input? [ Unless I've misunderstood something, ] if I were you, I'd investigate why Scorpio doesn't accept a perfectly valid payload.

[kzangeli]

The last attributes have invalid values for "type", e.g.:

"off": {
"type": "command",
"value": ""
}

The only valid values for "type" in NGSI-LD are:

• "Property"
• "Relationship"
• "GeoProperty"
• "LanguageProperty"

That's probably why you get the error.

[kzangeli]

It seems like your entity is a mix between NGSIv2 and NGSI-LD. As Orion-LD supports both formats, this can easily happen. Just create an entity using NGSIv2 and then patch it using an NGSI-LD request. I bet this is what's happening to you.

[Neeraj-Nec]

Hi Kzangeli ,

sorry for late response.. I am just integrating IoT agent from FogFlow broker via Orion broker . Please find the integration architecture diagram from https://github.com/smartfog/fogflow/blob/development/doc/en/source/ngsildbasediotintegration.rst) this link.

For reference I have used (https://ngsi-ld-tutorials.readthedocs.io/en/latest/iot-agent.html) this link for integration. In the integration FogFlow just subscribe to the Orion broker to get the data as notification . FogFlow broker did not create any mix data of ngsiv2 and MGSILD data.

[Neeraj-Nec]

Hi @Kzangeli, Please provide some suggestion how to do the integration ?

[Neeraj-Nec]

@kzangeli, Please let me know if need any kind of input from my side .

[kzangeli]

Well. as I said earlier, your entity seems to be a mix between NGSIv2 and NGSI-LD. Quite messy. I've asked our IoT Agent expert, @jason-fox to help out

[jason-fox]

@Neeraj-Nec - I am unable to reproduce your error. The issue is in your last two attributes. Assuming you have an IoT Agent and you have provisioned the devices correctly as LD, for undefined readings, it will create attributes like:

"value": {
    "@type": "Intangible",
    "@value": null
}

Similarly the attributes like:

"on_status": {
		"type": "Property",
		"value": {
			"@type": "commandStatus",
			"@value": "UNKNOWN"
		}
	},

Are part of the commands that have been provisioned.

I'm guessing here, but

"on": {
		"type": "command",
		"value": ""
	},
```	

Looks like you have made a v2 request to an LD broker - something like:

```console
curl -iX PATCH \
  'http://localhost:1026/v2/entities/urn:ngsi-ld:Water:001/attrs' \
  -H 'Content-Type: application/json' \
  -H 'fiware-service: openiot' \
  -H 'fiware-servicepath: /' \
  -d '{
  "on": {
      "type" : "command",
      "value" : ""
  }
}'

Which has somehow been interpreted as a v2 attribute create rather than an LD forwarding to the existing registrant.

The correct request to make is:

curl -L -X PATCH 'http://localhost:4041/ngsi-ld/v1/entities/urn:ngsi-ld:Device:water001/attrs/on' \
    -H 'fiware-service: openiot' \
    -H 'fiware-servicepath: /' \
    -H 'Content-Type: application/json' \
--data-raw '{

        "type": "Property",
        "value": " "

}'

Since it is a fork of Orion, Orion-LD can still service v2 requests sort of, however this interface is not well supported or tested, so I wouldn't be surprised if a v2 request doesn't forward to an attribute defined in LD registration and ends up shadowing it with some invalid data in the context-broker.

If you can supply the exact request that you are making to actuate the device, it would be easier to work out what is going wrong.

[Neeraj-Nec]

Hi @jason-fox

Thanks for your response

The following are the request created by me

1. Provisioning a Service Group

curl -iX POST 'http://192.168.21.232:4041/iot/services' \
-H 'fiware-service: openiot' \
-H 'fiware-servicepath: /' \
-H 'Content-Type: application/json' \
--data-raw '{
"services": [
        {
        "apikey": "4jggokgpepnvsb2uv4s40d59ov",
        "cbroker": "http://192.168.21.232:1026",
        "entity_type": "Device",
        "resource": "/iot/d",
        "attributes": [
                {
                "object_id": "bpm", "type": "Property", "name": "heartRate",
                "metadata": { "unitCode": {"type": "Text", "value": "5K" }}
                },
                {
                "object_id": "s", "name": "status", "type": "Property"
                },
                {
                "object_id": "gps", "name": "location", "type": "geo:point"
                }
        ],
        "static_attributes": [
                {
                "name": "category", "type": "Property", "value": "sensor"
                },
                {
            "name": "supportedProtocol", "type": "Property", "value": "ul20"
                }
        ]
        }
   ]
}'

2. Provisioning an Actuator

curl -L -X POST 'http://192.168.21.232:4041/iot/devices' \
-H 'fiware-service: openiot' \
-H 'fiware-servicepath: /' \
-H 'Content-Type: application/json' \
--data-raw '
        {
"devices": [{
        "device_id": "water001",
        "entity_name": "urn:ngsi-ld:Device:water001",
        "entity_type": "Device",
        "protocol": "PDI-IoTA-UltraLight",
        "transport": "HTTP",
        "endpoint": "http://192.168.21.232:3001/iot/water001",
        "commands": [{
                        "name": "on",
                        "type": "command"
                },
                {
                        "name": "off",
                        "type": "command"
                }
        ],
        "static_attributes": [{
                "name": "controlledAsset",
                "type": "Relationship",
                "value": "urn:ngsi-ld:Building:barn001"
        }]
    }]
}'

3. Verify Entity on Orion broker

curl -L -X GET 'http://192.168.21.232:1026/ngsi-ld/v1/entities/urn:ngsi-ld:Device:water001' \
-H 'fiware-service: openiot' \
-H 'fiware-servicepath: /' \
-H 'Link: <https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"' \
-H 'Content-Type: application/json'

4. update Waterpump status

curl -L -X PATCH 'http://192.168.21.232:4041/ngsi-ld/v1/entities/urn:ngsi-ld:Device:water001/attrs/on' \
-H 'fiware-service: openiot' \
-H 'fiware-servicepath: /' \
-H 'Content-Type: application/json' \
--data-raw '{

        "type": "Property",
        "value": " "

}'

5. Subscribe orion broker to get the data on Fogflow broker

curl -iX POST \
          'http://192.168.21.232:1026/ngsi-ld/v1/subscriptions' \
          -H 'Content-Type: application/json' \
          -H 'Accept: application/ld+json' \
          -H 'fiware-service: openiot' \
          -H 'fiware-servicepath: /' \
          -H 'Link: <https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"' \
          -d ' {
                "type": "Subscription",
                "entities": [{
                        "id": "urn:ngsi-ld:Device:water001",
                       "type": "Device"
                }],
              "notification": {
                  "format": "normalized",
                  "endpoint": {
                           "uri": "http://192.168.21.232:8070/ngsi-ld/v1/notifyContext/",
                           "accept": "application/ld+json"
                   }
               }
           }'

6. Send PATCH request to Enable Orion-Broker commands

curl -L -X PATCH 'http://192.168.21.232:1026/ngsi-ld/v1/entities/urn:ngsi-ld:Device:water001/attrs/on' \
-H 'fiware-service: openiot' \
-H 'fiware-servicepath: /' \
-H 'Accept: application/ld+json' \
-H 'Link: <https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"' \
-H 'Content-Type: application/json' \
--data-raw '{

        "type": "Property",
        "value": " "

}'

[Neeraj-Nec]

After sending all the request Fogflow broker get the following data as notification

{
	"id": "urn:ngsi-ld:Notification:614d4c9711b9d03888245e94",
	"type": "Notification",
	"subscriptionId": "urn:ngsi-ld:Subscription:614d4c6f11b9d03888245e92",
	"@context": "https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld",
	"notifiedAt": "2021-09-24T03:57:11.606Z",
	"data": [{
		"id": "urn:ngsi-ld:Device:water001",
		"type": "Device",
		"category": {
			"type": "Property",
			"value": "sensor",
			"observedAt": "2021-09-24T03:57:11.000Z"
		},
		"controlledAsset": {
			"type": "Relationship",
			"object": "urn:ngsi-ld:Building:barn001",
			"observedAt": "2021-09-24T03:57:11.000Z"
		},
		"heartRate": {
			"type": "Property",
			"value": {
				"@type": "Intangible",
				"@value": null
			},
			"unitCode": "5K"
		},
		"off_info": {
			"type": "Property",
			"value": {
				"@type": "commandResult",
				"@value": " "
			}
		},
		"off_status": {
			"type": "Property",
			"value": {
				"@type": "commandStatus",
				"@value": "UNKNOWN"
			}
		},
		"on_info": {
			"type": "Property",
			"value": {
				"@type": "commandResult",
				"@value": " on OK"
			},
			"observedAt": "2021-09-24T03:57:11.000Z"
		},
		"on_status": {
			"type": "Property",
			"value": {
				"@type": "commandStatus",
				"@value": "OK"
			},
			"observedAt": "2021-09-24T03:57:11.000Z"
		},
		"supportedProtocol": {
			"type": "Property",
			"value": "ul20",
			"observedAt": "2021-09-24T03:57:11.000Z"
		},
		"status": {
			"type": "Property",
			"value": {
				"@type": "Intangible",
				"@value": null
			}
		},
		"location": {
			"type": "GeoProperty",
			"value": {
				"type": "Point",
				"coordinates": [0, 0]
			}
		}
	}]
}

[jason-fox]

The issue is with your subscription Link header

-H 'Link: <https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld>

Will only supply the core @context, you need to supply the definition of the data-models as well. The NGSI-LD tutorials run a small HTTPD web server which supplies the data-models using:

"@context": "http://context-provider:3000/data-models/ngsi-context.jsonld"

The raw file can be found here - in your case you may need a file something like:

{
    "@context": ["https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld", "https://raw.githubusercontent.com/FIWARE/tutorials.IoT-Agent/NGSI-LD/data-models/ngsi-context.jsonld"]
}

offering core and data-models together. At that point the notification will be raised as shown:

{
	"id": "urn:ngsi-ld:Notification:614d4c9711b9d03888245e94",
	"type": "Notification",
	"subscriptionId": "urn:ngsi-ld:Subscription:614d4c6f11b9d03888245e92",
	"@context": ["https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld", "https://raw.githubusercontent.com/FIWARE/tutorials.IoT-Agent/NGSI-LD/data-models/ngsi-context.jsonld"],
	"notifiedAt": "2021-09-24T03:57:11.606Z",
	"data": [{
		"id": "urn:ngsi-ld:Device:water001",
		"type": "Device",
		"category": {
			"type": "Property",
			"value": "sensor",
			"observedAt": "2021-09-24T03:57:11.000Z"
		},
		"controlledAsset": {
			"type": "Relationship",
			"object": "urn:ngsi-ld:Building:barn001",
			"observedAt": "2021-09-24T03:57:11.000Z"
		},
		"heartRate": {
			"type": "Property",
			"value": {
				"@type": "Intangible",
				"@value": null
			},
			"unitCode": "5K"
		},
		"off_info": {
			"type": "Property",
			"value": {
				"@type": "commandResult",
				"@value": " "
			}
		},
		"off_status": {
			"type": "Property",
			"value": {
				"@type": "commandStatus",
				"@value": "UNKNOWN"
			}
		},
		"on_info": {
			"type": "Property",
			"value": {
				"@type": "commandResult",
				"@value": " on OK"
			},
			"observedAt": "2021-09-24T03:57:11.000Z"
		},
		"on_status": {
			"type": "Property",
			"value": {
				"@type": "commandStatus",
				"@value": "OK"
			},
			"observedAt": "2021-09-24T03:57:11.000Z"
		},
		"supportedProtocol": {
			"type": "Property",
			"value": "ul20",
			"observedAt": "2021-09-24T03:57:11.000Z"
		},
		"status": {
			"type": "Property",
			"value": {
				"@type": "Intangible",
				"@value": null
			}
		},
		"location": {
			"type": "GeoProperty",
			"value": {
				"type": "Point",
				"coordinates": [0, 0]
			}
		}
	}]
}

Which validates in the JSON-LD Playground - so if your parser is still having difficulties with null values like:

value": {
	"@type": "Intangible",
	"@value": null
}

it must be to do with your JSON-LD parsing library.

[Neeraj-Nec]

ok @jason-fox - Thanks for you response . I will apply your suggestion and will update you soon .

[Neeraj-Nec]

Hi @jason-fox ,

I changed the Subscription by following example .

curl -iX POST \
          'http://192.168.21.158:1026/ngsi-ld/v1/subscriptions' \
          -H 'Content-Type: application/ld+json' \
          -H 'Accept: application/ld+json' \
          -H 'fiware-service: openiot' \
          -H 'fiware-servicepath: /' \
          -d ' {
                "type": "Subscription",
                "entities": [{
                        "id": "urn:ngsi-ld:Device:water001",
                       "type": "Device"
                }],
              "notification": {
                  "format": "normalized",
                  "endpoint": {
                           "uri": "http://192.168.21.158:8070/ngsi-ld/v1/notifyContext/",
                           "accept": "application/ld+json"
                   }
               },
	 "@context": ["https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld", "https://raw.githubusercontent.com/FIWARE/tutorials.IoT-Agent/NGSI-LD/data-models/ngsi-context.jsonld"]
           }

After doing this FogFlow broker is not getting notification from Orion broker

[jason-fox]

Your subscription is wrong in three ways:

• an NGSI-LD request should be using the NGSILD_Tenant header
• In the tutorial, the type of the sprinkler is Water not Device
• The supplied context on the server should hold the array not the request.

I just tried the following:

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 low feedstock on Farm:001",
  "type": "Subscription",
  "entities": [{
"id": "urn:ngsi-ld:Device:water001",
"type": "Water"
}],
  "notification": {
    "format": "keyValues",
    "endpoint": {
      "uri": "http://tutorial:3000/subscription/low-stock-farm002",
      "accept": "application/json"
    }
  },
   "@context": "http://context/ngsi-context.jsonld"
}'

Which successfully displays the following payload in the App Monitor

{
 "id": "urn:ngsi-ld:Notification:6152c9dc4fe765e7ff7fc385",
 "type": "Notification",
 "subscriptionId": "urn:ngsi-ld:Subscription:6152c9cb4fe765e7ff7fc384",
 "notifiedAt": "2021-09-28T07:53:00.870Z",
 "data": [
  {
   "id": "urn:ngsi-ld:Device:water001",
   "type": "Water",
   "off_info": {
    "@type": "commandResult",
    "@value": " "
   },
   "off_status": {
    "@type": "commandStatus",
    "@value": "UNKNOWN"
   },
   "on_info": {
    "@type": "commandResult",
    "@value": " on OK"
   },
   "on_status": {
    "@type": "commandStatus",
    "@value": "OK"
   },
   "description": "Irrigation System",
   "category": "actuator",
   "controlledAsset": "urn:ngsi-ld:Building:barn001",
   "supportedProtocol": "ul20"
  }
 ]
}

Note that "@context": "http://context/ngsi-context.jsonld" refers to an HTTP Server holding the relevant context.

[Neeraj-Nec]

Hi @jason-fox ,

In the NGSI-LD specification it is clearly written that the value should be mandatory.

For reference you can see 4.5.2 in the spac https://www.etsi.org/deliver/etsi_gs/CIM/001_099/009/01.02.02_60/gs_CIM009v010202p.pdf

[jason-fox]

@Neeraj-Nec - section 4.5.2. NGSI-LD Property Representation is referring to the normalized representation. The example given above is using the keyValues format, a.k.a. Simplified Representation which is defined in 4.5.4.

You could alter the subscription as shown:

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 low feedstock on Farm:001",
  "type": "Subscription",
  "entities": [{
"id": "urn:ngsi-ld:Device:water001",
"type": "Water"
}],
  "notification": {
    "format": "normalized",
    "endpoint": {
      "uri": "http://tutorial:3000/subscription/low-stock-farm002",
      "accept": "application/json"
    }
  },
   "@context": "http://context/ngsi-context.jsonld"
}'

if you want the full NGSI-LD representation in your payload.

[naveennec]

@jason-fox I agree with your observation and Neeraj points. I have still few doubt which are not clear. please try to reply pointwise 1- As Per your comment https://github.com/FIWARE/context.Orion-LD/issues/919#issuecomment-926386195. Can we assume that below is correct as you saying that its working on jason-ld playground. value": { "@type": "Intangible", "@value": null } but as per NGSI-LD spec a property of an entity can never have NULL value. 2- As per your comment https://github.com/FIWARE/context.Orion-LD/issues/919#issuecomment-928950231, you have mentioned three points a- an NGSI-LD request should be using the NGSILD_Tenant header-

Agree with you, but FogFlow handles it differently with message-format variable, used internally in FogFlow b- In the tutorial, the type of the sprinkler is Water not Device As per point no 8 in tutorial https://ngsi-ld-tutorials.readthedocs.io/en/latest/iot-agent.html, "entity_type": "Device", so can we say that entit type is device not water. Please correct me if i am wrong. c- The supplied context on the server should hold the array not the request. As per comment no https://github.com/FIWARE/context.Orion-LD/issues/919#issuecomment-926386195, @context is accordingly written in comment https://github.com/FIWARE/context.Orion-LD/issues/919#issuecomment-926386195

final observation- Currently if FogFlow implements NULL value handling in property then everything works fine. Sorry for any mistakes, please correct me in case I am wrong.

[jason-fox]

The following two attributes from an NGSI-LD response validates within the JSON-LD Playground

{
  "filling1": {
    "type": "Property",
    "value": {
      "@type": "Intangible",
      "@value": null
    }
  },
  "filling2": {
    "type": "Property",
    "value": 0.1,
    "unitCode": "C62",
    "observedAt": "2020-12-09T16:25:12.000Z"
  }
}

The first is a null value (or rather a JSON object that resolves to null) the second is the format after observation.

The following is currently not valid NGSI-LD according to spec (it is still valid JSON-LD)

  "filling3": {
       "type": "Property",
       "value": null
    }

2. If the entity type is Device then an subscription based on type=Device will fire, however if you're not receiving an expected notification, then I'd check if the type is incorrect - for the tutorials I generally use type=Water, it depends upon how the device has been provisioned which may vary between the various tutorials - I'm merely suggest looking if you have wrong type if the notification has not fired (I've made this error myself before). type=Device is usually reserved for anonymous devices such as animal collars.

3. This is probably where the difference lies - NSGI-LD/JSON-LD payloads can have a weird structure which may form an edge case which needs special processing.

[naveennec]

@jason-fox Thank you very much for your reply. as you agree that The following is currently not valid NGSI-LD according to spec (it is still valid JSON-LD) "filling3": { "type": "Property", "value": null } But Orion-ld is a NGSI-LD implemented broker right ? not JSON-LD one. This is the main problem when FogFlow integrate with IOT-Agent(ultralight) via Orion-LD. as the payload received from Orion-ld have Null property, step 2 and step 3 in your comment are okay with FogFlow. Now please suggest where this changes need to be corrected either Orion-LD side or IOT-Agent(ultrlight) side. thanks in advance for your reply.

[jason-fox]

as the payload received from Orion-ld have null property

Unfortunately, being pedantic, this statement is incorrect. The existing workaround is that instead of passing a null property directly - which would have been invalid NGSI-LD., the context broker is holding a valid JSON Object which resolves to a null - which is acceptable NGSI-LD.

null values can indirectly exist within context brokers, and can be present in the payload of a notification either as normalized NGSI-LD:

"filling": {
    "type": "Property",
    "value": {
      "@type": "Intangible",
      "@value": null
    }
  }

or key-values (which is just JSON or JSON-LD anyway)

"filling": null

so the business logic of the receiving endpoint should be prepared to read these sorts of null values.

If you are writing a subscription, you may need to use the q parameter to filter out null from being sent - I guess something like q=filling>-1 should work depending on the mechanism that Orion-LD uses to define the truthiness of null - the link is for JavaScript, I'm not sure how C covers the same situation.

[jason-fox]

please suggest where this changes need to be corrected either Orion-LD side or IOT-Agent(ultralight) side.

• Orion-LD is working according to NGSI-LD spec in this area - there are no changes to be suggested.
• The ultralight IoT Agent delegates the creation of newly provisioned NGSI-LD devices to the iotagent-node-lib - null is being used as a default for unknown measures here. The NGSI-LD processing for non-numeric values is found here

Personally I see these defaults as reasonable, but if you want to discuss adding a flag to alter them, try raising an issue in the Telefónica repo and discuss your use case.

[naveennec]

@jason-fox Thank you very much for the clarity. your answer in comment https://github.com/FIWARE/context.Orion-LD/issues/919#issuecomment-940895369 explains everything. @Neeraj-Nec I think we should write the functionality in decoder code to handle the above situation.

[martin-p-bauer]

NGSI-LD does not allow any values to be NULL. The reason is the handling of NULL in JSON-LD. (NGSI-LD uses JSON-LD for serialization, so any NGSI-LD data is also JSON-LD). If you set a value to NULL in JSON-LD, it will be removed on expansion. You can check out this behaviour in the JSON-LD playground:

Taking an excerpt from the example above (complete example was expanded based on @context):

	"status": {
		"type": "Property",
		"value": {
			"@type": "Intangible",
			"@value": null
		}
	},

is expanded to

    "https://saref.etsi.org/core/status": [
      {
        "@type": [
          "https://uri.etsi.org/ngsi-ld/Property"
        ]
      }
    ],

Thus @value is gone after expansion, which is correct, as specified in the JSON-LD specfication.

JSON-LD Expansion is the first step done by a JSON-LD parser, e.g. as used by Scorpio, so a null value never reaches the internals of the Broker. Thus you need to do something else to convey an unknown value, e.g. a string "unknown" or even "null", but not just NULL. Orion-LD does expansion in its own way, so it would not necessarily be gone, but still, using NULL as a JSON "value" anywhere in the structure is not allowed in NGSI-LD.

[jason-fox]

Telefónica have accepted the PR to the library, so you can now use a workaround by building your own bleeding edge Docker Image iotagent for ultralight. (You will be a able to start using latest for testing once any further commit has landed in the repo, but at the moment the library has been updated not the service itself.

[Neeraj-Nec]

Thanks @jason-fox

[Neeraj-Nec]

Hi @jason-fox I am still getting the nil value issue . please share the version of correct Orion broker. I am using version: "3.5"

[jason-fox]

version: "3.5" at the head of a docker-compose file is defining the version of docker-compose format supported - it is nothing to do with any of the Docker Images. At heart, this issue is not a context broker issue, it is an IoT Agent issue. As described above, this issue will be solved either by using the latest bleeding edge image of an IoT Agent, or switching to a fixed version once a release has occurred. As it happens, the Telefónica Team responsible for releasing the IoT Agents is going through that process right now - you can follow the progress of the release tracked by this PR: https://github.com/telefonicaid/iotagent-node-lib/pull/1176

Once complete you can amend your docker-compose to point to a more recent stable version of the IoT Agent, by updating the image tag shown here:

  iot-agent:
    image: fiware/iotagent-ul:${ULTRALIGHT_VERSION}

[Neeraj-Nec]

hi @jason-fox The following entity is created by IoT agent to the Orion broker . In the entity two attribute "on" and "off" have type "command" . I think it should be either property, relationship or geopropety according to NGSILD specification.
{ "id": "urn:ngsi-ld:Device:water001", "type": "Device", "heartRate": { "type": "Property", "value": { "@type": "Intangible", "@value": null }, "unitCode": "5K" }, "status": { "type": "Property", "value": { "@type": "Intangible", "@value": null } }, "location": { "type": "GeoProperty", "value": { "type": "Point", "coordinates": [0, 0] } }, "controlledAsset": { "type": "Relationship", "object": "urn:ngsi-ld:Building:barn001" }, "category": { "type": "Property", "value": "sensor" }, "supportedProtocol": { "type": "Property", "value": "ul20" }, "on_status": { "type": "Property", "value": { "@type": "commandStatus", "@value": "UNKNOWN" } }, "on_info": { "type": "Property", "value": { "@type": "commandResult", "@value": " " } }, "off_status": { "type": "Property", "value": { "@type": "commandStatus", "@value": "UNKNOWN" } }, "off_info": { "type": "Property", "value": { "@type": "commandResult", "@value": " " } }, "on": { "type": "command", "value": "" }, "off": { "type": "command", "value": "" } }

[martin-p-bauer]

As correctly identified by @Neeraj-Nec "on" and "off" are not correct in NGSI-LD, as "command" does not exist as a type of Attribute. Also the Properties heartRate and status still use null as a value, which results in the whole value of the NGSI-LD property being removed on JSON-LD expansion and for this reason, null is not allowed as a JSON value in NGSI-LD.

[jason-fox]

"on" and "off" are not correct in NGSI-LD,

I've reproduced the bug and proposed a fix here: https://github.com/telefonicaid/iotagent-node-lib/pull/1185

Also the Properties heartRate and status still use null as a value

Fixed. PR was merged here: https://github.com/telefonicaid/iotagent-node-lib/pull/1118 - still awaiting a release by Telefónica to create a stable image with the fix in it.

Neither of these are Orion-LD issues and would have been better raised over on the Telefónica repos.