three-level tree struct in expected input data

[MLopezJ]

TL;DR

the following object will not be able to be received as result of the Thingy:91 - Coiote integration:

"3303": {
  "0": {
    "5700": {
      value: 27.18,
    },
    "5701": {
      value: "Cel",
    },
  },
  "1": {
      "5700": {
      value: 27.18,
    },
    "5701": {
      value: "Cel",
    },
  },
}

Because:

1. Humidity, temperature and pressure are the only objects that are needed in the flow that are defined as "multiple instance" in LwM2M
2. Thingy:91 only has one instance for temperature, pressure and humidity

So it is not necessary to implement changes to be able to identify the instance, because all will refers to the unique instance existing.

"3303": {
  "0": {
    "5700": {
      value: 27.18,
    },
    "5701": {
      value: "Cel",
    },
  },
}

Should looks like:

"3303:1.1": [
    {
      "5700": 27.18,
      "5701": "Cel",
    },
  ]

Issue discussion

AVSystem document the expect input of this repo as

three-level tree that has the following structure:

- object (e.g. a 'temperature sensor')
  - object instance (e.g. 'temperature sensor #1', 'temperature sensor #2' etc.)
    - resource (e.g. 'current temperature value')

LwM2M mappings - Azure IoT Hub Link

On other hand, as part of the transformation of data process, there is an assumption about reducing the object layers. Basically the assumption says that the second layers should be removed, but now there is known that this second layer belongs to the object instance.

Considering the option of multiple instances and comparing it with the definition schema of the final step of the complete flow (nRF Asset Tracker), looks like the app is not considering the option of multiple instances on their objects:

Example:

 "env": {
      "description": "Environment sensor readings",
      "type": "object",
      "properties": {
        "v": {
          "description": "The individual sensor readings",
          "type": "object",
          "properties": {
            "temp": {
              "description": "Temperature reading from external sensor",
              "type": "number"
            },
            "hum": {
              "description": "Humidity reading from external sensor",
              "type": "number",
              "minimum": 1,
              "maximum": 100
            },
            "atmp": {
              "description": "Atmospheric pressure reading from external sensor in kPa",
              "type": "number",
              "minimum": 0
            }
          },
          "required": ["hum", "temp", "atmp"]
        },
        "ts": {
          "description": "Timestamp as Unix epoch with millisecond precision (UTC)",
          "type": "integer",
          "minimum": 1234567890123
        }
      },
      "required": ["v", "ts"]
    }

So approach of removing second layer would still works to match expected format at the end of the complete process.

But this specific repo is not about meet criterial for the last step of the process. This repo is about taking Coiote's data and transform to the equivalent LwM2M data format (in order to check the veracity of struct before send it to others steps of the process )

So it is needed to contemplate this second layer of the object related to instances in the expected output

[MLopezJ]

Check MultipleInstances definition for LwM2M obejcts

LwM2M define if the object is able to have multiple instances or not in the MultipleInstances prop.

This value should be checked at the transformation process and expected output should be validated to see if struct is the correct in order to its definition.

[MLopezJ]

Discussion:

By checking the MultipleInstances prop there is ensure that the object struct assignment is the correct with its LwM2M definition; object or array.

But as it is right now there is lose the capability to identify to which instance the value belongs.

Lets assume the following example:

"3303": {
          "1": {
            "5601": {
              value: 27.18,
            },
            "5602": {
              value: 27.71,
            },
            "5700": {
              value: 27.18,
            },
            "5701": {
              value: "Cel",
            },
          },
        }

With the last input, the output will be

"3303:1.1": [
    {
      "5601": 27.18,
      "5602": 27.71,
      "5700": 27.18,
      "5701": "Cel",
    },
  ]

but we just lose the capability to know that value belongs to instance number 1 and we can assume it belongs to the instance number 0, which will be incorrect.

On other hand, if the output were:

"3303:1.1": [
   {1: 
       {
      "5601": 27.18,
      "5602": 27.71,
      "5700": 27.18,
      "5701": "Cel",
      }
    }
  ]

It is gain again the possibility to identify the instance without doubts, but the object inside of the array is not following any LwM2M object definition. And an extra step would be needed before checking against LwM2M types lib.

Another alternative to represent instances would be:

"3303:1.1": [
    undefined, 
    {
      "5601": 27.18,
      "5602": 27.71,
      "5700": 27.18,
      "5701": "Cel",
    },
  ]

[MLopezJ]

But as it is right now there is lose the capability to identify to which instance the value belongs.

What would be the implication of loses the capability to identify to which instance the value belongs?

Beyond if nRF Asset Tracker contemplate multiple instances or not, Coiote does and in the example AVSystem is providing in the documentation

"3": {
  "1": {
    "1": {
      "value": "airquality-0-Valparaiso"
    }
  }
},

means that we could assign the value to wrong instance. That is a risk!!!

However, The input data of the flow is ruled by the thingy. Can the Thingy have multiple instances of a Temperature, Humidity and Pressure?

If yes, this situation should be addressed. If not, it can be ignored in the implementation but documented with the reasons of the decision.

[MLopezJ]

However, The input data of the flow is ruled by the thingy. Can the Thingy have multiple instances of a Temperature, Humidity and Pressure?

Can the Thingy:91 have multiple instances of Temperature?

The thingy contains capability to catch environment sensors; temperature, humidity, air quality, and air pressure. All those values are getting from the same chip: bme680.

I can not confirm it at the 100%, but with what I see on the datasheet of the chip looks like it is only one instance. Same with humidity and pressure.

[MLopezJ]

I double check with Max and Bernt about how many temperature sensors the Thingy:91 has and it is only one in the BME680 chip. Same with humidity and pressure.

Conclusion:

If temperature, humidity and pressure are the only LwM2M objects defined as multiple instances in the requested input by nRF Asset Tracker, and there are just one instance of each object in the thingy:91, it means that there is not a possibility to receive multiple instances object from Coiote (in this context). so, the problem about instances identification will not happen and that also means that no changes will be needed but documentation about this will be required (documentation should be in text - readme- and in code -unit test-)