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'
}
Posted Oct 10, 2013 15:59 UTC (Thu)
by jhhaller (guest, #56103)
[Link] (8 responses)
Given all that, basic thermostats aren't subject to software bugs, and I would prefer that my furnace turn on if the temperature is lower than about 60, even if the automation system failed, and to turn off the furnace if it got above 80.
Posted Oct 10, 2013 18:04 UTC (Thu)
by rmayr (subscriber, #16880)
[Link] (6 responses)
When talking about lights, which do not have reaction times in the range of hours, the story is different. Here it can really have an impact to turn them on or off (or dim) based on occupation etc. On the other hand, you don't need much forecasting for that.
To summarize my point, I fully agree that the Internet of Things concepts for smart homes are worth it. Only the standard examples around heating typically don't apply to those houses which will benefit most from frameworks like this (i.e. very modern houses with bus systems, sensing, etc.).
Posted Oct 11, 2013 0:19 UTC (Fri)
by giraffedata (guest, #1954)
[Link] (5 responses)
Posted Oct 11, 2013 0:54 UTC (Fri)
by dlang (guest, #313)
[Link]
Insulation and heat pumps don't change this basic fact.
Insulation changes the rate at which the inside equalizes temps with the outside, and therefor the amount of heating cooling needed to maintain the temp difference. Heat pumps are relatively efficient tools to maintain the temp difference (at least under most conditions), so they reduce the cost.
but by far the most efficient thing to do is to not maintain the temp difference when it's not needed.
Posted Oct 11, 2013 6:35 UTC (Fri)
by rmayr (subscriber, #16880)
[Link] (3 responses)
Combine that with the fact that heating pump systems have a (realistic, not placebo) reaction time of >2h between turning on the heating system and actually making a difference in room temperature and you'll see the big difference between "modern" houses and old 1-glass-pane-windows-with-gas-heating scenarios (in which an elaborate control of heating makes sense, but those houses will probably lack the infrastructure to do so).
However, all of this is a complete tangent to the original article, and I am sorry for even bringing it up. I just get bored by the same examples for smart houses that have been used for the last 15 years (yup, I've been to ubiquitous/pervasive computing conferences for a while) and that just don't make that much sense.
Posted Oct 13, 2013 19:42 UTC (Sun)
by jzbiciak (guest, #5246)
[Link] (2 responses)
If you had computer-controlled blinds, it might make sense to control those, either to maximize incoming sunlight in the winter, or minimize it in the summer, except in occupied rooms of course. This is an extension of the lighting theme, but applied to natural lighting which also doubles as a source of heat.
Posted Oct 14, 2013 12:23 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Posted Oct 14, 2013 13:06 UTC (Mon)
by jzbiciak (guest, #5246)
[Link]
But yes, pets do throw things off a bit.
Posted Oct 12, 2013 1:46 UTC (Sat)
by ncm (guest, #165)
[Link]
Posted Oct 10, 2013 20:14 UTC (Thu)
by smurf (subscriber, #17840)
[Link] (2 responses)
There doesn't seem to be any site out there comparing the two, so I guess I'll have to do it myself. *Sigh*. ;-)
Posted Oct 11, 2013 6:42 UTC (Fri)
by rmayr (subscriber, #16880)
[Link]
Posted Oct 14, 2013 16:35 UTC (Mon)
by Jannes (subscriber, #80396)
[Link]
I'm currently running a ZWave nightmare on MiCasaVerde/Vera box. Terrible and expensive hardware, terrible proprietary protocol, bad software.
I'll have a look at both too.
Thank you.
Posted Oct 13, 2013 19:40 UTC (Sun)
by jzbiciak (guest, #5246)
[Link] (4 responses)
I think the reason the phrase causes me to eyeroll so hard is that I hear it spoken with the wrong emphasis far too often. It should be emphasized "the Internet of Things", but I too often here "the Internet of things." The latter intonation is almost as if the speaker is saying "it's the Internet, of all things" as if the "of all things" was just an adjunct clause, similar to "it's the Internet, can you imagine?" In any case, this does look like an interesting project. I imagine 'magic' will be hampered by inconsistencies among the various Things being controlled, such as inconsistent reporting units or eccentric behavior. I guess we'll see.
Posted Oct 14, 2013 16:55 UTC (Mon)
by Baylink (guest, #755)
[Link] (3 responses)
Or vice versa?
(NASA fans will know why this isn't even amusing...)
Posted Oct 14, 2013 18:09 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Posted Oct 14, 2013 22:36 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (1 responses)
And let's have them use reasonable paper sizes, too, while we're at it.
If nation states were like software companies, the USA would be Microsoft.
Posted Oct 14, 2013 23:03 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Think IBM with EBCDIC.
Posted Oct 14, 2013 16:53 UTC (Mon)
by Baylink (guest, #755)
[Link] (1 responses)
Cause it's best practice these days to treat *no* attached network as "safe"; you have to put the security right in the attached end device.
And since, as we all know, *no* consumer product pays any attention to security whatsoever...
I'm wrong: it's not that it will never make it. It's that the designed in Total Lack Of Security will burn millions of people. Possibly literally.
Posted Oct 14, 2013 17:21 UTC (Mon)
by pizza (subscriber, #46)
[Link]
The Thing System
The Thing System
What is it about heat pumps and proper insulation that means you don't want the house to be colder when you're at work (or asleep, I suppose)? Are you saying it takes all day to change the temperature a few degrees?
modern house heating control
modern house heating control
modern house heating control
modern house heating control
modern house heating control
modern house heating control
Turing
The Thing System
The Thing System
The Thing System
Rolling eyeballs
Rolling eyeballs
Rolling eyeballs
Rolling eyeballs
Rolling eyeballs
The Thing System
The Thing System
