smart-data-models/datamodel.device

Device Data Model

datamodel.device's Issues

Device schema is invalid: data/properties/controlledProperty/items/enum must NOT have duplicate items

I cannot use the Device schema in my express-openapi project since controlledProperty includes eatingActivity twice.

Could you please fix that?

Questions/Extensions to the Camera Data Model

We are in the process of adding our information of the CCTV in the are of our municipality and a few questions arose during the data model transformation (from our old data model to the Camera data model):

1. We have a status field that indicates if the camera is in operation, with issues, repairing, disable, etc. There seems to be no corresponding field. Would it be possible to add this field to the data model. The use-case for us is to understand and only display working camera's.
2. Is there an update on the cameraType enumerator? Is it still the 3 fields? We would like to add-one for Traffic Cameras.

Thank you in advance, if you agree with them I would be more than happy to contribute these changes!

Device examples do not include configuration property

The different examples related to the schema Device do not include an example of the content of configuration property. See for example example.jsonld

Parent-child relationship

This is not so much an issue, as a question, so please redirect me if there are more appropriate places to ask this.

How can a child-parent relationship between devices be modelled? Is the model still being followed even if a new attribute refParentDevice is added to give the relationship or can this be dealt with in a different manner within, the scope of the model?

Device schema cannot be used in Javascipt / Python since those Regex engines do not support POSIX Bracket Expressions

I cannot use the Device schema in my express-openapi project since macAddress pattern ^([[:xdigit:]]{2}[:.-]?){5}[[:xdigit:]]{2}$ is not supported by the Javascript Regex engine.

Could you please replace the POSIX Bracket Expression [[:xdigit:]] for hexadecimal digits through [A-Fa-f0-9] which is supported by all engines?

Some examples swapped between normalized/keyvalues format

It seems to be the case for : Device, DeviceModel, PrivacyObject.

Attributes controlledProperty and category are no longer defined

Hello,
recent commits 386e029 and 8078d03 made substantial edits to this data model.

One of the outcomes is that attributes controlledProperty and category are no longer defined. I suggest to restore the deleted information.

Issues with definition of the 'category' attribute

These are my comments from #9 that was closed, as I cannot reopen it.

1. In DeviceModel/doc/spec.md, category is not defined.
2. In Device/doc/spec.md, category is bad formatted.

Re 1:
It was well described before the changes in December 2020:

• category : Device's category(ies).
  - Attribute type: Property. List of Text
  - Allowed values, one of the following or any other meaningful to the
  application:
  - sensor : A device that detects and responds to events or changes in
  the physical environment such as light, motion, or temperature changes.
  https://w3id.org/saref#Sensor.
  - actuator : A device responsible for moving or controlling a mechanism
  or system. https://w3id.org/saref#Actuator.
  - (...)

Re2 :

The current state:

• category: A device that detects and responds to events or changes in the physical environment such as light, motion, or temperature changes. https://w3id.org/saref#Sensor. actuator : A device responsible for moving or controlling a mechanism or system. https://w3id.org/saref#Actuator. Meter : A device built to accurately detect and display a quantity in a form readable by a human being. Partially defined by SAREF. HVAC : Heating, Ventilation and Air Conditioning (HVAC) device that provides indoor environmental comfort. https://w3id.org/saref#HVAC. Network : A device used to connect other devices in a network, such as hub, switch or router in a LAN or Sensor network. (https://w3id.org/saref#Network.Multimedia : A device designed to display, store, record or play multimedia content such as audio, images, animation, video. Enum:'actuator, beacon, endgun, HVAC, implement, irrSection, irrSystem, meter, multimedia, network, sensor'

For instance, it is not clear what is the first part about ("A device that detects..."). Perhaps, word "sensor" is missing in the beginning. Attribute type is missing. It says 'Meter', but the correct value is 'meter'. A parenthesis is open but not closed. etc.

Forgive me but the problem is that we were referring to this documentation in our project, and since those changes, it's harder to read and to understand by newcomers.

Device: Non NGSI-LD conform example for controlledAsset

The example for controlledAsset of a Device right now is

"controlledAsset": {
        "type": "Relationship",
        "object": [
            "urn:ngsi-ld::wastecontainer-Osuna-100"
        ]
}

This usage of a list of Relationships is non conform to the current NGSI-LD specification (similar to the previous normalized NGSI-LD examples of the Road Data Model). Instead the example should look like this:

"controlledAsset": [
      {
        "type": "Relationship",
        "object":  "urn:ngsi-ld::wastecontainer-Osuna-100"
      }       
]

The datasetId can be omitted here, because there is only 1 (default) item. According to the current specification:

If no datasetId is provided, it is considered as the default Attribute instance. Thus the creation, updating, appending or deleting of Attributes without providing a datasetId only affects the default Attribute instance.

I am not sure whether

"controlledAsset": 
      {
        "type": "Relationship",
        "object":  "urn:ngsi-ld::wastecontainer-Osuna-100"
      }       

would also be valid in this case.

---

Additionally I saw that schema.json uses a Property annotation/description for controlledAsset:

"controlledAsset": {
          "type": "array",
          "description": "Property. Model:'https://schema.org/Text'. List of the asset(s) (building, object, etc.) controlled by the device.",
...

Shouldn't this be a Relationship?

Device schema cannot be used in OpenAPI 3.0 projects since const and version keywords are not supported

I cannot use the Device schema in my express-openapi project since version: 0.0.5 and batteryLevel const -1 are not supported keywords in OpenAPI 3.0 projects.

For batteryLevel I suggest to use following scheme:

batteryLevel:
  description: 'Device battery level. It must be equal to 1.0 when battery is full. 0.0 when battery is empty. -1 when transiently cannot be determined.'
  maximum: 1
  minimum: -1
  type: number
  default: -1

Could you please fix that?

Several quantitative values with different time stamps

We have a use case where we have devices with several quantitative values AND different time stamps. We cannot map this use case with the device model (also attached):
"controlledProperty": ["fillingLevel", "temperature"],
"value": "l%3D0.22%3Bt%3D21.2",

I could have thought of two possible solutions:
1: an additional timestamp per measured value; e.g. like:
{
"controlledProperty": ["electric_power"],
"value_electric_power": 5.00,
"timestamp_electric_power": "2020-06-01T00:00:00.00Z",

"controlledProperty_1": ["temperature"],
"value_temperature": 21.00,
"timestamp_temperature": "2020-06-01T00:10:00.00Z"

}

2: an additional/ new model "device observation"

Thanks and regards, Aline

rssi property should be expressed as dBm or renamed to be Normalized rssi

The rssi property is defined as follow "rssi : Received signal strength indicator for a wireless enabled device. It must be equal to 1.0 when the signal strength is maximum. 0.0 when signal is missing. -1.0 when it cannot be determined."

However, signal strength is usually expressed in mW or dBm. For example, a LoRaWAN device can have sensitivity below -120dBm and thus receive signals which could have rssi of -125dBm.
The current [0-1] scale looks like a "normalized rssi" which is not always available (which system provide such a normalised value ? Mobile handsets ?)

=> I suggest to modify the allowed range or clearly differentiate absolute vs normalised rssi.