 So, we're here to talk about IoT and the IoT Challenge. I'll explain along the presentation what I mean about IoT Challenge. But suffice to say, I don't believe that what we have today is what IoT should be. It should be quite different from what it is today. But before that, let me just introduce myself quickly. That is me working with high technology in 1982. So, my name is Tiago Maciera. I work for the open source technology center of Intel. I work in Portland, Oregon, the United States. I've been doing open source for the last 15 years. A little more actually than that. And I've been involved interestingly with networking ever since I started with open source. So, my story with open source starts way back in 1999 when I was applying for an internship. And they actually asked me, what do you want to do? So, I started thinking, looking at projects that were happening, I decided out of the blue, IPv6. So, by the way, I'm giving a session tomorrow on IPv6. One thing led to the other, I ended up working at Intel. And two years ago, we looked into what existed for IoT, what frameworks existed, and we did not find that there was anything that actually met our needs. So, we started our own. And that brought me back into networking and IPv6. So, what we're using in IoTivity and OCF, which I'll get to, is all based on standard technologies including IPv6. So, it's interesting that after a long while, I mean, I always kept up to date and I have IPv6 connection at home, that knowledge actually became useful when we're talking about how to do multicasting, how to do discovery, how to do connectivity, what information do we get from other devices. All of that knowledge of networking actually came in useful. It's not the only thing I do. I'm also maintaining a couple of other projects in open source, but for the past two years I've been involved. Like I said, 90% of my time has been IoT. So, without further ado, let's talk about the big news, which I don't know if you're following the IoT segment, you might have seen this. If you have not, let me explain to you. The All Seen Alliance is a Linux Foundation cooperative project. The Open Connectivity Foundation is a separate entity, but sponsors another Linux Foundation project called the IoTivity project. So, and what happened as of yesterday is that these two entities decided to join forces. They decided to merge and come together with a single roadmap for creating the IoT solution for the future. And that's the one I'm going to be talking about here. It's the one we've been working on the OCF for a while, but it is the one now that we all agreed. This is actually the technology that we combined forces will believe will take us for the next 10, 15 years, hopefully more. It consists of basically three pillars. One of them is the specification. So we're here at the Linux, an embedded Linux conference. We're talking about open source. Yes, we have source, but we need the specification. The reason for that is that we need to be able to say this is how it should work. There is a way to do things that if you want to reimplement from scratch, you're allowed to. You don't have to use our source code. So if you're, for example, a hardware manufacturer, let's say you're buying or designing an FPGA, something specific to put all of this communication we've designed into hardware. Well, you can because you don't have to use our source code, which was written for regular operating systems. You can just look at the specification, look at how it's done, and implement your own functionality. And the same way, you can use the source code without having to be a member and pass certification. Now, let me warn you, you do want to pass certification. If you do, and that's the last pillar there, you get a number of benefits of passing certification. That's a goal of interoperability. We want not just that you use our software and you read our specifications. We want to give the guarantee to the users that this device works with that device. It's a very simple scenario. Imagine, for example, you buy smart light bulbs. Do I have to buy controllers from the same brand? No. I mean, I have to be able to replace my light bulbs with a different one or buy a controller from a different device. And my TV from a different manufacturer from the light bulbs. So we are trying to create an interoperability between these different technologies, these different manufacturers by these three pillars. So again, a specific specification which you can read and which you can implement towards. And if you're a member of the Open Connectivity Foundation, you get a number of intellectual property benefits by implementing this. An open source project that is developed as open source that you can participate in and implement on your own project and your own devices and, finally, pass certification. Our vision is to create something that, like I just mentioned, is an open, published online specification which everybody can read. The draft standards are, for the moment, only for members. We've been discussing whether we should publish draft standards, for example, on GitHub and people can read as we develop them. This hasn't happened. It's free. The reference implementation is free and open source. The standard is published under reasonable nondiscriminatory with zero royalty. So it is free. Now, membership costs, but because we have costs and if you're going to certify a device, it does take somebody time to test everything. But plans are reasonable. It's seamless. It should work from any device, big or small. We don't care which technology you're using. IPv4 and IPv6 right now. There's been some discussion on whether we should use non-IP technologies. That's an open debate because we're seeing IP coming to everything. So maybe the problem will solve itself. It's fair and accessible, just like I mentioned. It's open source. Anybody with a merit can participate. We're doing with the large backing of companies and across the industry. So we have representatives of electronics, of chipset manufacturers that I can tell. We have cable operators, telecom operators. We have educational institutions. It's actually easier if I just show a bunch of logos for you. These are just the top members, Diamond and Platinum. As of this morning, we have more than 230 members. So please look at the webpage for the full list. We also have liaison agreements with a number of other organizations that are operating in an area similar to ours, so an IoT or IoT related. As a good example, I can point at the Thread Group, which is implementing a technology for mesh low power networking, specifically meant for smart home. Let me just point out as well the slides will be available online. So you can take a picture of me as well. There will be a video, but if you just want to look at them later, and everything is broken, you blame Philip. But the slides will be available online later. So you don't have to. So I was talking about the Thread Group. They are creating a low power mesh network based on IPv6 and the IEEE 802.15.4. And what they looked at was like, great, we got a network. What are we going to transport on this thing? Who's going to use it? And we are on the other side. We have a use, we need a network. Why don't we work together? And so we do. We created this liaison agreement where we exchange a bit of technology. We have a couple of companies that are members of both. And then we realized, hey, we actually need to do some technology exchange. So bringing a device onto your network, there's more than one step involved. And we have a program so that it's seamless when you integrate your device onto the Thread network it automatically gets the information for the OCF network. I'm going to come back into that. So that's all I'm going to do about the non-technical. If you want to hear more about the foundation, if you want to hear more about the merger that just happened, you can come to the OCF booth on the upper floor. We'll be happy to talk to you. The rest I'm going to talk about right now is technical. So thank you for putting up with the non-technical. Let's get technical now. I'm happy to take questions. This is a little complex. But I'm happy to work with you. And what I mentioned in the beginning about the challenge of IoT is this. Today we do not have IoT. Let me explain what I mean. I will use a concrete example. I bought these smart AC for my house. It's not the Nest. I just bought something. It came with a thing that comes on Wi-Fi, which is great. How do I control it? It comes with an app for my phone. And then somebody goes and buys those night-sit mood light bulbs. How do they work? Another app. So what you do have today is not IoT. It's not the Internet of Things, or even some people call it the Internet of Everything. What we have is isolated islands of everything. You have a type of device that does something smart, thankfully, and hopefully the smart device is smarter than the dumb device, which is not a guarantee. Let me tell you that. We have devices that are worse than the dumb counterpart. So you have smart devices that do something, but they don't talk to the other device. If I buy a smart microwave, I want my smart microwave to turn the lights in the dining room on when the dinner is ready. Who's going to program that? The only way this is going to work is if we have a common technology for this. And this is what we're trying to solve. Let's create a common technology stack so that the multiple devices underneath can be reached. Starts with a problem of transport, and this is what we're seeing here in this picture. So if you're up there writing your application and you're trying to reach devices that are down here, some of them are Wi-Fi, some of them are Bluetooth, some of them are going to be on ZigBey and Z-Wave. How do you do that? Each device is going to work differently. So if I buy two different light bulbs, mood light bulbs, they're going to have a different protocol. What we're trying to do is create one common connectivity framework so that you can find and communicate with each of those devices securely, the set of data models that explain what each device is. For a long time, we're going to have the end of the picture there, and I probably should reduce the font size because this looks horrible. I think this happened after I just plugged the monitor and the fonts didn't work. So on the other side, what you're going to have is for a time there will be legacy devices. So there are a number of devices coming today which have, for example, Z-Wave. They have a full stack up and down, discovery and communication and describing the device. What we're going to do is create plugins, a translation layer, so that if you're programming up here, you can talk to them as if they were local. You can see that the legs here have different sizes. That's because some technologies allow more information than the other. The example which, unfortunately, the name is hidden behind here, this was supposed to be Six Low Pan. So it doesn't have any way for us to describe what a device is, but Bluetooth on the other hand has a much higher stack because Bluetooth already comes with a way to describe certain devices. So if I come to my car, my phone automatically starts playing music because it detects as a music player and the car is a loudspeaker. It's a very mobile and big and expensive loudspeaker, but yes, what we need is to figure out, hey, I want to talk to all of these in one way. Our stack is, we selected it to be very based on standard technologies. We don't want to reinvent the wheel. We want to make things simpler and use what is proven. Some of them are not proven because they're so new that we need to prove them ourselves. So as an example, a very important example is, we're not using TCP. And you go like, what? How does that work? We're using only UDP. The reason why we're using only UDP is so that we can run on very tiny devices. So a colleague of mine is going to talk about this later. And if you were on the other session right here about Zephyr, they would be telling you, hey, we have an UDP stack, but our TCP one, I probably don't want to run it. Not that it's bad, it's just big. And by big, I mean 200 kilobytes. We want to run this on very tiny devices. I mentioned FPGAs before. So we're using, based on UDP alone, so you can see how this builds up, right? We can run over Bluetooth, or Wi-Fi, or 6-Low Pan. We built with UDP. We have session encryption, or the encryption is already here, right? So built in from the scratch. We have DTLS. No device is allowed to pass certification without having security. Now, we don't do the hardening, right? Left on the exercise for the reader. So if you're my reader here, you have to harden your device against other vectors of attack. But the moment that you bring it to certification, we're going to test, hey, do I enter the encryption? No, fail, forget, can go home. We have a security resource management from the beginning. So every device comes with an ability to set a number of access control lists. So can this resource be reached or not? I can give you an example of a door lock. A door lock in my house, the adults can open and close. That's fine, but not the kids. So if the kid is represented by the phone they have in their pocket, or a dongle, or whatever, or a fingerprint reader, well, the ACL says no, you're not allowed to open the door. Right? Only an adult can allow you to go outside and play or open for strangers coming in. So this kind of functionality is built in from the scratch, and I have to tell you, we're already thinking of the next one. We're not happy with the one we have. It works, yes. We want to get better. And you can build clients and servers. I'm not going to get much into the intermediary that's basically a client and server at the same time that passes information along. And you're going to add your own resources on top. So what are the resources? I'm going to get into the next two slides. We adopted a restful model. So what does it mean to be restful? What does it mean to use rest? For us, it means that we are much more able to grow, scale, and be native with cloud technologies. These, again, what I said before, these are proven technologies. We know how they work. We didn't use HTTP. Remember, I said we're not using TCP. Instead, what we're using is a protocol very similar to HTTP, but it is binary and UDP-based. It's called co-app. It was in the previous slide. It's not something we invented. It existed from the ITF, the Internet Engineering Task Force. You can find the protocol described on RFC. Same thing. We're using something very similar to JSON, but not JSON, because it's binary. So we're using C-board, concise binary object representation. Again, you can read the RFC. We're just using these technologies. The interaction is very simple. A client initiates a connection. It usually starts with a discovery. Who's there? Or who's a toaster here? And you get a reply saying, hey, I'm a toaster. Or in the case of security says, I might be a toaster, but I won't tell you until you open a secure connection to me. We've been having discussions. Should some devices reply randomly? I might be a toaster, but I know I'm not. So you have TVs replying, yeah, maybe, just to throw an attacker off. But anyway, I digress. The server replies. It hosts a resource. The interaction is do something for me, sends a response, and provides a service. It's simple. A resource, a device, let's look into inside of one. A physical device can contain multiple logical devices. Why would anyone want to do that? I don't know, but the point is I don't want to constrain you. But think of more simply, I have a much more capable device like my phone, and I have multiple applications running. As simple as that. But it could be for security separation. Some devices are more critical than others, so they run on different processes. Or it could be just the way that we developed things because this one needs to access some hardware, that one doesn't. I don't know. Each device comes with a couple of mandatory resources and a couple of these resources that are optional. Plus your own resources explaining what they are. They come with a description of what they are, so you can see, for example, that this one is described by manufacturer MNMM, which is manufacturer name. There's one M too many. Where's the second M in manufacturer? Anyway, so apparently our guys like a lot of consonants, but that's the name of the... I'm not joking. It's actually the spec. It says MNMM. It's manufacturer name. I don't know where the extra M comes from. It describes us, for example, a Samsung device. Why would that be? Well, if I want to find all of my Samsung devices at home, I might want to be able to manage them with a special interface that allows me to do upgrades. That's an example. This one describes each logical device and the res is a resolution. It's where everything starts. So I ask to all of the devices, ask for their res and say, who's a toaster? They reply. Looking into my own devices. So, for example, for industry, we're going to have... Hi, Richard. Good to see you. A light bulb, and by the way, question that comes up often, how many IoT engineers do you need to replace a light bulb? Because we keep talking about light bulbs. The answer is none. It's a hardware problem. We do software. A light bulb, for example, is described by the spec as a device that has a couple of mandatory things, like I showed you before, that it has, at least, and you can see their mandatory, at least a binary switch on and off. A light bulb must be able to be turned on and off. But it has a number of optional resources that it can add that are standardized. So if my light bulb can do brightness, great, I just add a brightness resource. If my light bulb can change color, I add the color resource. A light bulb can do, I don't know, set a temperature, might as well. I mean, yes, you can do temperature of the white. Why not? So you can do cool white, warm white. If it has a party mode, that's not standardized. So what do I do then? Well, I create my own resource. Remember, look at this. This is actually made by strings. I can just create my own for my own company. I can create party mode light bulb and just add it there. How did we get here? So let me just take a step back and talk about how devices get onto your network. And this is important because this is the root of all security. This is called the ownership transfer protocol. When you buy a device, it comes in an unowned state. It means I'm ready to accept ownership. You can put it back on an unowned state and factory wipe and give it to somebody else. Or it comes with a button on the button. I don't know. But it comes in an unowned state. It starts up. I'm not going to get into the details of how. This you can read on the spec. It starts up, finds the onboarding tool, which can be an app on my phone. It can be an application on my laptop. It could be a remote application on my router, which I access via the cloud. I don't know. But the point is there is a tool, which we're also developing, called the onboarding tool. It will discover that new device that it's willing, that was in an unowned state. So it confirms the device is in an unowned state, claims it, now it's mine. It does that by passing along the information about, for example, on Wi-Fi that's not the case because you have to actually get into Wi-Fi before you get the information. But on Thread Network, for example, you find the device before it joins your network, before it joins the mesh. And it joins it by receiving via this encrypted channel now, it receives the information of how to join your mesh network. And at the same time, it gets the certificate, so on all the provisioning data, to join the OCF network on top. So only devices that went through this will get the necessary encryption keys and certificate that will validate it against all other devices. And at the same time, they get a set of ACLs. So you can program your onboarding tool to always restrict, nobody can access it but me, so only admin can set information on it. A very good example is the resource on each device that controls ACLs needs to be made accessible only by the admin. But at that point, you can also control, yeah, yeah. This device actually belongs in the upstairs bedroom, so I'm going to add some information to it. I can add some description at the moment that I join onto my network. I can put into groups. I'm going to get into groups in a minute. Next slide, actually. So all of this starts from the beginning. We've developed the onboarding transfer protocol. The onboarding, yeah. To be secure, no man in the middle of possibility. Sometimes that's a little cumbersome because of the way we do things, so we also have the JustWorks model, right? It's just called JustWorks. It's a simple mechanism. It, depending on how long you take, it might be successful to attack. But there are ways to make sure that whenever you bring something onto your network, it is secure. Now, I don't want to maybe do one at a time. I might be able to provision them before they ship. So if I'm doing an industrial setting, so if I want to install 100 of these new devices onto my new network in my office, for example, which is a large place, I can do the transfer before, bring the device in. So, for example, pre-provision them with the information they need. I mentioned groups. Let me just explain where the groups are. So we're now talking about the data models. So we started from the bottom. So remember I said before, you have a binary switch. A light bulb is a binary switch. Well, microwaves also have a binary switch. A thermostat has a binary switch, right? So we started from common elements that apply to everything. Temperature is another one. Remember we talked about the warm light and cold light. I can have a temperature resource, which is a thermomester, or a thermostat. And they're different because one is a reading, the other is a setting. So all of these resources are described at the bottom level, the elementary resource of them, how they actually are, and you build on top of them. So I'm saying a thermostat is a switch because it can be turned on and off. It has a temperature reading and a temperature setting, right? So the temperature setting is the one on the far right because it's just something I set. I have a thermometer which has a temperature reading. But I could have an extra device which is just a thermometer which I can't turn on and off and I can't change its temperature, at least not programmatically like this, right? I can bring a flame to it, that's different. So we build these things from the bottom and the technology that allows us to group them together also allows us to group a series of these into larger, more logical information. So I can, for example, define that all devices, my house belongs to my house. I can call them upstairs bread room or kitchen, right? I'm sorry, I can do queries like give me all the kitchen lights. And if I have a light switch, the light switch controls the lights in that group. So there I have six buttons, right? Some of them turn this light on, some of them those, some of them the other types of lights. So that programming, right, we can make by using groups, collections of elements, collections of groups, and I can create groups of groups and so on. So that same technology. Remember, we're just building stuff. There's nothing innovative here. No, there is, all this putting together. And all of these data models, they are in this website, oneiota.org. You can go there. You have to accept the terms of use, the moment that you log in the first time. But this site is both a repository of data models in, again, Rammel and Jason. This is Jason Schema, sorry. These are standard technologies. And an IDE to develop them. So we are using it to develop our own. The next set, industrial, we're looking into how you describe, I don't know, an asynchronous motor. But you can go and add your own. You have a device that we hadn't thought of. You can contribute there. Or you have a device that has temperature, for example. But it's different from ours. So you can actually go there and describe temperature in a different way. In this other technology, like Z-Wave or AllJoin, it's described this way. We don't call it temperature. We call it something different. And instead of measuring in Celsius, we measure it in Millicelvin because it's integer. You can describe all the values. It's just an integer. Millicelvin, no floating point. I suggested this to OCF. They didn't like it. I'm not kidding. I did suggest like, are you crazy? Anyway, so you can actually come and describe other ways of doing the same thing. Now why would we want that? I'll tell you why. Because I actually want to create translations between them. So this website also supports describing translation, programmatic translation between one and the other. So if I go and create a bridge between OCF world. Remember I showed one of the first slides. We have transition technologies. We create bridges. We do it by examining the both sides. And somebody made the rules. So you divide by a thousand and subtract 273.15. The rule is there. So I know how to write the translation software. If possible, it actually generates code. We do have some prototype to generate JavaScript code. Most of the time it just puts on a comment saying this is what you should be doing. Please write the code. It's already, it's not everything. It's 100%. It gets you a long way around. We are, when we go to our liaison organizations, we go and tell them, hey, we would actually like you to work with us too. We would like you to host your IoT data models on this website. So we're coming up with terms of service that we're going to be acceptable to all of them. Some of them are going to be proprietary. So you have to log in to get some credentials to see some of the proprietary information for some of the other alliances and forums, for example. I don't know. And not happy with just this tool, we created the IoTivity project. So the IoTivity project is a Linux foundation open source by arrows changed again. What the hell happened with all my careful layout? I'm sorry, I lost train of thought. Yes, it's a Linux foundation project. We're using Apache 2.0 license. So if you're happy with that license in terms of what the patent grant gives you, you don't even need to join the OCF. Again, I recommend you do if you're a company because you get extra protections, you get to participate in the next protocol as well. And if you want to certify, I think you have to be a member. If you want to certify a device, you have to be a member. The project is very simple. So if you've seen, for example, how Yocto project works, it has an advisory board, an advisory committee, it's a number of people who are there to advise on non-technical matters. Everything else is left for the technical people, which I represented here in green. We call projects when it is something specific. We have a source code that needs to be done, or a section of source code, a module, a portion of the code. So we have somebody who maintains the discovery and connectivity. How do we work with finding other devices? And functions we call everything that works across the project. So we have a function for QA. Somebody is responsible for QA of the entire thing. We have a function for release management. Somebody has to release each of the different projects at some time. Meritocratic, fair, open development process. I'm going to show the vision before. Meritocratic is there. Fair is there. Open is there. And these are not anything you haven't seen before. We just want to do a good job in open source. You do not have to be a member of the OCF to participate in IoTivity. We have a couple of people who are individuals who like the technology. And every time I come to a conference, I get one or two more. I'm hoping to see some of you. They come, join us, implement it, and do something different. Try to do something we hadn't thought of. Why would you join if you're not a member? Well, you can actually go beyond the specification. You can create new things. So let me just give an example. We do have co-op over TCP. And the Bluetooth elite transport. That is not in the specification. The specification doesn't take this into account. So if you have a device that I tried to use with Bluetooth LE, great. You're not going to pass a notification. So why are we doing this? We're doing it to figure out where we should be going. This is experimental technology. All the bridge plugins are part... Not all of them. Some cannot be. But all of the ones we can are part of IoTivity. We're doing tests to figure out how to do cloud integration. As an example of an experimental technology that became part of the standard, we have the concepts called resource directory. So it is when a device registers itself with another device and stops listening on multicast. So the resource directory was something we created on the source code. We had more or less an idea we were going to need it. So what happened was that the source code went there, tested it, figured out, yeah, this is a good idea. It works. We went back and wrote the specification for it. So what you can do is you can influence on one side or you can influence on the other side. The two drive in parallel. And more than that, an important distinction between OCF and other groups that create standards. Like I'm going to pick on the Wi-Fi alliance. We only release the spec. If the reference implementation contains the code for it. If it's not on the reference implementation, you cannot require other people to do that. It might be an interesting technology that you wrote on the spec. Unless you wrote the equivalent implementation on the open source, on a open source, hopefully this one doesn't have to be, that technology cannot be required for others. The main implementation runs on Android, Linux, Tizen, and Windows. So we actually have Microsoft working with us on an open source project under the Linux foundation to support the operating systems. We're not restricted to that. Whoops, didn't take it. So we have the implementation for constrained devices. If you're interested in hearing more about it, there's a session later today at four, for ten, one of the rooms up there. So my colleague Kishan is going to be talking about it. It's been designed for scratch, for small devices. An example of the Intel Quark family. It doesn't use Malok. There is no single call to Malok in the source code. The reason for that is that I want to run on small devices that don't support dynamic memory management. Or I want to be real-time. So Malok is not deterministic. I just want to do a job fully compatible with the specification of the main implementation. Support for Linux, actually we have support. Support for Linux is mostly for testing so that we don't have to boot another operating system. It supports Zephyr. And I think that I forgot to add because it was only last week that he finished a port to Contiki. So if you're running Contiki, we already work on this and he has actually hardware working with it and you can talk to him later. We have an implementation for Node.js. And it's created in such a way that it feels home for Node.js developers. You use NPM to install it. And the API feels native, feels JavaScript. Here's the API. It's very simple. Based on promises and futures. I don't know if you're familiar with Node.js. It probably should be because it's taking over. I don't like it. I'm a C++ developer. So my talk on Thursday is about C++. But I see people using Node.js a lot. Based on simple promises, futures and events. Let me just give you an example. This is a Node.js client of Iotivity. So what it does is that it... Where's my mouse? Here we go. Imports Iotivity node, configures itself as a client, right? Then it will find resources here. This was just very simple. You can actually pass extra parameters describing what you're looking for. So who's a toaster? When a resource is found, run a Lambda. It will print some information. Check if it's the resource I was looking for. So don't do this. This is not the way to do resource research. You should put the requirement here. So you don't flood yourself with information back. This was only here. So we actually printed everything we found on the network. If it was what I wanted, I'm going to retrieve information about it, right? Then run a function. So it's a promise. Change a property and then update it. And if that is done, once the update confirms that it was done, it will exit. So this is less than 20 lines of code. I wrote an Iotivity client. The server is no bigger than this. Of course, there's a lot of code behind the scenes. But this is how we meant it to be simple. We also have a couple of other projects. So like I said, we have bridges to UPnP now. We have bridges to the all-join. You saw we'd merged. That was why. We were working on making the two technologies come together. We have a common direction forward. But I want my devices that were on the other side. So they have their all-join devices. They feel they find everybody else on the network. Testing tools, simulation, a couple of other things. So to finish, I'd like you to get involved. We have the open source project that's Iotivity. You can join. You don't have to be a member. We have the one Iota tool, which is, again, free and open. And at least our specifications are free and open source. Again, you don't have to be a member. You can just come and participate. And we have the open connectivity foundation, which leads you to the certification. That one is a paying foundation. Actually, individuals can join as well. I don't know how much we... I don't think individuals are... It's free. Yeah. So you can actually be as an individual, a member for free of the OCF. There are certain restrictions. If you're a part of a larger company, we actually invite you to join as a gold, diamond, or platinum member. So that's it. Any questions? If you have a simple scenario, two light switches and one light bulb, you define some kind of scenario for the light bulb on the one switch, where is it stored and can I access it from the other light switch too? So you're asking... I'm just repeating because we're being filmed. You're asking where the data is stored. Your question was mostly on I5, two light switches and one light bulb. Can I access the information? As an example, I have parallel switches. They both control the same light bulb and I want to toggle it instead of... I pressed it on. It was already on. It doesn't do anything. So basically it's what I said before. The smart device needs to be as smart as the dumb device. The protocol itself does not say anything. This is implementation detail. As in the sense of... If I'm writing my application, I need to figure out a way. Now, if you ask me how I think this is going to go, I actually expect that the light bulb is an OCF resource. It's a server. It sits there passively. The light switch is a light bulb. It's an OCF server. It stays there waiting to be discovered. It announces when you press the button and says, hey, I was pressed. So what I expect is that there's another device in your network that actually does bind everything together. Because if I buy a light switch, I might want to control something different than a light bulb. I might want to control my garage door or the sprinklers or the pump that refreshes the water in my swimming pool. So that functionality is not going to come programmed into each light bulb. What action it takes is something that I'm going to write. So I expect there will be another device in my network, usually your router, because it's in a central place, that receives all of that information, stores the state, and then sends the command off. Because I might want to, for some crazy reason, change the light bulb, which light it turns on depending on what time of day it is. Here's what interesting about this. If this device, which I'm looking at, I can program it. I can hold this morning on the keynote with Node-RED. So if I have Node-RED or an equivalent technology, I can just connect the multiple sensors, and light switches are nothing but sensors, like contact, toggle. Some of these, you flip them. Some of them, they come back to the original state. The point is, I can connect that to different things. I can do interesting things. I can send to the cloud how many times I turn the lights on and off. If I'm getting a reading from the energy company on how much the energy costs, I can turn three lights on instead of just one, if it's cheap, and it's night. So that technology, that information, I expect to be in different devices. I can write my own applications, and hopefully I'll also be able to download some of your interesting ideas and put it on my own device. Did I answer? Yes. So the question is, this rule engine, which I just mentioned, can be Node-RED, can be an FT-TT, can be something different, can be a Java, Node-JS application. Node-JS again. Should we standardize the way I communicate with it? I'll tell you this that we have not, because it hasn't come up yet. But personally, I think yes, to some extent. I don't want to standardize everything because I want to leave innovation for the people who create the rule engine. So if I go to MediaMarket, or I go to Best Buy in the US, and I buy this simple router, it's going to have only a basic interface. I might want to buy a more expensive model that has more information, that has connectivity to the cloud and gets information from... The example again we saw this morning, integrates with Alexa. So I can tell you what to do. It gets the information from my phone, where I am and automatically turns the AC on. So that extra functionality, we probably cannot standardize everything, and we should leave as innovation avenues for the different manufacturers. But yes, we should have something standardized. I really think that these rules engine devices are going to be very important, and therefore should deserve some attention. Is that a question? Okay. Any other questions? So I'm here for the rest of the week. Oh, sorry. There's a question there. So a binary switch. Could be, yes. Yeah. So how could we standardize as a developer in the developer perspective, if I had different features on different light bulbs, that would mean I would have to develop plugins for a central app or plugins for my router or plugins for something else if I want to implement that functionality. So the question is how do I connect the multiple devices with things that were not with special features, but basically with features that had not been... Not standardized, not mandatory. Not standardized, not mandatory or simply did not exist at the time whoever wrote the code. So that's a very good question. There are two things about this that is important. First, it is that we are creating for the next version of the spec called introspection. So you ask a device, what are you? What information do you have? Not just which properties it has, but also some human readable descriptions. Oh, this is the party mode. So that allows me to, when I'm looking at my rules engine that discovers everybody in the network, it says those light bulbs have party mode. And this is what they mean. Here's a link to the manufacturer's website to get more information and things like that. The introspection allows us to find the things that the device has, even if they did not exist at the time that I bought and installed my rules engine router. The second thing is that, depending on how that device works, it doesn't matter. It can be either a download, it doesn't have to be a plugin, it can be simple as what we saw this morning with Node-RED connecting boxes. I can have a web interface to my router, just go there, drag a few things, and now I have something new working on FTTT. This is a bit more advanced of what we're getting to. I want to get there, definitely, and I think this is my vision, mine, a couple of other people at Intel, most of OCF as well. This is our vision of where IoT needs to go. Smart home, yes, we're going to see slightly different on other industrial segments. Point is, we had to solve a different problem first. How do you find the device? How do you communicate with it? How do you represent the information? How do you get its own description? We had a couple of different problems to solve first. But once we're there, we start to look at the next problem. I think that's it. Do we come around to the beginning where every manufacturer is providing extensions to the protocol? Hopefully not, because we actually want to learn from you. We had an example of washing machines, and each washing machine has a different name for each of the features. We had manufacturers, no, no, no, mine isn't that which you standardize. It's something different because ours is better. We have to balance in such a way that manufacturers can have differentiation, but at the same time, we have interoperability communication. This is what OCF is for. For all of those manufacturers to get together and decide this is the common thing, this is such a way that it will work for everybody, and if I just want to turn light bulbs on, they're all on. We do want to keep the ability to differentiate, which does create back the original problem, but we're much further ahead from where we were in the beginning. So I'm out of time. Thank you for joining. Like I was saying, I'm here until Thursday evening. You can reach me by email or Google+. And I'm happy to answer questions outside, and by the OCF booth, Intel booth, or the Zephyr booth, where you find me. I'm happy to talk to you.