Zuli Smartplug is a Bluetooth Low Energy (BLE) smart outlet that, like most smart outlets, sits between a standard outlet and whatever you plug into it (e.g. lamp, oven, coffee pot). This allows users to:
- Turn devices on and off from a smartphone.
- Monitor energy consumption.
- Conserve energy by eliminating standby power (provided, of course, that the standby power of the device is greater than the energy needs of the smart outlet).
The market for smart outlets is getting crowded. To distinguish itself, Zuli is promising “location based automation,” which would detect when the user has left the room and turn off the lights and appliances automatically.
The feature is clever, I’ll give them that. Unfortunately, the technology they claim to use does not support the implementation they describe, so either they’re misguided or Zuli is far more complicated (and therefore difficult and expensive to design, test, and manufacture) than they claim.
< DIGRESSION >
I’ll confess, it’s been a struggle to take “smart appliances” seriously. The whole concept could have been ripped from a technology-for-technology’s-sake Home of the Future exhibit, one narrated with enough 1950s wholesome enthusiasm to make you gag. I know the real driving force is energy efficiency, but big fish like GE, Samsung, and Whirlpool are un-ironically selling internet-connected washing machines as if someone might actually need to start a load of wash remotely. (Stop. Just think that one through for a second.)
With no common interface for smart appliances, manufactures have an insurmountable advantage over third party hardware and software. With direct access to their proprietary interface, someone at GE can implement a “preheat the oven on your drive home” feature for their smart oven, while Zuli can only cut and restore power to the whole box. Still, because appliances are too expensive for most of us to replace with every iteration, there’s still a market for cheap, generic, “buy once, work everywhere” solutions like the smart outlet.
Because they restrict power to a device, smart outlets work great for simple things like light bulbs and irons. However, it gets complicated when sudden, unexpected power loss is harmful as it is for many more complex electronics. The onus is on the user here – an outlet has no direct knowledge of what it’s connected to – and though Zuli and other outlets are not explicit about what liability they accept, I think it’s safe the assume the answer is none.
< / DIGRESSION >
OK, back to Zuli’s location automation feature.
From their Kickstarter pitch, a single Zuli connected to your favorite lamp will let you monitor its energy consumption, dim it from the couch, and schedule it to turn on 10 minutes before you expect to be home (just like every other smart outlet). However, if you buy 3 or more Zulis, they form a “Bluetooth mesh network which allows them to talk to each other” and enables a location algorithm to automatically turn lights on and off when you enter the room.
Unfortunately, the Bluetooth Low Energy protocol does not support mesh networks. A device is either a master or a slave, not both simultaneously, and if it’s a slave (like Zuli), it can connect to only one master at a time.
Does that undermine the fundamental premise? No, not really. One can imagine a simple implementation in which a Zuli turns off when the phone walks out of range. It’s simple in principle, but difficult in practice – translating radio signal strength into location is a difficult problem to solve reliably. For example, if you rearrange your furniture and a Zuli suddenly finds itself hidden behind a couch, you might find lights turning off sooner than you expect.* It also means that your lights will turn off mid-house party if you and your phone step away to the bathroom for some alone time with Reddit.
There are certainly other technologies they could be using, but the creators leave no doubt that Zuli uses Bluetooth Low Energy:
That leaves a handful of interpretations:
- The creators do not understand the radio protocol they’ve chosen to use and honestly believe that Bluetooth Low Energy supports mesh networks.
- They’re planning to get Bluetooth certified under the recently ratified 4.1 specification, which permits simultaneous master-slave operation for low energy devices. Although this change enables more complex network topologies within BLE, I am aware of no radio IC that implements this feature.
- If they are using an uncertified off-the-shelf part, they’re betting the farm that it will pass certification testing prior to launch.
- If they planning to spin their own implementation, they’ve undertaken a huge project for 3 recent grads and a “hardware junkie.”
- They’re using BLE for Zuli-to-smartphone communication and a separate radio protocol for Zuli-to-Zuli communication. Although it’s perhaps the cleanest solution, it significantly complicates the hardware design, layout, testing, and FCC certification of a product they’re promising to ship in June 2014.
None of these interpretations inspire confidence in the team or the project.
I was hoping their video demonstration of the location feature would provide clarity, but it just raises more questions. For one thing, their documentation is very clear that the algorithm requires 3 smartplugs, but only 2 are used in the demo.
Now I’m almost certainly being paranoid, but since we’ve already established that some sleight-of-hand is going on in the video, doesn’t it seem like the lights are perfectly timed to his speech? There’s no evidence of someone behind the scenes flipping a switch (or something similarly fraudulent), but there’s no doubt this particular demo is tuned for the specific size and layout of their office. I seriously doubt I would get the same results in my apartment.
Anyway, while we’re still on the subject of radio technologies, almost all smart appliances and smart outlets are internet-enabled, but not Zuli. It’s a glaring omission in a market echoing the same sales pitch: you leave home in a hurry one day and can’t remember if the hall light was left on, wouldn’t it be nice to be able to check from you smartphone?
The only radio technology that Zuli claims to use is Bluetooth Low Energy, which means Zuli must be in direct radio contact with your smartphone for their app to work. That means you might be able to switch things off from a few rooms away, maybe even from the driveway, but certainly not from the office.
Zuli’s marketing toes a fine line here. They’re careful to not explicitly promise any use scenarios that would require internet connectivity, but they choose phrases that might imply it to a less tech-savvy consumer or someone reading quickly:
I can’t prove anything, but the whole thing seems fishy. With 6 days to go and $40k still to raise, Kicktraq projects them falling just short of their $150k goal, but a last-second marketing push could change that. If it does, I hope that push includes answers to some of these questions.
*To learn more about the challenges associated with using radio signal strength for indoor localization, I refer you to an article linked by reader ay. Read his full comment on our review of Lapa, a BLE location tag that has met its funding goal and promises to ship in February 2014.
Mesh networks can be formed over bluetooth and there are actual software implementations one can use. There is actually plenty of research on the subject. Here is a good starting point: https://www.google.com/search?q=aodv+bluetooth.
I have myself worked on using AODV routing over bluetooth for a multiplayer mobile game (in the days when internet was not widely available on mobile phones, but bluetooth was). It is an easier problem when the devices are fairly static, as the smartplugs would be – once the ad-hoc network is initially formed, routing becomes fast enough to serve the smartplugs’ purpose.
Which is not to say that the Zuli smartplugs actually work this way, but it is not technologically impossible, as you present it.
That’s certainly true for the Bluetooth Classic protocol, but Zuli is clear that it’s using Bluetooth Low Energy. The BLE “piconet” is simpler specifically to put fewer demands on peripherals to help them conserve battery life.
It’s certainly possible they have a dual mode radio chip and are using BLE for communication to a smartphone and Bluetooth classic from communication between Zulis. Alternatively, they’re using Bluetooth Classic for everything and just have their marketing wrong.
It’s much easier to use timing, rather than signal strength, to do location awareness. All the phone needs to do is send out timestamped messages to the devices and await replies. The average reply latencies can be compared to each other for extremely precise location within the triangle formed by three devices, and can give fairly accurate directions even when outside said triangle.
Because science.
Because BLE transmissions are discretized in time, the reply latency will just be the time until the next connection event, a value uniformly distributed between 0 and the connection interval.
Even in principle, this approach is not practical. Here’s a thought experiment:
A radio signal traveling at the speed of light will cover roughly 1 foot per nanosecond. In other words, if we assume zero delays in hardware or software, that signal will take 1 nanosecond longer to reach my device for every additional foot away it is, or 2 nanoseconds longer round trip.
Meanwhile, let’s say our device uses a 7.5 millisecond connection interval, the shortest allowed by the BLE spec. Moreover, let’s assume that our timestamped message is guaranteed to be transmitted by the phone (and received by the device) in the next connection event. That’s between 0.0 and 7.5 milliseconds of variability introduced by the protocol specification alone, or 7.5000000 milliseconds of noise on top of our 0.0000020 milliseconds of signal per foot of distance. And that’s for the completely unrealistic “best case.”
Let’s take it one step farther and imagine our timestamp is the exact moment our packet is sent. The BLE spec mandates we use an oscillator with no worse than 20 ppm accuracy as our clock source, which works out to 20,000 nanoseconds of drift per second of operation. Even if we could perfectly synchronize the clock of our device to our smartphone, they wouldn’t stay synchronized to our level of precision for longer than a few connection events.
Because engineering.