Delivering on the Promise of the IoT with Dotdot + Thread // Part Two

Part two of a two-part series on how Dotdot + Thread are delivering on the promise of the IoT.
Part one: Bringing the Internet’s foundational technologies to the Internet of Things (click here)
Part two: How Dotdot + Thread breaks down the walled garden and drives value for manufacturers, platforms, and every IoT stakeholder

By: Daniel Moneta, EVP Corporate Development, MMB Networks | Marketing Workgroup Chair, Zigbee Alliance | Marketing Workgroup Contributor, Thread Group

How Dotdot + Thread enables innovation and scale

My home is set up in a way that’s probably familiar to many of you. I’ve got about 20 smart home devices. Some joined to third-party IoT hubs. Some connected to their own bridges and apps. All connected up into each vendor’s cloud service, each with its own proprietary API. These are then linked to some other cloud service used by a controller like an Amazon Echo, Google Home, or smart home app.

Just thinking about the engineering calories spent developing all those APIs and then gluing them together just to make a light turn on and off makes me cringe a little. What makes me cringe even more is given the amount of constant change amongst all those interfaces, even with constant effort by every vendor to keep up, at any given time almost every device I have hasn’t worked for a bit (or even a moment). As the number of devices I have goes up, the probability of something being broken at any time approaches 100%. Thanks to my Alexa or Google Home, I now have a happy voice reminding me of exactly what’s broken every time I turn the lights on.

This is not scalable, and this is not something the market will accept — be it consumer or commercial. We can’t expect users to remember the organizational charts in their head of how all their devices connect to each other, just so they can troubleshoot when something goes wrong. Most heartbreaking is that it requires all of us, as users and industry members, to spend so much time simply gluing devices together, instead of spending our time creating new value and innovating.

Universal, open standards solve this. With Dotdot, you don’t have to build and mature your own protocols from scratch, and your device will be able to talk to any other Dotdot device right out of the box. If you’re an ecosystem vendor, that means you can build gateways, smart speakers, smart home apps, or IoT management platforms without having to manually integrate each new device with some kind of proprietary driver or skill. With one implementation, you can add support for any Dotdot-based product, and your customers can choose the products they want. Dotdot’s support for native, device-to-device interoperability means your platforms can talk directly to devices rather than going through cloud services. This eliminates the most common points of failure and increases responsiveness, security, and reliability.

If you’re a device vendor, it means you can build a device once and deploy it to multiple ecosystems and markets, without having to build drivers, skills, applets, or plugins, and constantly keep up with a changing landscape of APIs. You can focus on your product and creating new value for your customers.

All that gets even more interesting with Dotdot over Thread’s IP network.

Delivering on the promise of the IoT

The promise of the IoT was a win for all stakeholders. Product companies would now have closer relationships with customers than ever before, replete with invaluable data about their product use and maintenance, platforms for services they could monetize, and more. Users would have a home or business full of smart devices that they could combine and use in limitless combinations. And there would be a healthy ecosystem of innovative platforms and “killer applications” to connect all these devices in new, exciting, value-creating ways.

This vision hasn’t really been achieved yet, and getting to any of these outcomes has required significant effort and compromises.

Most IoT devices on non-IP networks have to be connected to some kind of gateway that is tied into a third-party platform and user interface. That traps them behind a walled garden and cuts them off from their manufacturer, meaning no valuable data for product vendors, and no way to easily add new features and delight your customers (or even just keep up with the market).

On the other side, companies that own that gateway, like telcos and security companies, now have to struggle to provide every feature users want at the rapid pace of the market, because they’re the sole interface through which users interact with their devices. So far, they’ve struggled to do so. Most smart home platforms, for instance, haven’t really evolved much from their initial feature sets.

For their part, users have to choose which ecosystem they’re going to commit to, with extremely high switching costs. Any new applications or innovations that aren’t tied into that or replicated by their ecosystem vendor? Too bad.

Not a lot of flexibility for anyone here.

Some vendors try to circumvent this by vertically integrating their whole product. Device, bridge, cloud, app. But then, you have to do everything — a never-ending battle to keep up with features that aren’t your core competency, and users constantly demanding compatibility with new ecosystems and apps that you must integrate with and support via a growing list of cloud APIs.

Thread’s IP connectivity enables all of these use cases without compromises. On an IP network, where devices are a part of the local network or on the Internet, relationships between devices aren’t one-to-one, and aren’t trapped behind walled gardens. A device can both “call home” to provide data or participate in services, while also talking to other apps and services — whether local or remote — that the customer might want.

For instance, your light bulb can report back to your service for lifecycle and usage data, but the user can still download that new music app that syncs with lighting, and it will just work— without having to marry the services together. Manufacturers can offer as much or as little by way of features and interfaces as they feel appropriate, focus on what they do best, and not have to be everything to everyone.

With everything speaking the same language using Dotdot, a third-party ecosystem of innovative applications can evolve. This is because developers can now create applications — from commercial IoT platforms to mobile apps — that can work natively with all users’ devices. If this sounds familiar, it should, because this is what happened in the smartphone market. When we went from feature phones that required handset manufacturers to develop every feature on their phones, to common platforms that abstracted the underlying hardware, innovation took off and we finally got to see all those killer apps.

The open IoT is for commercial, too

I’ve been talking a lot about the consumer space, but commercial is also important. Dotdot + Thread enables scalable flexibility in the commercial space as well. Devices that all speak the same language and are on the same network make it easier to manage, especially for smaller facilities.

At the same time, larger ones might want to separate devices into different operational networks with different management or security levels, but still leverage the strength of the mesh. Dotdot + Thread enables this too. While both Dotdot and Thread can be used for commercial applications today, both the Zigbee Alliance and the Thread Group are working on further commercial implementations and extensions of Dotdot and Thread to address use cases unique to the commercial market.

How to start working with Dotdot + Thread

Thread specification is already available and the Dotdot specification is available to Zigbee Alliance members with certification and testing going live soon. Right now, the best way forward is to join both organizations, get access to the early specs, and see how your peers and the industry are moving forward with Dotdot and Thread.

It’s also worth mentioning that if you are already building Zigbee devices (or plan to), you’ll be ahead of the game. Zigbee and Thread use the same hardware from most 802.15.4 silicon vendors, which means you can address multiple markets and use cases with the same product. If you already know Zigbee (or know a company like mine that is an expert at implementing it), you already know Dotdot and can hit the ground running.

If you’re looking for more information or have questions about all this, please reach out to me, or talk to our friends at Thread and Zigbee Alliance.

Zigbee: [email protected]
Thread: [email protected]