A Wakeup Call

I almost didn’t wake up this morning. OK, I’m being overly dramatic. My alarm clock failed to connect to the Internet. I still managed to wake up.

The failure is a wake-up call (OK, I apologize for the pun). Even something as simple as an alarm clock has become a service that is dependent upon a provider. That would be OK if we had resilience rather than a fatal dependency upon everything in the path working just right.

Do I need to say “alarm clock app” to distinguish it from a physical alarm clock? After all, my 1980 alarm clock was just a software app.

The difference is that the 1980 version ran on dedicated hardware, whereas my modern version is an app on a generic computer – a Google device.

In a way, the newer version is a step backward in that it fails if there isn’t a connection to the larger Internet. I took the photo of the GE clock radio in 2013 when I realized I could just use a smartphone as an alarm clock.

I didn’t replace the clock radio with the Samsung smartphone because I couldn’t do much better than the fixed-function device without custom programming. I also failed to anticipate the power of voice when I wrote a column deriding the fixation on voice2.

Alexa was an accident of history. Amazon failed in its attempt to create a Fire smartphone, but its voice command capability became the heart of Alexa.

Today there is an Alexa on my wife’s side of the bed that acts as a radio and an alarm clock, though, in practice, her alarm clock is a 21-year-old cat. It’s a smart alarm clock that decides when she is supposed to wake up. She has little say in the matter.

For variety, I have the Google Hub on my side of the bed. Yes, the one that failed me this morning. The current version is a terminal on the Internet rather than a local device that can, optionally, take advantage of the remote (AKA cloud) services to enhance local capabilities and function autonomously. Note that, increasingly, devices like smart doorbells do face recognition locally rather than completely failing in the absence of a connection.

It’s easy to understand the shift shifting from purpose-built devices to valuable services. It creates an incentive to invest in new capabilities that people want to pay for. Over one hundred million Alexa devices have been sold. Most people see connectivity through the lens of these services and are unaware that they can build their own applications.

Innovation Begins at Home

Living a Beta Life

I use the existing technologies and devices because they do make my life better. But they also whet my appetite as I think beyond their current design point and use cases.

My software ability and my limited ability to build hardware allows me to explore new possibilities. I can repurpose these devices and use them as building blocks.

Building my own solutions does have its downside since they don’t always work smoothly, and when things fail, I have to fix them.

These downsides are minor compared with what I learn from my efforts. And I also gain the benefits of the results. Why guess what an unlabeled wall switch does when I can use my own browser app, which gives me, in effect, labeled buttons.

Living the beta life allows me to explore potential futures and learn what is possible. I also learn from what doesn’t work so well. I quickly learned that the complex automation rules don’t scale and that it’s not wise to trust too much to mindless automation.

I’ve got over 250 connected devices in my home using mostly Wi-Fi connections. I see both how well this works but also how it fails. How do you manage hundreds of connected devices when a light bulb is an endpoint that may be part of other systems? The good news is that if I “bind” to my apps (and Alexa) by name, I don’t have to redo everything. I put the word bind in quotes because it’s a technical term here. I normally connect a wall switch to a light fixture by running a wire. With software, I can make that connection, a binding, by just giving both endpoints a common name, and they can see each other independent of how they are connected. At least that’s how it should work. But the current tools to do that are quite limited and don’t work well beyond the simplest cases.

Currently, we’re awash in bespoke automations, with each manufacture having its own app. In my beta life, I get a chance to see beyond this early phase.

Using What’s Available.

The Internet was not the result of trying to improve the phone network. If anything, it was closer to being the opposite – the availability of the phone network meant that developers could focus on the challenge of inter-networking data networks without worrying about all the constraints of supporting services such as voice calls.

Instead of building an entire new physical network, the Internet was built using existing facilities such as leased data connections even though they weren’t perfectly aligned with the needs of best-efforts connectivity.

In the same way, I’m not trying to hone the existing applications but leveraging them. For now, I can accept that sometimes my Google Hub goes offline and can be quirky. I still find it useful and, more important, I can learn from it.

I use both Google and Alexa so that I experience both ecosystems. Now that Apple is joining in the Project CHIP3, perhaps they will learn to play with others?

(Re)Factoring

The other kind of repurposing is developing the shared infrastructure that created synergy among disparate efforts. In the case of the Internet, that is the shared packet infrastructure. The web is based on common implementations of HTML and HTTP and, more recently, the increasing use of JSON-based APIs.

This is a work-in-progress. As I wrote in Rewriting my House4, I need to use shims such as port forwarding to extend the connectivity into my house. One lesson I’ve learned is that there is a difference between the current Internet, which is still tied to the internetworking-design point, and the more decentralized connectivity. So the networking in my house is a first-class facility that internetworks with other homes and the rest of the world. My neighbors and I should be able to share devices without relying on a centralized services for naming (DNS) and addressing (the IP address).

Homeward Bound

In a recent column5, I wrote about how the NAT (Router) at the edge of my house allowed me to experiment independently of the rest of the Internet. The devices in my house are not endpoints that are only valid when connected to the Internet. The connectivity within my house is independent of and different from the connectivity to the web. Within my house, the endpoints are the devices that I use.

This does make the term, the Internet of Things, strange. What other kind of Internet is there? The web is built using such devices.

This is why I’m encouraged by the increasing convergence on a common infrastructure, though I’m wary. Project CHIPs is encouraging, but there is a security perimeter in the Thread protocol. Wi-Fi works surprisingly well but is far from perfect. I can’t simply connect two devices in a new house without setting up a network.

My columns have built on the lessons I’ve learned. For example, my column Communities of Things6was based on what I learned from the simplicity of using simple protocols among devices on the same network and generalizing them beyond the physical topology.

Even when I’m using the web, I see it in terms of the underlying protocols. I was reminded of this watching a presentation7 about streaming APIs. It reminded developers that they don’t need special knowledge of the underlying networking because streaming protocols don’t need to block due to slow networks. Rather the applications should respond to the dynamic conditions. That is why I wrote8 about JavaScript as part of an ecosystem and not just a programming language.

I’ve learned how to leverage the DNS for binding endpoints within my house, and I figured out how to get certificates for devices that reside entirely within my house.

I plan to explore these concepts in detail in future columns.

Campus Bound

I was struck by a recent article in the IEEE Consumer Electronics Magazine9 , which showed a variety of applications for connectivity outside of the traditional web framing.

What was missing was the synergy of a common IP-based infrastructure. Just as I can assume connectivity within my house with any need for a subscription, we should be able to benefit from the synergy of Public Packet Infrastructure. We could focus on innovation rather than having to solve connectivity for each application one by one.

I call this the Campus Model because you can indeed assume connectivity on college campuses and in companies. It’s an approach that works well, but we fail to see beyond that because our focus is on the web, making it hard to see beyond it.

This why I lament 5G10. Unlike the campus model, which provides a common infrastructure, the design of 5G is a throwback to the days when we relied on a network for services as basic as phone calls. Today we need a Public Packet Infrastructure with connectivity starting from one’s house. While I can work around the limitations within my house, it is far more difficult to repurpose a 5G infrastructure.

We need a Public Packet Infrastructure as a common resource for innovation rather than giving preferences to legacy providers.

A Wakeup Call

Experimenting within my house allows for rapid experimenting and iteration. How do we take these lessons and apply them to society as a whole? The real value of my efforts within my house is my ability to experiment and learn. I avoid doing one-off implementations so that I can share the results.

Home Control is one application and not the only purpose of connectivity within my house – just as connecting to the web is just one way to use the wider Internet. I accept that we have a long way to go and that, sometimes, I won’t get the wake-up call. That’s OK; that’s the price of a beta life – a chance to live and help invent the future.