What Two Forgotten Smart Plugs Taught Me About the Future of Software

Building Pebble Home with AI coding agents, and wondering how personal software can become.

Disclosure: This article was drafted with AI from my firsthand project experience and project records. The cover is an AI-generated illustration; the screenshots show the implemented interface, with demonstration data identified where applicable.

A couple of months ago, I rediscovered two old Oakter smart plugs that had been lying in storage.

When I tried to use them again, the service I had relied on was no longer available to me. As smart plugs, they had become effectively useless. I had no reason to assume the electronics themselves had reached the end of their lives.

That bothered me enough to start investigating. How much of a device do we really own if its usefulness depends on a service continuing to exist?

I initially wanted to find out whether those plugs could be revived. That question opened a much larger project. Today, I am building a home automation platform called Pebble Home, with extensive support from AI coding agents, around the particular devices, rooms and habits of my household.

It is very much a work in progress. It has also changed how I think about the software we choose to build.

The house was already a collection of ecosystems

I came to this with decent experience of Home Assistant and some consulting work involving power monitoring and automation at a larger industrial scale. I understood the appeal of a common control layer, and I had seen how much work sits between a promising demonstration and a system people can depend on.

At home, I had accumulated close to 80 smart nodes from several vendors. Some carried familiar names, including Philips. Others came from less familiar brands. Some shared Tuya-based technology; others used their own protocols. Across the house were Zigbee devices, BLE mesh devices, older Bluetooth devices, Wi-Fi products and a couple of Matter devices.

Each purchase had solved a small problem. Together, they had created a collection of overlapping ecosystems, apps and assumptions.

Home Assistant had already taught me the value of local control. Its privacy documentation describes direct communication with devices where they support it. But the awkward devices in my own home made a distinction very tangible: having the right radio is only part of the problem. A controller still needs to understand the device's commands, authentication and behaviour. Home Assistant's Bluetooth documentation similarly distinguishes Bluetooth connectivity from the integrations that make individual products useful.

For some of my existing devices, there was no straightforward route from “I can detect it” to “I can reliably control it.” That gap became the project.

The investigation and the role of AI agents

The investigation involved days of reading, observing my own devices' network traffic, examining how their apps communicated and testing explanations against actual responses. OpenAI's coding agents were central to that work. They helped analyse protocols, develop small experiments, implement integrations, debug failures, design interfaces and build tests.

I want to give that contribution its full weight. This platform would have been a much harder undertaking for me without them.

My contribution was the context: what hardware was actually installed, what a room needed to do, what the family would find usable, and what happened when a proposed solution met the real house. The agents could help turn an observation into a hypothesis or a working implementation. I still had to judge whether the result was useful and whether the evidence supported it.

One episode captures the process well. A set of controllers began returning authentication and connection errors. Expired credentials seemed like a plausible explanation. Investigation showed that changing network addresses were the main cause; the stored credentials still worked once the controllers were found at their new addresses.

That led to better discovery and recovery behaviour. It also reinforced a habit I want to retain when working with AI: a convincing explanation is something to test.

Looking closely at these devices was occasionally uncomfortable. In the particular protocols I investigated, I found unencrypted local communication, weak protection of some command details and fragile dependencies. Those observations made me more cautious about the assumptions hidden behind a polished app. They do not amount to an audit of the entire smart-home industry, and building my own controller does not repair limitations inside a device's firmware.

Local control gives me more visibility and more choices. It also makes me responsible for the controller, its access rules and its maintenance.

What is working today

As the work progressed, the requirement became clearer. I wanted one coherent interface for this home: its lighting and switches, curtain controls, background music and compatible cameras, arranged in a way that made sense to the people using it.

Pebble Home now runs locally on a Raspberry Pi. It has room-based dashboards, household accounts with room permissions, named action-and-delay routines, a background-music dashboard and a camera interface. A compatible camera has been verified for local live video and bounded pan-and-tilt control. Camera support remains specific to the protocol we have actually tested.

The room-display interface, captured during development. Temperature, humidity and security sensors are explicitly shown as unconnected.

One particularly satisfying piece has been getting six existing tunable-white Theater Room track lights working through an ESP32 room node. Their room presets can execute on the node after the browser closes. The interface reports progress and individual outcomes, because a group of lights does not always behave like one device.

There is considerable engineering behind those ordinary-looking controls. A timeout can leave the result of a physical command uncertain. Repeating that command automatically may be the wrong response. A disconnected device needs to appear as unavailable. Upgrading the application needs to preserve the household's current configuration and data.

Those requirements have shaped the software as much as the screens have. Automated tests use fake device transports. Hardware checks are bounded and include restoring starting states. The latest deployed release passed 150 isolated automated tests on the Pi. That is useful evidence about the implementation; long-term reliability will still have to be earned through use.

I am also repurposing old tablets and phones that were lying around as control panels. A device that feels slow for everyday browsing may still be well suited to a small, carefully designed interface. Pebble now has a lightweight kiosk intended for older browsers, alongside the richer room display. Compatibility needs to be checked device by device as this part of the project develops.

The implemented kiosk interface, shown with demonstration data. It brings music and room controls into a touch-friendly view.

I like the possibility of giving that hardware a useful second role. It also changes the design question. Instead of buying a new screen and adapting the household to its interface, I can work towards an interface that suits the screen and the room I already have.

Does personal software change the case for the suite

This is where the project begins to raise a broader question for me. What happens when software built for a very specific environment becomes affordable enough to consider seriously?

Comprehensive software suites spread their development costs across many customers. They need broad capabilities, flexible settings and abstractions that accommodate unfamiliar situations. A household or a small organisation usually needs a much narrower set of things, arranged around details its occupants know intimately.

Historically, custom development often cost too much to justify that fit. The compromises in a general product were easier to accept than the effort of building and maintaining an alternative.

AI coding agents have changed that calculation in my own experience. They have made it practical to explore requirements I might previously have dismissed as too small, too specific or too time-consuming. A dashboard can be designed for one old tablet. A workflow can follow the way one household uses a room. An integration can serve hardware whose installed base, for my purposes, is one.

Does that mean the end of the comprehensive software suite? I doubt it. Shared infrastructure, maintained integrations, standards and large open-source communities remain enormously valuable. Pebble itself depends on existing software, libraries and other people's engineering work. Custom software also creates continuing obligations: documentation, backups, updates and a way for someone else to take over.

What seems plausible to me is a change in where general software ends and personal software begins. More people may use dependable shared foundations while commissioning or building a layer that closely fits their environment. The viability of that layer may depend as much on its clarity and maintainability as on how quickly an agent can generate its first version.

Home automation makes this unusually concrete. The requirements live in physical rooms. People have established habits. Hardware has quirks. An elegant feature is of little value if using the room becomes more difficult.

What I want to explore next

The immediate roadmap grows out of what is already working. Beyond it are a few ideas I want to investigate as the platform matures.

• Timers and routines that understand conditions. Named actions and delays are already implemented. Scheduled actions, time windows and device-state conditions would make them more useful, with clear explanations of why a routine ran and careful handling of restarts or missed deadlines.
• A more informative view of the house. Weather, connected sensors, active timers and clearer summaries could help a display explain what needs attention. Unknown or stale readings will need to remain visible as such.
• More capable room nodes. The ESP32 lighting work provides a starting point for exploring distributed infrared control and environmental sensors. Compatibility with older appliances and other proprietary lighting systems will require separate investigation.
• Energy awareness connected to useful decisions. My power-monitoring experience makes this especially interesting. I want to explore how available measurements might reveal consumption patterns and inform sensible automation, once the necessary devices and readings are verified.
• A bounded natural-language interface. Further out, I would like to investigate whether an assistant could translate an intention into an understandable routine, show its proposed actions and operate within explicit permissions.
• A system that remains understandable to someone else. Recovery, documentation and a straightforward handover deserve continued work. A platform built around my home should remain usable when I am unavailable to explain it.

The two forgotten plugs started an investigation into obsolete hardware. Along the way, I have found myself reconsidering the economics of custom software, the responsibilities of local control and the role of AI in making a personal project possible.

Pebble Home remains unfinished. Some devices are still unresolved, and there is plenty to learn from daily use. What I have now is a working foundation that I can shape around actual needs, with AI agents making an unusually large contribution to the effort.

I am curious how far this extends beyond home automation. Where would software built around your particular environment be valuable enough to justify owning its maintenance?