When Your Wife's IoT Bird Feeder Doesn't work, and You're a All Hats IT Engineer

It always starts simple: a thoughtful gift, a charming gadget, a new device that promises to bring joy. In this case, it was a hummingbird feeder with a built-in camera—ordered with enthusiasm, installed with care, and met with the dreaded modern curse: "Live View Not Available".

My wife picked this one out herself. A birthday present, no less. The design was right, the aesthetic clean, the promise straightforward: motion-activated clips and live streaming of visiting hummingbirds. It connected fine to the cloud. Motion events were arriving. But live view? Nothing. Just spinning, then failure. And thus began the inevitable process that kicks off when you're a IT engineer living with consumer-grade IoT:

"What do you do when your wife's new IoT toy doesn’t work? You run packet captures, build a network topology diagram, and reverse-engineer their NAT traversal logic over coffee."

First, Eliminate the Usual Suspects

The camera connected to our Wi-Fi without issue. DHCP lease confirmed. It began sending encrypted MQTT traffic outbound to AWS IPs, mostly on TCP 8883. From that, and the packet capture device id I knew this was a Tuya-based camera under the hood—typical of white-label smart home gear. Motion alerts confirmed the outbound pipeline was working: the camera pushed clips to the cloud, and the phone received notifications with no delay.

But trying to load the live stream failed. Every time.

So I started at Layer 3. nmap showed no open ports on the LAN side. The camera was fully cloud-tethered. I ran a packet capture and saw TLS traffic constantly active between the camera and Tuya’s Oregon-based relay cluster.

Then I turned to the phone.

Packet Captures Don’t Lie

Running a simultaneous capture while trying to access live view showed something critical:

• The phone made TLS connections to AWS Tuya endpoints
• There was a full handshake
• But no live stream data ever flowed back

Meanwhile, the camera was online and actively communicating with the same relay endpoints. It wasn’t that the device was down. The problem was that the relay handshake failed when both endpoints were on the same LAN.

The Breakthrough: LTE Works, LAN Doesn’t

Switching the phone to LTE made everything work instantly.

Live view loaded, streamed, and responded in real-time. That blew the case wide open. What I’d suspected was now confirmed: Tuya’s relay logic fails when both client and camera are behind the same public IP.

Whether by broken WebRTC fallback, flawed NAT traversal, or just poor cloud design, the result was the same: their tunnel logic can’t handle symmetric NAT scenarios.

Testing the Theory: VPN Detour

I happened to have a Raspberry Pi in the house already connected to my employer’s VPN. It routes all traffic from a dedicated Wi-Fi interface through our enterprise’s VPN for streaming purposes.

I connected my phone to that SSID, which hairpins all traffic through the company VPN. Just like LTE, this changed the public IP and broke the NAT symmetry.

Result: Live View worked flawlessly.

The Tuya backend suddenly saw two endpoints with different IPs, and the tunnel succeeded.

Building the Permanent Fix: BirdNet

Relying on my employer’s VPN to stream birds didn’t feel like the right long-term solution, so I’m building a permanent system. I’m calling it BirdNet. Below is the path I am currently leaning towards.

• A Raspberry Pi hardwired to my home network
• Running WireGuard as a client
• Connected to a Linode VPS with a stable public IP
• Configured to route all outbound traffic through the VPN tunnel
• Broadcasting a Wi-Fi SSID named BirdNet

But here's the better part—she doesn’t have to switch Wi-Fi at all. She can stay connected to BirdNet full-time. Because I control the tunnel, I can optimize it, restart it, and monitor it however I like. The tunnel watchdog will keep the route alive, and from her perspective, it's just Wi-Fi that always works.

Tuya’s failure to design around real-world home networks becomes irrelevant. Their cloud dependency is contained. The device works, because I made the network lie to their protocol.

Final Thoughts

This isn’t just about bird cams.

It’s about how fragile and opaque the IoT stack really is—and how network engineers, the people who build and understand infrastructure, are the only ones left capable of making these things work when they break.

They sell you magic. When it fails, you build your own spellbook.

I’ll share more about the BirdNet configuration in a follow-up post, including the WireGuard profile, firewall rules, and systemd setup that makes the whole thing transparent and resilient.

For now, the hummingbirds are live. The feeder works. And I didn’t have to rip it apart—just the network illusions it depended on.

--She Loves Hummingbirds
-Bryan