This is the 3rd post of the series “IoT Devices on Sofia2. Integration and Management”:
This post will present the needed steps to interconnect the IoT device with the Sofia2 platform. The explanation will be split into two parts, one corresponding to each end of the communication.
Starting on the platform side, we will proceed with the ThinKP definition on Sofia2. The ThinKP menu is located under the 3rd icon of the command menu on the left-hand side of the screen. Then select My ThinKPs.
Then on the next screen you will find the New ThinKP button.
The ThinKP creation window will show up. To define a ThinKP you will need to provide an identifier and a brief description about the ThinKP.
It will be also required to pair at least one Ontology associated to the current ThinKP. For this scenario we will only use one Ontology, demoDispositivos_RTFrame. Please find more info about this Ontology on Part II. Just select the Ontology and click on the creation button. Afterwards, you will see your ThinKP description as depicted in the image.
Under the My Tokens tab you will find the associated token for the ThinKP. This token will be used on the device side when establishing the connection. On the far right end you may see the last connection time for this ThinKP.
After ThinKP definition, the platform side will be ready. For this scenario we will use a ThinKP instance on the Gateway device (the Android smartphone). Thanks to this instance, the Android device will be able to insert, read and, in the end, make use of Sofia2 capabilities.
Next image shows a code snippet from the mobile application running on the Android device. You may see how the token appears,
For this demo, we will send sensor data to the platform using REST protocol. Using REST gives a lot of flexibility to data insertion, just editing a POST operation. Next image shows a piece of code containing the implementation of the JOIN message to open a session on Sofia2. This method uses the parameters associated to the ThinKP and the Ontology.
This will create the connector with Sofia2. After the JOIN message the smartphone may start inserting data into the Ontology.
Regarding data collection, on this scenario the smartphone also initiates the connection with the SensorTag using BLE (Bluetooth Low Energy). The characteristic associated to the available services on the SensorTag can be found on Texas Instruments website: http://processors.wiki.ti.com/index.php/CC2650_SensorTag_User’s_Guide
Data collection from SensorTag could be dissected into 3 main steps, defined on the diagram.
During the SCAN stage, the BLE API from Android. For this scenario we have developed an Android application working from KitKat level up to the current Android version. onLeScan is called by the underlying framework anytime a new MAC address is detected nearby. For this particular application, there is a filter looking for the precise MAC address of our SensorTag. When the desired MAC address is detected, the application launches a new Runnable thread to actually connect to the newly found device.
startLeScan/stopLeScan are used to start/stop the scanning action. These methods receive and instance to the callback to the onLeScan method presented earlier.
Upon connection to the SensorTag, the ENABLE stage starts. During this stage it is necessary to activate the desired sensors. The wiki on SensorTag TI’s website provides the accurate value to be introduced to the corresponding characteristics.
The GATT server on SensorTag provides a service for each particular sensor. These services contain 3 main characteristics:
- Configuration: This is the one for sensor enablement/disablement
- Data: This characteristic stores the measured value from the sensor.
- Period: This field contains the period between consecutive sensor readings.
In order to receive push notifications from the SensorTag whenever there is a change in the data characteristic, you will need to activate notifications for this characteristic (again more info on this can be found on SensorTag wiki).
These are the sensors we will be using for this demo:
- IR Temperature Sensor: Ambient Temperature + Remote Object Temperature (IR)
- 9-axis Movement Sensor: Just using Accelerometer + Gyroscope.
Next image depicts a sample of the necessary information to deal with the IR temperature sensor. You may find this same information for the rest of the sensors on TI wiki page. Following the picture’s instruction, in ENABLE stage you will need to write ‘0x01’ to the corresponding configuration characteristic. In FETCH stage, you may then read the data characteristic directly or you may also activate periodic notifications (the latter was the approached we used on the demo set).
Once you have the data on the smarpthone, then it is just matter of encapsulating these data according to the appropriate Ontology. In this particular example we opted to build a custom String you can analyze in the following picture. You may see we have actually extended our dataset by adding some info from the smartphone:
- IMEI code in order to uniquely identify the terminal
- GPS coordinates in order to geo-tag the measures.