Email sent.
Certainly there are lots of standards on this, and I’ll try to supply some relevant information. However the actual method of getting information from a device to a context broker will
vary depending upon the capabilities of the device.
Let’s start with the standards:
The NGSI v2 interface is defined here: https://fiware-ges.github.io/orion/api/v2/stable/ - This is the current basis of interoperability of all components of the FIWARE System
NGSI-LD is an evolution of NGSI v2 for Linked Data is now an ETSI standard - it can be found here: https://www.etsi.org/deliver/etsi_gs/CIM/001_099/009/01.01.01_60/gs_CIM009v010101p.pdf
The relevant Swagger definitions can be found:
NGSI v2: https://fiware.github.io/specifications/OpenAPI/ngsiv2
NGSI-LD: https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/gitlab/NGSI-LD/NGSI-LD/raw/master/spec/updated/full_api.json
Basically NGSI is a simple REST API with a JSON payload which defines three major operations:
1) Basic CRUD operations align with the standard HTTP verbs as expected (Batch operations use POST as expected)
2) Additional information can be retrieved from other sources using Registration operations
3) Asynchronous events can be publish/subscribed using Subscription Operations
The basic operations of a context broker are summarised in the first chapter of the tutorial information:
https://fiware-tutorials.readthedocs.io/en/latest/getting-started/index.html
So if I am a webservice wishing to register additional context I need to follow the standards of the registration endpoint
And if I am a web service wanting to do anything with context data I need to be able to listen and interpret information received by the subscription endpoint.
This is how all of the other elements in the FIWARE Catalogue interact with the context broker:
https://github.com/FIWARE/catalogue
Moving on to IoT devices you have three options:
1) For a high power device it could use the NGSI interfaces directly
2) For a low power device there would be another Edge component such as an IoT Agent
3) It is possible to use a third party IoT Platform (e.g. Watson) which then connects to a component which eventually talks NGSI.
Option 2) is the usually method of communication with IoT devices - there needs to be some communication layer (IoT protocol => NGSI and back again)
There is an existing library which offers an administration interface and can be mapped to a wide variety of Protocols and payloads:
https://github.com/FIWARE/specifications/tree/master/OpenAPI/iot.IoTagent-node-lib
An example of how it works can be seen here: https://www.youtube.com/watch?v=my6Kgiqx-OM&list=PLR9elAI9JscTyBVUq0P48OMVkrbdPitB7
An example of Option 3) would be the FIWARE contribution to Node RED
https://github.com/FIWARE/node-red-contrib-FIWARE_official
Of course robotic devices have their own protocols - FIWARE is linked to Fast-RTPS which is part of the ROS2 standard. There is also a connector
for the old ROS1 standard - more information can be found under here:
https://github.com/FIWARE/catalogue/tree/master/robotics
Specifically regarding agriculture, there is an ongoing initiative to promote a series of standard data models so that what you call a humidity reading
Is the same as what I call a humidity reading for example - the data models can be found here:
https://github.com/FIWARE/data-models/tree/master/specs/AgriFood
The NGSI standard is very open and flexible in that you only need a type and an id - all other attributes are self describing and optional. Linked Data
(NGSI-LD) uses the mechanisms defined in the JSON-LD 1.0 standard (http://JSON-ld.org) to ensure that data can be locked down to be
consistent (using a schema) and interoperable (using JSON-LD)
A full definition of a data model, including a JSON-LD @context and @graph along with a JSON schema will ensure that machines can read
and interpret separate context data sources.
I hope this short introduction will be useful, further technical learning materials can be found on the FIWARE Academy:
https://fiware-academy.readthedocs.io/
Email sent.