Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
5 tasks done
rakbladsvalsen opened this issue Aug 20, 2024 · 14 comments
Open
5 tasks done

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

rakbladsvalsen opened this issue Aug 20, 2024 · 14 comments
Labels
bug Something isn't working

Comments

@rakbladsvalsen
Copy link

rakbladsvalsen commented Aug 20, 2024

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:

  • Use a different NET_MODE mode (p2p/lan)
  • Try the latest :edge builds
  • Use static IP addresses for the cameras
  • Rule out possible router issues
  • 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 #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>
@rakbladsvalsen rakbladsvalsen added the bug Something isn't working label Aug 20, 2024
@mrlt8
Copy link
Owner

mrlt8 commented Aug 21, 2024

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
Copy link
Author

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
Copy link
Owner

mrlt8 commented Aug 21, 2024

image

@dgaust
Copy link

dgaust commented Aug 22, 2024

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

image

@rakbladsvalsen
Copy link
Author

rakbladsvalsen commented Aug 22, 2024

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
Copy link
Owner

mrlt8 commented Aug 22, 2024

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
Copy link
Author

rakbladsvalsen commented Aug 22, 2024

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
Copy link
Owner

mrlt8 commented Aug 22, 2024

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
Copy link
Owner

mrlt8 commented Aug 25, 2024

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

@thereal-BLKMGK
Copy link

I too am on the same firmware with a V3 camera working fine! Bridge v2.10.3 I did have major issues connecting remotely, these cameras are 800+ miles away. I did NOT upgrade them but it seems Wyze may have pushed something. All of my cams had been flashed back to older stuff and I was ignoring their warnings. Then half my cameras died and had various versions of firmware. Tailscale to the rescue - WAY more stable recording too! Nothing from my Flood cam but the V3 and PTV cam are working rock solid right now! Happy to help troubleshoot this if I can provide anything...

@erickpeniche
Copy link

@thereal-BLKMGK can you please point me to a guide or instructions on how to set up Tailscale to work for docker-wyze-bridge? I have a wireguard server available in my network if that helps or is also compatible.

I can't pull video or snapshots from my remote V3 cameras running 4.36.13.0416 .

@thereal-BLKMGK
Copy link

@thereal-BLKMGK can you please point me to a guide or instructions on how to set up Tailscale to work for docker-wyze-bridge? I have a wireguard server available in my network if that helps or is also compatible.

I can't pull video or snapshots from my remote V3 cameras running 4.36.13.0416 .

I'm sorry, I only just now saw this request! This is what I did for my system -> https://github.com/SierraSoftworks/tailscale-udm

Basically you SSH into the system and install TailScale from the commandline. You will want to read up on the commandline switches for routing and whatnot but it's not hard to sort and if you get stuck post here and I'll get back to you with my settings. Note: This isn't as persistant install so when autoupdate occurs you have to reinstall. I turned off the autoupdate - they updated right before a hurricane hit, most pissed I was to lose my cameras but got them back before power failed ugh.

Since you already have Wireguard installed you could just do that instead but in my case I didn't and didn't want to manually sort out what was going to be required. Tailscale made this pretty simple for me but it's really just a really good wrapper for WireGuard that handles managing keys and whatnot with some extra spice.

@erickpeniche
Copy link

@thereal-BLKMGK can you please point me to a guide or instructions on how to set up Tailscale to work for docker-wyze-bridge? I have a wireguard server available in my network if that helps or is also compatible.
I can't pull video or snapshots from my remote V3 cameras running 4.36.13.0416 .

I'm sorry, I only just now saw this request! This is what I did for my system -> https://github.com/SierraSoftworks/tailscale-udm

Basically you SSH into the system and install TailScale from the commandline. You will want to read up on the commandline switches for routing and whatnot but it's not hard to sort and if you get stuck post here and I'll get back to you with my settings. Note: This isn't as persistant install so when autoupdate occurs you have to reinstall. I turned off the autoupdate - they updated right before a hurricane hit, most pissed I was to lose my cameras but got them back before power failed ugh.

Since you already have Wireguard installed you could just do that instead but in my case I didn't and didn't want to manually sort out what was going to be required. Tailscale made this pretty simple for me but it's really just a really good wrapper for WireGuard that handles managing keys and whatnot with some extra spice.

Thanks for the reply, I’ll give it a try. In the meantime I had to downgrade the firmware to fix the issue and its working fine now.

@thereal-BLKMGK
Copy link

Don't rely too heavily on that, I did the same thing myself. My cameras are over 800 miles away and on a trip I did the downgrade too. Before too long I was getting the upgrade pop-up including as a modal dialog occasionally in the mobile app forcing me to close the app. That was simply a hassle but then I lost access to a camera and then later others and the firmware versions no longer matched one another. Pretty sure I wasn't upgrading and that Wyze had pushed me to some baseline that was no longer compatible forcing me to solve the VPN issue. Just a heads up anyway, if your cameras are remote it can be no fun to do the install - thankfully it went smoothly.

First time I did the install I created a firewall rule and reached in to the router directly then turned the rule off - it hasn't worked since! So I've been forced to use their sort of internal WiFiman teleport thing to do the installs. Thankfully even making changes to the Tailscale config while connected through it hasn't dropped the connection :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants