WAYNE PIEKARSKI: Welcome to the Fireside Chat
for Brillo and Weave.
I hope you've had a great day seeing all the talks here
at the Ubiquity conference.
As you can see, we've had a whole bunch
of really cool information just come out today
about Brillo and Weave and all the exciting possibilities
that it has.
My name's Wayne Piekarski, and I'm
a Developer Advocate at Google.
I work with the product teams to communicate information
to developers and also feed information
back to the product teams to help make our products better,
and so forth.
So we all work together, and we run events like this,
and so we hope you found it very useful.
What we thought we'd do is have a session where we can sit down
with some of the important people on the Brillo and Weave
team-- talk to them about what makes
them do the things that they do, and what they find interesting,
and what kind of ideas that they have.
So today, we have three speakers.
We've got Ryan Cairns, we've got Paul Westbrook,
and we've got Guarav Shah.
And what I'll do is I'll start off
by just asking them to say a little bit about what
they do at Google and what their important role is.
RYAN CAIRNS: Sure.
My name's Ryan.
I'm an engineering director.
I run the Brillo and Weave project.
I started the project about three years ago.
And I take care of all the engineering stuff.
PAUL WESTBROOK: My name is Paul Westbrook.
I'm the engineering lead of Weave.
We're focusing on the mobile device side and server
side of Weave.
GUARAV SHAH: Hey, I'm Guarav.
I'm the engineering lead for Brillo.
WAYNE PIEKARSKI: Cool.
Thanks.
I was hoping with the Fireside Chat,
we'd have an actual fireplace here.
But we don't have that.
They wouldn't let us run a fireplace screen on this thing.
Anyway, today we had the little pet feeder during the keynote.
That's something where I was like,
you know what, I really want this pet feeder,
because it solves a problem that I have.
And so I thought it would be a really cool question to ask.
What magic device have you always wanted
that, now that we have Brillo and Weave,
you maybe could build-- or someone else could
build-- and sell it as a product or whatever?
What's something that's exciting?
Guarav?
GUARAV SHAH: I guess my dream project is, all the walls are
screens, and it's easy for me to project anything
on any of the screens, or rather, the walls.
So that's what I would like to be able to prototype.
WAYNE PIEKARSKI: I guess some of these little boards
were giving-- they have like, little HDMI ports on them,
so you could do something like that pretty easily.
GUARAV SHAH: Absolutely.
And you can also drive LEDs and LCD screens via the [INAUDIBLE]
WAYNE PIEKARSKI: Yeah.
Actually, one of my colleagues had
this cool project where they were
controlling strips of lights and they were blinking,
all kinds of things.
And there's all kinds of cool possibilities of little things
you can do that doesn't require a massive screen,
but you can use really cheap little components
to make something interesting.
GUARAV SHAH: Yeah.
Definitely.
You can daisy chain them, and yeah.
Pretty exciting.
WAYNE PIEKARSKI: Cool.
What about you, Paul?
PAUL WESTBROOK: One of the things that I want to build
is something to control my garage door.
Because oftentimes, I will-- I'm always
worried about leaving it open.
RYAN CAIRNS: Well, then you just drive your car
and come back home and check again, and then drive off.
Right?
PAUL WESTBROOK: Well, that, but then-- you're wasting gas.
But the other thing is making sure the lights turn
on and off, especially to detect presence.
WAYNE PIEKARSKI: I was thinking I've always wanted something
where it's like-- what's the state of all the doors?
Show me every time they opened, show me
a log or something interesting like that.
Because the door may have been opened unexpectedly
or something like that.
Yeah, it's interesting.
What about you?
RYAN CAIRNS: For me, it was really--
I was working on Chromebooks at the time,
and we were doing a bunch of Wi-Fi stuff.
And I really wanted a Wi-Fi router that was easy to use.
So I'd kick that product off.
And then, beyond products, one of the reasons
that we did Brillo and Weave in the first place was we
just saw people wrestling with the same set of problems
over and over again.
Google was getting into doing hardware.
Everybody was fighting to figure out, OK,
what Wi-Fi solution do I need to use?
What Bluetooth solution do I need to use?
How's auto-update going to work?
What's my security story?
And we already solved a bunch of that
stuff, so we were looking at, how do we package that up
for people?
That was really my goal with this.
WAYNE PIEKARSKI: Yeah.
Security is an interesting thing.
Because I always have this terrifying thought of, well,
if my heater is controlled by my computer, and someone hacks
into it, they can set my house on fire or something like that.
So security seems a really big deal
that you really have to get this right.
And so, what kind of things are we
doing to make sure that security--
because it seems like that's like the number one priority
for a lot of things nowadays.
So what are we doing to make it really awesome?
RYAN CAIRNS: There's a few things.
At a high level, we're working on some platform security
features in the OS, and we'll let Guarav talk
about that in a second.
We're enabling software updates, because we
don't think that you can have a security solution with devices
being fixed in the field.
You always need to be able to push new code to them.
And then on the Weave side, I'll let Paul talk
to what we're doing about local authentication and things
like that.
GUARAV SHAH: So yeah, I can speak to the Brillo side.
Interestingly, before I was working on Brillo,
I was working on Chromebook security.
And we ended up designing a very defense in-depth model
for building a very secure device.
And that's pretty much been verified time and time again
based on various security competitions and intrusion
detection-- the performance of Chromebooks
at these kind of events.
So for Brillo, I think there are a couple of things that
are in boat on the platform.
So verified boot, which makes sure
that you're not running malicious code on your device.
I think that's a core part of the security,
and we talk about verified boot starting
from when your device boots up, so all the code that runs
is verified.
Then the other thing that you want to enable
is, we want to enable sandboxing and other mechanisms that
are default on and that are very easy to use.
So we have kind of build a lot of the same technologies
that Android already has, plus some of the things
that we designed for Chromebooks,
like second BPF and other sandboxing mechanisms.
These are a core part of Brillo.
The final part that Ryan alluded to is updates.
We really feel that updates are really
a core part of building a secure device,
because anything you build, any software you write,
it's always going to have bugs.
And being able to update this device in the field,
and doing so in a way that is very seamless, non-destructive,
error-free is very important.
And so update is a core part of Brillo security as well.
WAYNE PIEKARSKI: I guess one other thing
is that a lot of OEMs will make a device,
then they just forget about it, whereas at least Google
does some of the work of doing the security patches.
And you can just pull down updates and build it out
without having to have your own team maintaining all these.
You don't have to worry so much about security.
GUARAV SHAH: Yeah.
I think a large part of why we don't see a lot of updates
happening in the field is that it's kind of always the device
side, the device software.
But there's also infrastructure for running updates,
for actually serving the updates, for managing updates.
And with Brillo, we are making that something that
is the same infrastructure that we use in Google,
for Chromebooks and other devices,
and we are making that available for developers
to use for their devices.
So I really feel like that really
makes updates a no-brainer, if you're
building a connected device using Brillo and Weave.
WAYNE PIEKARSKI: See, I've got to focus on feeding dogs.
I don't want to worry about all that stuff.
RYAN CAIRNS: Just to add to the update story--
one of the big things is like, when people are shipping
devices that don't update themselves--
the whole internet is moving forward all the time, right?
People are building new code.
So those devices are just going to break over time.
They're going to bit rot.
The user is going to buy an experience today,
and in a year, that experience is going to be broken.
And what we really want to enable
is an always up-to-date, always working experience,
for devices that get better, as opposed to degrade over time.
WAYNE PIEKARSKI: Yeah.
You want to say something, Paul?
PAUL WESTBROOK: Yes, I was going to talk about the Weave side.
WAYNE PIEKARSKI: Sure.
RYAN CAIRNS: So on the Weave side, one of the benefits of it
is actually dealing with the Google Clouds.
So the devices themselves actually
have a secure connection to the Google Cloud,
so they can ensure that the commands that
are received by the device are actually authenticated
to come from Google.
And then also, the other part is actually the authentication,
or actually, the sharing model.
So the user has ultimate control over which
user, as well as which applications,
have access to their device.
And so then they can both grant access as well as
be able to revoke it, in case there's
a bad actor or some behavior that's actually not expected.
WAYNE PIEKARSKI: Well, that's the thing.
I mean, there's the possibility of bad actors
at so many places in the chain that it's very important
that you secure everything.
You can't just get away with having some parts secure
and some parts not.
PAUL WESTBROOK: We agree.
And in addition to the cloud connection,
Weave also has local authentication.
So when commands-- like for example,
let's say the internet connection goes down.
So commands that go between a phone to a device,
we can still ensure that that communication
is secure as well.
WAYNE PIEKARSKI: Cool.
So one question I hear people ask me every so
often is, so we've got Weave.
And then we have Nest, which have their own IoT
story as well.
So how does the whole Weave story
fit in with what Nest is doing right now?
RYAN CAIRNS: They're different product experiences
for the consumer.
From a technical perspective, we're very compatible.
In fact, we're trying to offer Thread in Weave
on top of Brillo, so that people who
want to build works with Nest devices with Brillo
are able to do that.
So with Thread, you've got layer 2, layer 3.
With Weave, you've got higher-level protocol.
And with our Weave, really the idea
was to tie in the mobile experience with the device.
So we wanted to focus on gateway protocols
instead of focusing on more edge-oriented protocols,
so that we could leverage the technologies that
are in the phone-- so primarily Wi-Fi and Bluetooth.
WAYNE PIEKARSKI: Yeah.
OK.
Anything else?
PAUL WESTBROOK: In addition, as some
of the previous talks mentioned, about the schemas-- so we've
been actually working with Nest, too, on the device model
schemas.
So there's a consistent model for actually representing
devices across both platforms.
WAYNE PIEKARSKI: OK.
Cool.
Another question people commonly ask me,
which I thought I'd bring up here
as well as that there's lots of IoT devices
and microcontrollers and kits and different ways of building
little apps that flash lights and things like that.
So how does Brillo differentiate itself from there?
It seems like the market is quite
saturated with different projects and companies.
So what are your guys' thoughts on that?
RYAN CAIRNS: Yeah, so the thing that we
found with a lot of these other platforms
is that they're really great experiences
for trying something out, prototyping, having some fun
on a weekend.
But when you go to commercialize a device
or take it to manufacturing, there's a lot of challenges.
Right?
Then it's not easy to do out of the box.
And what we have is a system that you can take all the way
from the prototyping stage-- where you've
got a bunch of dev boards that you can buy,
when you've got new silica, and it's very easy
to move your project to a new board
without much code change-- and take that all the way
through the manufacturing process.
And I think that's a key differentiator.
WAYNE PIEKARSKI: So how does that work?
So the manufacturers have some ability to customize them, or?
RYAN CAIRNS: No, it's more about being
able to work with the silicon vendors
and tap into the hardware ecosystem
so that you can have a common bit of code,
and then go to a Qualcomm, or a Marbel, or Mediatech,
or an Intel, and get a BSP from them.
WAYNE PIEKARSKI: So they provide the support package
for their particular processes, whatever.
So then you can make your own board,
and then drop their processor, and they've
ported the kernel over, and the drivers,
and all that kind of stuff.
RYAN CAIRNS: Exactly.
So you're not tied into the platform
that you ended up prototyping with.
You can go talk to anybody, whether it's
Imagination or Intel or--
WAYNE PIEKARSKI: Mhm.
OK, cool.
Right now, I guess everyone got their little kits to work with.
Some people got DragonBoards, some people got Edisons.
The cool thing about them is they're very similar,
the build process is the same.
RYAN CAIRNS: And over time, as people build these devices,
we anticipate that they're not actually going to build one.
Right?
You're going to be successful.
You go out this year, you have different silicon
than you have in the next spin of the product.
And the code, maybe, is the same,
and we want to make sure that your projects can--
you can have the same project on top of multiple boards
that you've shipped, so that you don't end up
with a morass of all this code that you
have to maintain for basically different spins
of the same project.
WAYNE PIEKARSKI: Yeah.
So in the past, when someone made a router or a light
or something like that-- so what,
they had teams of people who had to have kernels,
and what's the difference from before till now?
Now that we've got Brillo and Weave, this is the workflow.
How complicated was it before?
Do you want to explain how much people you needed
to have to build a product?
GUARAV SHAH: I think-- the development model was
very specific to the board, and it
was pretty much throwaway work.
So let's say that you are trying to build a router,
and you started on a particular chipset.
You decided to move to a different chipset.
It's just going to mean a completely new code drop,
and you're going to start from scratch.
You're going to rewrite a large number of portions of things,
because you don't have things like a HAL.
So the hardware is not abstracted.
So you're writing a better software,
but you're also writing a better software that
is very much dependent and makes assumptions
of the architecture it's running on,
on the specific details of the hardware.
And I think one of the things that we're
trying to do with Brillo is to make that to abstract away
those interfaces, whether it's things like various hardware
peripheral interfaces, or it's like, how
do you configure your [? kung ?] specific features,
or APS for dealing with sensors, for example.
So we're trying to abstract away these details
so that when you're writing your code,
you don't have to make assumptions
about the various hardware implementations.
WAYNE PIEKARSKI: Yeah.
Yeah.
It sounds like a nightmare where it's
like, a kernel bug comes out, so they might patch
in a Linux kernel or something.
But then you don't know it's there,
or you don't know what version you're on.
You might not follow it.
So if you forget to pull those patches,
you got all these vulnerable devices
that people don't know about, it's just-- yeah.
And if you've got a billion devices out there,
and you need to keep them up to date, if you missed this patch,
then it could be catastrophic.
RYAN CAIRNS: Right.
And what we're trying to do is create
a center of gravity for all these BSPs
upstream in our repository so that when these bugs get found
by the vendor or by us, they could get fixed in one place,
and then everybody can then pull from them
for their own individual products.
WAYNE PIEKARSKI: Yeah.
Cool, cool.
Nice.
OK.
We have the audience here.
We have a microphone floating around somewhere here,
so if anyone has any questions you'd like to ask of the team--
do we have a mic somewhere?
RYAN CAIRNS: We've got two mics in the back on the ends
out there--
WAYNE PIEKARSKI: Yeah.
In the corner of the room, we have a mic there,
and a mic there.
If you had a question, we'll see what we can answer for you.
AUDIENCE: Excuse me.
So if I understand correctly, you
want us to make our devices available on Weave
or through Weave, but Google itself
will not make Nest available through Weave?
Because it's special?
I don't understand this.
WAYNE PIEKARSKI: This is more about the Nest experience.
So what does it mean--
RYAN CAIRNS: Yeah, we're working with the Nest team
to try to make Nest available through Weave as well.
The big thing today is that they're
different because we're different teams,
and we're trying to align those things.
Like Paul said, we're working on shared schemas
so that the developer experience for a Nest device
shouldn't be different than developer experience
for the same, like kind of Weave device.
AUDIENCE: So it will become available through Weave?
RYAN CAIRNS: We'd like to.
WAYNE PIEKARSKI: I guess the thing with Weave
is that right now, we have specs for it.
There's all these different device types.
I can't remember off the top of my head.
Do you remember?
It's like light bulb, and--
PAUL WESTBROOK: I can briefly talk about the schemas.
So we actually have some device guides
that actually talk about light bulbs, and air conditioners,
and a number of other things.
But the one thing about the schemas is actually,
they're composable.
So we actually take the individual traits of,
let's say, a light bulb may be dimmable or not,
or have color or not, and a hardware maker
should be able to take the individual components that they
want and actually define the behavior that actually
corresponds to their device.
So yes, we do have device guides,
but we also define the schema as individual traits fit.
RYAN CAIRNS: We're also trying to work
to align the Nest cloud and the Google Cloud,
so that developers can work with both.
WAYNE PIEKARSKI: The other cool thing
is that, with these schemas, if you build a device that
implements the light bulb schema--
anyone can write an app that controls light bulbs.
And anyone can write an app that controls air conditioners.
And the app doesn't have to be tied to that device.
It's kind of nice.
Because you could have a house with different light bulbs
from different companies, and they can all talk together,
which is sort of a new thing that-- I think someone talked
about it today, earlier, during one of the talks, which is,
you want to be able to make these things all work together.
You come home, your light bulb turns
on, your doorbell is synced to it, your music
starts playing, things like that.
So people have the ability to build
these kind of cool, combined experiences
that has been very difficult to do before.
PAUL WESTBROOK: Personally, I'm very
excited about some of the opportunities
that app developers have now.
I mean, being able to actually combine these capabilities
into a single experience.
WAYNE PIEKARSKI: Yeah.
Do you have any things that you're
excited about in particular?
Is there a particular kind of scenario or demo that you want?
Because I'm sure someone will have
one of these built by the end of the code lab tomorrow.
PAUL WESTBROOK: OK, so this is what I want.
For example, I think being able to unlock a door
and actually have your lights turn on automatically
for you, or based on the time of day, have different behaviors.
I think there's a lot of experiences, especially
across different manufacturers, to be able to actually
have the consumer not have to worry about buying
one particular brand of a product,
and be able to actually have it work on multiple brands.
WAYNE PIEKARSKI: The other thing is,
because this is a ubiquitous computing conference,
and we're talking about many different areas--
so beacons could be combined with this,
like a beacon can announce presence.
You could have a beacon on your key chain,
or you could have one in your car or something.
And then it's possible for your phone to detect,
OK, I noticed you've just gotten out of your car,
but now you're approaching your house.
Or Wayne has come home, or Paul has come home, or whatever.
And you can detect different things.
And you have different theme music on.
So when I walk in, I can have my theme music.
Actually, I remember I went to a conference once,
and this guy was talking about this concept of playing theme
music whenever he came home.
RYAN CAIRNS: What would your theme music be?
WAYNE PIEKARSKI: I-- Wait a minute,
I'm asking the questions here.
What's your theme music?
RYAN CAIRNS: I have no theme music.
PAUL WESTBROOK: But I could imagine
using the beacons to actually detect presence in the room
and actually turn on and off lights, to actually control
the air conditioner fans.
There's a lot of opportunity, especially
being able to talk to devices as well as detect.
WAYNE PIEKARSKI: What I want to do, actually,
is I want to put a beacon on my dog's collar.
And then, I have a sensor on my couch
that detects when they get on the couch.
And then it sets off an alarm or something like that.
Because I actually have a legitimate problem with this.
A lot of my ideas that I build are actually
problems that I'm trying to solve for myself,
but I turn them into work problems,
so then I can write blog posts about it and stuff like that.
But my current challenge is a couch detector or something
to keep them off.
Because it's actually really hard.
And I would love to buy something like this.
And like a trash can that detects
when it's been popped open incorrectly
when the dog sticks his head in there to pull food out,
you know?
All kinds of-- yeah, the internet of dog products.
It's exciting stuff.
RYAN CAIRNS: I was going to add, the big thing to me
is that we don't make end users programmers.
Right?
Like I want to buy all these products,
I want to bring them into my house,
I want to do different things with them,
but I want those experiences to be suggestive.
I don't want to have to think about, OK,
how am I going to combine these things?
WAYNE PIEKARSKI: Yeah.
I was thinking a lot of people don't
know-- they want to have a good time,
but they don't know how to code.
And you don't want to have a "if this, then else" type scenario.
And I guess that's where Nest has been successful--
this thermostat.
And it just does the right thing.
And you play with the thermostat,
but it's not a traditional, set-the-number type thing.
It tries to look at your patterns.
And I guess now people have the opportunity
to build exciting things like this.
But that's the challenge now.
And so we've had a bunch of talks about machine learning
and TensorFlow and all these other things today.
I guess the thing with ubiquitous computing
is we're combining all these different areas together.
So you've got your air conditioning,
you've got your car and your-- but you
can use machine learning algorithms to study patterns
and try to do the right thing for the user when they want it.
And we have a question in the back there.
Yeah.
AUDIENCE: Hi there.
I hear a lot of you talking about both Brillo and Weave
on setting state, on, "This will turn a light on."
"I will know when a light is turned on."
I'll have all of these things.
What I'm not hearing are the inputs for some of them.
So I'm not hearing, for example, how
to use Weave to create the light switch-- just the switch part.
I kind of have an idea on how Weave would do that
on sending it, but not how that switch would say,
OK, this person has now toggled--
this person's now issuing showing a toggle command.
Or even on the Weave side, how to read for a toggle command.
So that's what I want to hear more about at this point.
WAYNE PIEKARSKI: Yeah, that's a good question.
Yeah.
PAUL WESTBROOK: Sure.
I can start with the Weave side of this.
So as part of the schemas, like for example,
let's take a light switch, for example.
The schema for a device actually represents
a couple of different things.
One is the commands that it can handle,
and the second part is actually the state
that it's currently in now.
For example, an application or a service
can actually watch the state and actually watch
state transitions and potentially
use that as a trigger to perform some action.
Whether the action happens to be another command
or happens to be-- whatever it wants to be.
The other part is actually the commands.
For example, in order to issue a command to a device,
there is some schema and so applications
would have to actually do that.
So in the case that you gave, like for example,
a light switch, I would imagine--
this is just off the top my head-- I would imagine
a light switch would actually define
a state which is on or off, maybe its brightness if it's
a fancy light switch.
But it would also represent a command.
And so I would be able to issue that command to that
light switch to actually trigger that.
That command would actually affect the state.
So then the application, in addition
to actually controlling the voltage of whatever
was connected to that thing, it could
also-- applications could watch that state change.
AUDIENCE: Well, but the problem is
that whatever is connected to that thing
is another, completely separate Brillo device.
So really, I now have a virtual switch and a virtual light,
and somewhere I need to make the connection that says,
when I toggle any of these three switches
on different sides of my dining room,
my dining room light needs to turn on.
And I can see how each individual part of that works,
but I can't see how it comes together.
RYAN CAIRNS: So the first kind that we have is very much
phone-to-device, but we're also working
on triggers and signals, which we haven't rolled out yet.
AUDIENCE: OK.
RYAN CAIRNS: And that'll let you do things like--
WAYNE PIEKARSKI: That's the glue.
RYAN CAIRNS: --the device-to-device stuff,
what you're talking about.
Like I flicked this device, now I
need to go send a message to these other things
to go broadcast what changed.
Or somebody might have to subscribe to something
and say, oh, this state changed.
How do I take action on it?
We're working on rolling that stuff out.
It'll be a little bit, but stay tuned.
WAYNE PIEKARSKI: I guess the thing, also,
that's important is that the Weave
API is a very cross-platform.
They work on iOS, Android, web-- have I missed anything?
Yeah, they work across most of the major devices.
So it's nice, because you're not restricted
to just forcing it to work on a phone or anything.
You could build something that runs on a server in the cloud
somewhere or whatever.
OK.
While we're talking about light switches and stuff like that,
what kind of markets are you guys
excited about for different-- what
are the big areas you think are going to be huge?
RYAN CAIRNS: We're doing a lot of consumer stuff right now.
We're talking a lot about home automation.
And I think the opportunity here is a lot bigger than just home
automation, which I think is a really interesting vertical,
but not the whole pie.
The thing I've been telling the team
is like, think about how we put a computer in every device,
and what does that look like?
And I think there's a lot of scenarios like smart cities,
like parking meters and things like that.
There's a lot of industrial use cases.
There's a lot of, potentially, healthcare use cases--
I don't know if we're going to get into that or not,
but definitely a lot of potential
to put computers in things.
And interesting problems fall out.
And I think we can--
WAYNE PIEKARSKI: Yeah.
Well, that's the thing with software--
not everything is about consumer devices.
There's a lot of companies that do contracting work, who--
they're asked to build infrastructure,
to put a smart meter in every house to measure its power
usage or something.
And those kind of things will all be useful for that too.
RYAN CAIRNS: One example would be cars, right?
Everybody thinks about cars in terms of, oh, you're
going to put a computer in the car, navigation system,
infotainment, that sort of stuff.
And that's great.
I think Android Auto is pretty awesome.
But there's all of these other subsystems inside of cars,
too, that we don't address.
For instance, in a Tesla, they have an NVIDIA Tegra processor
just running the gauge cluster, that's
doing some basic graphics for things like speedometer and end
user input and things like that.
And there's all sorts of other subsystems too.
WAYNE PIEKARSKI: Yeah.
Earlier, we talked about displays.
So the little Brillo boards that have an HDMI output-- what kind
of hardware do they have for graphics rendering?
Do they do open gel, or?
I'm not sure, actually.
GUARAV SHAH: Right now, graphics support
is-- we can support very basic, non-x related graphics.
But we're working on it.
But nothing to announce right now.
RYAN CAIRNS: The goal is to be headless, for the short term.
WAYNE PIEKARSKI: Yeah.
Well, that makes it really low-powered.
Although those boards are really powerful.
They're almost the same chip as in a cell phone, basically.
RYAN CAIRNS: Right.
A lot of that comes from the fact
that we were trying to get something to market quickly.
And Qualcomm and all of our other partners
wanted to put out a very full-featured set of boards
so the developers have access to everything.
And the goal would be you start with something
like that, that's geared towards a cell phone,
and then scale it down.
WAYNE PIEKARSKI: Yeah.
Yeah.
OK, cool.
Any more questions?
One in the back there, yeah.
AUDIENCE: This is going back a little bit,
back a question or so.
So my use case is, I just got the word,
I'm heading into Tier 3 from PG&E. My question is,
who's responsible around here?
That's a historical question.
Where does Weave run when you have
a question about a number of devices
that are all secondary devices?
They're power users.
And I can get how much power they're using,
but where do I put it?
Do I have to throw it all the way back to the cloud,
and does that scale?
Really?
If it's a local resource, is it a capable device?
A capable thermostat that it would run on?
Or some kind of neutral gateway device?
WAYNE PIEKARSKI: It sounds like there's logging in here.
Where would we put that?
AUDIENCE: Yeah.
I do historical log-- I log continuously.
PAUL WESTBROOK: Just to make sure
I understand the question correctly--
you would like to create a device that actually tracks
the power usage at your house, or you want the power
usage of the Weave devices?
AUDIENCE: Oh, of the lights and the appliances
within the house, not the--
WAYNE PIEKARSKI: He wants to find the culprit.
RYAN CAIRNS: You're aggregating everything.
AUDIENCE: Yes.
Yeah, and recording it piecemeal.
PAUL WESTBROOK: Sure.
This is possible to do with Weave.
One thing that you can do is actually create
a Weave device that actually aggregates this and actually
represents this power state as state changes.
And you could actually decide-- if you don't associate
that device with the cloud, then that logging would actually
remain local, and you can continue that.
Or you could actually associate that with a Google account,
and then that would actually then propagate to the cloud.
AUDIENCE: OK.
And this would not be a smartphone platform.
This would be a permanently resident device
within the home, perhaps DSL modem, an augmented gateway
device.
Weave capable.
PAUL WESTBROOK: OK.
So there is a hardware device that's
in the house that would actually gather this information?
That should be definitely doable with Weave, as well as
that could run Brillo, as well.
RYAN CAIRNS: It's in the things like the data retention policy,
and how much you upload to the cloud,
and how long you keep things uploaded to the cloud,
and who's allowed to see it, and things
like that all come down to sort of both OEM preference
and probably user preference.
And depending on who made the metering,
or what the user wants to pay for,
or what the economics of the situation are,
the device maker, I think, would come up with a suitable policy
there.
But we should be able to have a lot of flexibility
in the platform to be able to do different things for that.
WAYNE PIEKARSKI: The devices can be shared, too.
Like if you came over to my house, I could say,
hey, I'll share this device with you,
so you could feed my dog or something like that.
So you can give access to other people for the device--
PAUL WESTBROOK: That's correct.
And even sharing devices, not even
necessarily for functional, but for viewing access.
So, for example, in the case of a power meter.
Let's say, for example, I want to share this device
with my wife so she can see how much electricity we're
using at home.
That's also possible as well.
WAYNE PIEKARSKI: OK.
And we have another question over there.
AUDIENCE: Yeah, I got a couple questions.
Just really simple is, what Android version
is Brillo based on?
And then is there any plans to bring that modular update
architecture to just standard Android on phones?
So I don't have to wait like a year for the Marshmallow update
on my phone?
WAYNE PIEKARSKI: OK.
RYAN CAIRNS: So nothing to say about updates on Android,
but we can tell you what version.
GUARAV SHAH: It is based on the latest AOSP sources.
In fact we do all our development in open source.
And we do it regularly, not just code drops.
RYAN CAIRNS: Yeah, we work in the open.
GUARAV SHAH: In terms of versioning,
I think one thing to keep in mind
is that we're not using the same version or numbering
scheme as--
WAYNE PIEKARSKI: Yeah, it's not like KitKat, Marshmallow--
GUARAV SHAH: Yeah.
And that's just because all our development is in AOSP.
RYAN CAIRNS: Having said that, we
don't want to encourage people just
to take random snapshots of AOSP and push them to users.
We want to have some well-defined releases,
but we want to do it at a more granular level than what
Android does today with the dessert releases.
AUDIENCE: And also my second question
is, what's in it for Google, or what's
your monetization strategy?
Is there some kind of licensing that you're
doing for hardware manufacturers,
or are the app developers going to have to pay its licensing
fees, or what's up with that?
RYAN CAIRNS: So we're not taking a license fee.
When I think about what's in it for Google,
especially when people ask me at Google, what's
in it for Google, the answer is, we have
a lot of Android developers.
And we have a lot of developers that we
want to make sure that they can program
against the physical world.
This is one way to do it.
We also have a lot of services, and our developers
build a lot of services, and we want
to create a platform where both our developers and us can
easily distribute our software on top of.
And I think, by doing that, that creates
a lot of future monetization opportunities for both Google
and our developers.
WAYNE PIEKARSKI: That's also why we're running this conference,
I guess, is it's part of all the different products.
They all sort of fit together.
You've got Brillo and Weave and beacons and wearables and all
these different things, and they each
bring a piece of the puzzle that-- they can't all
solve the puzzle by themselves, but combined together,
they do very interesting things.
Like you said, there's all these Android developers.
That gives them new capabilities and things like that.
AUDIENCE: Awesome.
Well, thank you for that.
The other guys are doing pretty much the exact opposite.
So thanks.
WAYNE PIEKARSKI: Thank you.
Question over there?
AUDIENCE: Yeah, I had two different questions.
The first one is, considering that Weave
is a crucial part of the infrastructure
in communications, what is your target SLA for it?
And if there's any sort of queuing in case of an outage
or any sort of downtimes?
WAYNE PIEKARSKI: I missed the last part of the question,
but--
PAUL WESTBROOK: Yeah.
Would you mind repeating the question?
AUDIENCE: Just, what would be the SLA of the Weave services
as a whole in the cloud API side of it?
And is there any sort of road maps for queuing
or any sort of contingency plans when there is an outage?
PAUL WESTBROOK: Google services are-- the Weave service
is running in our backend.
I don't know if we publicly say SLAs.
RYAN CAIRNS: Yeah.
Being that this hasn't been fully
released to everybody yet, I think we're
holding back what our SLAs are.
But--
WAYNE PIEKARSKI: Yeah, right now it's a developer product.
So please do not build a nuclear reactor or anything
important with it.
Because that's not cool.
It is beta software, so please treat it accordingly.
RYAN CAIRNS: Like any Google product,
we're all carrying pagers.
And we're all trying to get latency down.
And we really care that 90th percentile is really fast
and their uptime is really high.
Unfortunately, I can't quote you an exact number right now.
AUDIENCE: Fair enough.
Yeah.
The second question is, the whole movement of Brillo Weave
is about interoperability, ability to connect everything.
But the realistic sense is that there
are several other IoT-based platforms out there.
And for you to expect a consumer to only use
Brillo or Weave-connected device is probably unrealistic.
And is there any thoughts-- and this
is not any plans or anything like that-- any thoughts
from you guys as far as any future plans or talks
or discussions with other major partners or players
out there for interoperability between platforms?
PAUL WESTBROOK: At least from the Brillo and Weave
point of view, we're open.
For example, if a OEM wants to make a Brillo and Weave device,
we're not going to prevent them from integrating that device
with any other platforms.
AUDIENCE: Thank you.
WAYNE PIEKARSKI: Another question over there.
AUDIENCE: Just curious for your thoughts.
Let's say that I'm a device manufacturer,
and I'm deciding what platform to build my new device off of.
I'm kind of curious what your thoughts on the story
would be that you would tell.
Why would I choose to build on Brillo,
say, as to just putting together a set
of yocto patches or some other embedded Linux system?
Is it just primarily the Google services,
the over-the-air updates metrics, that sort of thing?
Or are there benefits to, say, using the Android stack,
or other things that you see bringing
an advantage to a device manufacturer over something
like that?
RYAN CAIRNS: I think a few things.
I'll take a couple, and then maybe Guarav can chime in.
But the one I think of most is the Android hardware ecosystem.
It's very easy to go to any silicon
vendor who's supporting Android and say, give me
a Brillo thing.
And the second one is, obviously, the services
that you mentioned.
There's a lot of stuff like updates and analytics
and things like that that you get from Brillo that you
don't get in other stacks.
Guarav, security?
GUARAV SHAH: Yeah.
I think security developer experience,
hardware ecosystem-- yeah, I think that covers it.
I think we're also very proud of the services with respect
to analytics and updates.
I really think we have the best of the great there.
AUDIENCE: Thank you.
WAYNE PIEKARSKI: Over there?
AUDIENCE: Yeah.
I'm pretty sure this is more of a manufacturing concern,
but we talked a lot about security.
How about safety?
Like when you define the schemas or whatnot, are you concerned?
Like I might turn-- a user or a developer
might turn on the thermostat to like 160 degrees rapidly,
or even other things like that.
PAUL WESTBROOK: That's kind of hot.
I think there's a couple things.
One is, we are working with the OEMs and the hardware makers
to actually define the schemas.
So there's going to be-- the schemas
also support limits and ranges.
For example, let's say if all manufacturers
agreed that-- I'm just going to pick a thermostat-- say,
that 160 degrees is too hot.
There would be some agreement, working
with all the manufacturers to actually have some fixed limit.
But ultimately, the hardware maker
is the one that's responsible for making sure
that the hardware actually functions correctly.
I think that whether it's actually
through Weave or someone just spinning the dial too
far to the right, the device itself should behave correctly.
WAYNE PIEKARSKI: That's something else to think about.
Because when I was building the dog feeder, one of my concerns
actually is that if the dog feeder fed continuously
that entire tub, it can actually kill a dog.
I've actually taken my dog to the ER
twice from eating too much.
They will eat too much.
I couldn't believe it, right?
Cost me $500.
But anyway, the point is that I was like, well,
if the software fails, or if a wire shorts out, or something,
you really have to build multiple layers of protection
into the device.
So maybe with the switch that runs the paddle feeder,
it should say, well, if the switch ticks
more than four times in a second, you should shut down.
And if this happens, you should shut down.
You could have all these extra safety features in hardware
as close to the metal as possible to shut it
down and put it in a fail-safe mode
so that it fails gracefully, because putting all
the food out is unacceptable.
It's like an airplane shutting its engines down
if it doesn't know what it's doing.
You've got to design the hardware in a way that really
tries to think about, what's the worst case scenario,
and what can I do about it?
So like if it had a 160-degree thing,
you'd have a thermal fuse that melts at 150 to stop it
from getting to that point.
Have multiple levels of protection,
and don't just rely on the software somewhere else.
Because the user, if they set the dial,
then it would be kind of crazy to allow them to do that.
RYAN CAIRNS: Yeah.
We certainly can't design Brillo and Weave
to deal with operator error or malintent
from the hardware or things like that.
WAYNE PIEKARSKI: Well, that's the thing is that there might
be cases where you want to set a thermostat to 160
because you're building an industrial oven or something,
and that's a desirable outcome.
So you've got to make sure that-- the designer still
has to think about these things very carefully.
Any more questions?
Yeah.
AUDIENCE: Was that dog that overate different
than [INAUDIBLE]?
WAYNE PIEKARSKI: A fellow Googler from the San Francisco
office had that dog.
My dogs are at home, but different dog.
It's a constant challenge.
And it's a great motivator for coming up with innovations.
AUDIENCE: Early adapter dog.
WAYNE PIEKARSKI: Exactly.
Exactly.
Yeah.
RYAN CAIRNS: I got to say, I hope
you guys are learning as much about Brillo and Weave
as I am about Wayne's dogs.
WAYNE PIEKARSKI: I gotta write a book about them one day.
Yeah, question.
AUDIENCE: So I haven't heard much mention of this,
and I don't know, it's kind of early,
but I was wondering what the pricing model for [INAUDIBLE]?
WAYNE PIEKARSKI: All right.
Just to repeat the question-- for anyone
else who has questions, if you could go to the mics.
But the question was, what's the pricing model for the cloud
services and things like that?
RYAN CAIRNS: TBD.
Right now, there's no charge for, I think,
up to 500 developers.
WAYNE PIEKARSKI: 500?
RYAN CAIRNS: I think, for early access.
Don't quote me on that.
It might be 100.
AUDIENCE: So some of the other cloud services, they
offer assistance [INAUDIBLE]?
WAYNE PIEKARSKI: Assistance with programming stuff?
Like what kind of assistance?
RYAN CAIRNS: Like do you want back-end storage
and things like that?
And how are we going to price those services?
TBD.
Nothing to talk about today.
Sorry.
AUDIENCE: Right now it's just bare bones [INAUDIBLE].
RYAN CAIRNS: Yeah.
Right now, we have crash reports,
analytics, storage for updates-- Lawrence,
do you have a number in mind?
WAYNE PIEKARSKI: Do you want to go to the mic?
Are the mics ready?
Yeah.
MALE SPEAKER: So for things like metrics,
the storage requirements are so low that it's likely
that they'll remain free.
But for updates, for now, everything is free.
But once we see what the adoption is like,
and if people start to store a lot of different updates
and doing it every day, then we may have to revisit that.
But for now, it's free.
And TBD what the pricing model will be.
WAYNE PIEKARSKI: Actually, I remember when
I saw Lawrence's talk earlier.
It has all these graphs that you can draw of like temperatures
and things like that.
And I think it's going to be really
cool, because some company's going
to make a fleet of devices, and they're going to be like, wow.
We had a huge failure rate, and all of them
had a little spike in temperature one
week before they blew up.
And so a week before, you hear, oop,
that device is going to fail.
We can send a field technician out.
And so there might be a possibility
that you'll just get a call saying,
hey, your oven's about to fail.
We've already scheduled someone to come out
between next week and next Christmas to come out.
And they can fix it up for you, or whatever.
It will be a way of preemptively doing maintenance.
Because the worst thing that can happen is,
it's the middle of Thanksgiving, and your oven fails.
Whereas I think there's all kinds of exciting possibilities
to learn about your device fleet and what's going on.
And it helps you with maintenance and doing research
into making more reliable products, and--
RYAN CAIRNS: Yeah.
It helps with things like phone support, too.
If you could give that data to your phone techs in the future,
maybe that's a problem that we can help solve.
WAYNE PIEKARSKI: Many years ago, I did tech support in ISP,
and doing that was the hardest thing when
you didn't have remote access.
You had to coach them through a phone.
And it was even better when they couldn't
get the phone to their computer, and then you had to talk--
RYAN CAIRNS: Well, I mean not so much remote access.
I mean like if you had people working the call center,
and you knew that there was a big failure of all your devices
in the field, you could tell them
like, hey-- call volumes are going to go up,
and here's what you can tell people.
WAYNE PIEKARSKI: Yeah.
Yeah.
RYAN CAIRNS: Even before the remote access stuff.
WAYNE PIEKARSKI: I think it's going
to add a lot of really cool possibilities for that.
We just haven't been able to have that kind of thing.
Like PCs, they can kind of do remote support,
but every other device is kind of like, press the button
and bring it in and replace it.
And that's quite expensive.
If devices could self-report, that would be really cool.
Any more questions?
AUDIENCE: That's actually a great lead in to my question.
We heard a lot about rollout support.
What about rollback support?
So if--
WAYNE PIEKARSKI: As in backing a firmware update?
AUDIENCE: As in, if you push something out to the field,
and you start seeing a tremendous number of failures
with that, is there a way to say,
OK, let's easily go back to the previous version, which
may or may not still be installed
on the person's device?
Because we heard about partitioning, also.
Is there a way to say, look, you know that thing
that we sent you yesterday?
Forget it.
Just forget it.
GUARAV SHAH: We can always-- there's always the option
to push back a previous update.
When the update is pushed , your user data is on a different
partition, so that's not clobbered.
So you can, actually, go back in the same state you
were before the botched update.
But in general, we have actually designed the update model
to make it easy to do rollbacks.
AUDIENCE: And is that a real rollback,
or is that just pushing out a new version that just
looks like the old version?
GUARAV SHAH: So there are two kinds of rollbacks.
There is a rollback that will happen automatically
when the device detects that the new update is bad.
And that's basically-- it won't finalize the new update.
And it will keep the old version around,
and it will roll back to it when it detects that condition.
And if that, that usually catches 99.999% of the cases
if done right.
And I think we do it quite right.
And if that doesn't work, then there
is always the option to push the old update payload again,
and use that to bring the device back to the original state.
WAYNE PIEKARSKI: OK.
Cool.
All right.
Well, I guess we're almost out of time.
Did you guys have any final thoughts?
Oh.
You had a question there?
AUDIENCE: It was an extension of the OTAs.
Is there going to be a certain time
limit the OTA should complete?
Like it shouldn't take half an hour
if my door lock can't open for half an hour.
So is there going to be like, your update should only
take 30 seconds or?
RYAN CAIRNS: So updates actually happen in the background.
So the device should still function while updating.
It's when the device decides to apply the update which
is the question.
And that policy would be different
depending on the type of device that's there.
So the user shouldn't be hung up waiting
to interact with a device while it's updating.
That would be a pretty bad experience.
GUARAV SHAH: Yeah.
And the other technology we have is we do delta updates.
So the actual size of the update is very small.
So you're not downloading-- let's
say your image size is 100 megs.
You're not downloading 100 megs, you're
just downloading the delta, which
might be something as small as like 6 megabytes.
So that means that the time to download and time to apply
is also less.
WAYNE PIEKARSKI: Cool.
AUDIENCE: Just a last question.
The main goal of Weave [INAUDIBLE]?
RYAN CAIRNS: Yeah.
The question was, is the main goal of Weave interoperability?
PAUL WESTBROOK: I would say that's one goal.
The other goal is actually enabling-- well,
security is always a goal.
But I think it's enabling application and device
developers.
So I think that with the Weave APIs in Android and iOS
and web, it's very easy to write an application that
talked to multiple devices.
RYAN CAIRNS: And one thing that we haven't mentioned
about Weave is smart setup.
One of the big challenges that we see
is when users take these devices home,
the first step is getting it on your Wi-Fi.
The second step might be provisioning an account.
And the third step might be downloading the app.
And with the smart setup stuff, you
can just go and say OK, Google, set up my device.
We scan for the device, you select it.
The app for that device automatically
downloads in the background, and it connects to your Wi-Fi
automatically.
So the provisioning of it is very seamless.
And what we find for legacy products are things like--
things that were designed to be used in a dumb way and maybe
a smart way is that--
AUDIENCE: For dumb TV remote controls.
RYAN CAIRNS: Potentially still dumb TV
remote controls, as well as smart TV remote controls,
but yeah.
But the idea is that you don't have
these misconfigured devices.
There's a lot of people who sell Wi-Fi enabled devices
where something like 50%, 60% of the users
don't actually connect them to Wi-Fi ever.
And one of the goals of Weave is making sure
that the complete experience is configured out of the box
without much effort.
WAYNE PIEKARSKI: Yeah.
Nice.
OK, well, we're kind of out of time.
We got another session coming up.
At the end of this session, we have
a bunch of demos happening during the cocktail hour.
So some Googlers have actually brought in machines and devices
that they've built to show off some things that they've
done with Brillo and Weave.
We've got that happening.
We're all going to be around to ask questions of.
And then tomorrow, in the code lab room,
which is outside the building and one building over,
we have computers set up where you can try out the Brillo
BDK on one of our machines.
You can also show up with your own laptop.
And we're going to have office hours,
where various people from the Brillo and Weave teams--
all kinds of different people, like engineers, programmers,
managers, things like that-- everyone's going to be there.
And you can ask questions, show them code,
or we can walk you through the code labs and things like that.
And if you've had trouble setting up one of your devices
that you got in your little toolbox,
we can help out things like that.
So there's a lot of-- please take advantage of the fact
that everyone's here tomorrow, and enjoy that.
So that's the end of this session.
Thanks very much for coming by, and we
hope you all had a good time.
Thank you.