Jason Fox's profile - activity

If you are running Windows, you should follow the instructions here: https://www.poftut.com/install-use-cygwin-terminal-ssh-examples/ to ensure you have a working Cygwin command line. Obviously the install will depend on the underlying Windows version.

The tutorial documentation clearly states various prerequisites are required see: https://fiware-tutorials.readthedocs.io/en/latest/ - do you have the correct versions of Docker, Docker Compose and Cygwin for Windows running successfully?

Copy-Pasting the original docker-compose file into https://yamlvalidator.com shows that the original file is already valid YAML

There are also a series of Kubernetes deployment recipes based on Helm for common setups of FIWARE Generic Enablers including IDAS And Cygnus: https://github.com/FIWARE/production-...

After the review, it is a manual process to flick the switch and add your product to the FIWARE Marketplace, but the application should have all the relevant details already, so it shouldn't take long to become visible.

If for some reason you have been approved and the offering cannot be found, please contact someone in the FIWARE Foundation directly to follow up on this - the relevant button may not have been pressed.

As of December 2020, STH-Comet does not service the NGSI-LD interface and is NGSI-v2 only. However Orion-LD has recently been updated with a new backwards compatibility feature that allows it to send subscriptions in NGSI-v2 format.

An NGSI-LD subscription looks like this:

curl -L -X POST 'http://localhost:1026/ngsi-ld/v1/subscriptions/' \ -H 'Content-Type: application/json' \ -H 'Link: <https://fiware.github.io/tutorials.Step-by-Step/tutorials-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"' \ --data-raw '{ "description": "LD Notify me of low stock in Store 002", "type": "Subscription", "entities": [{"type": "Shelf"}], "watchedAttributes": ["numberOfItems"], "q": "numberOfItems<10;locatedIn==urn:ngsi-ld:Building:store002", "notification": { "attributes": ["numberOfItems", "stocks", "locatedIn"], "format": "normalized", "endpoint": { "uri": "http://tutorial:3000/subscription/low-stock-store002", "accept": "application/ld+json" } } }'

The format parameter is usually keyValues or normalized. The accept parameter is usually application/json or application/ld+json. Setting these to NGSIv2-Normalized and application/json should allow STH-Comet to receive subscriptions from Orion-LD.

The usual assumption with domain names is that the owner will be the name of the main domain who is then free to choose their own subdomains as they see fit.

Therefore fiware.orange.com would be taken to be owned by Orange and should never be needed to used as FQDN by the FIWARE Foundation itself

Within NGSI-LD currently the FIWARE Foundation uses https://uri.fiware.org/ns/data-models to prefix its URNs. https://schema.fiware.org has also been used in the past. It can be expected that whatever this changes to in the future it will be something.fiware.org

In the general case, you should be free to use any FQDN where you already have registered the root domain.

The reason that this remains unclear is that both options are possible.

• an active attribute ( that is configured as part of the attributes array) must actively send measures to the agent
• a lazy attribute ( that is configured as part of the lazy array) is requested by the IoT Agent whenever the context broker receives a request for the device.

Taking the HTTP transport as an example, the IoT Agent listens to the context broker on the north port and a "well-known" location on the southport so devices can send info to it. In the case of a lazy attribute the IoT Agent knows where to forward the request based on the resource defined by the configuration.

Taking the MQTT transport as an example, the IoT Agent listens to the context broker on the north port and subscribes to MQTT topics for each of the devices. In the case of a lazy attribute the IoT Agent publishes a topic for an update and polls and waits for the response before passing back to the context broker.

Active attributes are by far the commonest way to provision devices.

• see https://iotagent-node-lib.readthedocs...

The answers for this have been posted on Stack Overflow:

• https://stackoverflow.com/questions/6... - Docker Compose
• https://stackoverflow.com/questions/6... - Docker Swarm

There are a series of FIWARE consultancy services on the FIWARE Marketplace: https://marketplace.fiware.org/pages/...

In addition to the Tour Guide which gives a brief introduction to the major elements of the FIWARE Catalogue there is a growing list of learning materials being created on line:

• FIWARE Webinars
• FIWARE Tutorials

There is usually a quick start guide or simple tutorial to be found within the documentation of each generic enabler as well.

If you are using FIWARE Orion as-is and your software is merely sending/receiving context information there is no obligation to open source your own proprietary software. If you are just using the docker images that will be fine.

The AGPL 3.0 is more concerned about a developer who improves the source code of Orion and wants to keep that improvement to themselves for commercial gain - that would not be compliant. The AGPL is used because the current contributors to all of the FIWARE catalogue components are giving all updates back as free open source, and new contributors should as well.

Third parties commercial software connecting to the unchanged open source components are not obliged to be open source themselves - indeed the commercial offering found on the FIWARE Marketplace are good examples of this concept: https://marketplace.fiware.org/

It is difficult to decide what is a "best" approach as it will depend on your use case. Several options present themselves:

• Read NGSI entities direct from Orion and create your own code to display locations on the map - this is the bespoke approach used in the Step-by-step tutorials - https://github.com/FIWARE/tutorials.S...

• Abstract the reading of context data into a widget of some sort - such as described by jmcantera: https://github.com/jmcanterafonseca/l...

• Use a pre-existing Wirecloud widget which collates NGSI data via an NGSI proxy - see: https://github.com/FIWARE/tutorials.A...

• Display a fully interactive analytical business intellegence layer via Knowage https://knowage-suite.readthedocs.io/...

These run from the simple to the complex and are increasingly flexible as you go down the list.

When setting up the subscription, Cygnus currently only accepts notifications in the older NGSI v1 format- the attrsFormat=legacy is therefore needed.

see this : Stack Overflow Answer for more details

In your demo I’ve checked - you are connecting to a mongo DB - you are aggregating

docker run -it --network comet_demo_fiware_network --entrypoint /bin/bash mongo

mongo --host mongo_sth --port 27018

show dbs

admin 0.000GB config 0.000GB local 0.000GB sth_sensei_service 0.000GB

use sth_sensei_service

It looks the that your subscription is incorrect: { "entities": [ { "type": "PersonDetection", "isPattern": "false", "id": "PersonDetection" } ], "attributes": [ "ts" ], "reference": "http://sth:8666/notify" }

This means you are storing the ts attribute only.

Your request to comet is reading positionX and which has not been aggregated.

http://sth:8666/STH/v1/contextEntities/type/PersonDetection/id/PersonDetection/attributes/positionX

I hope this helps - you will need to alter your subscription - the attributes should be:

"attributes": [ “ts”, “posistionX” “positionY" ]

There is a simple "how to connect Cygnus" tutorial on GitHub - https://github.com/fiware/tutorials.Historic-Context

Ensure that you are running with logging to the max -I use the `CYGNUS_LOG_LEVEL=DEBUG` environment variable. Check that you are sending your notification to the right port - e.g. `CYGNUS_SERVICE_PORT=5050` would listen on "notification": {"http": { "url": "http://cygnus:5050/notify }}.

It looks like things have changed since the previous answer to this question. Standardization of a set of Urban Mobility data Models based on the GTFS transit feed is now being discussed with the following Pull Request

The notification.sh appears to be a simulation of the result of an Orion Subscription - and therefore needs to be posted to the port Cygnus is listening on - which is usually localhost:5050 - assuming you are running Cygnus on localhost.

Your couldn't connect to host message indicates that either you have not started Cygnus on localhost or you have configured an alternate port. Ensure you have used the environment variable CYGNUS_API_PORT=5080 somewhere or the agent.conf file holds a line cygnus-ngsi.sources.http-source.port = 5050

The subscription it is simulating is supposed to be something along the lines of When X occurs send a notification to cygnus - Therefore I'm guessing that localhost:5050 is the location where Cygnus is supposed to be listening.

When setting up a REAL subscription and running Orion it needs to be something like:

curl -X POST \ 'http://{{orion:port}}/v2/subscriptions/' \ -H 'Content-Type: application/json' \ -d '{ "description": "Notify Cygnus of all context changes", "subject": { "entities": [ { "idPattern": ".*" } ] }, "notification": { "http": { "url": "http://{{cygnus:port}}/notify" }, "attrsFormat": "legacy" }, "throttling": 5 }'

Replace {{orion:port}} and {{cyngnus:port}} as necessary (this assumes you are not using a fiware-header or fiware-servicepath yet...)

You can then update an existing entity with the PATCH command:

curl -X PATCH \ 'http://{{orion}}/v2/entities/<entity-id>/attrs' \ -H 'Content-Type: application/json' \ -d ' { "price":{"type":"Integer", "value": 89} }'

Obviously replace <entity-id> and the -d payload with your data.