Keep the utopians out of my fridge
Twine, the “Internet of things”, and the ghost of Stalin
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.
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? ®
COMMENTS
"from you and I"
Nope, from takes the accusative: "from you and me".
It amazes me how many people get this wrong
It never ceases to amaze me how many people get "... and me" / "... and I" wrong.
Hint: The correct form is whichever you'd use if it was just you -- so pretend the other person.wasn't in the sentence. Would you write "from I" or "from me" ?
Kike, you say?
Grammar Nazi approves of your nazi error.
</joke>
Oi you, open the windows, there's a cloud in the room.
That broadband router also draws /some/ power. Plenty of non-techies actually do /not/ leave it on, which would unwittingly break their home automation. Assuming that server will draw more is peecee-centric to the point of wilful dishonesty. Even a (x86/ia32 based) soekris might draw less than a quarter of your 45W figure. And it'll route your traffic too. That is, of course, ignoring all those integrated "home router" devices (regardless of whether those sport DSL and/or GSM/3G/LTE interfaces) that run some cut-down form of linux where you already can add your own programs; no reason why you couldn't add a "home automation" interface and accompanying software. And with enough demand there'll be more devices that draw even less power and are even more flexible. There already exist other options, some specifically aimed at embedding while maintaining easy expansion with new interfaces and very, very low power draw. DSL needs quite a bit of processing power so going below its power needs for the little computation resources needed to read a few sensors and run a few small scripts isn't actually hard if you put your mind to it.
And be honest now. While you won't pay directly for the running costs of clouds, including the hardware with regular need for upgrading, associated dedicated cooling, the networking hardware to connect it all, whatnot, it's there, someone will have to pay, and that someone is ultimately you the customer that bought this thing that relies on the cloud to do something you could do for less power at home. All it does is shift the burden of ensuring reliability to somewhere where you definitely cannot do anything about it, and in doing that hide running costs.Those will pop up anyway in the form of some subscription. It effectively pulls the wool over your eyes, and reading your comment, you haven't even noticed. Impressive how you think that hiding the complexity, removing control from the end user (if the cloud don't work, what's he gonna do, reboot it?), is the equivalent of "reducing complexity". Heck no it isn't.
