Two of my cameras won’t load in the web app at my.wyze.com and show “Web Connection Failed.” Both stream fine in the mobile app. Rather than guess, I captured the WebRTC signaling from the browser side, and the result is specific enough that I think it’s worth posting — the browser is doing everything correctly and the camera simply never answers.
SETUP
Cameras that FAIL in the web app:
- Cam A — model WYZEC1-JZ (Cam v2), firmware 4.9.9.3006
- Cam B — model HL_CFL2, firmware 4.53.11.7154
Cameras that WORK, in the same tab, on the same network, at the same moment:
- Cam C — model HL_CFL2, firmware 4.53.11.7154
- Cam D — model WYZE_CAKP2JFUS
- Cam E — model HL_PAN2
Cam C is the same model and the same firmware as Cam B and works fine, so this isn’t a model or firmware issue. It’s per-device.
Browser: Chrome 152 on macOS, tested with a brand new empty profile — no extensions, no cached cookies — to rule out anything on my end.
WHAT ACTUALLY HAPPENS
The web app streams over AWS Kinesis Video WebRTC. For every camera, the get-streams API call succeeds and returns a valid signaling URL, ICE servers, and auth token — including for the two that fail.
The browser then opens the KVS signaling WebSocket (handshake succeeds, HTTP 101), sends a well-formed SDP offer, and gathers a full set of ICE candidates: host, server-reflexive, and TURN relay. All normal.
Then nothing comes back. No SDP_ANSWER. The web client waits 15 seconds, closes the signaling socket (close code 1005), retries exactly once, fails the same way, and paints “Web Connection Failed.”
Here are the signaling message counts from a single page load. Each line is one camera: offers sent, answers received, ICE candidates out, ICE candidates in, and how many times the signaling socket closed.
- Cam C (works) — 1 offer, 1 answer, 19 ICE out, 20 ICE in, 0 closes
- Cam D (works) — 1 offer, 1 answer, 19 ICE out, 20 ICE in, 0 closes
- Cam E (works) — 1 offer, 1 answer, 19 ICE out, 20 ICE in, 0 closes
- Cam A (FAILS) — 2 offers, 0 answers, 36 ICE out, 38 ICE in, 2 closes
- Cam B (FAILS) — 2 offers, 1 answer, 37 ICE out, 39 ICE in, 2 closes
The three working cameras return their SDP_ANSWER in about 1 to 1.5 seconds and then connect directly over the LAN. Cam A returned no answer at all across both attempts. Cam B did eventually return one answer — but not inside the client’s 15-second window, so it got torn down anyway.
WHY I DON’T THINK THIS IS BROWSER-SIDE
Three other cameras streamed successfully in the same tab, on the same network, through the same TURN servers, at the same time. A browser problem, an extension, a firewall, a VPN, or acodec mismatch would not spare three cameras and hit exactly these two. And the failure happens before ICE connectivity or codec negotiation is ever reached — the offer goes out and no answer comes back.
That points at the WebRTC agent on the camera itself: registered on the signaling channel, bu.
THINGS I’VE ALREADY RULED OUT
- Clean browser profile, no extensions — same failure
- Signed out and back in — same failure
- Both cameras show online and stream normally in the mobile app
- Not model-specific (same model and firmware works on another camera)
QUESTIONS FOR ANYONE WHO’S SEEN THIS
- Has anyone else had specific cameras stick at “Web Connection Failed” in the web app whileDid a power cycle fix it, and did it stay fixed?
- Is the Cam v2 (WYZEC1-JZ) still fully supported for WebRTC playback in the web app? If it’ rather know. That still wouldn’t explain the HL_CFL2 though.
- Is 15 seconds the expected signaling timeout? Cam B did answer, just late — if the timeout were a bit more forgiving it might have connected.
@WyzeTeam — happy to re-run the capture and send full signaling logs, SDP payloads, or a HAR privately if that’s useful. I’ve also submitted logs from the app on the failing camera.