The smart plug had not physically failed. It still received power and showed no obvious sign of a defect. Yet I could no longer control it from my phone the way I used to.
The manufacturer had closed its business and stopped supporting its platform. For the first time, I realized that the useful lifespan of a smart-home product was not contained entirely inside the hardware.
Before that, I had already encountered an unexpected issue with remote air-conditioner control. The two incidents seemed different, but they led to the same question: what does it really mean for something to be "connected"?
The excitement of turning on an air conditioner from a phone
I started by using one integrated infrared (IR) remote controller for both my TV and air conditioner. When I pressed a button in the phone app from outside the house, the controller transmitted the equivalent remote-control signal to the appliance.
Being able to turn on the air conditioner before arriving home felt convenient. Controlling the TV with the same device seemed clever as well. At first, simply being able to press a remote button from outside was enough to make the home feel smarter.
Then something happened that I had not expected.
This was a long time ago, so I cannot recall the exact sequence. I think I accidentally touched the air conditioner's power button while using the integrated remote away from home. I could not check whether it had actually turned on, so I pressed the button once more and assumed the second press had turned it off.
When I got home, however, the air conditioner was still running. I do not know whether the first signal failed to arrive, the second failed, or one of them had a different effect than I expected.
The key problem was not ignorance about the room around the air conditioner. It was that I had sent commands to the device without any way to inspect its actual power state. Pressing an on-screen button twice was not proof that it was off.
A record of sending a command is not the device's real state
Afterward, my criteria for choosing connected devices changed. It was no longer enough that I could send a command. I wanted to know whether the target device could report what state it was actually in.
Of course, even a device that accurately reports its own power state does not automatically know everything happening around it. That is a separate question. First, I simply wanted to know whether the air conditioner I was controlling was presently on or off.
What mattered to me was not a log saying "Power button pressed," but trustworthy feedback indicating "The air conditioner is now off."
The smart plug failed for a different reason
My early smart plug came from a small company. It used Wi-Fi and depended on the manufacturer's app and cloud platform.
It was convenient while the service operated. I could switch whatever was plugged into it on and off remotely, without thinking much about wireless protocols.
Then the company discontinued its business and platform support. The previous remote-control method stopped being available. That felt strange: a physical device had lost useful functionality not because it had broken, but because the organization running its service had disappeared.
Buying a product also meant choosing the service architecture that made that product work.
After that, a long list of features and a low purchase price were no longer enough. I also considered how long the product might stay usable and what would happen if the manufacturer changed its service policy.
Why I started looking at Zigbee
I already owned a SmartThings Station, so Zigbee devices that worked directly with it offered a way to reduce the need for a different vendor app or dedicated gateway for every product.
For lighting switches, buttons, and plugs, I began checking real SmartThings compatibility before purchase. Sometimes compatible options were more expensive. But I cared more about consistency of the control system than the feature list of any single product.
| Earlier approach | Limitation I experienced | Criterion that mattered later |
|---|---|---|
| Integrated IR remote | Could not confirm actual ON/OFF state after pressing Power | Feedback about the target device's current state |
| Vendor-specific Wi-Fi plug | Lost remote functionality when the cloud platform closed | Reduce dependence on a proprietary platform |
| Compatible Zigbee device | May connect without a separate dedicated gateway | Verify hub compatibility and continued support |
Not all Wi-Fi products are bad, and not all Zigbee products are good. Some Wi-Fi devices support standards-based integrations and local control. Some Zigbee products only work correctly with selected hubs.
What I wanted to avoid was not a particular frequency or radio technology. It was an architecture that required adopting a new proprietary control platform for every device.
Zigbee does not remove every dependency
Zigbee is a wireless protocol, not a contractual promise of long-term service support. Two Zigbee-branded devices may provide different capabilities or pairing experiences on the same hub.
And direct pairing with SmartThings Station does not guarantee that every routine works without internet access. Some connections and automations depend on cloud services. I reduced the number of vendor platforms, but still depended on SmartThings as a central platform.
Nevertheless, it became easier to understand where things were connected and what to check when something did not respond. Most importantly, I could combine commonly used actions in a single set of routines and buttons.
Long-term usefulness depends on the architecture, not just the feature list
After years of use, I stopped looking only at specifications printed on the box. Connectivity, state feedback, standards support, and the likelihood of continuing platform availability all affected how useful a device remained.
I did not make a perfect technical choice from the beginning. I only understood what I valued after something went wrong.
Since then, I have tried to keep existing equipment wherever practical and connect compatible devices through a center I understand. Replacing light switches rather than every light fixture was part of that approach.
A good connected device should not merely work today; it should have a reasonable chance of supporting the same everyday routines tomorrow.
Next, I will describe the light switches and smart buttons that became part of our family routine—and why my most complicated automation eventually returned to a simple button.