The weekend just passed saw the annual gathering of the UK's Open Source Hardware enthusiasts for OSHCamp. Back in Hebden Bridge for a second year, this time it was intertwined with a host of web talks and going under the name Wuthering Bytes.

The talks were filmed, so hopefully will be available soon. In the meantime, here are so you can compare what I said with the slides and notes from the talk...

Thanks for inviting me to speak here today.

Hello, I'm Adrian McEwen. I run an Internet of Things studio called MCQN Ltd., I'm CTO of Good Night Lamp, and obligatory book plug I've written a book to help people make connected devices of their own, called Designing the Internet of Things.

It's being published by Wiley in the autumn, and you can pre-order it on Amazon now.

First off, what exactly is the Internet of Things?

It's the next wave of development in the Internet. First we got computers online, then phones, now everything else...

Sensors to measure how much chicken food is in a silo on a farm...

Machines to watch Twitter and blow bubbles whenever a keyword is mentioned...

Internet-connected lamps which let you stay in touch with loved ones, wherever you are in the world...

Radios that alter what they play depending on when and where you are listening...

Sounds wonderful, doesn't it? And it could be. But before we settle down to await our amazing future I want to tell you a story...

About ghosts of networks past, present and future.

Most of you won't be old enough to remember this, but back in the late 80s and early 90s, when companies first started getting email, it wasn't guaranteed that if you worked at one company you'd be able to send an email to your friend if they worked at a different company. There were lots of different email vendors, and they didn't interoperate. When it first arrived in business, email was a way to replace the corporate memo, not a way to talk to customers or suppliers.

And it wasn't just email. Discussions forums and information services were provided by companies like CompuServe and AOL. You'd have an account with them, and dial into their service to chat and find things out. Movie posters used to tell you the AOL keyword to search for to find out more. But if you were an AOL subscriber you'd only be able chat to other AOL subscribers, and you wouldn't be able to access any of the information services on CompuServe.

As the web took off, they each started giving limited access out onto the Internet until eventually they effectively became just ISPs, giving you a route onto the Internet, where you could then go and get all the information you wanted from other people.

And in the late 90s, although the web had swept away the old walled garden services like CompuServe, as the mobile phones started to get online the guys who developed WAP persuaded everyone that phones weren't powerful enough to talk to the web directly. Traipsing down the dead-end that was WAP, where you had to either learn a new set of technologies or as a user put up with mangled websites that had been through a gateway proxy, stunted the mobile web for almost a decade.

Okay, that's the past. But the mobile web has caught up now, and everything's fine now, right?

Well, there's similar level of confusion and uncertainty around the Internet of Things. There are good reasons for that - the Internet of Things cuts across so many different fields, with different challenges in terms of power usage and bandwidth. There are also the issues around managing so many devices - how do you get them on the network in the first place when you don't have a screen or a keyboard? How do you manage the interactions between them? Should there be interactions between them?

The easiest option is Ethernet. The cable means you don't have to worry about network IDs or passwords to connect to the network, and in most cases the rest of the configuration can be done automatically.

However, the cable is also the downside. It means you need to run Ethernet cables to wherever you want to deploy your devices, or otherwise you're just shifting the problem elsewhere.

Wireless communication naturally solves the Ethernet cable problem, and WiFi is the obvious existing solution to that. It's pretty much ubiquitous, but brings with it the problem of choosing the WiFi network and entering the passphrase if your WiFi is secured. Plus, if you're seriously constrained in power consumption, WiFi might not be the best option as it's focused on higher bandwidth rather than lowest power.

One option is to support more than one technology. The Smartthings hub, shown here, does that. It's got WiFi as well as Ethernet, but more importantly has both Zigbee and the Z-wave radio stacks, which are aimed at low-power, sensor networks or home automation. However, that adds to your costs - all those radio modules - and also needs you to provide an extra gateway/hub device to bridge onto the Internet proper.

A number of companies are trying to find ways to make things easier for people, but they're all positioning themselves as the one-true solution to the Internet of Things. It's perfectly natural, but I'm not sure it's healthy.

This is an Electric Imp, well, the little white SD card shaped module is. They're using standard WiFi for networking, coupled with a smartphone app to do the configuration (it flashes the screen to convey the information across). However, access to the code that runs on the modules is only via their servers. What would happen if they decide they don't like what you're doing, or if the company goes bust or is sold and the service is turned off? Re-engineering your product would be a huge task.

BERG have taken a different approach with their BERG Cloud service. They only provide the communications channel and device management, and have a system built on Zigbee rather than WiFi. That means that you need an additional box - the Bridge - but they've removed the need to enter any configuration details to get it on the network. The devices don't care whether they've found your Bridge or your neighbours, as all connections lead to BERG's servers anyway.

They make sure the connections are all secure all the way to their servers, so you don't have to worry about snoopers before that point, but are still gatekeepers (and a potential huge man-in-the-middle attack) for all of the connections they broker.

So, what does that signal for the future?

Either the Things in my house can't talk to those in your house because I've chosen all BERG Cloud devices and you went with Apple...

...or Argos has a whole new furniture section selling network hub cabinets to hold your BERG Cloud bridge and your SmartThings hub and your Apple iThingsPort and your Google ChromeGateway

Not that I think that we all need to head off in one direction. There won't be one solution for all of the problems facing the Internet of Things, just like there isn't just one solution for all of the problems of the Internet.

We should acknowledge that there will be multiple network technologies, and multiple protocols, and aim for interoperability between systems at all levels. All of the services I've talked about understand this at the web side of things - they've all got APIs to let you connect many things to it, yet many of them fail to extend that to the device end.

We should be heading towards that panoply of devices so, for example, the guys at BERG should be working towards letting the Little Printer talk to the SmartThings hub, for example, and vice versa.

Maybe we should look to the web and the Internet itself for ways to help frame the journey

Assume that IP is going to get everywhere. It's been a good enough bet for the past thirty years, no reason why it's going to stop now. If your specific application has really particular needs that the standard IP family doesn't address, follow the lead of (or join) groups like 6LoWPAN to help grow the standard protocols to encompass what you're doing.

Take the approach that gave us the Internet. Don't aim for one interdependent monolithic system, but rather break the system into smaller inter-related systems that are more flexible.

All of this might sound like I'm suggesting we need to come up with a new standard to solve all these problems.

I'm not. Let me repeat that. I'm not.

We have most of the standards that we need to build the Internet of Things. The ones we don't have will be for specialised applications or for specific aspects of device management or interoperability. But only in the same way that as the web evolves we discover new problems to solve. No-one (sane) is suggesting that we need one new protocol to solve all the problems of the web, yet I keep reading articles where people are proposing that as the missing piece in IoT adoption.

What we should do instead is that groups with those problems gather together and iterate through to implementations. The guys who built Oauth didn't declare that they're coming up with a new standard for the web, they said they're fixing the problem with authenticating with other sites without sharing your password. When the RSS format was defined, it wasn't a new standard to replace the web, it was a way to share new chunks of content.

So, to summarize - we should encourage and work towards interoperability between Things and services at all levels of the stack, both on the web side and the device side; we should work together to define new standards as we need them, when we're building them (not before); and most importantly, we need to be making more things!

Thank you for listening. Any questions?