As I continue to work with various IoT vendors to see how they could be used with the Oracle IoT cloud service, I came across one of these nice little Bosch XDK kits.
This is a demo kit to show off the many Bosch sensors available and give people an environment for prototyping. Here are some of the built-in sensors:
The device has built-in wifi and Bluetooth LE.
My goal was to get this to periodically send sensor data into the IoT cloud service and make it easy for others to do the same.
Bosch XDK Workbench Environment
Bosch has a development environment as an extension to Eclipse. This can be downloaded from their website. Beware, this is a very large download, so it will take some time to get things going.
Once running, there are many good samples to get started. The programming is done in C. The device is running a 32-bit microcontroller ARM Cortex M3. Plugging the XDK into a USB port allows you to flash the device and monitor the console log for debugging purposes.
The code I created was pretty simple:
- Read config info off SD card
- Setup Wifi connections
- Periodically get all the sensor data
- Build a JSON payload
- Send to the XDK bridge
I wanted to make it easy to get other devices running, so I put all the configuration data on the SD card. Ideally, you can flash a new XDK, update the SD card and be done. Changes to the config won’t require reflashing. This makes it easier if the device is moved into a new Wifi area or needs to send to a new IoT server. Here is a sample config:
config.txt – located at the root directory of the SD card.
description=John’s XDK Test Device
The parameters are pretty obvious.
The code is basically a cobbleing together of various samples. It can all be found here:
Note: there are a few parts.
- The XDK Workbench code. “StreamSensorDataOverREST”
This needs to be flashed onto the XDK device.
This needs to be updated, placed on an sdcard and put into the XDK device.
This is a simple bridge service which takes data from the XDK and sends it into the Oracle IoT Cloud service.
Configuration and Run
As I mentioned before, the config.txt file must be updated, put on an SD card and put into the XDK device. Once the device is powered on, it will connect to the wifi network (orange light turns solid) and then starts sending data (yellow light flashing).
In my sample config, data is sent every 10 seconds. This frequency can be modified as the device is running by pressing one of the two buttons. Press the button with “one dot” to increase the frequency and press the button with “two dots” to reduce the frequency.
Once running, the data will be sent in a basic JSON format:
name: ‘John\’s XDK’,
description: ‘John\’s XDK Test Device’,
location: ‘Sydney, Australia’,
Oracle IoT Cloud Setup
To setup the XDK device in IoT, I run a simple command to create the device:
curl -X POST -u iot:mypass -H ‘Content-Type: application/json’ -d ‘@deviceXDK.json’ https://iotcloud:10443/iot/api/v2/deviceModels/
where deviceXDK.json contains the format expected for each message. This command and deviceXDK.json file can be found on the github repository.
To facilitate the transfer of data, I wrote a simple XDK bridge in NodeJS. This leverages the Oracle IoT JSClient code to communicate with Oracle IoT. It also handles security and the automatic registration of new devices. This code is located in the github repository and offers up a simple rest service:
app.post(‘/bosch/xdk/senddata’, function (req, res)
With this nodeJS server running, the Oracle IoT cloud service is ready to receive data:
Another successful IoT device added!!!!
There was one issue I found and was unable to resolve. The Bosch libraries to send data to a server does not allow for modifying the header information of the payload. So, the “host” value is always an IP address and not the hostname given in the url (e.g. accs.oracle.com). This prevents services behind a virtual server address from working. So, until this is changed, you MUST have the bridge server running on a real IP address without a firewall or http server in front.
This is being addressed and discussed on the Bosch XDK community forum:
This device is very nice. It would be good to have GPS, but the rest of the sensors are wonderful. The coding was simple and the samples were good.
As I understand it, Bosch did not design this device to really be used in the field. It could be, if the number needed was in the 10-20 range. But Bosch wants people to use this device to get a better understanding of their sensor capability. Then, Bosch can create custom devices in large quantities to fulfill a given need.