The Thing System
"The Internet of Things" is a tech buzzword that provokes a lot of eye-rolling (right up there with "infotainment"), but the concept that it describes is still an important one: the pervasive connectivity of simple devices like sensors and switches. That connectivity makes it possible to automate the monitoring and control of physical systems like houses, offices, factories, and the like—from any computing device that has access to the internet. Getting to that blissful automated future remains a challenge, however; one that a new project called The Thing System is addressing with free software.
Sensors and devices with built-in connectivity are widespread and affordable: wireless weather stations, remote-controllable light bulbs and switches, web-accessible thermostats, and so on. The hurdle in deploying these products in a "smart home" scenario is that rarely do any two speak the same protocol—much less provide any APIs that would allow them to interact with each other. In many cases, they do not even use the same bits of spectrum for signaling; it is only in recent years that WiFi and Bluetooth Low Energy have become the norm, replacing proprietary protocols over RF.
Due to the difficulty of merging products from a host of different vendors, most whole-home automation packages rely on a central server process that monitors the state of all of the devices, queues and processes events, and provides a way to create macros or scripts (activating one device based on the status of another, for example). But it is often at the scripting interface that such projects begin to inflict pain on the user. MisterHouse and Linux MCE, for example, both support a wide variety of hardware, but they are often criticized for the difficulty of defining home automation "scenes" (which is home automation slang for a collection of lighting or device settings to be switched on as a group).
Control all the things
The complexity problem is an area where the developers of The Thing System believe
they can make significant strides. The project's mantra is that
" The example provided on the wiki is that an
environmental sensor would log carbon dioxide levels, and the master
process would run the ventilation system's fans until the levels
return to normal—without any user intervention whatsoever.
Clearly, such logic requires a detailed knowledge of the sensors and
devices that are available in the building as well as a semantic
understanding of what they can do—e.g., not just that there
is (for example) a Nest thermostat, but that the thermostat
activating the fan can lower the carbon dioxide level. The project
defines
a taxonomy
of ten device types: climate, lighting, switch, media, presence,
generic sensor, motive (that is, devices that implement some sort of
physical motion, like raising or lowering blinds), wearable,
indicator, and gateway.
Several of these categories are self-explanatory, although it is important to note that they may include
both monitoring and control. For instance, the climate category
includes weather sensors and thermostat controllers. Others are bit
more abstract: gateways are pseudo-devices that implement the Thing
System APIs but connect to a remote Internet service in the
background, and indicators are defined to be simple status
lights.
Still, the device categories are detailed where it is
appropriate; lighting devices can implement simple properties like
brightness percentage (from zero to 100%), less-common properties like RGB
color (a feature found in the Phillips Hue smart-bulb product line),
and even minutia like the number of milliseconds it takes to
transition from one state to another.
The Thing
System's master process is called the steward; it runs on Node.js and
is purported to be lightweight enough to function comfortably on a
small ARM system like the Raspberry Pi or BeagleBone Black. When it
starts up, the steward reads in a JavaScript module for each type of device
that is present in the building. There is a sizable list
of supported devices at present, although not all implement every
API. After loading in the necessary modules, the steward then
attempts to discover each device actually present on the network. It
does so via Simple
Service Discovery Protocol (SSDP), scanning for Bluetooth LE
devices, looking at attached USB devices, and scanning for devices
offering services over known TCP ports.
The steward's basic interface is a web-based client; it presents a grid of
buttons showing each discovered device, and for the well-supported
devices there is a usually a simple web control panel that the user can
bring up by clicking on the device's button. The project's
documentation does consistently refer to these interfaces as "simple
clients," however—meaning, for example, that they let the user switch
lamps on and off or adjust the light's color, but that they do
not implement magic.
Sadly, The Thing System's magic seems to still be a ways from
making its public debut. However, the project has developed several
interesting pieces of the puzzle along the way. First, there is the
Simple
Thing Protocol, which defines a WebSockets interface for the
steward to talk to programmable devices that (out of the box) offer only
a vendor-specific API. That makes supporting new hardware a
bit easier, and it establishes a generic interface with which it is
significantly easier to define scenes and events. In contrast,
scripting in other home automation systems like MisterHouse typically
requires knowledge of low-level configuration details for each device.
The project also defines the Thing
Sensor Report Protocol, which is a simpler, unidirectional
protocol for read-only sensors to send data to the steward. Here
again, most of the other well-known home-automation projects add
direct support for reading data for each sensor type. This is
difficult to support in the long run, particularly when one considers
that many simple sensors (say, thermometers or ambient light sensors)
change configuration every time the manufacturer releases an update.
Many home automation enthusiasts simply build such sensors themselves
from off-the-shelf electronic components or Arduino-like hardware.
Either way, if the scene descriptions and scripts assume details about the
sensors, the result is a hard-to-maintain configuration that
eventually falls into disuse.
Finally, The Thing System's scripting syntax is abstract
enough to be understandable to novices, without being too vague. The
key notion is activities,
which bind a status reading from one device to an action performed on
another device. For example, when a thermometer's
temperature property exceeds a pre-set value, the air
conditioning device is sent the on command. This temperature
event might be defined as:
It is not quite as simple as If This Then That, but by comparison to the competition,
it is straightforward.
The Thing System will probably be more interesting to revisit when
more advanced client applications (with lots of magic) become available, but the
overall design is good. Being web-based may be a turn-off to some,
but it is clearly the most future-proof way to offer support for
commercial hardware. Like it or not, most of the devices that
manufacturers release in the next few years will be accessible over
HTTP or (hopefully) HTTPS. Similarly, whether one loves or hates
JavaScript, the fact remains that is it far easier to find JavaScript
programmers who might contribute device drivers or clients to the
project than it is to find Perl programmers willing to do the same (as
MisterHouse requires).
Ultimately, what makes a home automation
system viable is its ease of use and its ability to support the
hardware that is actually available in stores today. The Thing System
looks to be making progress on both of those fronts.things should work like magic
", a notion that it defines
in a fairly specific way. Server-side logic should recognize patterns
and trigger events to solve a problem without requiring intervention
from the user.
The magic house
{ path : '/api/v1/event/create/0123456789abcdef'
, requestID : '1'
, name : 'gettin too hot'
, actor : 'climate/1'
, observe : 'comfortthreshold'
, parameter : 'temperature'
}
