Closed walterwootz closed 7 months ago
Since https://github.com/telefonicaid/iotagent-node-lib/releases/tag/3.4.0 initial entity is not created, so the behavior your describe is right.
So what do you suggest for iot agent users? Is it better to let them create the entities manually in orion, or can we automate the creation in some way?
According to documentation in PR https://github.com/telefonicaid/iotagent-node-lib/pull/1551 (soon to be merged)
This means that all entities into the Context Broker are created when data arrives from a device, no matter if the device is explicitly provisioned (via device provisioning API) or autoprovisioned
Does that suffice your use case? In negative case, please explain why don't.
Yes, the entity is created once a measure arrives from the device, but the created entity is missing active attributes. Only lazy ones are added.
The attributes are added to the entity as they come in measures.
For instance:
If you need all the possible active attributes in the entity from the very beginning, please consider to pre-provision the entity at CB using the CB NGSIv2 API.
Ok thanks @fgalan we understand now. But there is still a problem regarding our IoTAgent OPC UA: when trying to perform provisioning through API we have tried to add a custom attribute ("mappings", see below) in the body with info about the southbound connection, but it does not get propagated to the deviceProvisioningHandler function.
POST http://localhost:4041/iot/devices
{
"devices": [
{
"device_id": "age01_Car",
"entity_name": "age01_Car",
"entity_type": "Device",
"apikey": "iot",
"endpoint": "opc.tcp://localhost:5001/UA/CarServer",
"mappings": [
{
"ocb_id": "Engine_Temperature",
"opcua_id": "ns=3;s=Temperature",
"object_id": "ns=3;s=Temperature",
"inputArguments": []
}
],
"attributes": [
{
"object_id": "Engine_Temperature",
"name": "Engine_Temperature",
"type": "Number"
}
],
"lazy": [],
"commands": []
}
]
}
Is there any way to create a tests (Proof of Concept) for iotagent-node-lib which reproduce the behavior that you report @walterwootz ? The usage of iotagent-node-lib by iotagent-json or iotagent-opcua should be equivalent, and that wrong behavior you are reporting is not observed in iotagent-json.
Ok thanks @fgalan we understand now. But there is still a problem regarding our IoTAgent OPC UA: when trying to perform provisioning through API we have tried to add a custom attribute ("mappings", see below) in the body with info about the southbound connection, but it does not get propagated to the deviceProvisioningHandler function.
POST http://localhost:4041/iot/devices
{ "devices": [ { "device_id": "age01_Car", "entity_name": "age01_Car", "entity_type": "Device", "apikey": "iot", "endpoint": "opc.tcp://localhost:5001/UA/CarServer", "mappings": [ { "ocb_id": "Engine_Temperature", "opcua_id": "ns=3;s=Temperature", "object_id": "ns=3;s=Temperature", "inputArguments": [] } ], "attributes": [ { "object_id": "Engine_Temperature", "name": "Engine_Temperature", "type": "Number" } ], "lazy": [], "commands": [] } ] }
This is the test, the "mappings" array is not forwarded to the device provisioning handler function (see the function here, line 72).
It seems that mappings is something not handled by iotagent-node-lib and maybe is only just related with opcua iotagent.
Resolved using internal_attributes in the provisioning body request. In that field you can pass any additional data. Thank you
IoT Agent Node Lib version the issue has been seen with
3.4.4
Bound or port used (API interaction)
Northbound (Provision API and NGSI Interactions)
NGSI version
NGSIv2
Are you running a container?
No, I am running it natively
Image type
normal
Expected behaviour you didn't see
When calling POST http://localhost:4041/iot/devices a complete NGSI entity should be created, including active and lazy attributes.
Unexpected behaviour you saw
The created entity in Orion includes only lazy attributes and active ones are missing.
Steps to reproduce the problem
Orion response:
Active attributes are missing.
Configs
Log output