Rewiring my House … and the World
Using software-based relationships instead of physical wires gives insight in the parallels be-tween connectivity within my house and connectivity across the wider Internet.
03-Apr-2020Version 2: 2023-05-28 17:09:26

Available on the IEEE site via DOI.

I just rewired my doorbells without running wires. OK, technically, I did some wiring, but I didn’t use the wires to establish the relationship. Instead I simply associated my rear door button with the chime signal for the back door and did the same thing for the front door.

To put this into software terms, I create a binding between the doorbell button and the chime. This association is independent of where the two endpoints are. For me, software isn’t just about doing calculations. It’s the language I use to understand the world and reprogram it.

The idea of connecting two endpoints without a wire is not new – I can use a point to point radio as a virtual wire. Looking at this relationship between the two end points from a software perspective is fundamentally different. I’m indifferent to whatever is between the two endpoints.

I learn by doing so before we get into the abstract concepts, I’ll describe my very simple project. I’m excited by the Shelly devices from Allterco2. In particular, the Shelly1 which is a simple device that can control a relay. It can also detect a button press. It can operate on 110/220AC or 12VDC.

It has a built-in web server and supports a very simple http protocol for control. It also supports MQTT and CoAP signaling which allows me to listen for broadcast messages. It’s open source and I can reflash it with alternative software. It is a building block.

For this project I’m using a Shelly1 to detect when the button at the backdoor is pressed. Notice that I’ve marked this as 12VDC – most of my project have been controlling lights. For those I use 110VAC and am very cautious. Working with 12V is much safer.

After doing the wiring I can switch to use software to setup the relationship. In this case the Shelly will invoke the URL. Using a static IPV4 address is not ideal – I’d prefer to use a name (DNS or mDNS).

I would prefer to use https for an encrypted message but the certificate mechanism is tied to the DNS. Trying to use my own certificates is not currently feasible. This is especially frustrating because it means I can’t convert my web app into a full application. And Google then annoys me by presenting a scary message as if I were accessing a distant website.

Next step is to mount two Shellys in the front utility room.

The Shelly on the right (pink label) responds to the URL from the rear door button and closes the 0/1 contact which activates the chime for the rear door. It doesn’t have a wire connected to SW.

The Shelly on the left detects a button press from the front door and responds by closing the contact for the front door chime sound. Why bother when I can simply connect the button to the chime? Having the Shelly in the path allows me to have other apps listen in and allow creative uses such as turning on the foyer light when someone rings the bell.

Leaving Home

When I’m at home I can type in http://backbell.bob.z/relay/0?turn=on. I don’t require a special network and thus accept that the message might be delayed or might not get through. This is no different than when I was using a wire for the button and the wire broke. The visitor is part of the loop and if they don’t hear the bell, they can press again or go to plan B which, these days, is a cell phone call.

Today, because the pieces aren’t there, making the same URL to work inside and outside the house requires some effort. I’d need to use port forwarding to connect the inside network with the external network and then translate the name into the right internal device. What is important is that, while this does require some manual effort, it is transparent to the application and that’s the key architectural concept.

These concepts come together in my current home control system. I run my web app interface in devices (smartphones) I hang on the wall and the same app, unchanged, works anywhere in the world. Provided, of course, I have a connection.

Staying Alive

I can extend the “wire” as long as nothing blocks the path. Alas. The business model of telecommunications requires a roadblock simply to collect a rent because, in the past, we didn’t have phone apps, so we relied on phone companies.

The doorbell is useful because it takes the complex concepts and makes them very concrete. The same approach can work for a wrist device that monitors your heart. Today we have such capabilities but each one requires special arrangements. Your wrist device is connected to your phone after being paired with a Bluetooth connection and then uses your cellular phone to connect to the rest of the world (AKA, The Internet). Every element of the path has to be setup just right. And this has to be repeated for each new service.

What would it take to get such devices to “just work” anywhere and anytime? My doorbell application can work anywhere provided I’ve made the proper arrangements and the heart monitor works everywhere if every one of the intermediate steps is setup just right for that one application. The efforts at providing municipal Wi-Fi had some of the same limitations in requiring someone to manually login – something these building blocks cannot do.

What we need is a Public Packet Infrastructure (PPI) which provides open connectivity, perhaps as Wi-Fi. To act as infrastructure, it needs to have coverage in a geographic area rather than being limited to small hotspots. It can’t require knowing special codes.

The cable companies have a limited form of PPI in sharing a portion of the capacity of their customers’ routers without impacting the other uses. They also have Wi-Fi along their cable paths. Cities could take this idea to provide coverage. Anyone can extend the coverage of open connectivity.

The benefit in terms of lives saved by medical applications alone could pay for it. The city can also realize saving in being able to easily deploy their own technology such as environmental monitors.

Most important, for the future, is creating the opportunity to discover new possibilities. These building blocks allow us to apply our software skills to the physical world.

We don’t need to make the cities smart; we need an infrastructure that empowers everyone to add their smarts to the city.

Running a physical wire around the world is hard but with software I can create a virtual connection across the world just as easily as I can within my house … or at least I should be able to.

End Notes