It's interesting to see the discussion focus on IoT when Tony Fadell of Nest keeps repeating his view that Nest is not an Internet of Things company. I tend to agree with him. What Nest has done well is to concentrate on usability and comfort. Those sell to consumers and it's vital we concentrate on them if home automation and smart homes are ever going to take off.
Unfortunately most engineers approach it from the other end, which is to choose the technology and assume the consumer will buy it. Hence the discussions about ZigBee, Z-Wave, 6LoWPAN, Bluetooth, Wi-Fi and all of the others. All of this is gobble-de-gook for the consumer and concentrating on it will just delay the market. I think Thread will help by having the beneficial side-effect of killing off ZigBee and Z-Wave, as I've explained in an article at http://bit.ly/1skiECh, but that's a secondary bonus.
From what I can see, Thread looks to be an efficient protocol, which is good. What is more important is that it will be used by Nest and Google who both understand a lot about User Experience. It means the world will start to get examples of wireless products where the user interface does not appear to have been designed by engineers. And that's what the market needs far more than any new IoT standard.
There are 3 runners in the race for Home networking right now - WiFi, Zigbee and Z-Wave. Of the 3, I believe Z-Wave has the broadest range of available-right-now products for the average home owner who wants to automate (in the US).
WiFi is more attractive for renters and people who don't want to dig into the wiring, but you're not going to see a practical/low cost door/window sensor or movement sensor that is battery powered and WiFi.
6LoWPan based devices on the 2.4GHz band certainly look to be able to solve the battery problem, and by being a open standard, the product cost (which is also a huge challenge right now) can come down from the current $50 ish per trivial device.
From 2015 we could finally see cross compatible and cheap products come out. Then the next problem is how to control everything. It's great that Apple's HomeKit could provide a ubiquitous UI to all of these devices, but we still need a central controller to take care of scheduling and notiffying tasks when your iOS device is not at home. Will users just install a gateway and entrust everything to some paid service in the cloud, or do they want a non-recurring-cost, non-privacy-exposing controller at home (I certainly want the latter)
As an engineer, I wanted to get started on experimenting right now, so I'm putting some Z-Wave products in my house, so I foresee a hybrid solution as a requirement, no single protocol will be the winner. I'm definitely watching the 6LoWPan space though.
As reported it has good support and I see a number of our customers demanding this type of support from us. We do support a broad set of wireless and IoT protocols and this seems like a welcome addition that will mesh ;-) with other high level protocols as well as emerging wearables protocols.
The lack of an open specification publication with the announcement is clearly a tactical move to try and establish their segment of this huge space without telling anyone what they are doing or planning at a detailed level.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.