Original URL: https://www.theregister.com/2011/11/27/the_invasive_internet_of_things/

Keep the utopians out of my fridge

Twine, the “Internet of things”, and the ghost of Stalin

By Richard Chirgwin

Posted in On-Prem, 27th November 2011 23:30 GMT

Rant Inside of every free-wheeling tech entrepreneur, there’s a Stalinist trying to get out.

Supermechanical, for example, lauded inventor of the photo-printing night-stand table, is now getting utopians and gadget-heads excited over a cloud-connected home automation gadget called Twine.

Internet of things device fits into palm of hand

Well, I would like some genuinely useful home automation – skip trivia like automatic lights, if you’re too lazy to flick a switch by hand, grab another dozen burgers and let evolution do it’s work. But if it can only be had by passing my data to people I don’t know, I’ll do without or find some other way.

If you haven’t been asleep in a cave the last few years, you will know that we’re on the path to the “Internet of things”, in which today's passive and familiar appliance – say, your refrigerator – is going to become part of the Panopticon.

It’s what happens when the planets align, and the visionaries and vendors and VCs agree on the definition of A Good Thing. The vendors’ and the VCs’ interests are easy to identify: “we’ll make a bucket of money”. The visionaries are just suckers who can only prophecy downsides in retrospect.

That bucket of money ultimately will come from you and I, which makes it necessary that the “Internet of things” be justified to us.

The common justification is “efficiency” – we will invite the Internet into things that don’t actually need it, yielding up vast amounts of data about our lives and behaviours in our homes, in exchange for energy efficiency.

If that doesn’t sound a just little Stalinist, you’re probably too young.

This relentless centralism is why I’m not quite able to join with the rest of the tech press and laud Supermechanical’s new “Twine” device as some kind of home automation saviour. And that’s a pity, because it looks so much like something I, personally, could use.

Twine is an equal mix of the trivial, the cute, the innovative, and the invasive.

The trivial is a WiFi chip that connects to a home network: a piece of cake, even if running it on AAA batteries might have been a challenge.

Its “cute” factor comes from its packaging. The first iMac taught the world that looks matter, even if your product is only 2½” square.

Innovation comes in two forms: the Arduino-like ability for users to breadboard their own sensor connections with no soldering; and a natural language API, so “WHEN moisture sensor gets wet THEN tweet ‘The basement is flooding!’” is a valid programming statement. Alerts can currently be sent via e-mail, SMS, Twitter, or a configurable HTTP request.

What’s not to like? This bit: “Twine is a wireless module tightly integrated with a cloud-based service”.

Supermechanical just couldn’t resist the urge to centralize.

Let’s look at two scenarios in a real-world application, and count the dependencies. I’m going to select something that’s exercising my mind at the moment: how to get status reports from a solar power setup when I’m 100 Km distant.

In the first scenario, something like the Twine would collect the data, respond to a trigger (WHEN voltage falls below 49V THEN send SMS “Get Peter to start the generator!”), and send an SMS through a postpaid 3G dongle using its onboard SMS app.

The only upstream dependency is the 3G network.

Now, let’s add the the cloud: “WHEN voltage falls below 49V THEN tweet “Get Peter to start the generator!”

The dependencies have multiplied: my critical message can’t work without the cloud service (and every Internet dependency from here to America), I need to be connected to the Internet to receive the message, and heaven help me if Twitter has decided it needs a cup of tea, a Bex and a nice lie down.

I can see why the cloud infrastructure is there – it’s hosting the programming environment – but I don’t see why the compiled instructions couldn’t be returned to Twine so that it can function on its own. And I don’t see why it’s necessary, compelling and A Good Thing that in order to get messages out of home automation, the user must hand data upwards to the cloud.

Since I don’t want to be drawn into someone’s no-choice embrace, I guess I have to go back to doing things the hard way. How do I get data out of an Outback Power Systems Mate controller and into an Arduino again? ®