Migration to schema-generated specifications

In order to:

  1. Maintain updated the specifications
  2. Be able to provide them in multiple languages
  3. Being able to track what properties are already defined
  4. Populate properly the database of properties
  5. Have a shared image for all contributions
  6. Reduce the burden of work for the contributors (it will be reduced to just the documented json schema and the examples)

It has been decided that the description of the properties of the data models will be included in the schemas defining the data models (or those linked through $ref). so during next days, you will see minor changes in the schema.json of every data model in the initiative.

And although it will be announced previously all the spec.md will be replaced by an automatically generated (based on the info). See an example here. Design could be modified so any suggestion will be assessed and eventually implemented.

Customization will be possible through a new file named notes.yaml

This is taking most of our resources and impact on our bandwidth t provide answers to the PR, but we expect that this will reduce our workload significantly so we will be more agile after this change.

updated context.jsonld

The @context, located on the root of the github repository, of the initiative is now updated automatically.

The long URLs are now completely significative because either they point to the original URL of the property or they point to the terms.jsonld file where the definitions based on the existing data models are present.

 

New harmonized data models

Harmonization repository is dedicated to those data models that are mostly accepted and only requirements of consistency, complete documentation and examples availability.

Here there is a list of coming data models in different domains:

Battery
StorageBattery
StorageBatteryDevice
StorageBatteryMeasurement

Energy
ACMeasurement
InverterDevice
PhotoVoltaicDevice
PhotovoltaicMeasurement

Environment
ElectroMagneticObserved
PhreaticLevel
RainFallRadarObservation

Ports
BoatAtuthorized
BoatPlacesAvailable
BoatPlacesPricing
SeaportFacilities

Smart cities
CityWorks
StationDescription

Cheatsheet for installing a NGSI v2

We’ve submitted into the utils directory a short script for installing and running an instance of NGSI v2 and to create your first entity and to list it. It is not a complete guide which is available at FIWARE mains page in this link.

# 1.- if your are coming from a clean installation
sudo docker pull mongo:3.6
sudo docker pull fiware/orion
sudo docker network create fiware_default
sudo docker run -d –name=mongo-db –network=fiware_default –expose=27017 mongo:3.6 –bind_ip_all –smallfiles
sudo docker run -d –name fiware-orion -h orion –network=fiware_default -p 1026:1026 fiware/orion -dbhost mongo-db

# 2.- In case you already had a installation it is better to run these instructions
docker stop fiware-orion
docker rm fiware-orion
docker stop mongo-db
docker rm mongo-db
docker network rm fiware_default

# 3.- Check that your installation is up and running
curl -X GET ‘http://localhost:1026/version’

# 4.- Create your first entity
curl -iX POST ‘http://localhost:1026/v2/entities’ -H ‘Content-Type: application/json’ -d ‘
{
“id”: “urn:ngsi-ld:PhotovoltaicDevice:PhotovoltaicDevice:MNCA-PV-T2-R-012”,
“type”: “PhotovoltaicDevice”,
“name”: {
“type”: “Property”,
“value”: “DEVICE-PV-T2-R-012”
},
“alternateName”: {
“type”: “Property”,
“value”: “AirPort – global Observation”
},
“description”: {
“type”: “Property”,
“value”: “Photo-voltaic Device description”
},
“location”: {
“type”: “GeoProperty”,
“value”: {
“type”: “Point”,
“coordinates “: [43.664810, 7.196545]
}
},
“address”: {
“type”: “Property”,
“value”: {
“addressCountry”: “FR”,
“addressLocality”: “Nice”,
“streetAddress”: “Airport – Terminal 2 – Roof 2 – Local 12”
}
},
“areaServed”: {
“type”: “Property”,
“value”: “Nice Aeroport”
},
“refDevice”: {
“type”: “Relationship”,
“value”: “urn:ngsi-ld:Device:PV-T2-R-012”
},
“brandname”: {
“type”: “Property”,
“value”: “Canadian Solar”
},
“modelName”: {
“type”: “Property”,
“value”: “CS6P-270P”
},
“manufacturerName”: {
“type”: “Property”,
“value”: “Canadian Solar EMEA GmbH,”
},
“serialNumber”: {
“type”: “Property”,
“value”: [“CSPV270P-SN1804L6J34Z8742H”,
“CSPV270P-SN1804L6J34Z8743H”,
“CSPV270P-SN1804L6J34Z8744H”,
“CSPV270P-SN1804L6J34Z8745H”,
“CSPV270P-SN1804L6J34Z8746H”
]
},
“application”: {
“type”: “Property”,
“value”: “electric”
},
“cellType”: {
“type”: “Property”,
“value”: “polycrystalline”
},
“instalationMode”: {
“type”: “Property”,
“value”: “roofing”
},
“instalationCondition”: {
“type”: “Property”,
“value”: [“extremeHeat”, “extremeCold”, “extremeClimate”, “desert”]
},
“possibilityOfUsed”: {
“type”: “Property”,
“value”: “stationary”
},
“integrationMode”: {
“type”: “Property”,
“value”: “IAB”
},
“documentation”: {
“type”: “Property”,
“value”: “https://www.myDevicePV.Cn”
},
“owner”: {
“type”: “Property”,
“value”: [“Airport-Division Maintenance”]
},
“cellDimension”: {
“type”: “Property”,
“value”: {
“length”: 16.0,
“width”: 9.0,
“thickness”: 2.3
}
},
“moduleNbCells”: {
“type”: “Property”,
“value”: 60
},
“moduleDimension”: {
“type”: “Property”,
“value”: {
“length”: 1600,
“width”: 975,
“thickness”: 3.75
}
},
“panelNbModules”: {
“type”: “Property”,
“value”: 1
},
“panelDimension”: {
“type”: “Property”,
“value”: {
“length”: 1638,
“width”: 982,
“thickness”: 40
}
},
“panelWeight”: {
“type”: “Property”,
“value”: 18
},
“arealWeight”: {
“type”: “Property”,
“value”: 32
},
“maxPressureLoad”: {
“type”: “Property”,
“value”: {
“hail”: 2500,
“snow”: 5400,
“wind”: 2400
}
},
“NominalPower”: {
“type”: “Property”,
“value”: 270
},
“MaximumSystemVoltage”: {
“type”: “Property”,
“value”: 1000
},
“applicationClass”: {
“type”: “Property”,
“value”: “A”
},
“fireClass”: {
“type”: “Property”,
“value”: “C”
},
“pTCClass”: {
“type”: “Property”,
“value”: 92.1
},
“nTCClass”: {
“type”: “Property”,
“value”: 88.3
},
“protectionIP”: {
“type”: “Property”,
“value”: “IP67”
},
“moduleSTC”: {
“type”: “Property”,
“value”: {
“Pmax”: 270,
“Umpp”: 30.8,
“Impp”: 8.75,
“Uoc”: 37.9,
“Isc”: 9.32
}
},
“moduleNOCT”: {
“type”: “Property”,
“value”: {
“Pmax”: 196,
“Umpp”: 28.1,
“Impp”: 6.97,
“Uoc”: 34.8,
“Isc”: 7.55
}
},
“moduleYieldRate”: {
“type”: “Property”,
“value”: 16.79
},
“panelOperatingTemperature”: {
“type”: “Property”,
“value”: {
“min”: -40,
“max”: 85
}
},
“cellOperatingTemperature”: {
“type”: “Property”,
“value”: {
“min”: 45,
“max”: 2
}
},
“temperatureCoefficient”: {
“type”: “Property”,
“value”: {
“Pmax”: -0.41,
“Uoc”: -0.31,
“Isc”: 0.053
}
},
“performanceLowIrradiance”: {
“type”: “Property”,
“value”: 96.5
},
“panelLifetime”: {
“type”: “Property”,
“value”: 30
},
“panelYieldCurve”: {
“type”: “Property”,
“value”: [“95.0”, “92.5”, “90.0”, “87.5”, “85.0”, “80.0”]
},
“panelYieldRate”: {
“type”: “Property”,
“value”: 0.5
},
“panelTiltReference”: {
“type”: “Property”,
“value”: {
“min”: 28,
“max”: 37
}
}
}

# 5.- List the entity you have created
curl -G -X GET ‘http://localhost:1026/v2/entities’ -d ‘options=keyValues’

Drafting service for creation of automatic payloads of a Smart Data Model

We are in the way of creating a service for testing purposes for getting payloads according to a data model.

The service is under debugging, so it cannot be trusted for production purposes. Let us know issues here

In order to access it has to access this URL (https://smartdatamodels.org/extra/payload_generator.php) with these two parameters token and dataModel

I.e. with a weather observation in the link below:

https://smartdatamodels.org/extra/payload_generator.php?token=sSdme8954c9&dataModel=%22WeatherObserved (reload page several times for generation)

In the production stage, there will be necessary a token in order to, if necessary, to limit the access for a single user. Additionally, it should be available the options of normalized and keyvalues and for the NGSI v2 and LD.

Comments are welcomed

Official list of unitcodes

Whenever there is measurement it could be necessary to use the unitCode for setting the units for the value.

Now the guidelines for the data model’s creation include the place to find out these unit codes. See section units.

The list of UN/CEFACT Common Code (3 characters) can be download from this page. Or the list directly from here.

Automatic creation of examples

In order to reduce the amount of work in the contribution of data models, we have a script that generates the key-values format of a normalized NGSI LD payload.
It has been operated on 46 data models currently in the repository.

In a close future instead of submitting 4 examples, it will be only necessary to include 2 examples, the normalized payloads for NGSI v2 and NGSI LD (the other two would be generated automatically).

Making examples more consistent

All the repositories have been normalized in the naming of the core examples. So:

  • Key values in NGSI v2 is named example.json
  • Key values in NGSI LD is named example.jsonld
  • Normalized (default) in NGSI v2 is named example-normalized.json
  • Normalized (default) in NGSI LD is named example-normalized.jsonld

It is possible to have more examples in the directory. And in the same directory of every data model, there are other exports (csv) for the use of the data model users.
The goal is that this 4 examples were present in every data model