(upbeat music)
- Hi, everyone. I’m Kevin Po, a Senior Product Manager on the Nest team.
I’m here with Don Darling,
also a Staff Technical Solution Engineer on the Nest team,
to share how you can get started with Project Connect Home over IP, AKA CHIP,
a new smart home protocol we’ve been developing
with the smart home industry that will launch later this year.
We’ll begin with insights into the smart home industry and why CHIP exists.
Stepping back, the smart home ecosystem has had tremendous growth in the past few years,
with over 100 million devices connected to Google
across many verticals such as lighting, entertainment,
comfort and energy, security, and more.
We see an average of nine smart home devices per home
with the industry growing to an estimated $53 billion in size in 2022.
Though the growth’s been exciting, headwinds are acknowledged by the industry
preventing faster growth & fulfilling all our users’ needs.
Specifically, the smart home just doesn’t work yet.
Users are frustrated knowing if a new smart home device
is compatible with the devices used every day.
Even if they can interoperate, integration setup is complicated and inconsistent.
The underlying issue driving this problem is the connectivity protocol fragmentation
enabling these devices to speak to each other,
with competing protocols vying for adoption by users and device makers.
Device makers are particularly challenged since they need to manage costs
and time-to-market to support these protocols that users want.
In many cases, the stacks are lightly differentiated
but need engineering resources to build,
making it hard to invest in deeper feature differentiation
to unlock more value for users. CHIP intends to solve this problem
via a protocol that can integrate into smart home products
we hope can be widely adopted.
It provides baseline connectivity for discovery, setup,
and control of smart home devices.
With this baseline connectivity, as an industry, we can give users the choice
to have these devices interoperate the way they want.
To show compatibility and reduce purchase frustration,
a CHIP brand and marking will be used on products.
We founded CHIP with key industry partners in the Zigbee Alliance in December 2019.
The team has been hard at work at leveraging these technologies
and learnings from the past decade with IP as a centerpiece of the standard,
which allows us to truly have an Internet of Things in the home.
The new standard intends to improve smart home interactions in three key areas.
The first is around baseline setup,
where the underlying technology support, QR codes,
BLE, and Wi-Fi Soft-AP to help with simpler onboarding
and proof of possession during setup. The second is around interoperability
where device makers need to support one protocol
to communicate with many ecosystems. Lastly, reliability & security are improved
with IPv6 being a core enabling technology in the protocol.
Modern security practices are applied, like certificate-based device attestation
and PAKE-based algorithms for pairing. Since the kickoff in December 2019
we’ve had rapid progress building the standard.
For instance, we have three subgroups
focusing on technical, certification marketing areas
and over 30-plus teams driving their definition.
This is a massive undertaking
with over 160 organizations and over a thousand individuals involved.
The open-source repository John will describe further
already has over 2,800 commits.
The key devices for initial support are selected in areas like lighting,
access control, HVAC, and more.
With this hard work, we expect to land the specification
and certification program launch by late 2021.
With that, I’ll hand it over to Don
to go into more detail about the connected home.
- Hello, and welcome to our introduction to Project CHIP.
My name is Don, and I’m a Technical Solutions Engineer
at Google Nest, focusing on IoT.
If you’re like me,
the number of IoT devices in your home is growing rapidly.
There are connected TVs, speakers,
and now even appliances like refrigerators, washing machines, and stoves
all connected to the Internet.
Some devices connect directly to Wi-Fi. Most of us are familiar with how this works
since they connect to Wi-Fi in the same manner
that you would connect your laptop, phone, and other devices you frequently use.
Wi-Fi requires more power than other radio types like Bluetooth or Thread.
And you’ll notice that devices that make heavy use of Wi-Fi,
like smart TVs, are typically plugged into the wall
for a good source of power.
Other devices like your door lock and the alarm sensors in your windows
are designed to run on a battery for two to five years.
Wi-Fi power requirements cannot be met here,
and a low-power solution is needed.
These devices use-low-power radios and the IEEE 802.15.4 protocol
to form a peripheral network, or a low-power and lossy network.
This is what is used by Thread and Zigbee devices today.
There are a couple of noteworthy differences
between a Wi-Fi network and a peripheral network.
First off, a hub is required to pass messages
between your peripheral network and your Wi-Fi network,
and ultimately, the Internet.
The blue lines here show peripherals connected to a hub,
and the red line shows the hub’s connection to the Wi-Fi router.
A peripheral network can operate as a mesh to accommodate lower signal strength
and expand the range of your network.
In this example,
the thermostat is routing messages between a light bulb and the hub.
Although the thermostat is designed to be a low-power device,
let's assume it's wired to the HVAC system power
and has no design constraints preventing it from routing messages.
Whether or not a device can route messages is at the discretion of the device maker.
In this case, the lock could benefit
from routing messages through the window sensor,
but the window sensor doesn't perform routing,
since it needs to maximize its battery life.
Devices like window sensors and locks are often called sleepy end devices.
Project CHIP standardizes on Thread for peripheral networks,
which, among other things, uses IPv6 to communicate between devices.
This provides a consistent, well-proven transport
across your Wi-Fi, peripheral, cloud, and mobile networks.
All right, so let's dive into device development.
Although the first stable version of the CHIP specification has yet to be released,
the source code for Project CHIP is public and available to everyone.
This source repository is active,
with frequent contributions for popular development boards
and common device types.
There is plenty to dig into
to get a preview of CHIP device development
and you can run functional examples today.
Remember, CHIP device development and ecosystem deployment are separate,
which allows me to walk you through the basics
of building and running a simple lighting application
that could potentially be deployed anywhere.
Project CHIP is publicly available on GitHub
and it’s released under the Apache 2.0 license.
You can visit the link in this slide to go have a look.
Within the examples directory,
you can see a variety of different device applications
with support for boards from Espressif, Silicon Labs,
Nordic Semiconductor, NXP, and others.
I'm going to give you a brief walkthrough
of building and running the all-clusters-app on an Espressif WROVER kit.
We'll be using it to demonstrate a simple on-off operation
for something like a light bulb.
If you wanted,
you could use it to turn anything on and off using a GPIO pin,
but today, we’ll be toggling a virtual LED on its built-in display.
Although this will not be a complete codelab,
my goal is to familiarize you
with the steps you’ll be taking to get started
and show you how easy it is.
You’ll start with the BUILDING.md file in the docs directory.
This will instruct you to install the build dependencies for your operating system
and to check out the source code.
In this presentation, I’ll be showing steps for a Linux workstation,
but MacOS is also supported.
Next, you’ll run a script to initialize your build environment.
You'll see some nice ASCII art, some informational messages,
and finally a message that you are ready to go.
Before you build any device application,
you’ll want to build the CHIP Client Example,
called chip-tool.
You’ll run this on your host machine to communicate with your device via the network.
You'll find chip-tool within the examples directory
and will follow the instructions in the readme.
In many cases, Project CHIP uses the gn/ninja build system,
making build operations on the host as simple as what you see here.
Next, we’ll switch over to the all-clusters-app directory,
which is also under examples,
and then go into the board-specific esp32 directory.
Once here, the first thing you will do
is install the toolchain for your Espressif board.
Application developers have done an excellent job
documenting exactly what to do to build a sample app for a board,
right in the Project CHIP repository.
I've rarely needed to go to a manufacturer's website
and hunt for information just to get started.
It's all right there.
For this application,
Espressif requires you to check out their tools from their GitHub repository,
set an environment variable, and run their install script.
The All Clusters example supports multiple boards and pairing scenarios,
so you need to configure it before you build it.
When you run idf make menuconfig, you’ll be presented with a text interface
to configure application options.
Here, we’ve selected the WROVER kit as the board that we’re using.
And since we're not pairing it to an ecosystem,
we've disabled rendezvous mode, and will specify the Wi-Fi SSID and password
When configured this way,
the device will automatically connect to our Wi-Fi network when it boots,
and this will allow us to communicate with it without pairing it first.
Note that this step disables critical security features,
and devices should only be configured like this during development.
Next, we’ll build the application by running idf make.
To flash the application to your board,
you need to connect it to a USB port on your workstation,
and then run idf make flash.
And when you do this, you specify the USB tty
for the connected board.
Once the device is flashed, power cycle it.
If you connect a serial terminal to the same USB tty,
you will see logs as it boots up.
The important thing to watch for is the message saying the server is ready,
and what IP and port it is listening to.
Finally, we'll use chip-tool, which we built earlier,
to send commands to the device
that toggle a virtual green LED on the screen on and off.
The picture here shows you where to find the virtual green LED on the display.
Note that when running chip-tool,
we’re specifying the IP address and port number
we saw in the previous slide when booting the device.
The device is also showing the standardized QR code for CHIP devices
which allow it to pair using the camera on a mobile device in other pairing situations.
And that's it. You now have a functional CHIP device.
Now I’ll hand it back to Kevin to wrap things up.
- We hope you’ve enjoyed our introduction to Project CHIP
and encourage you to look at the GitHub repo to play around with the protocol.
It's an exciting, fast, and easy new way
to develop interoperable smart home devices.
Join the Zigbee Alliance if you’d like to build certified products with the technology.
We’re thinking of new features with our partners to add to the protocol
as well as new device types.
To learn how to take your devices’ integrations to the next level,
check out our other smart home sessions to learn how Google can help you.
Thank you.
(upbeat music)