A highly connected world where devices of all sorts intelligently use sensor data to be more efficient, adjust to changing conditions, prevent or at least flag problems, and optimize performance of themselves, workflows, and even personal health -- that is the vision of the Internet of things.

It's a great vision, but despite all the hype in the last year, it does not -- and may never -- exist.

[ Get the scoop on the Internet of things at its most fundamental level and find out where it's headed, in InfoWorld's downloadable PDF and ePub. | Pick up the latest insight on the tech news that matters from InfoWorld's Tech Watch blog. ]

It's increasingly clear that much of what is called the Internet of things is the same old automation and machine-to-machine (M2M) technologies that have been around for a decade or more. Most of the rest is a set of proprietary home-automation technologies that address trivial needs and actually endanger many residences through poor security.

Why we don't want everything connected to each other

If the Internet of things doesn't happen, that could be good news. As more items communicate with each other and, most important, affect each other's behavior, we risk a nightmare as bad actors take advantage of the unseen access. Look at the damage that hackers and phishers do using the Internet on computers.

But wait until they can access building boilers and turn them into bombs, disable our door locks, open our garage doors, turn on sprinkler systems in data centers, and set self-driving cars to crash or simply stay put.

I'm rarely a security alarmist, and security is in fact not the biggest challenge of the Internet of things. However, it shows why a truly open Internet of things is a questionable idea. (The bigger challenges involve the complexity of n-to-n workflow and technology integration. Not to mention user experience.)

The Internet of things today, traditional machine automation of yesterday

That's why, despite all the talk, what's actually happening is very different: a profusion of siloed, proprietary systems that take advantage of the advent of cheap sensors, cheap computing, and potentially cheaper communications.

Much of that has long roots. That became crystal-clear to me last week at the Internet of Things North America conference held in suburban Chicago. I went to an IoT conference in the American industrial heartland because the IoT conferences in Silicon Valley are full of silly notions, like wireless dinner plates that use cameras to identify your food and calculate its calories as part of a weight-loss problem. (Using smaller plates is the better solution, and it's both cheap and reliable.)

In suburban Chicago, I saw more-pragmatic ideas around combining sensors, computing, and connectivity, such as to manage building HVAC systems, diagnose airplane engine performance, adjust plowing patterns based on weather and local soil quality, track the state of perishable items during shipment, assess incipient failures in industrial equipment, and manage manufacturing lines based on data around supply availability and defect rates.

But these are the same use cases I was writing a decade ago for a variety of technology business publications. We didn't call it Internet of things back then.

These examples are all valid and useful. But they're not new notions. What's new is that they're cheaper and easier to deploy today than a decade ago, so they can be more widely adopted and utilized.

We now have cellular and local wireless data networks broadly deployed with decent speed for such uses. We have cheap cloud computing services to do much of the processing and even store the transactional data. And we have client devices (iPhones, iPads, and their Android equivalents) in wide use that can act as the portable, near-universal controllers of these systems.

Although we don't have common APIs and protocols, we're starting to see several centers of gravity emerge: Apple HomeKit, the AllSeen industry consortium, the Open Interconnect industry consortium, and perhaps Google's Thread and Works with Nest protocols.

The specialized networks of specific things

What we have and continue to build out is not an Internet of things, but lots of separate, specialized networks of specific things.

That's actually good because it lets us optimize for workflow, security, and technology stacks. A universal technology stack, much less a universal workflow design language, is unrealistic, and anything pretending to be that will disappoint.

For example, although it may make sense for some devices in the home to connect to each other -- a thermostat, furnace, fire detector, and perhaps sprinkler system; door locks, security cameras, and alarm/intruder-detection systems; or entertainment devices -- it doesn't make sense for these clusters to communicate with each other or initiate actions across the clusters. At most, you might use smartphones, tablets, and computers as a common console device -- with separate consoles (that is, apps) for each IoT cluster.

The same separation is even more necessary in commercial and industrial settings. You might remember the scare stories last week about how inflight Wi-Fi could be used to take down aircraft by providing access to avionics systems. That would be true only if they were only on the same network, which is an incredibly stupid thing to do. The Internet of things implies one network, but what we need and want are multiple networks.

In some cases, separate virtual LANs are sufficient. In other cases, you need separate physical networks. You may even want separate networking technologies -- there's a good reason why the Nest Protect smoke detectors communicate with each other via the proprietary Weave mesh-network protocol rather than through Wi-Fi. If Wi-Fi goes down, they can still communicate about detected smoke or carbon monoxide -- and a Wi-Fi device can't be used to send false signals over Weave. Again, this kind of network separation matters even more in industrial and commercial settings.

That's merely the networking side. Think about the APIs for devices that enable not only exchange of data but actuation of capabilities. What would a washing machine need to tell a stereo? Let you know the laundry is dry? Perhaps, but that's a trivial detail. How many such needs should most devices support? The more needs, the harder they are to develop, maintain, and support.

The result of this complexity and weak justification: We'll see IoT devices logically cluster into fairly small sets. Vendors' desire to "own" customers ironically will also help keep IoT clusters small. as the lack of interoperability and the serious unlikelihood of people replacing expensive gear like garage door openers and heaters just to make them interoperable.

A constrained scope for IoT functionality makes more sense than an "open Internet of things" style that gets all the media attention -- which is why functional silos are what's happening in the real world, both in the home and in industry. It's not the Internet of things, but it's more sensible.