Christoph and I exchange gadgets occasionally, and he sent me a SensorTag, which is a small little red thing with contains a bunch of sensors on it: a temperature sensor, a 9-axis motion sensor, a humidity sensor, an altimeter and pressure sensor, and an ambient light sensor. In addition to two buttons, the SensorTag also has a reed switch on it which I can activate with a magnet, and it has a buzzer (which I thought didn’t work until I held the device to my ear). Apparently it also has a serial flash on it for storage and OTA upgrades, and a battery. The teardown suggests it also has a microphone. The package is enclosed in red rubber which feels nice, and which can easily be removed to disclose a small, rectangular, plastic case with a transparent lid.
I spent an hour looking for information on the SensorTag, reading some articles about it, and generally attempting to get a feel for what it’s supposed to do, but I’m having trouble finding real use-cases for it. As a consumer for this “Thing” there is too much I don’t understand on the Texas Instruments SensorTag page. For example:
- The SimpleLink™ SensorTag allows quick and easy prototyping of IoT devices. How? What does this mean?
- IoT made easy, with a secure connection to the cloud. Maybe, but you need an app on a smart phone for that.
- The SensorTag comes in two variants. One of them is “coming soon”
- Low-power or battery-less operation. Which shall it be?
- Remove the barriers between software and hardware. How’s that? I need the hardware (SensorTag) and the software (an app).
- With the SensorTag app, you can build your own iOS app in minutes. It allows quick and easy prototyping of simple sensor applications.. There is absolutely no indication whatsoever that the iOS app “lets me build my own iOS app in munutes” or that it lets me do “easy prototyping of simple sensor applications”. Maybe what they mean is server-side, but that’s certainly not what the blurb says. Or do they mean a bit of drag and drop as shown in this video?
The getting started tab of the SensorTag page says I should download the app, remove the battery tab (so it does have a battery, eh?), and I can then “explore” my SensorTag. Yes, that works, as the following screenshot depicts, after I figure out that I have to poke one of the rubber buttons on the tag to allow it to be discovered.
I then find out by experimentation that I have to switch on the sourcing switch at the top of the app; this enables the app to push data to “the cloud”, and I can click on a link which takes me there:
The Web page updates the device data instantly. I forget where exactly, but I stumbled over the fact that the sensors’ data is also published to an IBM MQTT broker which I can subscribe to with any MQTT client, replacing the xxx in the subscription topic by the device ID which is displayed on the above IBM Internet of Things Foundation page. The MQTT topics are documented here.
mosquitto_sub -h quickstart.messaging.internetofthings.ibmcloud.com \
-v -i a:quickstart:jp01 -t 'iot-2/type/+/id/xxxxxxxxxxxx/evt/+/fmt/+'
iot-2/type/"multitool-app"/id/6e97b598fe86/evt/status/fmt/json {
"d":{
"key1":"0",
"key2":"0",
"AmbTemp":"21.65625",
"IRTemp":"17.625",
"humidity":"48.92485",
"baroPres":"999.24",
"baroHeight":"-0.08738943",
"accX":"0.004211426",
"accY":"0.00402832",
"accZ":"-0.2452393",
"gyroX":"-1.237335",
"gyroY":"1.867676",
"gyroZ":"-0.6459045",
"magX":"-1.798828",
"magY":"66.55664",
"magZ":"-10.04346",
"optical":"151.56"
}
}I did not format this payload; the formatted JSON string you see is what was transmitted, and it makes me shudder slightly because it makes scripting difficult. The monitoring topic doesn’t do that, but I do wonder who thought up the double quotes within the topic name:
iot-2/type/"multitool-app"/id/6e97b598fe86/mon { "Action": "Connect", "Time": "2015-11-24T07:16:46.294Z", "ClientAddr": "192.168.212.64", "ClientID": "d:quickstart:\"multitool-app\":xxxxxxxxxxxx", "Port": 1883, "SecureConnection": false, "Protocol": "mqtt-tcp", "ConnectTime": "2015-11-24T07:16:46.293Z" }Christoph wrote a nice little program which subscribes to that data stream and prints this out:
$ DEVICE=xxxxxxxxxxxx ./ti_from_ibm.py
magZ magY gyroY IRTemp baroPres baroHeigh magX accY accX accZ gyroZ gyroX humidity AmbTemp optical
18.43799 96.83691 0.1634216 20.5 1012.35 -0.603385 56.06348 0.0057983 0.0003662 -0.244995 0.1089478 -0.910491 53.73907 24.5625 0.48
18.43799 96.83691 0.1634216 20.375 1012.31 -0.258004 56.06348 0.0057983 0.0003662 -0.244995 0.1089478 -0.910491 53.73907 24.5625 0.48
18.43799 96.83691 0.1634216 20.40625 1012.28 -0 56.06348 0.0057983 0.0003662 -0.244995 0.1089478 -0.910491 53.73907 24.5625 0.48
18.43799 96.83691 0.1634216 20.34375 1012.31 -0.258004 56.06348 0.0057983 0.0003662 -0.244995 0.1089478 -0.910491 53.73907 24.5625 0.4
18.43799 96.83691 0.1634216 20.40625 1012.31 -0.258004 56.06348 0.0057983 0.0003662 -0.244995 0.1089478 -0.910491 53.73907 24.5625 0.48
18.43799 96.83691 0.1634216 20.46875 1012.26 0.1727007 56.06348 0.0057983 0.0003662 -0.244995 0.1089478 -0.910491 53.617 24.5625 0.48
19.3374 95.9375 0.2957153 20.59375 1012.27 0.0863499 55.16406 0.0075683 -0.001159 -0.244689 0.0077819 -0.8638 53.617 24.5625 0.48The program itself is quite simple:
#!/usr/bin/env python
import paho.mqtt.client as paho
import json
from os import getenv
device = getenv('DEVICE')
def on_connect(mosq, userdata, rc):
mqttc.subscribe('iot-2/type/+/id/%s/evt/+/fmt/+' % device, 0)
print "%9.9s %9.9s %9.9s %9.9s %9.9s %9.9s %9.9s %9.9s %9.9s %9.9s %9.9s %9.9s %9.9s %9.9s %9.9s" % ( "magZ", "magY", "gyroY", "IRTemp", "baroPres", "baroHeight", "magX", "accY", "accX", "accZ", "gyroZ", "gyroX", "humidity", "AmbTemp", "optical")
def on_message(mosq, userdata, msg):
data = json.loads(str(msg.payload))
d = data["d"]
print "%9.9s %9.9s %9.9s %9.9s %9.9s %9.9s %9.9s %9.9s %9.9s %9.9s %9.9s %9.9s %9.9s %9.9s %9.9s" % ( d["magZ"], d["magY"], d["gyroY"], d["IRTemp"], d["baroPres"], d["baroHeight"], d["magX"], d["accY"], d["accX"], d["accZ"], d["gyroZ"], d["gyroX"], d["humidity"], d["AmbTemp"], d["optical"])
mqttc = paho.Client(client_id="a:quickstart:%s" % device, clean_session=True, userdata=None, protocol=3)
mqttc.on_connect = on_connect
mqttc.on_message = on_message
mqttc.connect("quickstart.messaging.internetofthings.ibmcloud.com", 1883, 60)
mqttc.loop_forever()The documentation of this device is spread all over the place and the fact that there have been two versions of it doesn’t help at all. Some documentation is an a TI Wiki. The CC2650 SensorTag User’s Guide for example, warns about a pre-production FW image, but the app through which upgrades are apparently possible doesn’t show newer firmware versions being available.
Another link from the SensorTag page takes me here where I see ‘mqtt’ linked to. There I see I need a “free Temboo account”, and I have to “register with Twilio” where I get a phone number, and then I require a “Pagerduty account” and an API key, and, then I need a “Zendesk account”, … I very quickly closed that Web browser tab and shuddered. Gals & boys, if that’s what we need for the “Internet of Things”, we’re going to have 50 billion squared problems by the year 2020!
There’s also a quick guide to making a mobile app for the SensorTag which I haven’t tried, because I don’t see the point in creating a mobile app which displays the sensor data if I have to run the TI SensorTag app anyway.
Be that as it may I went in search of how to talk to the device directly, or rather, how to have the device talk to me, and found this.
After inserting a BLE-capable Bluetooth dongle into a laptop, I could actually scan for LE devices, and I learned that there may be one connection to a BLE device only, so I close the SensorTag app before attempting the scan:
$ hcitool -i hci1 lescan
LE Scan ...
B0:B4:48:BD:B8:05 CC2650 SensorTagand the rest was easy in as much as a chap called Ian Harvey has done the hard work.
jpmens/cc2650/b0b448bdb805 {"lux": 0.24, "ambient_temp": 25.14, "humidity": 48.42047119140625, "target_temp": 21.03125, "tst": 1448289252, "millibars": 1002.97}
jpmens/cc2650/b0b448bdb805/lux 0.24
jpmens/cc2650/b0b448bdb805/ambient_temp 25.14
jpmens/cc2650/b0b448bdb805/humidity 48.4204711914
jpmens/cc2650/b0b448bdb805/target_temp 21.03125
jpmens/cc2650/b0b448bdb805/tst 1448289252
jpmens/cc2650/b0b448bdb805/millibars 1002.97Minutes later, I had the device reporting via MQTT using this code and this doesn’t require a cloud service – I’d point this at my own MQTT broker of course.
After playing with this for a bit I realized that the Python implementation doesn’t appear to cater for all the SensorTag’s capabilities (i.e. sensors). I then found node-sensortag which does, and cobbled up something which publishes an MQTT payload whenever one of the sensors on the tag notifies NodeJS. This module also supports the buttons and the reed switch, and it auto-discovers the SensorTag proper, so I don’t have to configure it with the device identifier. The result, using Freeboard with the MQTT plugin gave me this:
As a BLE device, the SensorTag literally “goes away” when it’s too distant from whatever is receiving the data, be it the iOS app or the BT dongle in my laptop. I assume that the makers wanted the SensorTag to be carried in one pocket, with the cloud-connected smart phone in another. I just don’t know. The SensorTag specifications state that it can be toggled between Bluetooth Smart, 6LoWPAN and ZigBee and, as mentioned above, there is to be a WiFi version some time.
The SensorTag is small enough to be placed almost anywhere, and as it doesn’t need wiring, it would be nicely suited as an ambient light sensor to control, say, openHAB: an appropriate BLE dongle on an openHAB box in Bluetooth reach, and Bob’s your uncle. (BTW, the ambient light sensor is appears to be very good.) Christoph also suggests using it to determine whether your spouse drives more aggressively than you do, by monitoring the accelerometer. ;-)
If and when the WiFi version comes, and if it’s comparable in price to the BlueTooth version (USD 29.00), I could imagine getting two or three to use as temperature and luminescence sensors in the house.