Boom Media · Displayee Camera Add-On · Troubleshooting Guide

🔌 Getting the Tapo Camera Connected — Solutions & Explanations

Why the PC can't see the camera, how to fix it in every scenario, and why this exact problem is the product · July 13, 2026

TL;DR — the diagnosis

Measured: this PC = 192.168.100.10 (Ethernet) · Tapo camera = 192.168.30.13 · ping fails, port 554 closed from here.
Meaning: they're on two different networks. Nothing is wrong with the camera — the PC's network has no path to the camera's network.
Topology CONFIRMED: Omada-managed network (Omada router + VPN + cloud management) → this is Scenario S2: 192.168.30.x is a VLAN (likely IoT/cameras or a guest-flagged SSID), and either an ACL or the guest-network isolation flag is blocking inter-VLAN traffic. Exact fix in §5 (Omada playbook) — 10 minutes in the controller.
Fastest test today: a phone or laptop on the camera's own Wi-Fi + VLC (§3, Solution 1). Takes 5 minutes, requires nothing else.
The real fix (and the punchline): a tiny bridge device on the camera's network pushing outbound to the cloud — which is literally the Displayee add-on architecture. Solving this for your own house = building the demo (§5).

1 · Why the PC can't see the camera (plain-English explanation)

Home/business networks are split into subnets — groups of devices that can talk to each other directly. 192.168.100.x and 192.168.30.x are two different subnets. Traffic only crosses between subnets if a router routes between them, and consumer setups almost never do that automatically. Common reasons two subnets exist in one home/office:

Scenario	What it looks like	How to confirm
S1 · Two routers chained (double NAT)	ISP modem/router runs one network (e.g. 100.x); a second router (or mesh kit) plugged into it runs its own network (30.x). Camera joined the second router's Wi-Fi; PC is wired to the first.	Look at the camera's Wi-Fi name in the Tapo app → which router broadcasts that SSID? Log into it and check its LAN subnet.
S2 · VLANs / guest network	A managed router (Omada, UniFi, some ISP boxes) with the camera on an IoT/guest VLAN that's isolated from the main LAN on purpose.	Router admin → LAN/VLAN settings → is there a 192.168.30.0/24 network defined with isolation on?
S3 · Different buildings	Camera is at home; this PC is at the office (or vice versa). No cable connects the two — no local fix exists, only the bridge/cloud pattern.	Where is the camera physically? If it's not in this building, it's S3.

Key mental model: the Tapo app on your phone still works because it goes out to TP-Link's cloud and back (P2P) — it never needed the local route. RTSP/ONVIF are local-only protocols, so they're the first thing subnet isolation breaks. This is the exact NAT problem the whole camera add-on is designed around.

2 · Camera-side prerequisites (do these regardless)

Camera Account created ✅ done (on 192.168.30.13).
Third-Party Compatibility ON — Tapo app → Me → Third-Party Services (or Tapo Lab) → enable. On 2025+ firmware, port 554 stays closed until this is on — even from the correct network.
Reserve the camera's IP in its router's DHCP settings so 192.168.30.13 never changes.
Password/username caveat: both currently contain @. In RTSP URLs they must be encoded as %40; in VIGI VMS / go2rtc config fields, enter them plain. If auth keeps failing even encoded, recreate the camera account with a simple alphanumeric pair (e.g. boomcam / letters+numbers) — TP-Link's own docs warn about special characters, and it's a local-only account that doesn't need to be an email.

# The test URLs (with @ encoded as %40):
rtsp://eric%40boommedia.us:CNk%40212575@192.168.30.13:554/stream1   ← main stream
rtsp://eric%40boommedia.us:CNk%40212575@192.168.30.13:554/stream2   ← substream (what the bridge uses)
ONVIF for VIGI VMS / discovery:  IP 192.168.30.13 · port 2020 · plain credentials

3 · Solutions, easiest → most permanent

✅ Solution 1 — Test from a device on the camera's network 5 MIN · DO THIS FIRST

Works in every scenario. Put a phone/laptop on the same Wi-Fi the camera uses, install VLC (free, all platforms), Media → Open Network Stream → paste the stream1 URL above.

Plays → camera is 100% ready; every remaining problem is pure networking.
Doesn't play → fix §2 items (usually the Third-Party toggle) before touching any network settings.

✅ Solution 2 — Move the PC onto the camera's network EASY · S1/S2

Join this PC to the camera's Wi-Fi (or plug into the second router's LAN port). The PC gets a 192.168.30.x address and everything works instantly — VLC, VIGI VMS ONVIF add, go2rtc.

Limitation: the PC loses easy access to 100.x resources while switched (fine for testing; not a permanent posture).

🔧 Solution 3 — Static route between the two networks S1 ONLY · 15 MIN, ONE-TIME

If both routers are in the same building (S1), tell the main router how to reach the camera network:

Find the second router's WAN IP on the main network (it'll be something like 192.168.100.x — check the main router's client list).
Main router admin → Advanced/Routing → add static route: destination 192.168.30.0, subnet mask 255.255.255.0, gateway = that WAN IP.
On the second router, allow inbound from the WAN side or disable its firewall between the two LANs (varies by model), or enable "access point mode" if it doesn't need to be its own network at all.

Best variant of this fix: if the second router exists only for Wi-Fi coverage, switch it to Access Point (bridge) mode — then everything lands on ONE network (100.x) and the whole problem evaporates. Check first what else lives on 30.x before collapsing it.

🔧 Solution 4 — VLAN firewall rule S2 ONLY

If it's a managed router with deliberate IoT/camera isolation (good practice!): keep the isolation, add ONE narrow rule — allow the PC (or the future bridge device) → 192.168.30.13 on TCP 554 (RTSP) and 2020 (ONVIF). Nothing else crosses. This is exactly the pattern the client-install runbooks specify: cameras isolated, bridge gets a pinhole.

🏆 Solution 5 — The bridge (works in ALL scenarios, including different buildings) THE REAL ANSWER

Put a small always-on device on the camera's network — spare laptop, mini-PC, Raspberry Pi, even a Windows box that stays home — running go2rtc. It pulls the camera locally and pushes outbound to MediaMTX on the boom-hosting droplet. Then any device, on any network, anywhere, views the stream in a browser.

[Tapo 192.168.30.13] ←RTSP← [go2rtc on any box on the 30.x network] │ outbound only — no router changes at all ▼ [MediaMTX @ boom-hosting droplet] ▼ this PC · your phone on LTE · a client demo · Displayee dashboard

No static routes, no VLAN rules, no port forwarding, survives being in a different building — because the connection originates inside the camera's network going out. This is the Displayee add-on architecture doing its job. Quick-start config is in the decision doc §12.

4 · Which solution for which scenario

Your situation	Quick test	Permanent fix
S1 Two routers, same building	Solution 1 or 2	Solution 3 (static route / AP-mode collapse) — or Solution 5
S2 VLAN / guest isolation ← YOU (Omada)	Solution 1	Solution 4 pinhole — exact Omada steps in §5 — plus Solution 5 for the demo
S3 Camera at home, PC elsewhere	Solution 1 (when at home)	Solution 5 only — there is no local fix across buildings
Client sites (Gurapos etc.)	Solution 1 during survey	Always Solution 5 + Solution 4 isolation — this IS the product

5 · Omada Playbook — the exact fix for THIS network ⭐

Since the network is Omada-managed (router + VPN + cloud controller), the block is one of two things, both fixed in the Omada controller UI:

Check 1 — Is the camera's SSID flagged as a Guest Network?

Omada controller → Settings → Wireless Networks → find the SSID the camera joined.
If "Guest Network" is checked: that flag enforces client isolation — guests can reach the internet but nothing on other LANs, which produces exactly the symptoms measured (no ping, no 554).
Fix: either uncheck Guest Network (if that SSID is really your IoT network), or move the camera to a proper IoT SSID/VLAN and control access with ACLs instead (cleaner).

Check 2 — Gateway/Switch ACLs blocking inter-VLAN traffic

Omada routes between VLANs by default — if it's not a guest flag, an ACL is doing the blocking (often added by a setup wizard or a previous hardening pass).

Controller → Settings → Network Security → ACL → review Gateway ACL (and Switch ACL) rules mentioning the 30.x network.
Create two IP-Port Groups first (Settings → Profiles → Groups):
- grp-camera-rtsp = IP 192.168.30.13/32, TCP ports 554, 2020
- grp-trusted-viewers = the PC's IP 192.168.100.10/32 (later: the bridge box IP)
Add a Gateway ACL: direction LAN→LAN, policy Permit, source = grp-trusted-viewers, destination = grp-camera-rtsp — and place it above any deny rule covering the VLANs (Omada evaluates top-down, first match wins).
Keep the broad deny below it: cameras stay isolated from everything except the pinhole. This is the exact posture the client-install runbooks call for.

Omada gotcha: Switch ACLs are stateless — if the permit is done at the switch layer you must also allow the return traffic. Prefer Gateway ACL (stateful) for this rule and it "just works."

Bonus — the VPN you already run solves remote access

Your Omada router's VPN (WireGuard/OpenVPN) means that once the ACL pinhole exists, any device connected to the VPN can reach 192.168.30.13:554 from anywhere — phone on LTE, laptop at a client site. That's perfect for your own admin/testing. It is still not the SaaS delivery path (you can't put every Displayee customer's viewers on your VPN) — client-facing streams still go through the bridge → MediaMTX pattern (Solution 5). Use VPN for management, bridge for product.

Silver lining: this Omada setup is a perfect miniature of a proper client install — isolated camera VLAN + narrow ACL + managed hardware. Screenshot the finished config; it becomes the reference for the installer runbook (and it's all TP-Link gear you resell).

6 · Adding this Tapo to VIGI VMS desktop — exact recipe

VIGI VMS must run on a machine that can reach 192.168.30.13 (per §3 — same network, routed, or don't bother and use the bridge).
Device → Add Device → Manually Add (Auto Discover only finds VIGI-protocol devices — Tapo will never appear in the scan).
Protocol ONVIF · IP 192.168.30.13 · Port 2020 · camera-account credentials entered plain (no %40 — that's only for URLs).
Expect live view + basics; VIGI-native smart features won't apply to a Tapo. Normal.

Two-for-one: the moment this Tapo adds successfully to VIGI VMS via ONVIF, it's proven compatible with the Displayee bridge too — same account, same ports, same protocol.

7 · Recommended order for tonight/this week

Turn on Third-Party Compatibility in the Tapo app (§2.2) — 1 minute, do first.
Phone on the camera's Wi-Fi + VLC → play stream1 URL (Solution 1). This is the go/no-go.
Omada controller: run §5 Check 1 (guest flag on the camera's SSID?) then Check 2 (Gateway ACL pinhole: PC → 192.168.30.13 on TCP 554/2020).
Re-test from this PC: Test-NetConnection 192.168.30.13 -Port 554 should flip to True → then VLC and VIGI VMS (§6) work from here.
Stand up the $0 demo (decision doc §12): go2rtc on a box on the camera's network → MediaMTX on boom-hosting → watch it from this PC on 192.168.100.x. The fact that THAT works while a direct connection doesn't is the sales pitch, live.
Rotate the camera-account credentials once demos are done (they've been shared in plain text during setup).