 All right, welcome everyone. Thanks for being patient there. I always find technical problems at a technical conference the most funny to endure. So welcome to avoid the silos and help build the true internet of things. I'll rush through some of the earlier slides, hopefully get to more of the meaty stuff later on in the talk, so you don't miss out. So first the introduction, my name is Aaron Vernon. I'm the CTO at Tubals. We're a digital product consultancy. I've been at Tubals from the beginning with a few different stretches away at various startups. That was CTO of Blockify, a 3D printing for kids company, and VPS software engineering at LIFEX, the connected light bulb company. I'm also a member of the All Seen Alliance Technical Steering Committee. And today I'm gonna be covering the following, the complexities of the current IoT landscape, how this affects companies and users, the internet of silos example, and then finishing off with how we can work better together. So firstly, I have a few slides on transports. This is mostly revision, I would assume for most people in here, but just starting out from the lowest level of IoT, there's various different transports that you can use. That's the first area in which you start to have to make decisions as either a consumer or as a product designer. So obviously we have Wi-Fi, which uses 802.11 standard. It's got great range, great bandwidth, but it has high power consumption and it's high cost. Some examples of Wi-Fi devices are like the Nest Cam, Lifex, Canary, and the Honeywell Lyric. Next you've got Bluetooth Smart. It's become quite ubiquitous on mobile devices, but it's low bandwidth, medium range, but the big advantage of it is low power consumption and low cost. Some examples of that are the Flick, the Illumi and the Elgato Eve. Next you've got Zigbee, which is an older standard that's kind of still around at the moment, which uses the 802.15.4 mesh standard. It's low bandwidth, low range, low power consumption, very low cost, forms a mesh network, but it's known to have interop and interference problems. Some examples of that are the Philips Hue. Then we've got Zedwave, which is quite similar in the kinds of products that you typically find it in, but it's proprietary, so it's all owned by one company and as such you tend to get away from the interoperability and interference problems, but also low bandwidth, medium range, low power consumption, low cost, but you are locked into just that one manufacturer and it also has to use different frequencies in different countries, which can be quite annoying. Quite a lot of sensors and actuators use Zedwave, particularly in the home security sector. Then you have Thread, which is an up and comer in the transport space that uses the 802.15.4 standard and Six LowPan, which is low power IP over personal area network, and it can be bridged to the cloud relatively easily because you're talking a cut down version of IP on the local network, and then you can kind of wrap those packets and send them up to the cloud. It's low bandwidth, medium range, low power consumption, low cost, so it's got a lot of those advantages of the ZigBee and the Zedwave, but it's more of a forward thinking transport. It avoids a lot of the interference and the interop issues. It was open sourced earlier this year, which is great, and you're seeing it in a lot of Google and Nest type products. It was originally a project that Nest worked on before they spun it out and now eventually turned it open source. Last on the transport list, you have a Notion, which is something that we personally think is really cool. It's ultra, ultra low bandwidth, so we're talking like a packet being sent. And it uses energy harvesting so that it has no power consumption, just differentials in air temperature or kinetic energy from a finger touch on a switch is enough to fire off this packet so you can have these sensors and different IoT devices in the home that don't use power. Moving on to protocols and ecosystems where it starts to get a little bit more interesting. So I gave this talk about six months ago and I've updated the slides and kind of strike through the things that have changed and given a bit of an update of the situation. And the good news is that we are getting into a much better position, which is very, very exciting to see. So at the time, there was two competing Linux Foundation open source IoT projects, IoTivity and AllJoin, and I was like WTF. As of this week, the insanity is over, so I think we can all celebrate the fact that there is now one less open standard in the IoT space. OCF, Open Connectivity Foundation, is now the one specification and they sponsor both the AllJoin and the IoTivity project under the Linux Foundation. Current devices running on AllJoin or IoTivity will be interoperable and backward compatible. Not exactly sure how that's all gonna work yet, but that's at least the mission that they're driving towards, which is great. And a great step forward for IoT. I still think this is gonna put IoT back a little bit, just there's gonna be a bit of turmoil with obviously having to build bridges and adapting things over. So I think it will set us back maybe six to 12 months, but at least we're in a much better strategic location to move forward. A lot of great thinking went into common device models in 16.04 in AllJoin, something that I was heavily involved in and the team from Tubals. That went on into 16.10, and so that will still be released as part of AllJoin, but we're really hoping to bring the best parts of that over to IoTivity and OCFs, the best parts being groups and presets and scenes, and lots of really great demo code to help developers very easily either ship a consumer experience or a new device. So the prominent members of OCF are a lot of the big names in IoT, Intel, Samsung, Microsoft, Qualcomm, Electrolux, Cisco, G, Digital and Technicolor. So it's great to see all those big names now cooperating with each other. Weave, at the time when I spoke last, there was two versions of Weave. There was NestWeave and there was GoogleWeave. Once again, lots of positive movement in this space and Google seems to be unifying its IoT efforts. Most notably, you would have seen in the news the core platform team from Nest now works for Google. And I think that's a really strong move for Google to make sure that all of their IoT technology is built on the one stack and they're all focused in the same direction. I also think it's a really good thing for Google to bring across both the great aspects of these two different technologies. So NestWeave was coming at things from a low power, low latency perspective. They were using thread underneath. But it was very much in a walled garden. You had to work with Nest. You had to go through certification process similar to what you would find with an Apple product or service. Google was coming at it from a Google Cloud perspective. So it's all that cloud provisioning using the Google Cloud infrastructure and also easy to use for a developer, which is obviously very important for a protocol such as this. It was also a very heavily REST-based resource model similar to what you find in an OCF type standard and initially focused on Wi-Fi and BLE. But it was kind of too heavy weight. NestWeave's too lightweight. And from what I hear and see, they're moving somewhere in the middle, which I think will be really great. But unfortunately, once again, we're gonna probably have to wait another 60, 12 months to really see this stuff make a big difference. Apple HomeKit. So you really can't talk about IoT without talking about HomeKit because consumers want it. They're always screaming for it. I know when I was at LIFX, we pretty much 50% of our inquiries was like, when are you gonna support HomeKit? And unfortunately, Apple makes it very, very difficult for device manufacturers to support HomeKit. You have to update your product, create a new SKU, which includes the MFI chip, which is an Apple tax essentially that you put into your device to make it more secure. And that has ramifications on your supply chain. It has ramifications on your base costs, your bond costs of your product. And at the end, then you can get into the Apple HomeKit ecosystem. And if that ecosystem was thriving, then maybe that would be something that would be worth doing. But at the moment, it's still in its infancy. The situation once again was much worse six months ago. HomeKit wasn't available on anything other than iOS. It's now available on TVOS 10, which is great. There was no killer app from Apple. We now have the Home app and early reports of that say that it's quite good. The ecosystem of the available devices, though, still needs to grow quite a bit. And I think having the Apple TV or the iPad still required in the home is a little bit of a difficult thing to sell to users. They don't really understand why that needs to be the case. When we talk about protocols and ecosystems, a lot of the transports that I talked about earlier, they also have application level profiles. So, you know, there'll be a Notion profiles, Zipi profiles, Z-Wave profiles, Bluetooth profiles. What you'll tend to find with these is they're quite scattered. They're not widely adopted. So, if you adopt some of them, you might get some percentage of the market, but you certainly won't get all of it. And each time you're integrating with the new transport and new profiles, you're obviously adding a lot of complexity either into your device or into the application that you're making. The last one that I talk about when talking about protocols and ecosystems is Samsung SmartThings, which doesn't really position itself as a protocol or ecosystem. But I mention it because it does have a lot of mind-share in the consumer's head at the moment. And that's because it works. You can buy Samsung things together with Samsung apps and the ecosystem will work. And that's predominantly because it's a very curated environment and because they're focused on use cases first. They haven't focused on trying to own the whole platform. They've just done their thing and they've sold the use cases to users. And I think that's something that's really important and I certainly come back to it later on in my slides. So when a company wants to get involved in IoT, what do they currently have to do? Well, for the purposes of this section, I'm going to reference transports, protocols, ecosystems, all of that as stuff. It's stuff that isn't your differentiating factor in your product. It's stuff that you should need to have to do. It's just stuff that is table stakes for IoT. So a company wants to make an IoT product or service. They spend a large amount of time building and maintaining this stuff. There's limited amount of stuff that they can physically fit in an embedded device. Users are confused about what stuff they even need or want. And at the end result is the company struggles as most of their time they're working on the stuff rather than the actual differential value to their users. But what happens when a user wants to get involved in IoT? Well, a user is enticed to buy a starter kit from an ecosystem. They see the advertisement and they want to go out and buy that product because that product gives them the use case that they want. The learning curve is steep but eventually they get everything onboarded and working. A new device comes out that they really, really want but it does not work with the ecosystem at launch. Regardless, they go and buy it. They learn a new way of doing things. They onboard it. They control it. And to get the full benefit of that new device they buy more devices to go with that new device. Repeat this process a few times and now the user has several competing ecosystems, multiple device silos and a bunch of apps that all function in a unique way. And then we wonder why consumer IoT hasn't taken off yet. So that brings me to the internet of silos which is like a dooms day example of how bad we are right now in IoT and what would happen if this was the internet. So imagine for a moment that HTTP never came to be and the internet was like IoT right now. It would take 15 minutes to load your first website, three hours if you had certain types of routers. Every time you click a link you would have to install a new browser to consume the content. Sometimes you may even need to purchase and plug in a new dongle just to follow the link. When you want to read the news, forget of which of your 10 browsers that all have different UI, UX you need to use. There would be the W3C and the W3A and both would contain roughly the same companies and claim to be the only way forward. Yet everyone would keep telling you how fucking awesome the internet is. So how can we do better? We can look at that, we can laugh but sadly that's the situation we live in right now. So how can we do better? Well, I was gonna fill this slide with the utopian vision of what true IoT looks like but the truth is most of us already know what it looks like. It's why we're in IoT, it's why we build these devices, we build these experiences. We wanna enable these exciting things for real life consumers. So that's not the difficulty. We know what we wanna build, we just need to build it. We need to do better. So as I said, evident from the presentation but if we wanna be the multi-billion dollar sector that the world is expecting us to be we need to reach mainstream consumers. We need to reach more than hobbyists, more than tech geeks. The mainstream consumers is what's gonna bring the big bucks to IoT. And idealistic but if we grow the space together there'll be enough revenue to go around. Stop trying to be the platform and start contributing to a real ecosystem. Remember the users, it's all about the use cases. If you don't have use cases, users aren't interested in us. So make sure you're trying to deliver those notable use cases. Most mainstream users don't even know what IoT is and if you talked about an IoT device they may have some in their home that they wouldn't necessarily call them IoT devices. So let's stop thinking in this IoT and high tech and connected devices way and just start thinking about how can we deliver real use cases to real users? Solve real problems. So one way in which we can work together is with an open source protocol. So the ideal way forward is a simple open source protocol and cross-platform framework that exists outside of all the world gardens and bridges between them. It's my strong belief that these world gardens are always going to exist. You're always going to have your Google. You're going to have your Apple. There's going to be other kinds of competition out there. Maybe some telecoms might get involved and we need a way to bridge between them so that the IoT ecosystem actually works. This would provide a lowest common denominator for IoT. So once again, I'll go back to at the time there was these two competing projects. To be honest, we're actually a lot closer to this one open source solution than what we were previously and we must pool our minds, resources and efforts to bring us even closer. So in that kind of a scenario, you can see the different protocols around the outside in the circles and there's some kind of open protocol X that you can use to talk between them. And I like to bring it back to this, keep it simple on this, right? So at its most basic level, the open source solution needs to contain schemers for devices and the ability to transfer these schemers across a network using different transports. It should be focused in my opinion on IPv6 over Wi-Fi, Thread and Bluetooth Smart because that gives a good mix of ubiquitous technology and forward thinking technology between high power, low power, high cost, low cost. And Thread and Bluetooth Smart are also able to achieve IPv6 over 6 low pan. So it means you can be talking IP or a variant of IP across your whole open protocol stack. And given the focus on IP, the cloud can then be layered on top using an MQTT or a co-app using a gateway node. Anything else on top of this is nice to have. If we can't get this right, then we don't have an open source solution that works. So I think that should be the primary goal of anyone who wants to start contributing to an open source protocol solution. Just sketching it out a little bit further into, once you have this protocol, this is the kind of real ecosystem that you can start to support. So you can see I've got kind of three high level buckets of the different transports. You've got Thread, Bluetooth Smart, and Wi-Fi. I've substituted OCF in here, just hoping that it will become true and it will become the thing that we can all start talking. You can have a node native OCF device. I think there is a little bit of work at the moment to support OCF on Thread, the beginnings of it are there. Also on Bluetooth and then Wi-Fi. So these are native devices speaking the open protocol. And then you can have other ecosystems that can bridge through to that open protocol with the little white circles here. And then once again, as I said, you could have MQTT or co-app bridge through a gateway node to the cloud. And so you can have all these different closed world gardens. You can have native devices, you can have foreign devices, but you can have an ecosystem that does all talk together. And I think if we could achieve something like this, then all of a sudden IoT will actually start becoming more of a real thing for real users. So what if that doesn't happen? What if a open source solution doesn't happen as far as the protocol goes? Well then in that case, we strongly feel that the fallback should be an open source translator. So to be honest, we actually feel regardless of how the space evolves, that this open source translator is gonna be a very integral part to IoT. Once again, because you have all of these different protocols, they're going to exist, there's gonna be world gardens, there's gonna be open gardens. But if you have a single place outside of any kind of closed ecosystem where these translators can be worked on in an open source manner, you can start to bridge together the whole of IoT much more easily. So when I talk about an open source translator, what do I mean? It would essentially be a cross-platform solution for plugging in different protocol translators. So we could go OCF to Weave for a light bulb, or Weave to all join for a switch, as some examples. When I ever talk about this translator, I'd be very careful to make sure that it comes across. It's not yet another protocol. This is a translation from one protocol to another. There will be some kind of schema in memory, but that's not a public schema. That's not a schema that is documented as being another standard. And also, the other tricky thing about translators is security. So obviously any kind of translation from an application layer protocol to another application layer protocol is gonna break the application layer security. And I know AllJoin has very comprehensive security 2.0 application layer security. I know OCF has plans for something very similar. Google's obviously very interested in security. So this is gonna be a tricky one. We've had some brainstorms. We think we might have a few different paths forward, but I do believe there will be trade-offs. So obviously an open source protocol is gonna be a better approach, but if we had to go down the translator way, there might be some workarounds where we put more of the onus onto the user, essentially having more visibility of the things that they're allowing so that they have more control. Early prototyping has shown that if we loosely coupled the translator plugins, then they could be easily developed on different platforms and in different languages. And I think that's something that's really important to make sure that the translator could get open source code contributions. So this is what that would kind of look like at a high level. So on the wire, you can see that the different protocols are still being spoken, but then you've got a translator in the middle that is translating between them. So final thoughts on working together. Get involved, come to conferences and share your knowledge. Get involved in open source projects. Even if you don't commit code, I think it's still great just to be involved and share the perspectives of your company. I know it was the case in the All Scene Alliance, and I'm assuming will also now be the case in OCF and the All Join project as it continues in its new form, is that we need the perspectives of real companies. We need device manufacturers to speak up, app developers to speak up so that we know what we're building, who we're building for and how we can tailor it and be just right. And of course, code contributions are always very welcome. You should try to focus on developing the core value of your product and service and leverage existing technology for everything else. I mean, that's just basic software engineering, but I feel too many of the IoT companies out there at the moment are trying to reinvent the wheel, trying to own the platform rather than focusing on that differential value. Just to note that this is how Web 2.0 and Mobile Technology Ways were so successful. There was a huge reuse of technology and allowed companies to move very rapidly. We have the power. So as engineers and product managers, we actually hold more power than we think. We're the ones that build the future, so encourage your companies to think about the success or failure of IoT on a larger landscape. If your company is trying to build the platform that's going to take everything over, really press the business for why they are trying to do that and why, what is the differential product value that you're trying to provide. And that's it, thank you. And that's my email address up there if anyone wants to contact me. Did I run on time in the end?