Maybe it's going nowhere because nobody really wants to have all their things become agents working for someone else (best case) or be exploited and cause massive grief (worst case).
I'd much rather have an INTRAnet of things, where nothing depends on "the cloud".
> I'd much rather have an INTRAnet of things, where nothing depends on "the cloud".
I couldn't agree more. "Cloud" integration is actually a negative selling point for me. Besides the very real problems you mentioned, your expensive IoT devices could just stop working and die[1] because someone decided to shut down the servers.
This generally shouldn't be a worry if you pick a large enough hosting company. Amazon isn't going to shut down its cloud service anytime soon.
I see your point - as an individual, I will never use Spotify because I like owning all of my own .mp3 files and I don't want some streaming service to have my by the balls when I want to listen to my own music.
But for the majority of business, it makes much more sense from a cost and complexity standpoint to use cloud services rather than having in-house servers and IT solutions. So I imagine hosted services will only be gaining in popularity in the near future, which should ease your fears of someone deciding to shut down the servers arbitrarily. AWS would find itself out of business pretty quickly if it let that happen to customers.
> This generally shouldn't be a worry if you pick a large enough hosting company.
It doesn't matter who provides the infrastructure. If the business entity that runs the services on that infrastructure closes its doors, the services shut down and any devices that depended on those services are hampered, crippled, or rendered useless.
> Few big players seem to be making use of such a thing. They'd currently rather have their own walled gardens. :)
Even some of the small maker targeted ones. For awhile I was searching for a cheap wifi connected microcontroller for some hobbyist home automation stuff. Both the Electric Imp[1] and Particle/Spark[2] products looked great, but they seem to both have obligatory cloud integration. If I spend weeks building something for my home, It has to be able to work until the hardware dies.
Luckily, I found the ESP8266[3] has pretty much all the capabilities I want, no cloud required.
No compelling use case, anyway. Now that the "Put microcontrollers in ALL THE THINGS!" frenzy is dying down, what's left are a handful of decent applications and a small minority that geeks out to being able to control their living room lights from halfway across the world.
Maybe there's a parallel to the "Do everything on the web!" frenzy. Out of that we got Amazon and Pets.com. Amazon turned out to be worthwhile. A bunch of the others, not so much.
Yes! I'm still excited by the IoT because I've turned both a dumb air conditioner and a dumb body scale into "IoT" items that never send their data outside of my network. I just think it is much more niche then people thought.
The V2V stuff is interesting, but from what I've seen, it is definitely a 1st gen design, especially with regards to security. Not that I know how I'd fix it.
What I'm talking about is this. Suppose I've got this nice 802.11p transceiver system in my car. My car uses it to talk to the infrastructure and other vehicles to get warnings and such. The HUD in my car can then give me a pop-up when there's an accident ahead, and all the usual stuff being talked about.
Now, for completely unrelated reasons, I wrecked my car (texting while driving, sheesh, when will I ever learn?). The car is sold to a junkyard. The 802.11p module survived the crash with no damage, though.
Evil hacker then goes to the junkyard and buys the module, and maybe the ECU as well if necessary. He can then do fun stuff like continuously broadcasting things like my car has had an accident, or has engaged emergency braking, which will cause warnings to pop up for other drivers, or with autonomous vehicles, they may act directly on that information.
Its still a valid BRAND NAME manufacturer's 802.11p unit. But without a way to revoke the "security certificate" for my specific vehicle, the rest of the network will still trust it. As far as I know, the trust is on a per-manufacturer or per-model level, and not per-device.
But of course, doing per-device drastically increases memory requirements, which will cost a lot of money, and make the system slower too.
This is a problem with antimatter CRLs (so called because the CRL is like antimatter: it wanders around, annihilating a cert only if it encounters it). Rather than sending out revocation lists, agents should be forced to renew their certificates regularly. Store a small trusted base in-memory (perhaps one trust root per nation-state), and then use certificate chains to authenticate.
Fortunately, there's already a precedent for a credential one needs to renew from the government in order to operate a vehicle: a license plate.
Heck, one could avoid the whole problem by doing what the government could have one do with one's license plates in case of accident: turn 'em in.
The architecture you propose sounds better that what's currently being implemented.
Now the problem is going to be educating the public that they are directly responsible for their "license transponder" too, and that they need to be really careful with it in the case of an accident or at other times when the car is out of their possession.
> The architecture you propose sounds better that what's currently being implemented.
Thanks. It's not actually my idea—it dates back to the mid-1990s, and the work done on RFCs 2692 & 2693. Our industry's failure to seriously adopt their framework is one of the more damning indictments of our maturity which I can think of right now.
One idea: On crash, the module could lock down to broadcasting a timestamped accident warning (no replay attacks) and would need someone with authorized access to reset it.
Doesn't really solve a hacker getting a non-crashed-but-otherwise-junked vehicle though :)
Edit: There's no reason to assume a hacker won't get access to the kit to reset a module as well. Guess we need to put a UseYourBestJudgement module in line with it for your driverless car ;D
To be fair, Low Energy Bluetooth has very quick connection setup, and most applications can actually get by using a connectionless advertising channel.
I've become very soured to IoT, the industry is spending more and more time making inconsequential devices communicate while ignoring the oligarchy controlling how real people communicate. Cellular providers and Facebook control almost all human communication.
That is fair, though as a practical matter for connecting with moving things the tiny range of BLE makes it more or less useless. In terms of "most applications" you probably mean body area networks (e.g. FitBit) where it does indeed do well but beyond that, BLE is not a serious IoT option for "most applications".
The issue of radio spectrum is glossed over in a short bullet-point summary at the end of the article while I believe it deserves to be the article's thesis. The limitations imposed by the radio spectrum and its availability are at the root of every other point made by the author.
You just can't have high bandwidth, excellent protection from interference, and low energy usage all at once. The blcoks of spectrum that offer the best balance of those qualities are already booked up for things like OTA TV broadcasts and "high-cost and high-powered cellular" networks. The issues with mesh networking are also immediately apparent if some classes of device are to be kept on separate networks or have to forgo their role as a node due to the power requirements of a repeater.
A simple example for what airwaves would look like in the crowded "IoT' future is your average apartment complex and the 2.4ghz spectrum. 30+ routers competing for the same tiny space absolutely destroys the quality (latency, throughput, power draw from the devices radio) of the connection. The space is so crowded that you may only see 5-10 networks as the signal from a router 2 stories up is so dirty that you can't even receive the SSID but the interference is still there.
There is only so much spectrum available for use, even if it was all unrestricted. There won't be a mass adoption of networked "things" until someone is able to find a loophole in the laws of physics.
I covered this in a separate piece on low power wide area networks http://www.slideshare.net/haystacktech/the-iot-hunger-games-... though to be clear, we are not talking about high bandwidth like Ethernet. We are seeing good signal propagation in sub-1GHz bands (measured in miles) while preserving multi-year AA battery life with some newer PHY layer technologies like LoRa and others. 2.4GHz is a mosh pit that most serious IoT vendors are fleeing due to the high interference and the resulting RMA's and related costs. For sensor networks, there is rarely a good reason not to use one of the more popular sub-1GHz bands 433/868/915 regardless of your geographic location.
It is a feature of using lower frequencies together with lower data rates and signal processing technologies. Consult with any RF engineer -- there is no magic here, just practical engineering to solve a particular set of problems.
> 2.4GHz is a mosh pit that most serious IoT vendors are fleeing due to the high interference and the resulting RMA's and related costs.
Your sales hyperbole is drowning out the good points you have. Knock it down a notch.
2.4GHz is a mosh pit. However, nobody is going away from it precisely because you need it to bootstrap the network. Data is most useful when it hits the internet, and, for better or worse, the only cheap way of doing that is WiFi with the occasional side of Bluetooth Low Energy with an attached phone/tablet/etc (however, people get annoyed at the extra battery drain).
Now, if you convince Apple or Google to throw 433/868/915 chips into all their devices, then, yes, people will dump 2.4GHz like a hot potato.
"2.4GHz is a mosh pit. However, nobody is going away from it"
Nobody strikes me as hyperbole, really. You will see one of the two companies you mention embrace sub-1GHz in the next 6 months. Also LPWAN's are almost entirely driven by sub-1GHz now and the list of participating telco's are not nobodies.
It's not quite that bad as the channel time requirements for most IoT applications are small. I did some research on this (https://github.com/hughobrien/wlan-stats) but it's far from complete.
When your wireless technology has an average outdoor range of 30-40 feet, of course spectrum is not an issue. When large numbers of endpoints (thousands or tens of thousands) share a common access point over many miles, it's a really significant issue that can be addressed in a number of ways outlined here http://bit.ly/1hExgtG
You're demanding conflicting things in the article. Fast connection time conflicts with security, long range with low power.
You can already get near-instant connectivity with nothing more than raw Wi-Fi frames. What you won't get are datagram delivery, guaranteed delivery, TCP streams and on up the OSI stack.
What's happening right now is vendors figuring out the bare minimum needed for a product category and then there will be a shootout with subsequent standardisation. Really no different from any other communication protocol evolution we've seen in the past.
Beyond the security issue, by installing IOT devices in your home, you are essentially lowering the value of it. Think about it. When you go into a home for a viewing, seeing an out of date dishwasher, fridge, etc lowers the value. It makes the house less attractive. Now add IOT devices, that are out of date, that really hurts the home. Would love to get people's thoughts of homes full of these outdates and possibly insecure devices.
Does it lower the value? Or do newer appliances increase the value? I sold a house last year that included a Nest thermostat and some z-wave outlets (that could also be controlled manually) - the buyer (in her 20's) said that these added to the appeal. Will generic z-wave devices go out of date any more quickly than other appliances?
Well, I suppose the correct answer is that for a given technology T there is a window W in which T causes value to increase, after which T causes value to decrease. The slope of the value increase from the moment of installation I to the end of the window, I+W, is probably quite steep, then levels off, then, at W, declines at first slowly then after some W' (the moment of real obsolescence), declines precipitously, and declines below the original value V.
In other words, that Nest has/had appeal for 1-3 years, after which it is/was yesterday's news. A house sold during those 1-3 sells for more because of the Nest, but, if sold afterwards, sells for less (adjusted for other market factors) because of it.
I have to disagree in regards to the Nest. Most houses still have their original thermostat. I don't see the Nest ever causing a house to sell for less. Even if Next/Google stopped supporting the product it would be trivial to replace it with a cheap conventional thermostat.
That only applies if you are selling the home when outdated IOT devices.
Just like appliances, where a a modern stainless steel Viking range can increase your home value, so too could a modern controller for IOT devices. But both these things get outdated (at different rates), and lose their luster at which point they are upgraded or left to get older because they may not be the new hotness, but they work.
This is an ad from Haystack Technologies, disguised as an article. The article claims that the big problem with the Internet of Things is that the handshake time for establishing a connection is too long for fast moving vehicles. Guess what Haystack Technologies sells.
The big problems with the Internet of Things so far are well known.
- All your stuff are belong to us. Everything is tied to some "cloud" service. Since the typical lifespan of a cloud service is only a few years, this is a big problem for home automation.
- Security. What security? Most of these devices can be taken over by almost anybody. Have we had the first IoT murder yet? Would we know?
- Limited consumer benefit. Being able to control your stuff from your cell phone is more cool than useful. A refrigerator with a tablet on the door isn't that useful, especially when it costs more than the refrigerator plus a separate tablet, and the tablet will be obsolete long before the refrigerator.
- Installation. It's possible to do insanely great HVAC, with windows, skylights, fans, and shutters all operating to minimize energy consumption and make the building pleasant to live in. You can even get all that stuff for your house. Now try to get it installed, configured, and maintained.
- "Connected" vehicles not too useful. Most of the talk about "connected vehicles" is about advertising or consumer tracking, or does stuff you can do now. Urmson, who runs Google's self-driving car project, says they don't need connected vehicles. They have to have sensing and sensor analysis good enough to reliably detect trouble that isn't "connected".
- Been there, done that. We've had X10 since the 1980s. Better systems since the 1990s. Nobody uses them.
I think people underestimate the extent to which this matters. In fact, I might even say this is the only thing that matters. There are some of us who are concerned with privacy, ownership, security, etc. But most don't, and never will.
The real nail in the coffin is that we're not solving a real need.
:The real nail in the coffin is that we're not solving a real need."
I'd tend to agree, except that half of YC's companies don't solve a real need. Neither Twitter nor Facebook solve a real need. It's just that they got enough early users to benefit from network effects.
If someone comes up with some IoT thing so compelling that you have to have it in your pocket/on your wrist when you're anywhere away from home, that could be a big win. A wristband that lets you into your house, starts your car, logs you into your computer, gets you onto airplanes, and won't work if it's on someone else's wrist.
You're focusing on the consumer space. The big promise currently is elsewhere - sensors, automation, warehouses (for physical goods), and so forth. This is especially true for data collection in physically challenging environments, like mines.
This stuff is not necessarily tied to any cloud. There is a new term (wait for it), "the fog", that implies on-site data processing and analytics for all of these connected devices.
The funny part is the IoT is already here. Such systems are being deployed now in mining, oil and gas, etc.
Pure curiosity: Is security taken more seriously in those deployments than it is in the consumer stuff we've all heard of? (Would love some links to read up on the subject.)
Looking at the wireless protocols being deployed in nearly all cases, my vote would be no. We are installing junk wireless with junk security, some of which is just comical. I don't have all the answers, but there are a few straightforward improvements to be made that I outline here: https://medium.com/the-startup-magazine-collection/a-simple-...
IoT is a buzzword. Buzzwords eventually die off because they're nebulous. What was "Web 2.0"? Did it die? Are we in Web 3.0 now? Does it matter one way or the other?
There will be many successful connected device startups. Many others will be started & funded for the wrong reason: because IoT is "hot" right now.
IoT is a particularly maddening buzzword because the name is mis-leading. There's not a separate internet for things, but rather these are just "things connected to the internet". Not as catchy, which I suppose is the point.
As an aside: I worry I may be turning into Andy Rooney :)
Anything that makes technology approachable to the masses is a step forward I think, even if it might sub optimize in favor of the consumers perspective (Curating a Facebook account vs blog for example)
I'm currently a uni student. Combined IT and Business Management.
The amount of lectures where Web 2.0 is dealt with as if it is a real tangible thing is astonishing.
These kind of management-oriented IT degrees are the source of all these problems. They teach managers just enough to be dangerous and make all these buzzwords live on for far longer than their sell-by date.
Sooo.... categorize IoT devices, develop different communications standards for each category of device, and have each device support at least one standard for its category. Then develop border gateways for each layer.
Different MANETs either already exist or are being developed; this doesn't seem like a problem, it's just a young industry. Like the early days before/during 802.11b when there were incompatible proprietary wireless networks and protocols. Eventually one or two standards will emerge and the industry will pick them up.
I think the most exciting thing about IoT is we have an opportunity to lay the groundwork for new hybrid networks built on IoT-connected devices. My imagination conjures up an L2 switch built into every device with the ability to segment network traffic among different nodes.
Imagine long city blocks littered with IoT devices, all passing a lunch order from an app on your IoT smartphone to the IoT point-of-sale system at your favorite cafe, without a managed network. This is different than P2P because you could support different types of network communication simultaneously.
The BT SIG is doing what you describe in your first paragraph. I can't shake the feeling that we're lobotomising perfectly general computing and networking devices this way though. They're powerful enough to be interrogated and reprogrammed remotely, forth was doing this decades ago.
You need to go one level up and look at the economic situation.
There are a lot of companies that can benefit from IoT tech, but there's this nagging little problem of the cloud layer in the middle.
Let's take the example of a fast-food chain that wants to have all of their refrigerators upload their current temperatures to a central point. (This might or might not be related to something I'm working on) Seems like a simple little technical problem for the refrigerator manufacturer, right? At the physical layer, it totally is. We can drop wifi points and 802.11b radios all over the globe and we're in business. The restaurant chain is happy - the equipment vendor has handled it all and we're on our way.
But now all that data is coming into a server somewhere. And the questions start piling up:
1) Who owns that server? The restaurant chain or the fridge maker? Is the data proprietary?
2) Who is paying for the server maintenance? Who's paying for the broadband connections in every store?
3) Who is going to write the dashboard that lets corp see the nifty graphics about system uptime? Who maintains that? Where does it live?
So should the fridge maker switch to a subscription model and rent out the units? That'll take care of the cost. But if the restaurant is renting the units, then surely the fridge maker should be on 24/7 call to service these units when they fail! Oops, now the fridge maker needs to implement a service team.
This is a holy mess. There are plenty of middlemen popping up to handle the cloud layer like Digi and Exosite. But in the end someone has to write the check and neither side wants to do it. The restaurant wants their food safety data without the added cost. The fridge maker wants to sell units and minimize the support cost.
Companies like Amazon are in a much better position because that Dash button feeds directly into their ecosystem. For the rest of the world, the world that IoT is trying to target, they're still out in the cold.
So, I've been in a variant of the situation. In my version we were the "refrigerator maker" and wanted the data for improved/faster/cheaper service since service costs were eating us alive.
We owned the data. Customers had to sign up for the system, but we got them to do it by offering a lower cost service contract if they did. Since we were a large multinational, we already had an IT department to manage the servers and lots of developers to write code and obviously an existing service team, since that was the whole reason we did it in the first place.
But here's the thing. What I really learned from being the technical lead on that project is that there are growing market opportunities for third party companies to do exactly this and take over the responsibility from the restaurant and the fridge maker. You build the hardware (it's usually pretty cheap and simple) and write the webapp/dashboard, and charge a recurring fee for the service.
It's a lot of work for a one-man shop, but I'm still toying with starting a business in this space.
There's already some competition in this space. Digi and Exosite are two examples I named. There's also Helium, co-founded by Shawn Fanning so they get a lot of press for a solution that (imo) isn't fully complete.
So what makes things more complicated is moving to the next step: two-way data. Let's say it's not a fridge now but an oven, loaded with data pushed down from the cloud by a chef at the restaurant's corporate HQ. Recipes. Holding times. Training videos. I'm not quite sure a major restaurant chain wants this data on a server out of their control. It's something I'm still trying to understand from my customers.
Doesn't the industrial/building automation industry already have solid solutions for your fridge example?
Many buildings already have sensors wired in to PLCs and it's easy to network with the PLC to record and display the signals (for which there are many existing "dashboards" - HMI packages of varying cost and ability).
I don't think it would matter much who owns or maintains the server if you're using a PLC to aggregate your signals onto the network. Many companies are paranoid and would want an in-house server. But it wouldn't be much different to use a cloud based instance.
It's true that existing automation hardware and software are obscenely expensive compared to consumer tech, to the point where renting/subscription might make sense for certain use cases. The systems sufficiently complicated, though, that independent professionals usually manage the setup and maintenance.
That's kind of the dirty little secret here, right? This technology has been around forever, it only became attractive and fashionable lately because the smartphone revolution has dropped the price of radio hardware to the point where it can be dropped into everything/anything.
So now we face the challenge of groups that want Stuttgart-Siemens-PLC functionality for Shenzen-ESP-IoT pricing. Oh yeah, and let's skip all that service contract nonsense. I mean why am I paying $20/month in service for a chip that costs $1.50?
I think you're painting it more complex than it really is. I developed just such a solution for a manufacturer. The manufacturer paid for it and charges the end users for the service and the end user pays for maintenance of the sensors and transmitters. We used a cellular technology (not wifi) from the moving things and its worldwide. And it runs on a utility cloud service similar to Amazon. It's not that hard, really.
The part of the article that addresses data interoperability and databasing on the endpoint (without cloud middleman) is important for use cases where there are ownership issues. The author would no-doubt agree that having to subscribe to a cloud-based gatekeeper middleman, to access the data on the fridge you own, is absurd and against the spirit of the internet.
Movement? That isn't the problem. Cost and interoperability are the problem.
On the cost side of IoT, the rent is just too damn high: I don't want to pay $50 for a fancy light bulb. I want to pay _maybe_ an extra 50 cents or $1 extra per bulb.
On the interoperability side: Most of the things I really care about are plugged into my home's electrical sockets. I'd love to see a new single standard "smart" plug that wires my devices into my home network when I plug it in. I can plug "dumb" devices into it and at a minimum turn if on/off. If I can do that, all my lamps work. For "smart" devices, they would push/pull data via TCP/IP.
I've been eyeing DASH7 for a few years now, because the authors concerns with existing popular standards certainly are valid. Problem is, DASH7 is relatively unknown, and big marketing makes more noise in the market.
It's a well-designed protocol, read up on it.
A cow as a slowly moving thing? Clearly, the author has never been chasing an escaped cow. (I had to, and it was not pretty. Cows are FAST if they want!)
It's still early days. Niche, maker domain. Pieces of the puzzle are emerging such as the low cost "wino board". (I'm looking forward to this). Keeping costs down allows more experiments and creative mixing and matching.
Intranet of things is important too. People want a connected but secure and private home. Things are personal. Do we really need or want Google in our fridge? If the fridge senses only one egg left in egg compartment, there needs to be options for how that information is then made available to members of the household. Google cloud, sure. But also more private exclusive services too with a focus on privacy not advertising and "link with Google profile in order to use this feature" nonsense.
Sensors, logic and easily configured rules are important. We want to sense whether the cat has walked downstairs or a human. Cat doesn't need night light. How many humans are now downstairs, maybe one is sitting still in a chair, the other moving around. A smart house knows all this.. Via low cost sensors and a reliable rules engine, standards and easily configured without tech knowledge. Still a way to go.
It needs to easy like piecing together Lego. Depending on your home and things and people in your life you will have a different arrangement of connections.
69 comments
[ 3.4 ms ] story [ 130 ms ] threadI'd much rather have an INTRAnet of things, where nothing depends on "the cloud".
I couldn't agree more. "Cloud" integration is actually a negative selling point for me. Besides the very real problems you mentioned, your expensive IoT devices could just stop working and die[1] because someone decided to shut down the servers.
[1] https://en.wikipedia.org/wiki/Zeo,_Inc.#Out_of_business
I see your point - as an individual, I will never use Spotify because I like owning all of my own .mp3 files and I don't want some streaming service to have my by the balls when I want to listen to my own music.
But for the majority of business, it makes much more sense from a cost and complexity standpoint to use cloud services rather than having in-house servers and IT solutions. So I imagine hosted services will only be gaining in popularity in the near future, which should ease your fears of someone deciding to shut down the servers arbitrarily. AWS would find itself out of business pretty quickly if it let that happen to customers.
It doesn't matter who provides the infrastructure. If the business entity that runs the services on that infrastructure closes its doors, the services shut down and any devices that depended on those services are hampered, crippled, or rendered useless.
Even some of the small maker targeted ones. For awhile I was searching for a cheap wifi connected microcontroller for some hobbyist home automation stuff. Both the Electric Imp[1] and Particle/Spark[2] products looked great, but they seem to both have obligatory cloud integration. If I spend weeks building something for my home, It has to be able to work until the hardware dies.
Luckily, I found the ESP8266[3] has pretty much all the capabilities I want, no cloud required.
[1] https://electricimp.com/
[2] https://www.particle.io/
[3] http://www.esp8266.com/
* Funky, confusing little form factor? Check! :D
* Really cute way to get network credentials into the device? Check! :D
* Only programmable in some Javascript variant? Check! :/
* Application server that lets you remotely change the code running on any activated device? Check! :D
* Complete and utter absence of locally-hostable version of said application server? Check! :(
They won't even give you the option of paying more for the hardware to get a copy of the application server. :/
What I'm talking about is this. Suppose I've got this nice 802.11p transceiver system in my car. My car uses it to talk to the infrastructure and other vehicles to get warnings and such. The HUD in my car can then give me a pop-up when there's an accident ahead, and all the usual stuff being talked about.
Now, for completely unrelated reasons, I wrecked my car (texting while driving, sheesh, when will I ever learn?). The car is sold to a junkyard. The 802.11p module survived the crash with no damage, though.
Evil hacker then goes to the junkyard and buys the module, and maybe the ECU as well if necessary. He can then do fun stuff like continuously broadcasting things like my car has had an accident, or has engaged emergency braking, which will cause warnings to pop up for other drivers, or with autonomous vehicles, they may act directly on that information.
Its still a valid BRAND NAME manufacturer's 802.11p unit. But without a way to revoke the "security certificate" for my specific vehicle, the rest of the network will still trust it. As far as I know, the trust is on a per-manufacturer or per-model level, and not per-device.
But of course, doing per-device drastically increases memory requirements, which will cost a lot of money, and make the system slower too.
Like I said, I don't know how I'd fix it...
Fortunately, there's already a precedent for a credential one needs to renew from the government in order to operate a vehicle: a license plate.
Heck, one could avoid the whole problem by doing what the government could have one do with one's license plates in case of accident: turn 'em in.
Now the problem is going to be educating the public that they are directly responsible for their "license transponder" too, and that they need to be really careful with it in the case of an accident or at other times when the car is out of their possession.
Thanks. It's not actually my idea—it dates back to the mid-1990s, and the work done on RFCs 2692 & 2693. Our industry's failure to seriously adopt their framework is one of the more damning indictments of our maturity which I can think of right now.
Doesn't really solve a hacker getting a non-crashed-but-otherwise-junked vehicle though :)
Edit: There's no reason to assume a hacker won't get access to the kit to reset a module as well. Guess we need to put a UseYourBestJudgement module in line with it for your driverless car ;D
I've become very soured to IoT, the industry is spending more and more time making inconsequential devices communicate while ignoring the oligarchy controlling how real people communicate. Cellular providers and Facebook control almost all human communication.
Zigbee is the biggest joke with tons of proprietary and incompatible implementations of an open standard.
You just can't have high bandwidth, excellent protection from interference, and low energy usage all at once. The blcoks of spectrum that offer the best balance of those qualities are already booked up for things like OTA TV broadcasts and "high-cost and high-powered cellular" networks. The issues with mesh networking are also immediately apparent if some classes of device are to be kept on separate networks or have to forgo their role as a node due to the power requirements of a repeater.
A simple example for what airwaves would look like in the crowded "IoT' future is your average apartment complex and the 2.4ghz spectrum. 30+ routers competing for the same tiny space absolutely destroys the quality (latency, throughput, power draw from the devices radio) of the connection. The space is so crowded that you may only see 5-10 networks as the signal from a router 2 stories up is so dirty that you can't even receive the SSID but the interference is still there.
There is only so much spectrum available for use, even if it was all unrestricted. There won't be a mass adoption of networked "things" until someone is able to find a loophole in the laws of physics.
Do you have any test data to confirm this? Is there a device that can be acquired that has implemented your specification?
Your sales hyperbole is drowning out the good points you have. Knock it down a notch.
2.4GHz is a mosh pit. However, nobody is going away from it precisely because you need it to bootstrap the network. Data is most useful when it hits the internet, and, for better or worse, the only cheap way of doing that is WiFi with the occasional side of Bluetooth Low Energy with an attached phone/tablet/etc (however, people get annoyed at the extra battery drain).
Now, if you convince Apple or Google to throw 433/868/915 chips into all their devices, then, yes, people will dump 2.4GHz like a hot potato.
Good luck, but I won't be holding my breath.
Nobody strikes me as hyperbole, really. You will see one of the two companies you mention embrace sub-1GHz in the next 6 months. Also LPWAN's are almost entirely driven by sub-1GHz now and the list of participating telco's are not nobodies.
You can already get near-instant connectivity with nothing more than raw Wi-Fi frames. What you won't get are datagram delivery, guaranteed delivery, TCP streams and on up the OSI stack.
What's happening right now is vendors figuring out the bare minimum needed for a product category and then there will be a shootout with subsequent standardisation. Really no different from any other communication protocol evolution we've seen in the past.
In other words, that Nest has/had appeal for 1-3 years, after which it is/was yesterday's news. A house sold during those 1-3 sells for more because of the Nest, but, if sold afterwards, sells for less (adjusted for other market factors) because of it.
Just like appliances, where a a modern stainless steel Viking range can increase your home value, so too could a modern controller for IOT devices. But both these things get outdated (at different rates), and lose their luster at which point they are upgraded or left to get older because they may not be the new hotness, but they work.
No major difference here.
The big problems with the Internet of Things so far are well known.
- All your stuff are belong to us. Everything is tied to some "cloud" service. Since the typical lifespan of a cloud service is only a few years, this is a big problem for home automation.
- Security. What security? Most of these devices can be taken over by almost anybody. Have we had the first IoT murder yet? Would we know?
- Limited consumer benefit. Being able to control your stuff from your cell phone is more cool than useful. A refrigerator with a tablet on the door isn't that useful, especially when it costs more than the refrigerator plus a separate tablet, and the tablet will be obsolete long before the refrigerator.
- Installation. It's possible to do insanely great HVAC, with windows, skylights, fans, and shutters all operating to minimize energy consumption and make the building pleasant to live in. You can even get all that stuff for your house. Now try to get it installed, configured, and maintained.
- "Connected" vehicles not too useful. Most of the talk about "connected vehicles" is about advertising or consumer tracking, or does stuff you can do now. Urmson, who runs Google's self-driving car project, says they don't need connected vehicles. They have to have sensing and sensor analysis good enough to reliably detect trouble that isn't "connected".
- Been there, done that. We've had X10 since the 1980s. Better systems since the 1990s. Nobody uses them.
I think people underestimate the extent to which this matters. In fact, I might even say this is the only thing that matters. There are some of us who are concerned with privacy, ownership, security, etc. But most don't, and never will.
The real nail in the coffin is that we're not solving a real need.
I'd tend to agree, except that half of YC's companies don't solve a real need. Neither Twitter nor Facebook solve a real need. It's just that they got enough early users to benefit from network effects.
If someone comes up with some IoT thing so compelling that you have to have it in your pocket/on your wrist when you're anywhere away from home, that could be a big win. A wristband that lets you into your house, starts your car, logs you into your computer, gets you onto airplanes, and won't work if it's on someone else's wrist.
This stuff is not necessarily tied to any cloud. There is a new term (wait for it), "the fog", that implies on-site data processing and analytics for all of these connected devices.
The funny part is the IoT is already here. Such systems are being deployed now in mining, oil and gas, etc.
<drink out nose> Thanks. You owe me a new keyboard. :)
No. If anything, it's worse.
There will be many successful connected device startups. Many others will be started & funded for the wrong reason: because IoT is "hot" right now.
IoT is a particularly maddening buzzword because the name is mis-leading. There's not a separate internet for things, but rather these are just "things connected to the internet". Not as catchy, which I suppose is the point.
As an aside: I worry I may be turning into Andy Rooney :)
The amount of lectures where Web 2.0 is dealt with as if it is a real tangible thing is astonishing.
These kind of management-oriented IT degrees are the source of all these problems. They teach managers just enough to be dangerous and make all these buzzwords live on for far longer than their sell-by date.
Different MANETs either already exist or are being developed; this doesn't seem like a problem, it's just a young industry. Like the early days before/during 802.11b when there were incompatible proprietary wireless networks and protocols. Eventually one or two standards will emerge and the industry will pick them up.
I think the most exciting thing about IoT is we have an opportunity to lay the groundwork for new hybrid networks built on IoT-connected devices. My imagination conjures up an L2 switch built into every device with the ability to segment network traffic among different nodes.
Imagine long city blocks littered with IoT devices, all passing a lunch order from an app on your IoT smartphone to the IoT point-of-sale system at your favorite cafe, without a managed network. This is different than P2P because you could support different types of network communication simultaneously.
There are a lot of companies that can benefit from IoT tech, but there's this nagging little problem of the cloud layer in the middle.
Let's take the example of a fast-food chain that wants to have all of their refrigerators upload their current temperatures to a central point. (This might or might not be related to something I'm working on) Seems like a simple little technical problem for the refrigerator manufacturer, right? At the physical layer, it totally is. We can drop wifi points and 802.11b radios all over the globe and we're in business. The restaurant chain is happy - the equipment vendor has handled it all and we're on our way.
But now all that data is coming into a server somewhere. And the questions start piling up:
1) Who owns that server? The restaurant chain or the fridge maker? Is the data proprietary?
2) Who is paying for the server maintenance? Who's paying for the broadband connections in every store?
3) Who is going to write the dashboard that lets corp see the nifty graphics about system uptime? Who maintains that? Where does it live?
So should the fridge maker switch to a subscription model and rent out the units? That'll take care of the cost. But if the restaurant is renting the units, then surely the fridge maker should be on 24/7 call to service these units when they fail! Oops, now the fridge maker needs to implement a service team.
This is a holy mess. There are plenty of middlemen popping up to handle the cloud layer like Digi and Exosite. But in the end someone has to write the check and neither side wants to do it. The restaurant wants their food safety data without the added cost. The fridge maker wants to sell units and minimize the support cost.
Companies like Amazon are in a much better position because that Dash button feeds directly into their ecosystem. For the rest of the world, the world that IoT is trying to target, they're still out in the cold.
We owned the data. Customers had to sign up for the system, but we got them to do it by offering a lower cost service contract if they did. Since we were a large multinational, we already had an IT department to manage the servers and lots of developers to write code and obviously an existing service team, since that was the whole reason we did it in the first place.
But here's the thing. What I really learned from being the technical lead on that project is that there are growing market opportunities for third party companies to do exactly this and take over the responsibility from the restaurant and the fridge maker. You build the hardware (it's usually pretty cheap and simple) and write the webapp/dashboard, and charge a recurring fee for the service.
It's a lot of work for a one-man shop, but I'm still toying with starting a business in this space.
So what makes things more complicated is moving to the next step: two-way data. Let's say it's not a fridge now but an oven, loaded with data pushed down from the cloud by a chef at the restaurant's corporate HQ. Recipes. Holding times. Training videos. I'm not quite sure a major restaurant chain wants this data on a server out of their control. It's something I'm still trying to understand from my customers.
Many buildings already have sensors wired in to PLCs and it's easy to network with the PLC to record and display the signals (for which there are many existing "dashboards" - HMI packages of varying cost and ability).
I don't think it would matter much who owns or maintains the server if you're using a PLC to aggregate your signals onto the network. Many companies are paranoid and would want an in-house server. But it wouldn't be much different to use a cloud based instance.
It's true that existing automation hardware and software are obscenely expensive compared to consumer tech, to the point where renting/subscription might make sense for certain use cases. The systems sufficiently complicated, though, that independent professionals usually manage the setup and maintenance.
So now we face the challenge of groups that want Stuttgart-Siemens-PLC functionality for Shenzen-ESP-IoT pricing. Oh yeah, and let's skip all that service contract nonsense. I mean why am I paying $20/month in service for a chip that costs $1.50?
But we'll still lack useful applications for it at home.
On the cost side of IoT, the rent is just too damn high: I don't want to pay $50 for a fancy light bulb. I want to pay _maybe_ an extra 50 cents or $1 extra per bulb.
On the interoperability side: Most of the things I really care about are plugged into my home's electrical sockets. I'd love to see a new single standard "smart" plug that wires my devices into my home network when I plug it in. I can plug "dumb" devices into it and at a minimum turn if on/off. If I can do that, all my lamps work. For "smart" devices, they would push/pull data via TCP/IP.
Intranet of things is important too. People want a connected but secure and private home. Things are personal. Do we really need or want Google in our fridge? If the fridge senses only one egg left in egg compartment, there needs to be options for how that information is then made available to members of the household. Google cloud, sure. But also more private exclusive services too with a focus on privacy not advertising and "link with Google profile in order to use this feature" nonsense.
Sensors, logic and easily configured rules are important. We want to sense whether the cat has walked downstairs or a human. Cat doesn't need night light. How many humans are now downstairs, maybe one is sitting still in a chair, the other moving around. A smart house knows all this.. Via low cost sensors and a reliable rules engine, standards and easily configured without tech knowledge. Still a way to go.
It needs to easy like piecing together Lego. Depending on your home and things and people in your life you will have a different arrangement of connections.