Something can be done about this – and we’ll discuss how.
The intense activity in the Internet-of-Things space can almost be viewed as a search for the Holy Grail.
In essence, IoT is all about taking automation to the next level - by having devices intelligently communicate among themselves to accomplish certain tasks with little to none human interaction. Examples of such automation range from a simple alarm clock that changes your wake up time when it is notified that your flight is delayed, to fully automated assembly lines spanning across different continents. A key feature in achieving this level of automation is indeed interoperability - interoperability that goes beyond the use of protocols and actually includes semantics.
So how do you make devices really understand each other in a very simple and lightweight way? And yes, ‘simple’ implies that the devices must be application agnostic, which is not really the case for many available offerings today.
Enter IPSO Alliance. The IPSO Alliance was established in 2008 and one of its main goals is interoperability: “Organize interoperability tests that will allow members and interested parties to show that products and services using IP for Smart Objects can work together and meet industry standards for communication”.
The inaugural embodiment of this goal is the IPSO Smart Object Starter Pack which describes 18 Smart Object types: a temperature sensor, a light controller, an accelerometer, a presence sensor, and other common sensor and actuator types. “This first object set is intended to be used as a starting place from which to build more objects and object sets, in order to address vertical application segments and new functional requirements for Smart Objects.”
In a previous blog post we covered the inner workings of IPSO Smart Objects, so here we will only deal with one simple question: - How does one talk to a device? Well, it is all about simplicity, therefore the Starter Pack builds upon the OMA LWM2M object model in order to provide a Resource Oriented Architecture (ROA) to access the different devices that have been registered. The addressing scheme follows this structure:
protocol :// host_name_here : port / ObjectID / InstanceId/ ResourceId
example:
coap :// localhost : 8080 / 3303/ 1 / 5700 where
- 3303 is the IPSO identifier of the object (in this case a thermometer),
- 1 is the instance of the object (there can be multiple instances of an object of type thermometer and we don’t want to explain what a thermometer is every time), and
- 5700 is the resource of the thermometer object that gives us access to what the thermometer measures (also known as “Sensor Value”)
This is a fairly simple and direct way to access and interact with a device, most importantly because one can utilize a RESTful vocabulary (GET, PUT, POST, DELETE) in order to state one’s intentions.
However, remembering all these numbers might be a bit tricky and it can make things harder if someone wants to address a larger set of devices. Would it be possible to re-use the IPSO Smart Object Model, maintain the same addressing scheme and semantics, but also allow for richer queries to be made to our system?
The answer is yes and the remaining paragraphs in this blog post are going to illustrate a simple technique which allows us to do just that. In fact, you can achieve this rather effortlessly using . In this article we are going to use Elasticsearch since it gives us right out of the bat a RESTFul approach to look up data and a simple Query Doman Specific Language (DSL) for writing queries. Moreover, Elasticsearch does not impose a particular schema on the data to be stored; it rather identifies the data structure from the data that is inserted into the system. In our case, this means that it will adapt to the structure defined by IPSO Smart Objects. The main drawback is that Elasticsearch does not support relationships since it is not a relationship database. However, continue reading as we will show how to overcome this limitation.
So let’s get started putting data into Elasticsearch. (Spoiler: The first three HTTP POST requests can be omitted if you don’t need to capture the full semantics provided by IPSO. So if you just want to start recording data, you can go ahead and skip to the fourth HTTP POST).
Step 1: Define the Sensor Value Item (also known as 5700)
POST /ipso/item/5700
{
"Name": "SensorValue",
"Operations": "R",
"MultipleInstances": "Single",
"Mandatory": "Mandatory",
"Type": "Float",
"Units": "Definedby“Units”resource.",
"Description": "LastorCurrentMeasuredValuefromtheSensor"
}
This command will define the “Sensor Value” item which is one of the resources of the Temperature Object. It will record that in the index ipso, it will generate the type item and identify it using the value 5700.
Step 2: Define the Thermometer object (also known as 3303)
POST /ipso/object/3303
{
"ObjectType": "MODefinition",
"Name": "Temperature",
"Description": "This IPSO object should be used with a temperature sensor to report a temperature measurement. It also provides resources for minimum/maximum measured values and the minimum/maximum range that can be measured by the temperature sensor. An example measurement unit is degrees Celsius (ucum:Cel).",
"ObjectID": "3303",
"ObjectURN": "urn:oma:lwm2m:ext:3303",
"MultipleInstances": "Multiple",
"Mandatory": "Optional",
"Resources": {
"Item": [
{
"id": "5700",
"Name": "Sensor Value"
}
]
}
}
This step defines the Thermometer IPSO object which is also stored in the same index (ipso), it becomes of type object and it is identified by the 3303 id.
Step 3: Define an instance of a thermometer (in this case 1)
POST /ipso/instance/1
{
"object": {
"id": 3303,
"name": "Temperature"
}
}
The third step allows us to register an instance of a Thermometer. The object information is inserted here in order to associate the instance with a particular object. Elasticsearch is not a relational database therefore it does not support relationships between objects. In order to overcome this limitation, the name of the Object is added again (redundancy) in order avoid additional queries.
Step 4: Submit a measurement made by the particular instance of the thermometer
POST /ipso/measurement
{
"instance": {
"id": 1
},
"object": {
“id": 3303,
"name": "Temperature"
},
"Item": {
"id": 5700,
"Name": "Sensor Value"
},
"timeStamp": "2015-08-23T10:29:37.000",
"value": 30.9
}
The fourth step allows us to record a measurement. In this HTTP POST we associate the measurement with the particular instance that made the measurement, the object that this instance complies with and also the resource (the item) of the object that we are measuring, in this case ‘Sensor Value’. Other items that we could measure are Min Value, or Max Value since the device was powered on but there are omitted here for the purposes of simplicity. The measurement type as conveyed here is somewhat an extension to what is defined in the Sensor Value type in IPSO since in our case we are also interested in the time when this information is recorded.
Now that are data is stored, what kind of question can we ask? There are several ways to answer this question and probably the best answer would involve reading up on the Query DSL that is. However, here are two very simple examples:
1) Querying using names, not numbers:
curl -XGET 'localhost:9200/ipso/measurement/_search?q=temperature'
2) Retrieving those thermometers that detected a temperature higher than 30:
curl -XPOST 'localhost:9200/ipso/measurement/_search' -d '{ "query" : { "filtered" : { "filter" : { "range" : { "value" : { "gt" : 30 } } },"query" : { "match" : { "name" : "Temperature" } } } } }'
What have we gained so far? We have learned how to describe Smart Objects. Moreover, we learned how to reuse the same description and addressing scheme in order to make rich user-friendly queries. What is still missing? The RESTful vocabulary we mentioned earlier can be used in order to send a command to a device (actuation), i.e. HTTP PUT the value 5 into a light dimmer; this would re-adjust its luminosity. A PUT request to Elasticsearch won’t have the same effect. However, one can use the query mechanism provided by Elasticsearch in order to recover the identities of all light dimmers in a building and then fallback to individual direct requests to send the command to each device.
