BUG: [v3 cam] Wyze-bridge no longer works with newer firmware

rakbladsvalsen commented 3 weeks ago

Describe the bug

Hey, just as the title suggests, looks like Wyze Inc. killed the bridge with the latest firmware update for the v3 cameras. I don't know if this is also the case for the other models, but as far as the regular v3 goes it no longer works.

I already tried the following:

[x] Use a different NET_MODE mode (p2p/lan)
[x] Try the latest :edge builds
[x] Use static IP addresses for the cameras
[x] Rule out possible router issues
[x] Use nmap to verify whether the IP discovered by WyzeBridge is valid (and yes, it is)

I know something is definitely up because wyze-bridge does work with the old FW. I have multiple v3 cameras and I tried updating just one of them and surprise surprise, the new fw magically breaks the bridge. The phone app is still working fine as usual.

WyzeBridge] 🔍 Could not find local cache for 'user'
[WyzeBridge] ☁ Fetching 'user' from the Wyze API...
[WyzeBridge] 💾 Saving 'user' to local cache...
[WyzeBridge] 🔍 Could not find local cache for 'cameras'
[WyzeBridge] ☁ Fetching 'cameras' from the Wyze API...
[WyzeBridge] [API] Fetched [3] cameras
[WyzeBridge] 💾 Saving 'cameras' to local cache...
< snip >
[WyzeBridge] 🎉 Connecting to WyzeCam V3 - right on 192.168.68.63
[WyzeBridge] 🎉 Connecting to WyzeCam V3 - left on 192.168.68.64
[right] [-13] IOTC_ER_TIMEOUT
[left] [-13] IOTC_ER_TIMEOUT
<... repeats over and over ...>

I believe this might be a duplicate of https://github.com/mrlt8/docker-wyze-bridge/issues/1298, except this affects the v3 series cameras and everything is broken, regardless of the network access mode.

Affected Bridge Version

v2.10.1 X86_64

Bridge type

Docker Run/Compose

Affected Camera(s)

v3

Affected Camera Firmware

4.36.13.0416

docker-compose or config (if applicable)

wyze:
    image: mrlt8/wyze-bridge
    container_name: wyze
    restart: always
    environment:
      - RECORD_ALL=True
      - FRESH_DATA=True
      - WYZE_EMAIL=REDACTED
      - WYZE_PASSWORD=REDACTED
      - API_ID=REDACTED
      - API_KEY=REDACTED
      - MTX_READTIMEOUT=10s
      - ON_DEMAND=False   
      - ENABLE_AUDIO=True
      - RECORD_LENGTH=60s
    volumes:
      - ... <local path>
    ports:
      - ... <some IP>

mrlt8 commented 3 weeks ago

I believe 4.36.13.0416 should still work locally. Is your bridge on the same network as the cameras? There's a known issue with all firmware released after 2024 that is causing issues with remote/p2p connections as well as limiting the number of active connections to the camera.

One temporary solution is to use vpn like Tailscale or OpenVPN to put the bridge on the same network as the cameras.

rakbladsvalsen commented 3 weeks ago

I believe 4.36.13.0416 should still work locally. Is your bridge on the same network as the cameras?

Hey, thanks for the prompt response.

Yes, I even tried setting NET_MODE to LAN to no avail. In fact, the log excerpt I posted shows the bridge is trying to connect locally (192.168.x.x), and the container indeed lives on the same network as the cameras.

I think this bug might affect different models in different ways - but at least the v3 is completely unusable with the bridge as of the latest firmware, unless someone says otherwise.

mrlt8 commented 3 weeks ago

dgaust commented 3 weeks ago

This doesn't resolve your issue, but I have a V3 running the same firmware with Wyze-Bridge and working as expected.

rakbladsvalsen commented 3 weeks ago

This doesn't resolve your issue, but I have a V3 running the same firmware with Wyze-Bridge and working as expected.

That's quite weird. The computer/server lives in the same network as the cameras so I don't really see a valid reason for failure. I also find it a little bit confusing that as soon as I upgrade the FW, the bridge stops working - even with local addresses.

I checked out the free version of tinycam and it surprisingly works fine and doesn't seem to use a relay/p2p connection. Perhaps they're using a different version of the tutk library? Here's its output:

P2P mode - LAN
Camera IP - 192.168.68.64
Camera port - 40628
Camera NAT type - Unknown
Local NAT type - Unknown
Relay type - Not relay
Wyze devices
[1] Camera 'right' (dtls, mac: 7C78B299C157, fw: 4.36.13.0416)
[2] Camera 'left' (dtls, mac: D03F270B8464, fw: 4.36.13.0416)
[3] Camera 'up' (mac: D03F27186FB1, fw: 4.36.10.4054)

mrlt8 commented 3 weeks ago

Probably. Unfortunately, I only have access to version 4.2 of the tutk SDK from srvm.tutk.com and I believe they're on 4.3 right now.

However, the bridge should still be able to work locally as long as you can ping the cameras from the bridge.

rakbladsvalsen commented 3 weeks ago

However, the bridge should still be able to work locally as long as you can ping the cameras from the bridge.

Yeah, I mean it technically should work fine if we take into account issue #1298, but perhaps we're being served different firmware versions?

I docker exec 'd into the bridge container, installed ping and I was able to successfully ping all the cameras, so it's definitely something else:

ping 192.168.68.64
PING 192.168.68.64 (192.168.68.64) 56(84) bytes of data.
...
^C
--- 192.168.68.64 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 4.639/5.191/6.033/0.604 ms
root@83537bf089dc:/app# ping 192.168.68.63
PING 192.168.68.63 (192.168.68.63) 56(84) bytes of data.
...
^C
--- 192.168.68.63 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 8.542/10.981/12.368/1.730 ms
root@83537bf089dc:/app# ping 192.168.68.65
PING 192.168.68.65 (192.168.68.65) 56(84) bytes of data.
...
^C
--- 192.168.68.65 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 4.868/5.905/6.722/0.772 ms

mrlt8 commented 3 weeks ago

That is weird. I can still remotely connect to some of my family's cams on the latest version over tailscale or openvpn.

Have you tried setting FRESH_DATA=true?

For reference:

Wyze bridge v1.0+ TUTK 4.2.1.1
Old Wyze app (2.47) was using TUTK 3.4.4.3
New Wyze app (2.48+) is using TUTK 4.3.4.0
Old TinyCam was using TUTK 3.4.4.3
New TinyCam is using TUTK 4.3.4.1

mrlt8 commented 2 weeks ago

Interestingly, the decompiled 4.36.13.0416 firmware still seems to be using TUTK 3.4.4.4

mrlt8 / docker-wyze-bridge