IoT Agent integration issue with Scorpio Broker

[amitrnec]

Hi,
As we are doing integration of IoT Agent with Scorpio Broker.
For Northbound the data coming from IoT Agent is:
{
"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": ""
}
}

But NGSI-LD does not supports the type: "command" , as the issue regarding this has already been raised
FIWARE/context.Orion-LD#919

Is there any update on this or when it is plan to fix this issue?

Thanks,
Amit.

[mapedraza]

Which version of agent are you using?. It seems that the problem was addressed in iotagent-node-lib 2.19.0 which is used by iotagent-ul 1.20.0. Probably @jason-fox can help you better.

[amitrnec]

Hi,
Currently we are using 1.19.0 version.
"libVersion": "2.18.0",
"version": "1.19.0"

Thanks.

[jason-fox]

This was a bug identified in the 1.19.0 release as @mapedraza stated. To fix it, just update to 1.20.0 or higher.

[RupamNEC]

Hi @jason-fox

We tried it using version IoTagent-ul 1.20.1
The data coming from iotagent is:
{
"id": "urn:ngsi-ld:Device:water001",
"type": "Device",
"category": {
"type": "Property",
"value": "sensor"
},
"controlledAsset": {
"type": "Relationship",
"object": "urn:ngsi-ld:Building:barn001"
},
"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_status": {
"type": "Property",
"value": {
"type": "commandStatus",
"@value": "UNKNOWN"
}
},
"supportedProtocol": {
"type": "Property",
"value": "ul20"
},
"location": {
"type": "GeoProperty",
"value": {
"type": "Point",
"coordinates": [
0,
0
]
}
}
}

So, here "on" and "off" attributes are not coming so how would we partially update these attributes from Scorpio Broker?

"on": {
"type": "property",
"value": ""
},
"off": {
"type": "property",
"value": ""
}
The above attributes with type property should be there.

Thanks,
Rupam Kumari

[jason-fox]

@RupamNEC - on should be a registered attribute - you should be able to switch on the actuator using:

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": " "
}'

[jason-fox]

Note that there are ongoing discussions within ETSI attempting to clarify two different usages of NGSI-LD registrations - Orion-LD and Stellio follow the actuator mechanism, Scorpio follows a federation pattern, so it is likely that the IoT Agent registration will need to amended to align to the updated ETSI spec once details have been decided.

There is no conflict between brokers using subscriptions, so you may want to provision your device using bidirectional attributes instead.

[RupamNEC]

Hi @martin-p-bauer
Could you please confirm the above comment on Jasonfox. I am little confused. As per my understanding, my issue is in northbound data where data is blank and the type is different from allowed NGSI-LD.
Thanks

[RupamNEC]

Hi @jason-fox
Currently, we are using Scorpio Broker NGSI-LD v1.3.3
Data coming from iot-agent in CSource registration is in form of NGSI-LD v1.2 that is
"properties": {
"@id": "ngsi-ld:properties",
"@type": "@vocab"
}
But Scorpio Broker supports NGSI-LD v1.3.3 that is
"propertyNames ": {
"@id": "ngsi-ld:propertyNames",
"@type": "@vocab"
}

So there is version conflict while integrating Scorpio Broker with IoT Agent.
Is there any plan to update IoT Agent with NGSI-LD v1.3.3 ?

@martin-p-bauer @ScorpioBroker

Thanks

[martin-p-bauer]

@RupamNEC I just discussed the issue with @jason-fox. This is indeed a breaking change between NGSI-LDv1.2.1 and NGSI-LDv1.3.1. The idea here is to move all FIWARE Brokers to the NGSI-LDv1.3.1 @context soon, which would enable solving this particular issue. However, we identified that this problem is only the "tip of the iceberg" and that HTTP OPTIONS may help us to solve (a larger part of) the general problem.

[martin-p-bauer]

Hi @martin-p-bauer Could you please confirm the above comment on Jasonfox. I am little confused. As per my understanding, my issue is in northbound data where data is blank and the type is different from allowed NGSI-LD. Thanks

@RupamNEC So, indeed we are currently working on distributed operation / forwarding in ETSI and we have identified different cases. So far, Scorpio primarily supports the federation case, i.e. it forwards queries and subscriptions to registered Contest Sources that may have information fitting the request.

For IoT agents, there are two approaches for supporting actuation, the subscriptions-based one that we anyway support and the update forwarding one that we now want to support in addition. We have initially made simplified assumptions for implementing the latter, i.e. for forwarding updates we require that entity id AND attribute are part of the registration. The current work in ETSI will slightly change this, as the functionality offered will be explicitly specified in the registration.