albertoabellagarcia
commented
4 years ago 1.- First of all thank for the contribution 2.- We have these repositories frozen while evolution has been derived to http://github.com/smart-data-models initiative 3.- Specifically this PR should be accepted here https://github.com/smart-data-models/dataModel.Streetlighting/tree/master/StreetlightControlCabinet 4.- In order to be accepted there, it should include additionally the changes on the schema.json (in fact it is critical) 5.- There are guidelines (https://github.com/smart-data-models/data-models/blob/master/guidelines.md) and a contribution manual (http://data-models.fiware.org/index.php/2020/05/15/contribution-manual/) for making things as smooth as possible
Please contact me if you have any doubt alberto.abella @ fiware. org
This PR is a contribution coming from real usage cases from Diputación de Castellón (Spain).
We propose a de-normalization of the following attributes in StreetlightControlCabinet entity type: activePower, reactivePower, intensity, thdrIntensity, thdrVoltage and voltage. Instead of having an StructureValue with an array of objects composed of name and value keys, we propose to simplify this and having attribute per each different electrical phase (R, S and T). For instance: activePowerR, activePowerS and activePowerT.
The rationale of this is that phases are always R, S and T in real-world electricity installations, so it doesn’t make sense to use sub-properties here. Indeed, using denormalized attributes such as activePowerR, activePowerS and activePowerT is easier for context consumer and context producers of this information.
In addition, we have found in real deployments that powerFactor is also specified phase by phase, so we propose to change powerFactor single attribute to powerFactorR, powerFactorS and powerFactorT attributes.
We have changed the documentation and examples in the .md files and some .json files. Changes in other places (JSON Schema? NGSI-LD schema?) are beyond our knowledge.