The problem with “remote power-on”
I wanted to turn on my PC from anywhere.
Wake-on-LAN is the obvious answer. It’s also the obvious rabbit hole:
static IPs, router rules, NAT/CGNAT, and re-doing fragile setups every time a
machine gets updated or reinstalled.
Some of the older office PCs didn’t even support WOL properly.
And even when they did, every OS update or fresh install meant
going through the whole ritual again.
After dealing with that a few times… I was out.
I didn’t want reliability to depend on network configuration.
So I stopped trying to wake the PC over the network.
I decided to press the power button.
Remotely.
The idea
An ESP8266 and a relay, wired to the motherboard Power SW header in parallel
with the case button.
Before assembly.
ESP8266 + relay wired in parallel to the motherboard Power SW header.
It electrically mimics a physical press of the case power button.
When triggered, the relay briefly shorts the pins.
That’s it.
No BIOS settings.
No port forwarding.
No VPN.
No inbound traffic at all.
The device only makes outbound HTTPS requests to fetch a tiny command.
If the value changes, it taps the button.
This one design choice — outbound only — is why the system is boringly reliable
behind NAT, CGNAT, and whatever network shape you happen to have that day.
Sometimes the most “IoT” thing you can do is avoid infrastructure.
Why Google Sheets?
Because it’s already there.
A single cell becomes a control panel.
Google Apps Script turns that cell into a tiny HTTPS endpoint.
The ESP8266 polls it and watches for changes.
Is it elegant? Not in the academic sense.
Is it practical, free, and reproducible in five minutes? Absolutely.
And more importantly: there’s almost nothing to break.
What actually matters here
I won’t repeat wiring diagrams or setup steps — the README covers those clearly.
What’s interesting is why this works so well:
- It doesn’t depend on router configuration
- It doesn’t need persistent connections
- It tolerates network weirdness
- It behaves like a human finger, not a protocol
This is less “remote control” and more “remote fingertip.”
And that turns out to be a very stable abstraction.
Real-world behavior
Polling is not instant. That’s fine. Power-on is patient.
If the PC is already on, a press behaves exactly like a real press:
sleep, shutdown, or nothing — depending on OS settings.
The system doesn’t try to be smart.
It just does the one physical action faithfully.
And that simplicity is the whole point.
From hobby build to embedded system (v2 thinking)
I built this a few years ago. Open-sourcing it made me want to clean it up
— not with features, but with engineering discipline.
The next iteration focuses on:
- Non-blocking scheduling (
millis()instead ofdelay()) - Retry logic with exponential backoff
- Avoiding heap fragmentation from repeated
Stringusage - Clear module boundaries (
Network,Command,Relay,State) - An explicit state machine
- Watchdog, boot-reason logging, and failure recovery
In other words: make it the kind of firmware that can run for months
without anyone thinking about it.
Because that’s what this device should be.
Invisible.
What I learned
- Outbound-only designs quietly solve a lot of networking pain.
- Physical abstractions are sometimes more reliable than clever protocols.
- “Simple” doesn’t mean “unprofessional” — if it’s documented and reproducible, it’s solid engineering.
If you want the full implementation — wiring, firmware, Apps Script, setup —
it’s all in the repo README.
GitHub: Hysus12/esp8266-remote-power-button
If you build one, I’d love to see your version of the remote finger.
Top comments (0)