
The unsexy IoT - wolframhempel
http://deepstream.io/blog/the-unsexy-iot/
======
notgood
IoT has many other problems... as pointed out by the popular twitter account
against it:
[https://twitter.com/internetofshit?lang=en](https://twitter.com/internetofshit?lang=en)

Some of the most amusing posts:

\- Nest not being able to function while there is service outage (e.g. can't
change temperature if server is down)
[https://twitter.com/Jenthulhu/status/688918036791840768](https://twitter.com/Jenthulhu/status/688918036791840768)

\- Tried to install an Spotify update for the car, ended disabling brakes.
[https://twitter.com/internetofshit/status/687693238103224320](https://twitter.com/internetofshit/status/687693238103224320)

\- Extortion by your own appliances (in-app-purchases + IoT, parody?):
[https://twitter.com/internetofshit/status/633278514284920833...](https://twitter.com/internetofshit/status/633278514284920833/photo/1)

\- Samsumg smart fridge exposes your Google credentials:
[https://twitter.com/internetofshit/status/636102318585475072...](https://twitter.com/internetofshit/status/636102318585475072/photo/1)

\- Can't change thermostat while updating:
[https://twitter.com/internetofshit/status/684831858463387648...](https://twitter.com/internetofshit/status/684831858463387648/photo/1)

\- Mall smart screens get blue screen of death:
[https://twitter.com/internetofshit/status/652403071859970048](https://twitter.com/internetofshit/status/652403071859970048)

~~~
StavrosK
"The internet has many other problems. Just a few days ago, Dropbox was down."

~~~
amelius
The solution is federated, P2P-like systems. But, unfortunately, there is no
money to be made with such solutions.

~~~
lgieron
No one's making money of BitTorrent, and yet it functions. I think that P2P
Dropbox or even youtube (without ads) is a pretty good idea.

~~~
amelius
You are completely right, those are very good ideas... except if you want to
make some money with your coding efforts.

The sad thing is, these days you only seem to be able to make money by holding
your customers hostage in your online systems (cloud) or ecosystems. I miss
the days where developers could make money selling just software.

------
vdnkh
I work for a company doing unsexy IoT and I've been dreaming about writing
this article for months now. We're a tiny company in New Jersey whose been
around in some form or another for the last 25 years, supplying remote
telemetry units (RTUs) to the industrial assets industry. Helium, oxygen,
nitrogen, whatever, on boats, trucks, and static sites. We also provide a
monitoring platform which is where I come in. We're a very uncool Apple -
vertically integrated, we design, build, manufacture, ship, and program all of
our RTUs in-house. IoT has been around for a long long time now - a lot of our
work comes from clients who can't maintain their old systems anymore.

The entire hype wave of IoT has more or less passed right over us. Nobody has
heard our name, save for the gas industry itself. But that industry is about
to (not literally) explode. Helium is an extremely lucrative industry and is
growing by the minute, and there's really nobody in this space but us. Remote
monitoring - IoT - has never been more critical to helium than it has now.
Without going into too much detail, knowing the pressure levels of your tank
24/7 can save you _a lot_ of money.

So where do I come in? Our platform is written in C#, with the front-end done
in Silverlight. I'm the dude getting us off it with some really hip JS work in
React. Before that I wrote a lot of microservices to handle various aspects of
our system. We were in a pretty bad state when I got there so I spent a lot of
time improving our development team. We didn't have PRs for a long time. For a
first job out of college, it's not bad. I get to do a lot of cool work, and on
my current project I've made every technical decision. But sometimes I wish
that we could attract better talent. Oh well, I'm (hopefully) leaving soon.

~~~
pjmlp
C#? Quite interesting.

Anything that you can share about it?

The language geek in me loves the use of C#, Java and similar safe stacks in
the IoT domain. :)

~~~
vdnkh
We don't program the boards in C#, just the services/Silverlight. The
communication methods between the boards is well abstracted - most of our
devices are reached via phone number. They have a SIM card with a carrier and
services essentially make a phone call to get the data. There's a lot to do
with communication protocols (i.e. bytes 0-8 are the configuration, 9-12
readings, etc.) but .NET has nice support for binary constructs. Some RTUs are
difficult to work with because they have conversations with our server, and
the lifetime of that call must be maintained while a million other things are
going on.

I wasn't here when the C# decision was made, but it's worked out really well
for us so far, Silverlight notwithstanding. Microservices work out really well
for us too because there's a lot of code written for specific RTUs which will
not (and should not) be shared, and having them explicitly separated keeps
everything tidy. Microservices communicate via a centralized publisher using
WCF, which uses MSMQ as the underlying transport method. Our #1 priority is to
never loose data so these technologies are a pretty safe bet. Like I mentioned
before, C# has good support for low-level stuff, but we don't do as much low-
level as you think. Our greatest challenge is handling several distinct
protocols with as much as the same code path as possible, and C# has really
great generics support which makes our lives easy. We don't require the
performance a C++ platform would bring.

To elaborate a bit more, our basic control flow goes something like:

Poll unit -> get data -> push data -> translate data -> assign data to
business objects -> operate on data -> present data

Each step usually involves a save to the database of critical info at that
stage.

~~~
pjmlp
Thanks for sharing.

I am currently aware of stuff using .NET CF, the old WinCE/Pocket PC stack or
just doing straight IO control from the PC side to "dumb" firmware that just
follows the given commands.

------
CaptSpify
> There is, however, enormous opportunity in crossing this chasm. The new IoT
> provides valuable data about its users, their habits, daily routines and
> preferences. The old IoT generates detailed information about the
> environment they interact in. Combining both with big data crunching
> technology will lead to unprecedented (and slightly scary) insights into
> individual user’s behavioral patterns as well as into the systems they
> compose.

And this is the gap that I don't want to be bridged. One of the reasons I love
my rpi's, is that I end up with ultimate control over my device and it's data.
At the end of the day, I decide what leaves my home, not $smart_company. If I
decide to submit that data to them, sure, they can run with it, but if they
require me to send it? I'm not even going to consider their product.

The data-crunching would also have to be done on my server, or I'm not
interested. Yes, I understand that my home-server is probably not powerful
enough to do the processing required, but I'll live without whatever feature
requires it.

~~~
StavrosK
I wrote a library to enable secure communications over insecure channels for
IoT, maybe it'll be useful to you:
[https://stringphone.readthedocs.org/en/latest/](https://stringphone.readthedocs.org/en/latest/)

~~~
CaptSpify
Interesting. I actually run a web-server, and I only control my stuff through
a web-API's, but that could also be useful....

Thanks

~~~
StavrosK
It doesn't really matter how you get messages to clients, the library just
makes sure that each participant is who they say they are. For example, a
rogue client could connect to your API and start sending commands, but with
this library, they'd have to know the key.

That said, it's definitely not useful everywhere, e.g. if you use TLS and the
application is only for stuff at home, you're probably fine.

------
NeutronBoy
My view with IoT is that is true value lies in the monitoring and data
collection aspect, and the analysis and prediction that it enables. Consumer
IoT doesn't value from this - consumer IoT is all about having Bluetooth and
smartphone apps for your foobar gadget.

Industrial IoT is where the value is - and it's been around for years.
Airlines and manufacturers like Boeing and Airbus have streams of data from
planes all over the world that allow them to pick trends, predict failures,
and take preemptive action. Agriculture use IoT to take real-time measurements
across their entire farms without spending hours driving, and get their
robotic tractors to go respond with water/fertilizer/pest control. Consumer
IoT isn't in a position to get these 'aggregate' benefits.

~~~
tmuir
I don't think there are any valid use cases for a widely distributed network
of any kind of personal item that make sense for consumers. Consumers don't
continuously manage large repetitive processes. They don't own items that
remain distributed, or are being redistributed on any regular basis. They
simply don't have the minimum threshold of Things that would benefit from the
Internet.

~~~
massysett
I don't know what qualifies as "large" but procuring food for my family is a
tedious and time-consuming task so for me at least it is large and repetitive.
I'm not sure how much that can be automated though.

The parent post mentioned tracking of airplanes. I wouldn't mind if a company
monitored my home heating system or refrigerator and notified me if they were
about to fail, as these failures can be expensive and a huge hassle if not
anticipated. Also consumers already benefit from alarm systems and cameras
they can monitor remotely. Heck, alarm systems have been centrally monitored
for decades, just over proprietary networks rather than the Internet.

~~~
pjc50
_I wouldn 't mind if a company monitored my home heating system or
refrigerator and notified me if they were about to fail, as these failures can
be expensive_

I'd be worried that the pre-emptive maintenance would be far more expensive.
You can already get heating system insurance, but I wouldn't trust the IoT
system to not over-order maintenance in order to maintain the company's
profits.

I saw an advert for HP's printer ink subscription service:
[http://www8.hp.com/uk/en/ads/instant-
ink/overview.html](http://www8.hp.com/uk/en/ads/instant-ink/overview.html) and
recoiled in horror. It's already the most expensive liquid most people will
buy, and you want to let the printer order it for you?

We're back to the door in Ubik that asked the user for a nickel before it
would open every time.

~~~
TeMPOraL
Indeed. I'd be totally for such a system, but as a _product_ , not a
_service_. Some things really should _not_ be managed by third parties - and
sadly, our economy is moving towards exactly that.

------
ktamura
I totally echo the OP (Disclaimer: I work at a big data analytics SaaS with
IoT customers called Treasure Data).

The "unsexy" IoT can be really unsexy. One customer wanted to get their data
out of SCADA (www.scada.com), and as it turns out, the only way to get
telemetry data out of their SCADA boxes was through emails as CSV attachments.

We ended up working with a third party dev shop to build a simple mail server
that parses the incoming CSVs and send them to our backend so that the vendor
could analyze the data coming from SCADA (which in turn came from heavy
industry devices) using SQL, Salesforce, etc.

I never thought that MIME attachments would be a critical part in a "big
data", "IoT" analytics pipeline...

~~~
timthorn
Beauty is in the eye of the beholder.

SMTP has its own advantages over HTTP in M2M/IoT space, both in terms of
simplicity and robustness. Sure, it's not as tightly coupled or feature rich
as a web API, but that might not be such a bad thing.

------
TeMPOraL
> _The new IoT provides valuable data about its users, their habits, daily
> routines and preferences._

Herein lies the problem. IoT should _not_ provide that data to the third
parties.

Also this:

> _We have become more comfortable with sharing personal data, e.g. when it
> comes to incorporating wearables or fitness trackers into our daily
> routine._

That those are the only reasonable examples one could come with only shows
that the "sexy" IoT is just a bunch of bullshit, overpriced toys that are only
meant to monetize people's data even more. This trend should be nipped in the
bud.

RE "unsexy" IoT, the article says:

> _It is now almost completely based on open protocols, rather than the
> proprietary ones of the past that were used to tie customers to a specific
> vendor._

I didn't know that. Somehow I was led to believe all those protocols are
closed and licensed, requiring you to join some "consortium" or "alliance",
paying a $shitton entry/licensing fee. I'll look into it. If there are
established open, working standards out there, then it's what I want to use in
my DIY IoT / home automation solutions.

EDIT:

> _(...) into your app._

That's _another_ problem. Our obsession with apps. This is something that
really needs to be culled too. One of the biggest factor that makes the "sexy
IoT" barely usable is that every device has its own app. Which means, every
company gets to develop a shit UI (each crappy in different way), and the time
it takes to switch between apps is several seconds. This should all be
standardized - I should have just _one_ app for all my IoT, and it definitely
must _not_ be made by one of the vendors (for the same reason nobody uses
software provided by e.g. printer vendors).

~~~
deelowe
> Herein lies the problem. IoT should not provide that data to the third
> parties.

To an extent, maybe. There's tremendous value in this space for all kinds of
things. The canonical example from Bill Joy's time is a fridge that predicts
your eating habits and keeps you stocked with the items you need for dinner
via automated delivery services.

> overpriced toys that are only meant to monetize people's data even more.
> This trend should be nipped in the bud.

"The internet is just a fad."

> I was led to believe all those protocols are closed and licensed, requiring
> you to join some "consortium" or "alliance", paying a $shitton
> entry/licensing fee.

There are plenty. This is one of the ones I'm familiar with:
[http://github.com/spark](http://github.com/spark)

> That's another problem. Our obsession with apps.

I think that even apps will be marginalized over time. People generally don't
want to interact directly with software/technology at all. They want it to
"just work" ala Google search. The best "IoT" devices will seamlessly augment
existing interfaces and technologies instead of inventing new ones.

~~~
TeMPOraL
> _The canonical example from Bill Joy 's time is a fridge that predicts your
> eating habits and keeps you stocked with the items you need for dinner via
> automated delivery services._

Yes, but in this canonical example the prediction could, and IMO should, be
entirely done client-side; only actual food orders would be done on-line.

> _There are plenty. This is one of the ones I 'm familiar with:
> [http://github.com/spark*](http://github.com/spark*)

Thanks! Though this still looks like the "sexy IoT" generation protocol; I was
wondering about the article's assertion that "unsexy IoT" is now based on open
protocols.

------
sdhsdh
We see a lot of both sides of this at BR
([http://buildingrobotics.com/](http://buildingrobotics.com/)) -- we are
actually BACnet experts, but also provide a really novel user experience on
top of this legacy protocol. One thing I'd add is that many of the "legacy"
industries have evolved in a way that's very different from what the Internet
crowd expects and so you can't always make the same assumptions.

Also, it might be "unsexy" but buildings consume 70-ish percent of US
electricity, a lot of which is controlled by BACnet and friends... and it
turns out there's a ton of low-hanging fruit that's only a (carefully crafted,
ASN.1-ish) UDP packet away..

------
skywhopper
> IPv6 has massively increased the number of available IPs, > allowing every
> sensor and relay within a system to be > addressable from the public
> internet

... which, while necessary for the IoT dream, is a very very very dangerous
thing.

Another downside of an upside is the idea of over-the-net updatable firmware
for all devices in your house. The unfortunate flipside of easily-updated-by-
the-vendor software is that the initial software will not be fully tested--"we
can fix any 'little' bugs later"\--and future releases will also not be
adequately tested. Not to mention the glaring security hole when your entire
house is run by devices and sensors that can be updated remotely.

It's going to get messy...

------
tmd
> IPv6 has massively increased the number of available IPs, allowing every
> sensor and relay within a system to be addressable from the public internet

That's a really scary idea from the security point of view and something that
bothers me about the IoT craze. Every consumer device visible on the Internet
should quickly and reliably self-update its software if a security issue is
found and remote updates are still a bit tricky to implement in embedded
devices (little storage, diverse hardware).

~~~
StavrosK
Firewalling them is probably a better idea. For most applications, connecting
to a central server/hub that's better secured is just fine.

------
nicolsc
Fully agree: most of the IoT solutions are "unsexy" stuff.

It's often painfully hard to explain that the kickstarter-sexy projects are
only the tip of the iceberg.

A BLE "smart" waffle machine would surely be fun, and good material for
@internetofshit. But while we're looking at useless/gadgets stuff, there are a
LOT of useful (or at least midly interesting) things happening in the IoT.

Unsexy doesn't mean old. And IoT doesn't mean "smart device". A dumb sensor
sending raw data can bring in a lot of valuable data.

Metering is still a thing, and i see new projects every week in various fields
: agriculture, public equipments, healthcare, safety, ... Lot of independent
things that don't need to be used by a user, and that you don't especially
know they are "connected"

------
pjmlp
Also regarding unsexy IoT, despite having been replaced by Android Java fork
in the mobiles space, J2ME and Embedded Java are being used by quite a few
companies in the unsexy IoT space.

