A few years ago I was meeting with a small wireless interconnect company called ZeroG Wireless, and the discussion included a vision of machines and devices and appliances and people interacting via this huge, messy, chaotic structure we refer to as the internet. And all of the vagaries and un-thought-through possibilities and the promise of things as-yet unimagined were neatly wrapped up in a succinct little phrase: the Internet of Things.

I loved how descriptive the term was; I hadn’t heard it before then, and it was a long time before I really heard it again, so I frankly thought they had come up with it. Well, I no longer think that, and, having just returned from the Sensors Expo, I can safely say that the Internet of Things was at the top of the agenda (above sensor fusion). It’s frickin’ everywhere.

The question is, how does it work? How does a maker of a thing enroll his or her “thing” into this much vaunted IoT? I mean, all of the hardware and infrastructure are in place for anything to talk to anything at any time; how hard can it be? *

As you might suspect, it’s very hard for your average dude who is not thoroughly imbued with the details and nuances of everything that happens on the internet – and who doesn’t care about that crap. Well, a new company called Ayla Networks is trying to make that easier – and, ironically, the CEO has ZeroG as part of his pedigree. I can’t decide if that’s a random quantum fluctuation or if there’s some cause/effect, but there you have it.

Before we talk about what they are proposing to do, let’s start by drilling into an example of a problem to explore where some of the complicated bits might lie. And believe me, we won’t get anywhere close to the detail that would be necessary; my goal is to get you nearer the messy bits just to put your nerves on edge about the kinds of things you’d need to consider.

Let’s say I’m going to make a smart thermostat. Yes, we’ve all heard about the one you can turn on and off remotely. That’s so 2000s. This is going to be even more awesomer. You see, people have things like delicate orchids and rare tropical fish. So saving power by turning off the A/C or heater when no one is home is good, but not at the expense of the fishies or the flowers. So here’s one use case we can work through: the homeowner can program in times for the temperature to come up to comfort level, and he or she can override that by “radioing ahead” to say “I’m coming home” so that the system has time to adjust the inside temperature. But here’s the cool part: they can set an alarm level so that if it’s a really hot day and the inside temp gets too high, even if they’re hours from coming home, it can send an alert and the homeowner can approve (or not) whether to turn on the A/C early.

Now, critical question: how to send the alert? Well, we may have to be flexible there since not everyone has the same equipment. Of course, we have to have a smartphone app because anyone that’s cool has a smartphone and cool companies have to have apps because everyone is doing apps and we want to be cool so we have to have an app. It’s also a really useful way to do this. So that one’s obvious.

But there are people that opt for older style phones with no data plan; apps won’t work on that. So we need to sell to these folks as well, so how about we send them a text; we can use a text response to tell the thermostat what to do.

And finally, for those people that may be traveling internationally, their phones might not work if they didn’t set up international data (or it’s too expensive), so we could… hmmm… this does get a tad messier: how about sending an email that they can read when they log in and then a website to log into to provide a response? That might delay things, depending on when they check in – it would be better to send the little man with the bell around poolside to deliver the message, but that’s hard to automate – and the damage might have already been done by then, but we should provide it as a deprecated last option.

OK, so we have three notification options: app, text, and email/website. Great. Now: how do I do this?

Well… building this all into the thermostat is looking a bit nasty. I would need a way to get into the cellular network to send a text or communicate with the phone app. I need to get into the internet in order to send the email and communicate with the website. I just can’t see putting that much connectivity into the dang thermostat, and I certainly don’t want it to have to have its own phone number, so that’s not going to work.

So now what? Well, what about the cloud? I can use the internet – say WiFi – to get to the cloud. Then maybe I can figure out how to send a text or email from the cloud. So let’s see, I need to find a cloud provider, figure out how to allocate servers (How the heck many do I need, anyway? And do I need to load balance and add/drop servers in real time?), and then write my software.

And that software has to have a low-level way to communicate with the thermostat and phones and website, it has to manage the sessions, and then, at the very top of the stack, it has to execute the business logic that takes information from the thermostat and other devices and does the right things with it.

Specifically, we have a couple of choices. I could make the thermostat a little fancier and include an alarm feature. If I did that, then the thermostat could send an alert to the cloud; the cloud would then forward the alert to the phones (or whatever). It would take the response and then command the thermostat to turn on the A/C if that’s what the response dictates.

Another option would be to have a cheaper, dumber thermostat with no alarm feature; only turn on/off commands and the ability to read the temperature. In that case, the cloud might need to ping the thermostat every, say, ten minutes and then, if the critical temperature is reached, the cloud generates the alarm and we proceed as before. Heck, I could even get fancy and ping every couple of hours unless the temperature starts to rise and then, as the limit is approached, ping more frequently. I could call that “Intelligent Polling” or something awesome.

OK, so I gotta sort out all that crap. Frankly not sure how to do any of it – I’m a thermostat dude, not a bricklayer! – but I’m sure a bit of Googling will make it all easy.

There’s also the bit about the phone app. Need to write that. Not sure how to do that and how to get data to and from the phone… It’s gotta be easy, given all the apps that are out there. Not going to sweat that one.

I will also have to figure out how to take a return text and parse it to decide whether the user approved turning on the A/C or not… and figure out how to retrieve that response and what the data format is so that I can parse it…

Oh, and the website: need to build that and have it interact with the cloud stuff. But everyone does websites these days; they’ve got to be easy as pie (says the guy who never did one before).

Ah! And then… there’s security. Yeah… Oh crap…

Any of this have you wondering whether this is really going to be the picnic you’d like? I’m sure there are a million more details that haven’t been broached in the above musings. And we haven’t even talked about costs or business model issues. After all, we’re in a time when everyone everywhere along the way has their hand out for a piece of your revenue stack. Going at this ad hoc, you run the real risk of everyone else eating your cake and leaving none for you.

This is the problem that Ayla Networks is trying to solve. Their goal is to abstract away all of these details by pre-baking pieces of a solution that provides the flexibility for you to design stuff to work the way you want without having to invent (or, really, re-invent) all of the low-level parts needed to make it work.

Specifically, they say they provide “all software for networking, security, cloud infrastructure, and application networking.” That’s the bulk of the nuts and bolts required to get all of these pieces to talk to each other – and to do it securely (you don’t get an option to do it insecurely). You get a driver with the chip or module you purchase, and you have your thermostat microcontroller talk to it; the driver abstracts the rest of the communication away.

You still have work to do. The business logic, for instance. But this is done with business objects in the cloud to abstract away details. Some are in place already; if not, you can use a Domain-Specific Language (DSL) to define rules that are processed by their rules engine.

You also need to get an app developer to do the app and a web developer to do the website. But they also can work at the upper levels, focusing on presentation and business logic. The communication is handled.

Then there are the analytics. You can generate data for storage in the cloud and access it and other data for use both in the business logic and for understanding how people are using your system. The data is anonymous – Ayla does seem to be very aware of privacy sensitivities, and they are saying things that sound non-evil. But there is this whole big-data side of things that they are helping to manage.

I’m not going to dive into the next level of feature details, like single-step device registration or LAN autodetect or other such capabilities intended to provide an easy use experience for end customers with a minimum of required development work.

Finally, there’s the question of money (a topic that, admittedly, I don’t get into that often). Again, Ayla could appear to be just another hand trying to tap into your revenue stream. But, at least for the basic stuff, that doesn’t seem to be their strategy: they’re asking for a single up-front payment. (They do have optional premium services… I didn’t pursue those…)

Now… those of you with a keen eye and a sturdy memory may see some resemblance between this and Imagination Technologies’ FlowWorld. I checked in with the Imagination folks, and they had an interesting perspective. It felt to me like they were more focused on content, but in fact they say that’s not really what they’re working on. They claim to provide the integration that Ayla is announcing – which goes from device or module to the cloud and back out – but that they also integrate all the way down to the IC level, by tying in the IP cores that will participate in this chain of communication.

Of course, that benefit really only accrues to those with pockets deep enough to fund an SoC, which leaves plenty of folks using simple microcontrollers today. On the other hand, Imagination’s position is also that, in order to fulfill the promise of M2M communication and co-operation, designers will need to create custom SoCs optimized to the task; microcontrollers won’t cut it.

At the very least, we have a battle here. Or the makings of a battle, anyway. Which is usually a good thing for designers as each team vies for their favor. And this is where those second-level features also start to make a difference if there’s parity (or near parity) at the first level.

It may be easy to rocket from “this should be easy” to “oh my god this is impossible” back to “ah, so now my problem is solved.” It feels to me like there are a lot of pieces to this puzzle that they promise are in place. I frankly had a hard time getting my head around all of this; it wasn’t until I sat down and created the thermostat scenario that it started to feel concrete to me. So there’s lots of proving that has to happen. The devil was in the details before; there are now new – hopefully easier – details to inspect for new devilry.

They have demos and such, so it’s clear that something is there that works. They’ve also got a lead agreement with Sina in China. Does it fulfill all of the promise of ease of development? We’ll see that as OEMs start to try this stuff out. I’ve seen things like this collapse under their own weight before, but I’m cautiously hopeful about this.

More info:

Ayla Networks

Ayla Networks announcement

*5 most dangerous words… hands in your pockets…