AUSTIN BOZOWSKI: Hi.
I'm Austin, a technical solutions engineer at Google.
We're very excited about the possibilities
that the Matter Protocol brings to smart home devices.
Together with my colleague Vinit,
we're going to explore the key tools and processes
of the development experience of Matter devices for Google home.
The tools demonstrated in this video
will be available at our developer preview in late June.
Throughout this video code lab, we'll cover environment setup
and building a virtual device; creating a Matter integration
for Google Home; the virtual device
controller, a graphical user interface
for controlling our virtual device;
commissioning our virtual device;
testing with the Google Home extension for Visual Studio
Code and the test suite; and finally, we
will cover the creation of new device types,
thus allowing you to begin development
of your own devices.
More information about Matter can
be found on the Google Home Developer Center or Connected
Standards Alliance website.
Our first step will be to set up our virtual device.
The virtual device is simply a program
running on a Linux host which emulates the networking
functionality of a physical matter device.
During the early stages of development,
using the virtual device offers a few advantages
over using a physical device.
Notably, through use of the virtual device,
a physical device is not necessary to begin
developing Matter devices.
When making changes to the device's characteristics
or features, it is only necessary to rebuild and rerun
the virtual device.
In the case of a physical device,
we must first produce a build for the device and reflash it.
Additionally, the virtual device also
offers convenient observability via terminal output.
There is no need to connect to and monitor
a device over serial ports.
Before we begin, we will need to install Docker on a Linux host
machine.
Once Docker is installed, we will pull a container image
which includes all dependencies necessary for building
and running a Matter virtual device.
Windows and Mac OS computers are currently not supported
by this Docker installation.
Instructions for manually installing and building Matter
without the container image can be found
in the Matter documentation.
Installing Docker is not covered by this video.
Please refer to the Docker documentation
to install Docker on your Linux system.
Now that Docker is installed, we may pull the virtual device
image.
In this case, we are pulling the image from Google Cloud
Container Registry.
Please refer to the published code lab for the latest
URL of the image.
In our video, the Docker image already
exists in the local cache and the pull operation
completes quickly.
However, expect that this step may
take a few minutes to complete when run for the first time.
Before starting a container, we run the xhost command.
This allows the x window system to receive connections
from local hosts on port 1,000.
Our container will use this address
to provide graphical user interfaces.
Now we will run a container using the pulled image
by providing three arguments to the Docker run command.
Dash dash IPC equals host allows Docker
to share the interprocess communication namespace
with your host machine.
Dash dash net equal host allows Docker
to use the host's network stack inside the container.
This is necessary to export display.
Finally, dash e exports your host's display environment
variable to the container.
X client programs running in the container
will then connect to your host's x server,
thus providing graphical user interfaces.
This is important to run the zap tool for editing Matter
clusters.
We will need to execute commands from within the container
to build and run our virtual device.
In a second terminal window, open
another interactive terminal session in the container
by executing bash in the Docker exec command.
Note that the dash it option runs
Docker with an interactive terminal instead
of in a background process.
Now that we have completed the setup of our virtual device
container, we may begin building our Matter device.
All Matter examples are placed in the examples directory
located within the route of the github repository.
There are several samples available
but our focus in this video will be on Chef.
Chef is a sample app that provides a terminal interface
and wrapping feature similar to those found in the app located
at example/shell.
It is also a script that conveniently encapsulates
several of the common tasks necessary for development
into a single command.
We will now execute chef to create our example device.
Chef has several options that can
be viewed by running the script with the dash each option.
Taking a closer look at the options
we are using in this example, we find dash t, which
defines the input device type.
We have chosen lighting, which is a single color light bulb.
Dash z invokes the zap tool.
This generates source files that implement the specified device
type.
Zap automatically creates code for our build.
This code defines the light being the data model
and its interaction with other devices the interaction model.
Dash b builds our device.
Dash r is optional.
This option enables RPCs on the virtual device
so that other components, such as a graphical user interface
can communicate with it.
Finally, dash t is the target platform.
Chef supports builds targeting Linux
and some physical chipsets.
Device builds targeting Linux may
be run by executing the application located
in the Linux Build Output Directory.
We will now execute the application.
Upon execution, we are prompted to enter a matter shell.
Once in the matter shell, we run the command,
onboarding codes on network to retrieve
setup information necessary for commissioning
our device over IP.
This is one of several commands available in Matter Shell which
allow us to analyze the state of our device.
We will leave our device running.
To ensure our device is accessible,
we will disable our firewall.
If you wish to leave your firewall running,
allow list TCP and UDP connections to port 5540.
The Google Home Developer Center Console
is a web application which centralizes integrations
with Google Home on Matter as well as
Smart Home and Local Home.
Any Matter device that has gone through Matter's certification
works with Google Home.
During development, we will create a project
which provides additional context for the device we
are developing.
After our device is certified and we launch our project,
the Google Home console will remain our hub
for all of the additional features Google Home offers
to Matter devices.
On the Manage Projects page of the Google Home Developer
Center Console, we select Create A Project.
We choose the option New Project and name our project
matter-test.
we open our new project and select Add Matter Integration.
The virtual device we built previously
was a lighting example.
Respectively, we will name our new device
integration Matter Light and select the device type Light.
Finally, we must now enter the vendor ID and product ID.
We populate vendor ID with 0XFFF1
and product ID with 0X8000.
Note that the vendor ids from 0XFFF1 through 0XFFF4
are reserved for testing.
Before launching your product, you'll
need to apply for a vendor ID from the Connected Standards
Alliance.
Offscreen, we will reboot our hub
to ensure that it receives the most recent actions project
configuration.
If you need to change the vendor ID or product ID later,
please reboot your hub again after saving the project.
The virtual device controller is a standalone application
that provides a graphical user interface
to control and display the states of matter
virtual devices.
The device controller issues remote procedure calls
to Matter devices in our development environment.
For the purpose of example, we will demonstrate installation
in our environment.
We begin by cloning the git repository of the device
controller.
Please refer to the published code
lab for the latest url of the virtual device controller.
Once our clone operation is complete,
we install dependencies and build the application.
We will launch the newly built device controller
by running electron main.js.
The virtual device controller has two options at startup.
Dash dash s followed by host pull
and port tells the controller to connect to a virtual device's
network socket at the specified host and port.
Dash dash d, followed by a serial port file address,
such as dev tty usb zero tells the device controller
to connect to a physical device over the specified serial port.
It is also possible to launch the device controller
with no option specified.
Under these circumstances, the device controller
will default to the network socket option using port 33,000
and host local host.
Observing the virtual device controller's interface,
we are treated to a complete representation
of our virtual device's state along with facilities
for updating that state.
Each time we update the light switch, brightness,
or color setting, the device controller
will send a remote procedure call to our virtual device.
Once every second, the device controller
will pull the device state and refresh the interface
accordingly.
Let's observe the device controller's behavior
when we control our device with the Google Home app.
You'll notice that the switch on the device controller
interface updates shortly after the light state is
toggled in the home app.
Conveniently, we may also retrieve the QR code
used in our virtual device's commissioning
flow from the virtual device controller interface.
We will open the QR code for our virtual device in this example
and leave it available for our next step.
We will now commission our virtual device.
Before commissioning our device, we
will need to verify that the following steps are complete.
A Google Home Mini, Google Nest Mini,
or Nest Hub second generation device, our hub,
is in the home network.
Our device is configured in the Google Home Developer Console
as we executed previously.
Our hub is paired with the same Google
account we use to sign in on the Google Home Developer Console.
Our hub is on the same Wi-Fi network
as the computer we are using to run our virtual Matter device.
And finally, our hub is in the same structure
we are using on our Google Home app.
Structure is the house on the Google home graph.
We will now turn our attention to the Google home app.
To begin commissioning our device,
we tapped the plus icon in the upper left corner.
Next, we select Set Up Device and New Device.
We select a home to commission our new device into and tap
next.
The app begins scanning.
We now choose the option CHIP Device.
Depending on when you were viewing this video,
look for an option that says Matter Device in the event
that you do not see an option for CHIP device.
We just scanned our virtual device's QR code.
You can retrieve this QR code from the virtual device
controller, as seen previously.
You can also retrieve the QR code from a web page
at the link seen below in our virtual device's terminal
output at startup.
Let's observe from the virtual device side
as the commissioning process completes.
Our virtual device has been successfully commissioned
into our home.
We will name our new device Office Light and Test Control.
The Google Home extension for VS Code
offers features and tools useful when developing Matter devices.
Note that the installation of VS Code and the Google Home
extension is not covered in this video.
Let's take a moment to examine the Google Home
extension for VS Code.
We select the Google Home icon on VS Code's activity bar.
We now select our project, matter-test.
In the Quick Access menu, we select Resources.
This displays links to resources helpful
throughout our development within the Google Home
ecosystem.
We will turn our attention to the Google Assistant
simulator in the lower left of the screen.
Issuing text commands and the assistant simulator
performs the same operations as voice commands
issued to the Google Home assistant on our hub or phone.
In our example, we will test the command Turn
On The Light, which updates the state of our virtual device.
Returning to the Quick Access menu,
we select the option Cloud Logging.
This opens the Cloud Logging logs viewer,
which contains a record of messages
flowing between the system and our device.
Expanding the different log entries
to view their full content, we can quickly
locate the success log for our previous intent
whilst turning on the light.
We now return to the Resources tab
and select the Home Graph Viewer.
The Home Graph Viewer allows us to view
all of the devices in the home graph within the extension.
Test Suite is a public tool that allows
us to self-test and validate our smart home implementation.
The test suite automatically generates and runs test cases
based on the devices and traits associated with our project.
Let's utilize the test suite on our virtual device.
In the Developer Center Console, we
navigate to the test tab on the left menu.
In the device settings to the right,
we click on the test button to launch Test Suite.
The devices associated with our project
are listed in the resulting screen.
We select our light bulb.
We confirm the test cases will run and start the process.
Test Suite then generates test cases for the selected devices
and executes the test.
Failing tests will be marked in red.
In our final exploration of the matter development
process and tooling, we will create a new device type.
We will do so by editing the Zapp file previously used
to generate our virtual device and change
the device from a light bulb to a matter sensor which
measures temperature.
A ZAP file is a JSON file that contains the data model
configuration of clusters, attributes, and commands
that are enabled for an application.
A ZAP file can be created using the ZCL advanced platform
or ZAP tool.
The ZAP tool is a third-party tool
offering a generic templating engine
for applications and libraries based on the Zigbee Cluster
Library.
This tool is included in the Matter repository
as a submodule.
We begin by launching this ZAP tool from the command line
and providing the light bulb's app file as an argument.
The ZAP tool may be launched directly or from chef
with the appropriate flags.
The ZAP tool's Zigbee cluster configurator window appears.
We don't need to make changes to endpoint 0
as it contains the root node.
The temperature sensor will also contain the root node
with the same information.
We select the edit button of endpoint 1.
In the dialogue that appears, we select matter temperature
sensor 0x302 and click on Save.
The required clusters for the temperature sensor device
will be selected on endpoint 1.
But confirm in the specification the right configuration
for your device type.
Some clusters, attributes, and commands are optional.
And there are changes in the specification that might not
be reflected in the tool.
Moreover, feature flags should reflect the capabilities
of your device.
We set the filter to show enabled clusters.
Now the list only contains the selected clusters.
We click the blue gear icon to edit the cluster's attributes
and commands.
You may edit whether a cluster server
or client is individually enabled
by selecting the enable column.
You may also set show back to all clusters
and individually add or remove clusters
to or from this endpoint.
In the upper left hand menu, we select File, Save As.
We save the configuration file in example/chef as temperature
sensor.zap and exit the tool.
We have now created a new Matter device type.
Now that we have completed the creation of a new device type,
we can step back through the previous sections of the code
lab and iterate on our design.
We may start by asking the assistant emulator
for the reading of the sensor in the Google Home
extension for VS Code or by executing the array of tests
already available to us in the Test Suite.
To iterate on our design further,
we may relaunch the ZAP tool, update our device,
and rebuild it.
This concludes our exploration of the tools
and processes fundamental to the development
experience of Matter devices for Google Home.
We hope that you enjoyed watching this video
and are excited by the Matter protocol's integration
into Google Home.
As a reminder, the tools on display throughout this video
will be available in late June.
Please continue referring to the Google Home Developer Center
for more information on availability, timelines,
and documentation.