The unsexy IoT | Hacker News Reader

The unsexy IoT

deepstream.io

81 pointswolframhempel42 comments

IoT has many other problems... as pointed out by the popular twitter account against it: 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

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

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

- Samsumg smart fridge exposes your Google credentials: https://twitter.com/internetofshit/status/636102318585475072...

- Can't change thermostat while updating: https://twitter.com/internetofshit/status/684831858463387648...

- Mall smart screens get blue screen of death: https://twitter.com/internetofshit/status/652403071859970048

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

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

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.

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.

The BitTorrent company makes money off of their torrent clients.

> 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

This was actually a software bug shipped in an automatic update. The bug caused the Nest battery to drain faster than the HVAC power line could charge it. In my experience, Nest works fine when not connected to the Internet.

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.

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. :)

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.

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.

Sounds like you found a good niche. Your work is solving real problems and you can make real money from your product, instead of just creating another VC subsidized ad platform that gets breathless hype in TechCrunch. I'd consider sitting tight for now, there is a sea change going on in the tech world and money is getting tighter. In the not too distant future you might find it easier to attract better talent.

Dude! Same here! I'm moving a C#/Silverlight behemoth into React. I'm the only guy working on it, but my boss basically wants me to build something he can work on (not a JS guy!) so he doesn't have to employ me as much. I have 2 weeks left before I go back to college in another state for the semester.

And it's hard to remote because we have a poorly architected and somehow buggy SVN repo. git-svn can't load SVN history from it, so I don't get to use that. Still using VS2010 for the C# to target Silverlight 4, using my own free .edu ReSharper license, just factored out an entire Service from behind a C# Web Api by exposing solution-wide data classes.

Best bit? I don't have any concrete spec to build to. All I have is that it should look 'a bit like this'.

RIP me.

What company? Curious, I also live in Jersey.

I think you hit the nail on the head here. You are delivering within a vertical, which means you have a good chance at being successful.

IoT, like BigData before it, is suffering from an overload of people building technology for the sake of technology. I have done a lot of hands-on work in the Remote Service side of IoT, implementing solutions for GE, the TSA, etc.

At no point did I ever encounter a customer who longingly cried out "Woe is me, is there a horizontal technology anywhere that kinda solves a piece of my problem?!".

I fear that as we follow down the hype curve in IoT over the next 24 months, the roadsides will be littered with interesting and functional platforms that failed to solve a business problem.

Companies like the one described above will continue to make money and solve problems without any of the press that comes along with each new IoT platform.

> 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.

Do the channels yourself with NATS. http://bit.ly/1ZzpJAw

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/

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

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.

I agree with you mostly, but I do want that divide to be crossed, by software that I the user control, not by software that $smart_company controls. It's my data!

If it's a choice between $smart_company or nobody though, I'll take nobody. Thanks to firewalls and blocking outbound connections from IoT devices, it's often not that black and white.

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.

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.

How about the various "where are my friends" tracking apps, dating gadgets that light up when a person with shared interests is nearby, body metrics scanner that help health services create a map of say areas with an increased amount of people having hay fever?

Mostly true, but I think there can be exceptions such as PressureNet and Waze.

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.

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 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.

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.

"It's already the most expensive liquid most people will buy, and you want to let the printer order it for you?"

Beats running out of ink at 10pm when I need a printout by tomorrow morning.

Well, the aggregate benefits are there... just not for the consumer. The company producing the product, who collects all that data on their customers, gets to pick trends, predict failures, and take preemptive action. ...Often whether their customers like it or not.

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...

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.

> 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).

> 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

> 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.

> 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*

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.

We see a lot of both sides of this at BR (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..

> 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...

> 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).

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

Even if updates were easily implemented, you still have the same problems as consumer routers: once the product is off the shelves, there's little incentive for the vendor to spend money on support to even offer updates.

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"

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.

Reply on news.ycombinator.com