So you’ve just finished building your prototype Internet of Things (IoT) device. It doesn’t look slick yet, it’s still a bit bulky and all devices still connect over WiFi; but these are problems that can be fixed before production. What matters is you have a working, fully functioning prototype and both you and your investors are very excited. But you’ll need more than excited investors if you’re to move from a company with a successful prototype to a company with a successful product. You will need a quality product that looks professional, is easy to use and provides real value for your customers. But to do that do you really need to address WiFi as an issue? Well maybe not. But then again maybe.
You’re probably thinking by now what’s so bad about WiFi? And the answer would be absolutely nothing at all. WiFi is an excellent wireless communication tool that has served the technology industry well. However, like all tools there are use cases that suit them and use cases that do not. Hammers for nails and screwdrivers for screws is a good, if not oversimplified, analogy.
So what is WiFi good at?
WiFi is an excellent wireless communication medium for transporting high bit rate data – for example audio or video or rich web content. However, there is a cost for this high bit rate data transfer. Specifically, there is a power cost associated. If we wanted low power consumption and could afford to sacrifice bit rate for it there are other technologies that may be more suitable.
BLE, ZigBee and Z-Wave
BLE, ZigBee and Z-Wave are all low power WPAN technologies. And although exact comparison of energy consumption is application dependent, these technologies represent lower power (but also lower bit rate) alternatives to WiFI. In fact, in a presentation for the ZigBee Alliance Ryan Maley reported the hourly energy consumption of ZigBee device is only 1/100,000th of the consumption a WiFi device. And a ZigBee Green devices energy consumption is only 1/100th of the consumption of a ZigBee device.
What about data transfer rates? Data transfer rates for ZigBee range from 20kb/s to 250kb/s. The maximum for BLE is 260kbps. And Z-Wave is 100kpbs – whereas WiFi 802.11ac can achieve hundreds of Mb/s.
So what Wireless technology should I use?
If you want a high bit rate where high power is acceptable, then you should use WiFi. And if you want low power where low bit rate is acceptable, then you should use BLE, ZigBee or Z-Wave. But if you’ve chosen one of the low power options you will then have to select a specific technology. Let’s consider the features of the different technologies.
All the technologies can support energy harvesting applications – that is they can be included in projects that are not powered by batteries/cabled power but rather by technologies such as solar or piezoelectrics.
Both ZigBee and Z-Wave support mesh networking. This feature has made them particularly useful in applications such as home automation. In fact, Nest have a ZigBee antenna in their smart Thermostatand Protect systems. The use of mesh networking means that these protocols can extend their tranmission range by using the nodes of the network as intermediaries to a transmission between two devices that would be otherwise out of range. BLE doesn’t currently support mesh networking. However, the Bluetooth SIG announced recently that they had formed Bluetooth Smart Mesh Working Group. So BLE will have mesh networking support but they’ll have to catch up with ground ZigBee and Z-Wave have already made in the market.
But it’s not all bad news for BLE. According to a CEPro blog comparing the technologies for home automation, Bluetooth modules are much more affordable than ZigBee and Z-Wave. With the average cost of a module for Bluetooth coming in at $2.50 and for ZigBee and Z-Wave at $4 – $5. Small costs for a once off product but don’t forget you when you’re a successful IoT company you’ll want to ship millions of devices.
So in answer to the question of which to choose? Well that’s a decision for each product developer who will have differing constraints to every other developer and there’s also interoperability (which wediscussed previously) to consider. But at least now we’ve established some of the facts so we can start thinking about what wireless technology our product should really use.