IPSO sensor object application type resource

[dirtyha]

I work for a sensor manufacturer for environmental monitoring. Generally speaking I like what IPSO sensor objects have to offer. However, I'm frustrated that 'Application Type' -resource is missing in many sensor objects (3200-3350). Let's take an example Temperature /3303 that contains no Application Type. Our weather stations can contain multiple temperature sensors: air temperature, road surface temperature, sensor heating (rain gauge during winter) temperature, weather station ambient temperature, not to mention calculated temperatures reported by the station: dew point temperature, wind chill etc. It is absolutely necessary to identity application type of the measurement. I ask you to harmonize IPSO sensor objects so that they all contain 'Application Type'.

[mkgillmore]

@dirtyha Could this functionality be added with a re-usable resource? Could you provide an example of how you would like to see 'Application Type' added to a object? Thanks!

[akeranen]

We could simply add resource 5750 to the IPSO SOs that are lacking it, or at least the ones we are now updating. @mkgillmore see for example 3200 vs. 3303.

However some of the "application types" @dirtyha mentioned seem more like a "context". I wonder if we should have different resource(s) for describing different things or do we want to lump all the info into single "application type"?

@dirtyha do you have some comprehensive list of information you would like to store in the resources? That would help ensuring a re-usable design.

[dirtyha]

Ok, let's see the backgroud for my request. In our measurement systems we use a (non-LwM2M related) structure called 'measurement parameters'. It is meta data that describes what has been measured and how. It contains the following fields:

1.type: measurement type e.g. numerical, textual etc. (match in IPSO SO meta data) 2.name: our standard to identify what has been measured e.g. AIR_TEMPERATURE, SURFACE_TEMPERATURE, DEW_POINT_TEMPERATURE,... 3.unit: self explanatory (match in IPSO SO) 4.statistics: e.g. VALUE, MIN, MAX, AVERAGE, DELTA (partly match in IPSO SO) 5.statistical period: ISO8601 period for statistics e.g. PT1M, PT10M, PT1H (no match in IPSO SO) 6.height: for example, a weather station may have multiple wind sensors at different heights from the ground, so measurement name alone is not enough to identify the measurement (no match in IPSO SO)

So, IPSO SOs have a pretty good match, but not complete. At first we hoped that we could use SO resource 'Application Type' for #2, but as @akeranen suggested, it might not be the optimal solution. How about if IPSO SO contains an Objlnk type of resource that points to a sensor metadata object?

[dirtyha]

I noticed this issue (https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/429). Based on that issue and comment by @hannestschofenig , I could add optional re-usable resources into my IPSO SO and still conform to LwM2M standard. Is that so? That would solve the missing Application Type resource in some SOs.

[dirtyha]

A call with @akeranen revealed that adding re-usable resource (Application Type) implicitly to IPSO object is not possible. So, my proposal is to explicitly add it to IPSO objects by creating a new object version.

The following IPSO objects are missing Application Type (5750) reusable resource, possibly accidentally.

ID Name

3301 Illuminance 3302 Presence 3303 Temperature 3304 Humidity 3305 Power Measurement 3310 Load Control 3313 Accelerometer 3314 Magnetometer 3315 Barometer

[akeranen]

Seems that the application type resource descriptions should also be aligned across objects. Now we have:

10254.xml: The application type of the sensor or actuator as a string, for instance, “Air Pressure”. 10258.xml: The application type of the sensor or actuator as a string, for instance, “Air Pressure”. 10311.xml: The application type of the sensor or actuator as a string, for instance "Air Pressure". 3200.xml: The application type of the sensor or actuator as a string, for instance, "Air Pressure" 3201.xml: The application type of the output as a string, for instance, "LED" 3202.xml: The application type of the sensor or actuator as a string, for instance, "Air Pressure" 3203.xml: If present, the application type of the actuator as a string, for instance, "Valve" 3300.xml: If present, the application type of the sensor as a string, for instance, "CO2" 3311.xml: The application type of the sensor or actuator as a string, for instance, "Air Pressure" 3312.xml: The application type of the sensor or actuator as a string, for instance, "Air Pressure" 3316.xml: The application type of the sensor or actuator as a string depending on the use case 3317.xml: The application type of the sensor or actuator as a string depending on the use case 3318.xml: The application type of the sensor or actuator as a string depending on the use case 3319.xml: The application type of the sensor or actuator as a string depending on the use case 3320.xml: The application type of the sensor or actuator as a string depending on the use case 3321.xml: The application type of the sensor or actuator as a string depending on the use case 3322.xml: The application type of the sensor or actuator as a string depending on the use case 3323.xml: The application type of the sensor or actuator as a string depending on the use case 3324.xml: The application type of the sensor or actuator as a string depending on the use case 3325.xml: The application type of the sensor or actuator as a string depending on the use case 3326.xml: The application type of the sensor or actuator as a string depending on the use case 3327.xml: The application type of the sensor or actuator as a string depending on the use case 3328.xml: The application type of the sensor or actuator as a string depending on the use case 3329.xml: The application type of the sensor or actuator as a string depending on the use case 3330.xml: The application type of the sensor or actuator as a string depending on the use case 3331.xml: The application type of the sensor or actuator as a string depending on the use case. 3332.xml: The application type of the sensor or actuator as a string depending on the use case. 3333.xml: The application type of the sensor or actuator as a string depending on the use case. 3334.xml: The application type of the sensor or actuator as a string depending on the use case. 3335.xml: The application type of the sensor or actuator as a string depending on the use case. 3336.xml: The application type of the sensor or actuator as a string depending on the use case. 3337.xml: The application type of the sensor or actuator as a string depending on the use case. 3338.xml: The application type of the sensor or actuator as a string depending on the use case. 3339.xml: The application type of the sensor or actuator as a string depending on the use case. 3340.xml: The application type of the sensor or actuator as a string depending on the use case. 3341.xml: The application type of the sensor or actuator as a string depending on the use case. 3342.xml: The application type of the sensor or actuator as a string depending on the use case. 3343.xml: The application type of the sensor or actuator as a string depending on the use case 3344.xml: The application type of the sensor or actuator as a string depending on the use case. 3345.xml: The application type of the sensor or actuator as a string depending on the use case. 3346.xml: The application type of the sensor or actuator as a string depending on the use case 3347.xml: The application type of the sensor or actuator as a string depending on the use case. 3348.xml: The application type of the sensor or actuator as a string depending on the use case. 3349.xml: The application type of the sensor or actuator as a string depending on the use case. 3350.xml: The application type of the sensor or actuator as a string depending on the use case. Common.xml: The application type of the sensor or actuator as a string, for instance "Air Pressure"

Probably using the most common "The application type of the sensor or actuator as a string depending on the use case." across all objects is the best option.

[seanmcilroy29]

IPSO smart sensor objects update plan by Vaisala

• ok = resource now exists in object
• + = resource to be added into an object as an optional resource
• N/A = resource not applicable for object

IPSO_smart_sensor_object_update_proposal.txt

[seanmcilroy29]

Resource update applied in PR https://github.com/OpenMobileAlliance/lwm2m-registry/pull/403

[mkgillmore]

Closed due to issue 181