New structure for the sensors field

Until now the sensors field in the Space API specification only specifies a few sensor types. As hackerspaces are using many more sensor types it’s time to define some more.

Also does the sensors field have a bad structure at the moment. Some hackerspaces use arrays while others use objects for multiple instances of a sensor type. Some encode the sensor location or name into the sensor key. This led to a big mess and it’s necessary to improve this.

There are two proposals to do so.

  • Making the sensors field an object with as many subelements as there are sensor types. Every subelement then contains an array of objects which are the actual sensor instances.
  • The second proposes to make the sensors field an array of objects which represent the sensor instances with the sensor type being an attribute.

Sensor type as a key

{
    "sensors" : {
        "temperature": [
            {
                "value" : 3,
                "unit" : "°C",
                "location" : "Outside",
                "name" : "Roof"
            },
            {
                "value" : 3,
                "unit" : "°C",
                "location" : "Room 1",
                "name" : "Corner 1"
            },
            {
                "value" : 3,
                "unit" : "°C",
                "location" : "Room 1",
                "name" : "Corner 2"
            }
        ],
        "barometer" : [
            {
                "value" : 32,
                "unit" : "Pa",
                "location" : "Outside",
                "name" : ""
            }
        ],
        "people" : [
            {
                "value" : 3,
                "unit" : "ppl",
                "location" : "Room 1",
                "name" : "Table 1"
            },
            {
                "value" : 2,
                "unit" : "ppl",
                "location" : "Room 1",
                "name" : "Table 2"
            },
            {
                "value" : 5,
                "unit" : "ppl",
                "location" : "Room 1",
                "name" : "Total"
            }
        ],
        "ext_spiff-diff" : [ /* unofficial extension */
            {
                "value" : 32,
                "unit" : "spdf",
                "location" : "locker1",
                "name" : "asdf"
            }
        ]
        
    }
}

Pro:

  • Client applications can easily calculate the amount of sensor instances of a certain type.
  • The backend code is more consistent when creating the filter keys hierarchically.
  • It’s quite obvious what sensor types are implementd. A sensor type is defined in one place.

Con:

  • Sensor types which can have only one instance must be a one-element array.

Sensor type as an attribute

{
    "sensors" : [  
        {
            "type" : "temperature",
            "value" : 3,
            "unit" : "°C",
            "location" : "Outside",
            "name" : "Roof"
        },
        {
            "type" : "temperature",
            "value" : 3,
            "unit" : "°C",
            "location" : "Room 1",
            "name" : "Corner 1"
        },
        {
            "type" : "temperature",
            "value" : 3,
            "unit" : "°C",
            "location" : "Room 1",
            "name" : "Corner 2"
        },
        {
            "type" : "barometer",
            "value" : 32,
            "unit" : "Pa",
            "location" : "Outside",
            "name" : ""
        },
        {
            "type" : "people",
            "value" : 3,
            "unit" : "ppl",
            "location" : "Room 1",
            "name" : "Table 1"
        },
        {
            "type" : "people",
            "value" : 2,
            "unit" : "ppl",
            "location" : "Room 1",
            "name" : "Table 2"
        },
        {
            "type" : "people",
            "value" : 5,
            "unit" : "ppl",
            "location" : "Room 1",
            "name" : "Total"
        },
        {
            "type" : "ext_spiff-diff", /* unofficial extension */
            "value" : 32,
            "unit" : "spdf",
            "location" : "locker1",
            "name" : "asdf"
        }
    ]
}

Pro:

  • Sensor types which can have only one instance don’t need to be a one-element array.

Con:

  • Client applications must iterate over the whole sensors array to get the sensor instances of a specific type.
  • If the array is big and if the sensor types are not one after the other but mixed (e.g. one instance of temperature then one of barometer and finally again a temperature) then it’s less obvious what sensor types are used.

Personally I tend to use the first variant. It doesn’t hurt really to use one-element arrays for sensor types that can have one instance at most.

What are your suggestions?

3 Comments

  1. I would second the first option, it gives a clear structure and also seems more intuitive to me for integration into other apps even with growing numbers of different sensor classes, for example geiger counters, which I’m working on right now to feed uSv/h data of the Hackerspace’s location into the big soup with a Raspberry Pi and a cheap add-on board to connect the geiger tube.

  2. rohieb

    Yes, first variant, as you already said. One-element arrays are just a corner case.

  3. slopjong

    The new structure got implemented right after this discussion. Check the reference for details. If there are questions, ask.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>