Past Issues: Typically required re-pairing cameras, downgrading firmware, etc. All resolved.
Hello all, I cannot for the life of me get my Wyze Cam v4 working with docker-wyze-bridge to feed into my Frigate instance. It is refusing to play nice, and despite firmware changes, firewall triple checks, switching container maintainers, updating my API key, verifying the cameras are active on the Wyze proprietary web app, etc. I cannot get the cameras back online. Can anyone help me?
[[ A workaround was found to get streams back at 640x360@10FPS using go2rtc, details below ]]
You’ll need to downgrade the firmware manually and turn off auto updates until Wyze Bridge makes the necessary changes (obviously it is up to them if/when they do that). A new security protocol has been implemented, and they need to implement it to match. As far as I know, Tiny Cam Pro is the only one so far to have made the update in the latest version.
I believe the last working firmware version for many apps is 4.52.9.4188 but you may need to go back further to the one prior to the one that added “verified view”.
Or maybe I’m misunderstanding, are you saying it worked fine on 4188 before? If so maybe something is going on with the API right now, or maybe something updated on your Docker instance or Wyze Bridge? I suppose the question is - what changed at the time it broke?
It’s been working just fine on that firmware, which I flashed to following a similar event in February. However, it has stopped working – I made no changes to the configuration and the cameras have not auto-updated since. There have been no changes to anything that I can find that would have caused a shift in behavior, but alas.
[[ Spoiler: Wyze server-side change that broke TUTK P2P ]]
If you’re certain there were no updates to docker or wyze bridge or anything else in your setup then it would point to some connectivity issue, perhaps something blocking the connection to the Wyze API (or that API just having problems right now).
Is this the only cam you have or do you have others that are still working?
Both cameras are down. One camera went down and the other went down after I selected “reconnect” in the Wyze-Bridge UI.
I agree with the connectivity issue, but it would seem to be a change on the Wyze side – I haven’t touched camera connectivity firewall rules or anything of that nature.
Could also be ISP or router related, sometimes they push out a new ruleset to their malware protection that starts having false positives on something, or a routing issue in their network.
Maybe try some tests to https://auth-prod.api.wyze.com/api/user/login or just auth-prod.api.wyze.com and see if it is reachable from within your docker. You should probably get a 405 response if you just try to browse to the URL. Though I suppose it could appear to be reachable but when the actual code/JSON gets sent through something triggers and blocks it, that would be a malware protection type issue.
If you’re using a router with that sort of filtering in it, maybe try disabling it temporarily.
Right now I’m trying to simply login via the API with my credentials. It’s rejecting every attempt. I changed my password and API key/ID. Not getting through.
I’m not good enough with code to compare yours to theirs, theirs seems simpler with just nesting the MD5 3 times but no idea if that’s the same or not.
Maybe try their code exactly (with your credentials)?
Excellent, finally managed to get in. Didn’t like my strings. An updated script to check Wyze API login for anyone else stumbling on this conversation is as follows:
import hashlib, os, uuid, requests
email = os.environ["WYZE_EMAIL"]
password = os.environ["WYZE_PASSWORD"]
keyid = os.environ["API_ID"]
apikey = os.environ["API_KEY"]
def wyze_login(email, password, api_key, key_id):
# Triple MD5 the password
hashed = password
for _ in range(3):
hashed = hashlib.md5(hashed.encode("ascii")).hexdigest()
phone_id = str(uuid.uuid4())
resp = requests.post(
"https://auth-prod.api.wyze.com/api/user/login",
json={"email": email, "password": hashed},
headers={
"apikey": api_key,
"keyid": key_id,
"user-agent": "docker-wyze-bridge",
},
)
# Parse the response body BEFORE raise_for_status so we can see
# the actual error message from Wyze on 4xx responses.
resp_json = resp.json()
print(f"Status: {resp.status_code}")
print(f"Response: {resp_json}")
resp_code = str(resp_json.get("code", resp_json.get("errorCode", 0)))
if resp_code not in {"1", "0"}:
msg = resp_json.get("msg", resp_json.get("description", resp_code))
raise Exception(f"Wyze API error: code={resp_code} msg={msg}")
data = resp_json.get("data", resp_json)
data["phone_id"] = phone_id
return data # contains access_token, refresh_token, user_id
if __name__ == "__main__":
print(wyze_login(email, password, apikey, keyid))
Unfortunately, this only confirms that I can access the Wyze API properly from my network, and from the device which I’ve been using to access the cameras (from within the docker-wyze-bridge container itself).
Well you’ve at least confirmed the API is up and running and accepting your login.
Can you install a docker where you can run that same test from within docker? Off the top of my head I can’t remember the name of the various web tools for linux but there are several and I’m sure there is a docker version of many of them.
If that works, then the challenge becomes determining if it is the incoming stream that is having the issue, or maybe if wyze bridge is having some sort of issue with some update wyze may have made.
Does wyze bridge have logging you can enable? I haven’t used it.
Tagging @carverofchoice as he’s the guru on this, I believe @seapup is probably pretty familiar too.
Also worth noting that they mention a rate limit on the API, maybe all the testing has just locked you out for a while, but I would think your test above wouldn’t even get a response in that case, but I don’t know.
Edit: Please note this is not a fix for the problem, it is a temporary workaround.
Alright, so after an extensive search and rabbit hole, I have a bandage (not a fix) for getting the stream back up and running. So, Wyze must have made a server-side change that broke TUTK P2P for HL_CAM4 models. The cameras’ TUTK services simply don’t respond. I tried using nickdnj’s v4fix fork of Docker Wyze Bridge, but it did not work.
That being said, I found a workaround, which is to bypass TUTK entirely and pull streams through Wyze’s AWS Kinesis Video Streams (KVS) WebRTC, which still works. Wyze-Bridge even exposes this already at /signaling/<camera_name>/?kvs. So you can add go2rtc alongside your DWB container with the configuration below. Then you can update the configuration downstream (HASS, Frigate, whatever) to use this go2rtc instance. Note the streams are all 640x360@10FPSand that this cannot be changed.
You’d think if the TUTK was broken it would be impacting a lot of other stuff. Maybe just via the API, in which case hopefully they’ll fix it soon so you aren’t stuck with 640x360. I’ll tag @carverofchoice again as he’s probably interested to see this when he’s back online.
I wonder what the webRTC at that resolution is usually used for. Maybe alexa/google displays or something.
I also think that, and I wonder why I haven’t really seen anyone else complaining anywhere on Reddit, Github, or here. I definitely hope that there is a better fix that allows me to access the HD stream again soon.
As for why, it might be the previews that show in the app before you click on a stream.
Thank you very much for your assistance by the way, I really appreciate it.
Pretty sure you figured it out yourself, I was just along for the ride. I haven’t had a need to use the API or any of the 3rd party software (I do have them connected to my fire TV stick just for the heck of it but that’s all natively supported).
I see carver is online now so he’s probably interrogating it himself right now…..
Looking forward to RTSP being released for v4 and Panv4 hopefully this summer. That will make things easier on a lot of people that want to use their own in-home solution. Basically 0 reliance on wyze servers, API, etc. Just streams direct from the cam with a local username and password you create.
I’m suspecting that they’re giving RTSP back due to all the additional security they’ve been adding. We may see the API go away once all the cams have RTSP.
I can confirm that I am also seeing Wyze changed their TUTK protocol in some cameras that used to use it. I noticed this on my network logs weeks ago. I have been waiting for someone else to bring it up (thank you @jmesches for posting about this, and @dave27 for tagging me). I would like Wyze to comment on this publicly, but so far they have not done so. I believe this change is partially responsible for multiple 3rd party connectivity breakages and some seeming connectivity issues. I’d like them to elaborate on the change.
For what it’s worth, docker Wyze bridge was entirely dependent on TUTK and never worked with Gwell based cameras that used the lotvid SDK instead of TUTK for authentication, so there was a forked Cryze project for those other cameras… but it appears that recently some cameras that used to used to use TUTK no longer do, and this is why they stopped functioning in docker Wyze bridge which only supports TUTK. I knew it was only a matter of time before someone else noticed, figured out the issue and publicly posted about this. Well done. Now if we can just get Wyze to post something publicly about this issue.
