These responses are missing the point. Yes, BT Smart has IPv6. Yes, it's low power. Yes, you can make a mesh network with it.
Do they really think the engineers at Nest didn't think about that? Creating a new standard is a massive job that will face a lot of resistance. They didn't just make Thread up for fun or to have a proprietary ecosystem to lock out competitors.
I don't know exactly why BT smart wasn't good enough. What I suspect, is that while it is possible to build a mesh network with Bluetooth it isn't possible to do so with the extremely minimal power consumption promised by Thread, and I also suspect it isn't possible to build an efficient BT Smart mesh network that can scale to over 250 devices.
Those are good points askubel, and that's exactly why CSR developed the CSRmesh, but with a lighter protocol that does support thousands of devices - it looks like the engineers at CSR and Nest were looking at similar solutions from different directions at the same time, which is why we end up in this kind of situation.
It will be interesting to see CSRmesh opened up as the company has said, but Thread also needs to be an open protocol.
Then I suspect there's an opportunity for smart ways to provide a multi-protocol solution without the resource overhead - that's the kind of thinking that Imagination Technologies is following with its auto-discovery and configuration approach.
As IoT grows out of its infancy, there will be room for improved standards -- especially those that offer lower power consumption. Just because BT Smart is the incumbent, don't assume that challengers can't improve on it.
Hi askubel - I think we need to see more details of Thread before we can say things like this. CSRmesh does support over 250 devices in a single mesh - that has been demonstrated, along with the lower power capability for LED lighting, so it does address exactly the points you rightly raise. I'm not sure you can say the same about Thread as yet - once it is opened up, then we will have the chance to see how the implementation differs, particularly with the need for a hub to link to a smartphone.
Until then, there is still this pretty fundamental split on which protocol and underlying technology to choose.
This is a battle on two fronts - the radio layer and the protocol layer. BT smart would seem to be an established technology when it comes to the radio layer, but at the protocol layer, there are many groups trying to create IoT protocols that bridge devices to the general internet.
Those protocols are invariably IP based, so the radio layer is going to have to meet them with an IP API. 6LoWPAN does that, but IP over BT Smart has only just started to be discussed:
"We created the railroad track and still need to engineer the train on how it's going to carry the traffic," he said. "We know people are interested in using Bluetooth to carry IP traffic natively. It's not necessarily a limitation today...but we want to provide another option for the next generation of technology."
Yes, it can. As long as IP packet get through. However Bluetooth have long history that it do not work very well with IP. Original LAN Profile was instant failure. PAN profile (sometimes called BNEP, Bluetooth Network Encupsulation Protocol) was not great success neither.
Even though Bluetooth SIG announced that "BT4.1 CAN support IPv6" but I believe no implementation still exists today. As long as I know there is no description how to implement IP over BT in BT4.1 core spec. IP neighbor discovery is heavily relys on multicast, but Blutooth do not handle multicast very well. Fragmentation is another issue they must solve. BTLE frame size is 39byte maximum, much shorter than notorious 802.15.4 (127byte max). Do they apply 6LowPAN? I don't know.
They say IPv6 over BT is "work in progress". Until we see actual implementation, we don't know how practical IP over BT4.1 really is.
Representatives from a lot of these IOT manufacturers, including Zigbee, zWave, and Bluetooth Smart are furious to hear about yet-another-IOT standard--Thread.
I could just imagine how the Bluetooth group feels--talk about stealing their thunder. They had just made an announcement with CSR (Cambridge Silicon Radio) for using Bluetooth in a mesh for home control, then Thread gets announced, by Google and Samsung no less.
As a consumer I have mixed feelings. On the one hand, it seems that with so many standards, there will never be any compatibility among the many devices out there. Will the Philips Hue light bulbs work with Bluetooth Mesh or Thread? Nope.
On the other hand, the one thing common among the standards out there now, is the high cost. I assume that there are high licensing costs involved. And I assume that will also be true with Bluetooth mesh.
Two things Google has managed with Android is to have a big ecosystem with lots of software, and bringing costs down. If they can do this with Thread too, then consumers win. Even if Thread doesn't end up being the winner (in truth, Bluetooth Mesh sounds promising), if it forces the others to raise their standards of security and useabliltiy while bringing costs down, then we all win.
Fortunatelly or unfortunatelly, it the way Captalism world works. Every time when new market oppotunity shows up, various companies jump in with different and incompatible technologies, try to get lion's share and have good business from license income. Everybody wants to be like Apple.
Of course their mastermind plan do not always works. In fact there are much more failures than very few sucess. Sometimes the "new market oppotunity" do not happen after all. That was what happend to UWB (Ultra Wide Band) fiesta about 10 years ago.
Is IOT/IOE real or marketing bluff? I don't know. Only time will tell. Who will be the winner of IOT? I could be millionere if I know :-) Perhaps different standard will be used in fragmented market segments - for example 802.15.4g + SEP2.0 for smart grid, Bluetooth LE for mobile application, some IP-based WiFi IOT for home appliance. There might not be single, universal, can-do-everything "holy grail" IOT standard protocol. Maybe.
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.