NGSI

We do not use that precise stack, but we have got many production deployments keeping context historical data on MongoDb by using FIWARE Orion (v2 API) with FIWARE Cygnus (NGSIMongo Sink for historical raw data, and NGSISTH Sink for aggregated data at MongoDB).

https://github.com/telefonicaid/fiware-cygnus/blob/master/doc/cygnus-ngsi/flume_extensions_catalogue/ngsi_mongo_sink.md

https://github.com/telefonicaid/fiware-cygnus/blob/master/doc/cygnus-ngsi/flume_extensions_catalogue/ngsi_sth_sink.md

Maybe this help.

To put it simply, I realized that the problem I was experiencing was due to the parameters that I did not change in the config.js file of the STH Comet I set up on the remote server.

So, I changed the host parameter (from "localhost" to the "server's own IP") in config.server part and the URI parameter (from "localhost:27017" to "serversIP:27017") in the config.database part in the file.

The system is now working as expected.

As described here, the NGSI-LD interface is a flexible API which outputs various JSON and JSON-LD formats and is used for data exchange. The tutorials are describing the correct use of the interface only. They do not cover production deployments.

After I restart the tutorial all data i have written is deleted.

The tutorials are just that - they start from a clean slate. The Mongo-DB instance in the docker-file does not have a persistent volume and cleans up after itself.

it accepts any data, ignoring the data-model.

That is because JSON-LD @context isn't used to validate JSON data - you need a JSON schema for that. Technically the @vocab element in the NGSI-LD core context @context file pushes any unknown elements onto the so-called default context https://uri.etsi.org/ngsi-ld/default-context/. The @context file is simply providing a mechanism to standardize the attribute names into IRIs. Assuming you have created a Swagger/Open API file for your use case, then you can use the Swagger editor to generate server or client code stubs. Doing this in Java say, will result in a POJO which just accepts the attributes of your model.

How to setup the orion context broker

You could use the docker-compose provided as a basis for getting started, but for proper large scale deployments on Kubernetes, the provided Helm Charts are recommended. The Orion-LD documentation goes into more details.

How to provide the context File to the Context Broker

You place the @context file on a public web server. How you host your @context file is up to you. The tutorials use HTTPD for this purpose. The main idea behind an @context is that you are publishing an agreed set of IRIs which correspond to the attributes in your data. Smart Data Models, Schema.org, GS1 and plenty of other bodies generate IRIs, you should reuse them and link to them or publish your own @context describing your own world.

Once an @context just append the Link header to each context broker request.

ok, this seems to be a problem in the broker. Create an issue on Orion-LD's github, please: https://github.com/FIWARE/context.Orion-LD/issues.

I recently implemented tenant checks for retrievals. It's OK to create new tenants on the fly (entity create operations), but for queries, the tenant must exist already, and the list is in RAM. Meaning, only the broker that created the entity knows about the tenant. It completely explains your problem. I didn't think about this use case, but you are absolutely right. I will have to improve the way I check for "tenant exists" for retrieval operations.

This is a consequence of the decision of Docker to remove or limit automated builds from various account types. It has made collating the images much more complicated. Previously the FIWARE Builds would trigger as clones of the contributory repositories. The problems caused by this issue have been recognized by the Technical Steering Committee of FIWARE. At the moment builds are transitioning to a newer build mechanism - possibly using a duplicate or alternative image repositories as well.

In most cases, such as the case of Orion and Cygnus created by Telefónica, you will still be able find tagged build generated from the original source repository under their own Docker Hub account - e.g telefonicaiot/fiware-orion and telefonicaiot/fiware-cygnus. The FIWARE clones of these images (a pull/push of the same SHA1 hash) are built and tested by the fiwarebot periodically - fiware/orion:3.3.0 is now available for example, but the mechanism to fully standardize and automate this procedure will need some bedding in.

Once the system is fully in place, it is likely that the FIWARE builds will still lag the builds made by the teams behind each generic enabler, but a standard release will occur in alignment with each of the full FIWARE Releases

You have a complex scenario here, composed of an end-to-end chain of 5 components:

• Prosys OPC-UA Server Simulation
• OPC-UA FIWARE IoT Agent
• Orion Context Broker
• FIWARE Cygnus Connector
• PostgreSQL database

My recomendation here would be to check every step in the chain (looking in logs, etc.) to ensure everything is correct before of checking the next step.

The id should be generated by the application itself. You have multiple ways of generating unique ids but I would recommend ids that have some semantics behind so that you can, for instance, infer from an id in which area the sensor is located, who the owner is, etc.

Orion-LD does not implement federation yet. The concept is being defined in ETSI ISG CIM and until it is decided exactly how it is to work (in a standard way), it cannot be implemented (unless we're willing to reimplement it once it gets defined in ETSI).

That said, Scorpio (another NGSi-LD broker) implements its own "NEC proprietary" federation scheme.

About "/op/notify", it is actually implemented in Orion-LD (POST /ngsi-ld/ex/v1/notify), it's just not meant for federation but for maintaining a local copy of some other broker's entities, based on subscriptions/notifications. This feature in brand new and was added to Orion-LD a few weeks ago.

CURLOPT_POSTFIELDS expects a char* but you are supplying a std::string.

This should be working better: