IoT Platform Documentation
Note well
-
This home wiki redirects to
SDK-v1SDK-v2, but also toserver installationwiki. -
Developers of AI, WMS and/or HMI components can skip document about
installing the platform, and focus on SDK-v1 and SDK-v2 documents.
SDKs
If you want to test communications with the platform, then please ignore the IoT platform installation wiki and proceed to test comms with development server environment
IoT Platform available servers
We currently use two deployments (platforms) for NAIADES,
-
DEVELOPMENT platform: also known asdev platform, is an environment where we test new features, test integration, etc. DATABASEs data will probably be wiped out from time to time -
PRODUCTION platform: also known asprod platform, is an environment where we deploy stable features, databases are backed-up regularly
| environment | host | opened ports | services running |
|---|---|---|---|
| DEVELOPMENT | 5.53.108.182 | 1026/tcp 1027/tcp 3005/tcp 8668/tcp |
current data (pull and/or subscribe) access controlled querying identity manager querying historical data |
| PRODUCTION | ? | 80/tcp 443/tcp |
IoT Platform services
The following table describes what is the purposes of each platform service:
| service | purpose |
|---|---|
| db-crate | database for timeseries (historical data) |
| db-mongo | database for context-manager (currrent data) |
| db-mysql | database for identities and roles |
| fiware-keyrock | manages identities and roles |
| fiware-orion | context manager, API server for all entities |
| fiware-orion-proxy | enforce access control |
| fiware-quantumleap | REST service for storing, querying and retrieving NGSI v2 spatial-temporal data |
| wms-app-example | Dummy example of a WMS component, acts as a consumer(subscriber) and publisher of messages to NAIADES |
SDK (software development kits)
Here below we provide some documents which will help any developer either i) communicate with an existing IoT platform (as clients) or ii) deploy the IoT platform (deploy your own server).
NOTE:
Developers of AI, WMS and/or HMI components can skip document about server installation, and focus on SDK-v1 and SDK-v2 documents:
| Document description | Document link | Comments |
|---|---|---|
| Installing the IoT platform in your own server | server installation | Advanced Only for partners which want to build their own IoT platform. Not needed for running SDKs |
| Getting started with Context Manager and Time Series APIs | SDK-v1 | Please run SDK scripts against dev environment server (5.53.108.182) |
| How to use IdM API and tokens for queries | SDK-v2 | Please run SDK scripts against dev environment server (5.53.108.182) |
| Some basic API client examples using postman | postman collection |
Integration tests:
The following table describes which partners have managed to test successfully communications with the dev platform
| Partner | Component | Testeds comms ok (sdk-v1) | Tested Auth(s) comms ok (sdk-v2) |
|---|---|---|---|
| UDGA | Data collection | OK | OK |
| SIMAVI | Data collection |
not tested |
not tested |
| ADSYS | Data collection |
not tested |
not tested |
| AIMEN | Data collection |
not tested |
not tested |
| IHE | WMS service |
not tested |
not tested |
| JSI | WMS service |
not tested |
not tested |
| AIMEN | WMS service |
not tested |
not tested |
| CERTH | WMS service | OK | OK |
| ADSYS | Data fusion |
not tested |
not tested |
| KT | HMI |
not tested |
not tested |
| ICCS | HMI |
not tested |
not tested |
| SIMAVI | HMI |
not tested |
not tested |
FAQs:
[Q] Do we need to install the platform (the part with docker) if we want to run the SDK?
[A] Nope, you can either run the SDK requests against the development server.
[Q] the WMS module and its associated ML algorithm (e.g. to predict weather values and send them to the platform) should be developed as a separate container? e.g. using wms_example as a starting point?
[A] yep, you can use that as a starting point, WMS_example only exemplifies how to use the subscription feature or of the IoT platfrom though.. you will probably need more than that . E.g. consuming data from the historical API
[Q] how to we integrate our module to the platform?
[A] you can either push the code to the git repo (different branch from master) and provide the Dockerfile describing how to build and run the service, or you can push directly the docker image to dockerhub and then we will pull the image from there :)
[Q] How do I create an entity and push historical records to the historical API?
[A]
step1. define your entity id, it should follow the conventions:
udn:ngsi-ld:<dataType>:<string>
e.g
urn:ngsi-ld:WaterQualityObserved:fountain-1
step2. create entity, use script example named watering_01_create_entity.sh
step3. ask historical DB to start tracking a certain entity (start saving records in historic DB)
please use as template script historic_01_set_up.sh, you will need to update the description and the type as minimal modifications
step4. test it
please use as template script historic_02_api_query.sh
DOESNT IT WORK?
- check again step 3 and 4 .sh examples
- remeber to include the headers in the requyest:
--header "Fiware-Service: carouge"
--header "Fiware-ServicePath: /"TODO :
- fill in PRODUCTION row after testing services are reachable (SIMAVI)
- Include section about maintainance , e.g. data base backups and restoring (UDGA)
- Describe NGINX integration (SIMAVI)