Placeholder Image

Subtitles section Play video

  • 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.

WAYNE PIEKARSKI: Welcome to the Fireside Chat

Subtitles and vocabulary

Click the word to look it up Click the word to find further inforamtion about it