Support for Wyze Video Doorbell Pro?
terryhonn opened this issue · 104 comments
Are there plans to support the new Video Doorbell Pro, model WWVDP? I hope so... if not, who wants to buy a Wyze Video Doorbell Pro? ;-)
I'll have a look at the app.
Is the pro 100% battery operated or can it also be powered like the non pro?
The Pro has both power options, as well. Thanks for taking a look!
Any chance it works like the WYZEDB3? I don't see anything for WWVDP, so I'm wondering if the pro is actually the WYZEDB3-S?
Edit: looks like the pro is actually the GW_BE1
Edit: looks like the pro is actually the
GW_BE1
I don't know if that means it's possible, or not, but if there's anything I can do to help, please let me know!
The doorbell pro seems to be made by Gwell and has a model number of GW_BE1.
Does the doorbell even show up in the bridge? Looks like it might be using their "mars" platform or whatever that is and streams over KVS which is what they're using for the WebRTC streams...
I wonder if they're trying to move away from TUTK to AWS which could be the reason for the forced updates coming next month.
Does that mean it's a feature that's coming eventually or is it not possible? I also have one of these and I'm willing to do what I can to help test this.
This bridge is currently based around the cameras that use the Throughtek Kalay SDK "tutk" to stream video. From what I could tell, it seems like the new Doorbell Pro is not using tutk, so we can't use that SDK to connect to the doorbell.
Starting with v1.1.0, we added the option to try to pull the WebRTC credentials if available. You could try adding WEBRTC=True to your docker-compose.yml to see if can pull the credentials of the doorbell.
Added the WebRTC env to an instance and included the WVDP in the FILTER_NAMES var. When the bridge starts up, it pulls the info for 3 cams and then does this:
Would you rather I open a separate bug report, since this doesn't appear to be directly related to the WVDP?
File "/app/wyze_bridge.py", line 584, in <module>
wb.run()
File "/app/wyze_bridge.py", line 49, in run
self.get_webrtc()
File "/app/wyze_bridge.py", line 401, in get_webrtc
if wss := wyzecam.api.get_cam_webrtc(self.auth, cam.mac):
File "/app/wyzecam/api.py", line 230, in get_cam_webrtc
resp.raise_for_status()
File "/usr/local/lib/python3.10/site-packages/requests/models.py", line 960, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 404 Client Error: Not Found for url: https://webrtc.api.wyze.com/signaling/device/REDACTED/use_trickle=true```
That's a known issue that has already been patched in the dev branch.
It just means the auth tokens are expired and temporarily adding FRESH_DATA=True should get you past that.
I had tried forcing the fresh data, but still getting the error. I uninstalled and reinstalled (this instance is the HASS Addon, BTW), and enabled WebRTC from the start. It says it's starting 1/11 cameras (I have 12 in the Wyze app, however a few are either disabled or turned off), and it gets through the first 3 and then throws the same error.
File "/app/wyze_bridge.py", line 584, in <module>
wb.run()
File "/app/wyze_bridge.py", line 49, in run
self.get_webrtc()
File "/app/wyze_bridge.py", line 401, in get_webrtc
if wss := wyzecam.api.get_cam_webrtc(self.auth, cam.mac):
File "/app/wyzecam/api.py", line 230, in get_cam_webrtc
resp.raise_for_status()
File "/usr/local/lib/python3.10/site-packages/requests/models.py", line 960, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 404 Client Error: Not Found for url: https://webrtc.api.wyze.com/signaling/device/2CAA8EF6E97F?use_trickle=true
The device it is puking on is a regular Wyze Video Doorbell, not the Pro. Happy to help with debugging, just tell me what to do.
Thanks!
I have a Wyze Video Doorbell Pro and was hoping to help test this. I am also getting errors when I try using these environment variables. I removed WEBRTC=True for now. I don't think I'm running the dev branch. Is this working in dev?
Has anyone tried to see what kind of traffic is going between the app and camera?
@Z1mDMan Could you try blocking your phone or the doorbell from the internet to see if we can even communicate with it locally?
anyone happen to have the firmware update link for this new model doorbell?
I also have a Doorbell Pro and can help with any testing. Would really like to get this working
Has anyone tried to see what kind of traffic is going between the app and camera?
@Z1mDMan Could you try blocking your phone or the doorbell from the internet to see if we can even communicate with it locally?
Wow sorry I completely missed this. Is this still something that would help? I can easily block things from the internet on my network.
I see that there's a homebridge plugin that discovers this doorbell however it only shows up as a switch not a camera. https://github.com/jfarmer08/homebridge-wyze-smart-home
Does this help at all?
I think that will let you to "power" on/off the camera over their web API which I believe uses AWS IoT core to communicate with the cameras.
I believe they're using WebRTC for the doorbell Pro over AWS Kinesis - can you see the doorbell if you go to view.wyze.com?
I cannot view my Doorbell Pro from view.wyze.com
Thanks for the data point. Not sure why they're using a different method for this camera alone.
They seem to have gone back to the regular tutk video stream for the other "pro" 2k cams.
Well, glad I found this, as I've been wracking by brain trying to get it to work.
Any update on this?
If it is any help, the interface for the camera view is similar to that of the newer v2 sensors.
I think that will let you to "power" on/off the camera over their web API which I believe uses AWS IoT core to communicate with the cameras.
I believe they're using WebRTC for the doorbell Pro over AWS Kinesis - can you see the doorbell if you go to view.wyze.com?
I wasn't able to see it on view.wyze.com either but I did notice it now gets exposed as a switch in homebridge-wyze-smart-home plugin. Doesn't seem to do anything but it's a start.
it does show on view.wyze.com now but as unsupported.
Any updates on this? It seems that the video doorbell pro will not be able to be supported without major work. Is that correct or are there ways to help here?
Correct. The doorbell pro seems to be the only camera in the wyze lineup manufactured by gwell and stream over webrtc instead of using the throughtek SDK (tutk) to stream and control the camera like the rest of their products. So I don't think we'll be able to support it with the current method we're using to pull the streams locally.
Wyze seems to be trying to get the rest of their cameras to stream over webrtc - cam plus web view/smart displays. Still haven't confirmed it, but I believe the latest app/firmware is also using webrtc, so we may eventually be able to support all the cameras via webrtc.
Understood, is there any work that can be done to add WebRTC to this repo or is it a big enough change to warrant an entire re-write?
Right now, we're using the tutk protocol to pull the video and audio frames from the camera and repackage that into an RTSP stream, so if we could find a library that can connect and pull the WebRTC stream from the AWS IoT Core server, then we may be able to use that as a replacement.
any updates on this? Devices like RING DOORBELL have a fantastic integration into Home Assistant and it would be awesome if the wyze doorbell pro could have something similar...
I have been slowly looking into it but nothing up and running yet. There are a few libraries that will convert the WebRTV stream to digestible frames but I have not started any implementation as I am working on another Wyze project at the moment. Will update when I have more info/time to get started on this.
@mrlt8 I have been doing some research today and it looks like we can get a live HLS video stream URL from AWS Kinesis with some pretty straightforward methods provided by the AWS SDK. My question is, can we even scrape the correct authentication and credentials to setup that stream? I have a doorbell pro so I am happy to help but I must say I am pretty new to reverse engineering network calls. Are you familar with how we might be able to get some of the data being passed between the camera, bridge and Wyze AWS endpoints? It looks like we need the below information to get somewhere with this:
var options = {
accessKeyId: $('#accessKeyId').val(),
secretAccessKey: $('#secretAccessKey').val(),
sessionToken: $('#sessionToken').val() || undefined,
region: $('#region').val(),
endpoint: $('#endpoint').val() || undefined
}
var kinesisVideo = new AWS.KinesisVideo(options);
var kinesisVideoArchivedContent = new AWS.KinesisVideoArchivedMedia(options);
kinesisVideoArchivedContent.getHLSStreamingSessionURL({
StreamName: streamName,
PlaybackMode: $('#playbackMode').val(),
HLSFragmentSelector: {
FragmentSelectorType: $('#fragmentSelectorType').val(),
TimestampRange: $('#playbackMode').val() === "LIVE" ? undefined : {
StartTimestamp: new Date($('#startTimestamp').val()),
EndTimestamp: new Date($('#endTimestamp').val())
}
},
ContainerFormat: $('#containerFormat').val(),
DiscontinuityMode: $('#discontinuityMode').val(),
DisplayFragmentTimestamp: $('#displayFragmentTimestamp').val(),
MaxMediaPlaylistFragmentResults: parseInt($('#maxResults').val()),
Expires: parseInt($('#expires').val())
Most of these are options that can be set once but the interesting parts will be the accessKey and secretKey.
Let me know if you have any ideas on this or how we can test my device and scrape some of the needed information.
Other link for AWS example I am referencing: https://github.com/aws-samples/amazon-kinesis-video-streams-media-viewer
EDIT: I was also thinking that even if the camera stream runs through AWS the camera itself has to be creating and sending some stream of video from the doorbell pro or the bridge and I am wondering if that is possible to uncover and use directly for a direct connection to the system instead of involving an outside service.
I'm not very familiar with AWS, but I believe the camera pulls a couple of AWS related certificates on boot. I believe the cameras also use AWS's IOT Core to "power" on/off the cameras and for the other missing commands.
I don't think the secretKey ever gets revealed, but I was able to open a web socket connection with the credentials that the bridge can pull with the WEBRTC=True option. However, I the gwell cameras seem to use a different "mars" API endpoint https://wyze-mars-service.wyzecam.com, so I don't know if they even support the standard WebRTC like the cameras that support the official web view.
You could try to run the app through a proxy to try to capture the traffic related to "mars", but you'll need a way to disable the certificate pinning on your device.
I believe the KVS live view endpoint should be at "plugin/mars/live_replay_url", but I'm not familiar with that area of the wyze API.
I am also not super familiar with the AWS or Kinesis tech just been reading about it. Are you able to see a live stream from the normal Wyzecams using WebRTC and the credentials provided?
What leads you to think that the KVS live view endpoint will be at plugin/mars/live_replay_url? I just want to understand the current knowledge before diving too deep. Thanks!
it looks like you can connect to the websocket but the authorization is not working for me from what I can tell. Are you able to connect to the websocket without getting a 403 HTTP error?
It looks like all of the info needed to connect to the WebRTC stream is given in the WSS url but decoding what each part is actually used for when connected to KVS seems to be trial and error at the moment.
You can see some of the API endpoints if you decrypt the official apk/ipa.
You may be able to get some of the values from the wss if you URL decode it with something like https://meyerweb.com/eric/tools/dencoder/.
I believe the new Wyze OG cameras are also being built by gwell so we may have the same issues streaming from those cameras.
Hey @carTloyal123, v1.11 should decode the signalingUrl, so you should be able to use that to open a web socket connection!
@mrlt8 Thank you I will check it out and see what I can find. If the new cameras are also Gwell over AWS hopefully we can find a way to tap into that.
It looks like Wyze has an api service that handles all of the KVS and AWS setup. They have an api call that might just simply return the live streaming URL but maybe that is already what the WebRTC calls are doing that you have added.
Something calling to "https://ams-api.wyzecam.com:443/api/v1/kinesis/live_replay_url/get" that takes normal API call params for authentication plus the following:
{
"sc": "a9ecb0f8ea7b4da2b6ab56542403d769",
"sv": "2c36005f9d714dfcb08aa261c2f6edd3",
"device_mac": "XXXX",
"device_model":"GW_BE1", # for Video Doorbell Pro
"max_manifest_fragment": 1000,
"expires":3600,
"begin_time":1673458804,
"end_time": 1673458814
}Going to look at using the existing API infrastructure to add this additional call and see what it returns.
Looks like I am able to ping the endpoint but the authorization status is not working correctly. Any ideas here? Here is some output:
URL:
https://ams-api.wyzecam.com:443/api/v1/kinesis/live_replay_url/get
Headers:
{'X-API-Key': 'WMXHYf79Nr5gIlt3r0r7p9Tcw5bvs6BB4U8O8nGJ', 'Phone-Id': 'XXX', 'User-Agent': 'Wyze/2.38.3.3 (iPhone; iOS 16.2; Scale/3.00)', 'Content-Type': 'application/json'}
{
"sc": "a9ecb0f8ea7b4da2b6ab56542403d769",
"sv": "2c36005f9d714dfcb08aa261c2f6edd3",
"app_ver": "2.38.3.3",
"app_name": "com.hualai.WyzeCam___2.38.3.3",
"phone_system_type": "1",
"ts": "1673492859864",
"access_token": "XXX",
"phone_id": "XXX",
"device_mac": "GW_BE1_XXX",
"device_model": "GW_BE1",
"max_manifest_fragment": "1000",
"expires": "3600",
"begin_time": "1673492281204",
"end_time": "1673492281214"
}
Response:
{"ts":1673492918150,"code":"3005","msg":"UnauthorizedOperation","data":{}}
We're currently getting the signalingUrl from webrtc.api.wyze.com:
docker-wyze-bridge/app/wyzecam/api.py
Line 235 in be46025
I did try the live_replay_url but seems like it only works for certain models? Keep getting 3005 except for the v2 which responds with an empty live_replay_url:
{
"ts": 1673501945477,
"code": "1",
"msg": "",
"data": {
"live_replay_url": ""
}
}Is it returning a valid url when the request is made from the app? I believe some of the API endpoints require a signature.
Yeah I have been getting the empty live url for my V2 cams and then the authorization error for the Doorbell Pro. The signaling URL is good to have but it seems we need to have additional AWS credentials in order to connect to that signaling channel and receive data. I will look into it more but the format from the Kinesis dev webpage suggests we need more information.
What kind of signature do you mean? Like a different API key than the one I have listed?
The signaling url is pre-signed to avoid leaking their keys: https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-query-string-auth.html
The webrtc.api.wyze.com api should also return the turn auth/credentials in addition to the signalingUrl.
What kind of signature do you mean? Like a different API key than the one I have listed?
Some of the other Wyze API endpoints seem to require a signature or signature2 header:
signature2: d121afe2ab054386badf71a293c726ae
Luckily, none of the endpoints that the bridge currently uses require the signature header, but I have seen some endpoints that do.
So I think I've made some progress on the WebRTC stuff. I have a JavaScript client that will connect to the web socket and negotiate the webrtc details. The issue I am finding is that the cameras have to be prompted in some way to actually send frames over the webrtc protocol. This is likely just another wyze endpoint that pings and starts the camera streaming. It makes sense because the camera is battery operated so it isn't streaming all the time. Any thoughts on how to tell the device to start streaming would be awesome. I'll continue to look into the same thing as well as port over the code to python for use in this plugin.
Awesome! Is that for the doorbell or the cam? I think the next step would be to send the SDP_OFFER followed by the ICE_CANDIDATE?
Here are some other potential API endpoints:
https://ams-api.wyzecam.com:443/api/v1/kinesis/live_url/get
https://wyze-mars-service.wyzecam.com/plugin/mars/live_replay_url?did=<mac>&startTime=<timestamp>&endTime=<timestamp+300>
I believe the mars one requires the Signature2 header.
Yeah the webrtc setup is totally complete and that is for the doorbell pro. My client is fully configured and just waitingto receive webrtc tracks or streams. The issue is that once the webrtc connection is setup the doorbell cam has to be prompted somehow to start sending data over the webrtc connection or even has to be prompted to setup its end of the connection then send frames. This seems to be why in the app when you connect to the doorbell you actually get a little setting up connection screen while it waits for webrtc to begin on both sides. The strange thing is that the signaling endpoint returns a signalToken but I do not know what to do with that. It's possible that they are using custom web socket servers through aws which somehow incorporate the token but it's hard to tell. From all I have ready Amazon simply creates a signaling server on request and the websocket setup is from them.
The live url endpoint seems to return nothing for the v3 cams implying they probably don't use it and for the doorbell pro I can't seem to authorize the request correctly. The mars endpoint seems to be for getting stored events that the cameras have recorded which is useful but not entirely.
I'll test my webrtc client with the v3 cams and see if that gets anywhere.
Quick update: WebRTC for V3 cams is working. I have a JavaScript implementation that will stream the video to a webpage. Just need to investigate converting that to python and how to convert the frame data to something more friendly if needed.
On the other hand, same exact setup does not work with Video Doorbell Pro so not sure what is going on with that. I imagine it has to do with some extra authentication or again, pinging the doorbell somehow to start sending data over the connection. Might have to do with pinging the doorbell bridge to setup the live connection.
Awesome, can you post some more details for the non-doorbells? We could probably stick that into the webUI for now.
As for the doorbell, are you getting the signaling url from webrtc.api? Have you tried:
https://wyze-mars-service.wyzecam.com/signaling/device/{mac}?use_trickle=true
Is the doorbell pro showing up as unsupported on view.wyze.com? It could be like the outdoor cams which aren't supported on the web view because they also need a wake command sent to the base station.
I would be happy to join in the testing.
Ok, so I had a look at the wyze app to see if we can wake the doorbell and it looks like the Doorbell Pro (mars) and the new OG/3X (gemini) are actually using Tencent Cloud's P2P protocol for streaming video to the app.
For reference, the other cameras (Hualai) are using the ThroughTek Kalay platform.
That's very good to know. How are you profiling the app to find extra info?
I'll look into that platform and see about adding it alongside the TUTK platform that is already implemented.
So WebRTC is basically only for some of the updated firmware on V2 cams? Is it worth continuing to work on WebRTC and implementing it in the bridge?
You can see some of the test code I was using for the WebRTC/AWS Kinesis here at this repo: https://github.com/carTloyal123/wyze-webrtc-kinesis-tools
I will clean it up when I have time but a decent bit of it will be useful in the client script.
Thanks for the example! I was able to get it working with a couple of v2/v3s but not on any of the outdoor cams even when they were awake and streaming to the bridge.
Easiest way to profile the app is by decompiling it and just looking through the code. While it is possible with IPAs, it's usually much faster and easier to download and decrypt the APKs with something like jadx.
As for sniffing the traffic, you'll either need to jailbreak your device or sideload a modified app with certificate pinning turned off so you can actually see the requests in a debugging proxy like Charles.
You could also try unpacking the actual firmware files, but unfortunately, I don't believe there are any public links available for the Doorbell Pro. The firmware link may be visible on https://wyze-upgrade-service.wyzecam.com/app/v2/upgrade/get_firmware_detail (requires Signature2).
Sounds good. Hopefully that started code was a little bit helpful for the V2/V3.
As for the outdoor cams and doorbell pro, I will try to ping some of the other endpoints and get some info on the Tencent P2P SDK. They have some examples but the examples seem difficult to transfer over since they all require Tencent access tokens from the account. If I had to guess the Tencent information is probably at another Wyze endpoint that sends over credentials similar to how the kinesis signaling url is sent over a wyze api call. Do you have any thoughts on looking into Tencent further and how it might interact with Wyze services?
@holocronology hey there, so far there is not much to actually test but hopefully that will change soon. If @mrlt8 wants someone to check the WebRTC live view that might be useful but I defer to @mrlt8 for that. If you want to get into the software by all means go for it, this thread has as much info as I am aware of.
Any chance some of the auth stuff get returned like enr does in in https://api.wyzecam.com/app/v2/home_page/get_object_list?
Added some basic support for webrtc in the webrtc branch.
Looks like the enr field is empty for the dbpro. What is that field for usually?
The object list does include a p2p_id which might be the unique room id used in Tencent p2p connections. Might look into that unless there are other theories.
Wyze uses the enr to authenticate with camera over tutk (authkey, password, challenge response, etc).
I believe IoTVideoSdk requires an accessToken and accessID..?
Can't find anything in English, but this seems to be the relevant documentation: https://cloud.tencent.com/document/product/1131/42244
Yeah those docs look solid. I have seen a few demo apps on github that we might be able to test with. I am guessing we can just try the normal accessToken as one credential and possible the p2p_id for the accessID. I have been trying to ping they Mars endpoints but as mentioned they require the signature2 which needs the correct signing secret. I have not been able to find the correct signing secret so still looking for that.
Even if the IotVideoSdk works out, it does not look like they have a python version so that might be a little messy to figure out unless there is some way to load those libraries. I think they have DLLs for PC which could be bound to python I suppose if needed.
Is the DBP now working?
@holocronology Not up and running yet, have been slowly looking into it still since it uses a different framework than the other cams.
I am a noobie who just bought 10 Wyze OG cameras thinking I could use those with a Windows PC Blue Iris or ISpy system. But I've learned a lot - I was looking, just a few days ago at a Wyze web page on how to upload the beta firmware with RTSP into a Wyze cam V3, the first cam I bought. First mistake - I was thinking that would work on the new fantastic $20 OG cams. But, after ordering the cams, I looked for the instruction page and downloads - and could not find them. They have removed them. More info in this thread I started on the Wyze forum: https://forums.wyze.com/t/should-i-return-my-10-og-cameras/257699
Sorry - I tried "add a link"
In any case, I want to volunteer to help, and my oldest son is an international "software architect" for a major firm, and works mostly in Java. Perhaps he could contribute something, although he is presently preparing to move permanently to Spain (we lived there when he was 5-15).
If you can read that thread above, you will see my programing experience is mostly assembly code for air traffic control systems.
However, if you read my last post, perhaps I might be most useful in trying to connect with the right person in Wyze and show them the light that they would benefit enormously by making public, even if only to a few willing to sign non-disclosures, the details of the communication protocols, etc, so that WE can access the data and do as we wish with it.
I worked 10 years in Spain, as well as South America and the Middle East, had top secret clearance in the Embassy. Maybe I could help along those lines?
I did a brief search and skim looking to see if this had been mentioned before, but it looks like not. One problem we might have with the Doorbell Pro is that the Chime unit sets up a 2.4ghz AP specifically for the Doorbell unit to connect to. I'm not sure whether or not that matters for RTSP, but it means you won't find the Doorbell unit on your network, you'll find the Chime. Hopefully that might help in the quest to access it for the bridge.
[rant] I'm annoyed they chose this path for the pro because it further taints the already crowded 2.4ghz band even more. I've got 3 APs spread across the non overlapping channels, but the stupid chime almost always reads more strength than my fairly decent 3 AP setup. [/rant]
EDIT: [rant] Now I'm super frustrated. The chime will broadcast on whatever channel it's receiving on 🤦 [\rant]
@RayfenWindspear I've not investigated the exact connection mechanism, but I do know that regardless of which BSSID it is using, it does connect to and get it's own IP on your local network. So if it is connected through the Chime AP it is likely just bridged to it's client connection to your networks AP.
The doorbell however is only reachable on the network when either you connect to it in app, or when motion or a button press triggers recording/notifications.
I believe the reason they did this was to allow the WiFi to sleep while allowing the camera to quickly associate with the chime which is already constantly associated with the network. On normal APs the device would disassociate after being asleep for some time and take longer to associate.
As for how it engages when you view from the app, I believe that is the purpose of the Bluetooth component. They are most likely using BLE to communicate to the doorbell asking it to wake up.
I will try to investigate this more this weekend if it can potentially help.
Hey there! Looks like ya'll are getting close yeah? I see it showing up on the page, just no available stream. Interestingly the preview image is from a few hours ago so its deff pulling in something
Preview image is coming from the Wyze API. You can manually pull a new image (if available) from the /thumb/cam-nam.jpg endpoint.
Hey there! Looks like ya'll are getting close yeah? I see it showing up on the page, just no available stream. Interestingly the preview image is from a few hours ago so its deff pulling in something
Nothing from my doorbell pro showing up on my docker. Just updated to V2.0.0, might take a while for HA to recognize the doorbell...
Is this even still being worked on?
I am still looking into it but because of the challenges mentioned and this idea that the doorbell is hidden somehow it has become much more difficult than the other cameras. My idea is really to see if we can back out how the wyze app accesses the camera feed without having to get involved in the camera hardware at all but this is also challenging. Feel free to look into it yourself and add useful information to this thread if you find anything @holocronology
Pardon my reply above and if it sounded flippant. I was being serious. I'm happy to provide whatever information I can and help test development. Unfortunately, I think is beyond my technical skills to come up with a solution, as much as I'd like to. @carTloyal123
Wow there has been real progress here! I can see a snapshot in the web gui now for my Doorbell Pro! Let me know if there's anything a non-programmer can do to help test getting the stream working. Thanks all for the progress so far!
Wow there has been real progress here! I can see a snapshot in the web gui now for my Doorbell Pro! Let me know if there's anything a non-programmer can do to help test getting the stream working. Thanks all for the progress so far!
No such snapshot on my end.
/thumb/cam-nam.jpg
i saw the thumbnail but not a updated one.
Something notable about Wyze's own webview. No support there for Doorbell Pro either. So it seems something that wyze is running custom that doesn't support local views.
Still should be some way to intercept the stream locally. Might need to try sniffing the traffic using a MITM attack to expose the traffic to wyze's servers if it can't be found elsewhere.
I may be interested enough to take a crack at it eventually. Going to be a busy summer, so it may not fit into a crazy schedule.
One thing worth knowing too. If you link up the doorbell with google homehub, it can connect and shown the camera feed on the screen. See if this information helps ?
Here is the video showing google home hub connecting doorbell pro
Google/Alexa/IFTTT have access to a separate private API that communicates directly with wyze so we have no way to see what's going on.
Even if they have separate private API access can we somehow use the Google home api and tunnel that into the bridge. So something like Camera -> wyze -> Google or other provider -> docker bridge. This feels feasible but I haven’t looked at the technical details
I can also see the screenshot now. However the video stream is still not supported.
I realize that I have been responding to Wyze Cam OG comments and not the VDP2 which is the device I have been interested in. I will make updates here from now on.
@mrlt8 do you already handle h264 data streams in the bridge? If so then I am up to that point with the VDP2 and will start trying to merge the two together. I can produce an h264 data stream from the camera given the login details and deviceId so just looking to see what the next step is here to integrate further. Thanks!
It's probably not the best way, but we actually use a subprocess to pipe the raw h264 from the tutk library into ffmpeg which then publishes the stream to MediaMTX and that handles all the WebRTC and other streams.
I wonder if we might be able to do something with a named pipe across the containers?
Ah I see. That seems to be a fine way of doing it thus far. Is there a better approach you know of? Seems like a case of "ain't broke, don't fix it" but I am curious if you think there is a way to improve it. I will look at setting up a named pipe for the raw video h264 data. Do you have any thoughts on how to pass other data like login credentials and deviceIds to the new container/application? My thought is that I would add a new class to handle gwell cameras here in wyze-bridge that would be a websocket client to be used for things like starting/stopping streams, passing credentials, logging, and passing device info. Thanks for your input on this!
Also, I am curious if you know if there is currently a mechanism in place to notify us that someone wants to view the video stream. This is an obvious concern for most doorbell users since the units run on battery power. Is the h264 stream from existing cams always running or is it requested to start when the bridge starts? Also after the bridge starts, does the stream continue in the background or does it start and stop as needed when clients connect/subscribe to the various feeds? I am looking through the code but figured it is worth it to hear the dev perspective as well if possible. Thanks!
For now it looks like I can create a new class similar to wyze-stream.py since the stream.py outlines protocol/interface the stream manager can deal with. Let me know if you see a better approach to integrate the needs of the gwell cams.
Hello folks, good day to all of you. First off, thank you very much for all your hard work in supporting and trying to get the Wyze Doorbell Pro to work.
I wanted to see if there is any update on this, maybe a beta version that I can help test? I would really love to be able to view my front door camera in Home Assistant so that I don't have to constantly access the Wyze app on my phone whenever someone rings the doorbell.
Not intending this to rush anyone or whatnot. Just curious if we are any closer to finding a way to view the camera in HA. Thanks again for all the amazing work!
You can check out Cryze. I have done the reverse-engineering to access your video doorbell camera stream and am in the process of integrating that technology into outside services like this repo (docker-wyze-bridge) and other smarthome platforms of interest (native homekit, Home Assistant, so forth). The Cryze project is not quite ready for people to use and consume easily but that is what I am working on now. I have a docker container that hosts the connection to your camera and another container that hosts a server for routing that data around. Once there is an easy way for people to set this up I will update the Cryze readme immediately. Feel free to peak at that repo over the next few days/weeks for updates. Thanks for the interest!
By any chance will your work allow accessing the Wyze cam OG as well?
On Mon, Feb 26, 2024 at 7:11 PM carTloyal123 @.***>
wrote:
You can check out Cryze https://github.com/carTloyal123/cryze. I have
done the reverse-engineering to access your video doorbell camera stream
and am in the process of integrating that technology into outside services
like this repo (docker-wyze-bridge) and other smarthome platforms of
interest (native homekit, Home Assistant, so forth). The Cryze project is
not quite ready for people to use and consume easily but that is what I
am working on now. I have a docker container that hosts the connection to
your camera and another container that hosts a server for routing that data
around. Once there is an easy way for people to set this up I will update
the Cryze readme immediately. Feel free to peak at that repo over the next
few days/weeks for updates. Thanks for the interest!
—
Reply to this email directly, view it on GitHub
or unsubscribe
.
You are receiving this because you commented.Message ID:
@.***>
Yes it should. I actually just got an OG in the mail today so I will start testing with it shortly.
You can check out Cryze. I have done the reverse-engineering to access your video doorbell camera stream and am in the process of integrating that technology into outside services like this repo (docker-wyze-bridge) and other smarthome platforms of interest (native homekit, Home Assistant, so forth). The Cryze project is not quite ready for people to use and consume easily but that is what I am working on now. I have a docker container that hosts the connection to your camera and another container that hosts a server for routing that data around. Once there is an easy way for people to set this up I will update the Cryze readme immediately. Feel free to peak at that repo over the next few days/weeks for updates. Thanks for the interest!
@carTloyal123 thank you very much for your reply. I will give it a spin and see how it goes. Do you know how this performs with Wyze Cam V3 Pro, in terms of streaming on an android tablet? I posted an issue for Cam V3 Pro through Wyze Docker Bridge here, where I am unable to get Cam Pro V3 to stream on android tablets unless I use the substream. Running the regular stream, even with WebRTC still results in the stream freezing and not loading at all. The substream works fine but at the same time is occasionally laggy and the quality is really subpar. I believe mrlt8 was the one trying to help me out (thank you again mrlt8), but I'm still on a mission to try and run the default full quality stream of the Cam V3 Pro on my android tablets. I'm really hoping this works much better through Cryze.
You can check out Cryze. I have done the reverse-engineering to access your video doorbell camera stream and am in the process of integrating that technology into outside services like this repo (docker-wyze-bridge) and other smarthome platforms of interest (native homekit, Home Assistant, so forth). The Cryze project is not quite ready for people to use and consume easily but that is what I am working on now. I have a docker container that hosts the connection to your camera and another container that hosts a server for routing that data around. Once there is an easy way for people to set this up I will update the Cryze readme immediately. Feel free to peak at that repo over the next few days/weeks for updates. Thanks for the interest!
@carTloyal123 thank you very much for your reply. I will give it a spin and see how it goes. Do you know how this performs with Wyze Cam V3 Pro, in terms of streaming on an android tablet? I posted an issue for Cam V3 Pro through Wyze Docker Bridge here, where I am unable to get Cam Pro V3 to stream on android tablets unless I use the substream. Running the regular stream, even with WebRTC still results in the stream freezing and not loading at all. The substream works fine but at the same time is occasionally laggy and the quality is really subpar. I believe mrlt8 was the one trying to help me out (thank you again mrlt8), but I'm still on a mission to try and run the default full quality stream of the Cam V3 Pro on my android tablets. I'm really hoping this works much better through Cryze.
Sounds like there could be a lot of factors going on to affect the quality of the stream. I assume in the Wyze app you can see the stream full quality just fine? What do you mean the substream?
Dear carTloyal123, I have lots of questions, and while I have a lot of electronics and computer experience - these cameras, Docker, Cryze are all brand new to me, so please pardon me if some of my questions are too ignorant. [1] - Am I correct that to be able to access my OG cameras’ data, I would use docker and your two docker containers? [2] - Are you aware of any instructional guides on the installation and implementation of Docker (it appears more complicated than just pulling stuff off the BitHub page)? [3] - Likewise, do you have plans for a simple to follow guide for Cryze? [4] - Perhaps this is not the best place to ask, but I did see a post, without details, speaking of using an active PoE splitter (UCTRONICS) and PoE injector (TP-Link TL-PoE160S) to interface to a Wyze camera. However, I was under the impression that all the Wyze cameras USB connectors are only to supply power, and there is no data on it - all data has to be transmitted over WiFi. Is that correct? What’s more - seems that before spending $30+ on a splitter and injector for one camera, I would consider looking for a ready-built IP camera. [5] - Are you familiar with and do you have an opinion on which is better for recording and displaying the cameras - Blue Iris or ISpy? Thanks again for all your work. Mark
…
On Feb 26, 2024, at 9:38 PM, carTloyal123 @.> wrote: By any chance will your work allow accessing the Wyze cam OG as well? On Mon, Feb 26, 2024 at 7:11 PM carTloyal123 @.> wrote: You can check out Cryze https://github.com/carTloyal123/cryze. I have done the reverse-engineering to access your video doorbell camera stream and am in the process of integrating that technology into outside services like this repo (docker-wyze-bridge) and other smarthome platforms of interest (native homekit, Home Assistant, so forth). The Cryze project is not quite ready for people to use and consume easily but that is what I am working on now. I have a docker container that hosts the connection to your camera and another container that hosts a server for routing that data around. Once there is an easy way for people to set this up I will update the Cryze readme immediately. Feel free to peak at that repo over the next few days/weeks for updates. Thanks for the interest! — Reply to this email directly, view it on GitHub #276 (comment) <#276 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/A5WCUOHM5APS57GZXWXCXMTYVUQD5AVCNFSM5LO4ZWOKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJWGU2TKNZYGYYQ . You are receiving this because you commented.Message ID: @.***> Yes it should. I actually just got an OG in the mail today so I will start testing with it shortly. — Reply to this email directly, view it on GitHub <#276 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/A5WCUOEWXPYRBF7OCVMR3FTYVVBJDAVCNFSM5LO4ZWOKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJWGU3DQMZSHEYA. You are receiving this because you commented.
First, thanks for the interest and curiosity about this new work going on. Let me address these one by one:
[1] - Am I correct that to be able to access my OG cameras’ data, I would use docker and your two docker containers?
Answer: That is correct. One docker container will be a proxy between your setup and your camera video stream, the other will be a server that you can use to route your video stream wherever you want. This will enable multiple clients to route the camera data to different platforms like docker wyze bridge, homekit, home assistant etc.
[2] - Are you aware of any instructional guides on the installation and implementation of Docker (it appears more complicated than just pulling stuff off the BitHub page)?
Answer: Depends on what you are trying to do, if you simply want to learn more about docker then this link is a good place to start Docker Overview. If you just want to use docker, then there are loose instructions on most repos that require it including Cryze and docker wyze bridge.
[3] - Likewise, do you have plans for a simple to follow guide for Cryze?
Answer: Yes as I continue to complete and update the project, the instructions will also be updated to reflect the simplest installation and setup. At the moment the main repo has instructions for the proxy and server: Cryze
[4] - Perhaps this is not the best place to ask, but I did see a post, without details, speaking of using an active PoE splitter (UCTRONICS) and PoE injector (TP-Link TL-PoE160S) to interface to a Wyze camera. However, I was under the impression that all the Wyze cameras USB connectors are only to supply power, and there is no data on it - all data has to be transmitted over WiFi. Is that correct?
Answer: I have never tried to access my camera over a wired connection but they do not have RJ45 ethernet ports on them so I have no idea how you would connect to a PoE connection of any kind. Best to stick to Wifi for simplicity unless you are specifically trying to reverse engineer the hardware connections.
Thanks @22gred !
@carTloyal123 , very enthused for the possibility of being able to use any of the GW cams outside of the Wyze world. I've got both the Cryze server and android-emulator running in separate Docker containers, but they're not doing anything and I don't know where to go from here. Is there any further documentation on setting necessary configs? Also, the readme mentions a community forum for asking questions/getting help... can you share a link to that, please? And thanks for your efforts here...
Same here @terryhonn. I installed both containers (even had to modify one the Android dockerfile to run the emulator) but I don't know how to set my credentials. @carTloyal123 Any suggestions?
@terryhonn @lflondonol92
Hey guys, first of all thanks for the support and for checking out the Cryze project. As you both noticed there is still work to be done as far as setup and setup instructions go. Currently you have to execute your own python script that passes in Wyze credentials through the sever to the emulator. I have not had much time recently to iron out more details basically since the last time I made a commit. To keep things organized please feel free to open an issue with the exact errors you guys get in the respective Cryze repository. Again thank you for the support, it is great motivation to carve out the time to get this thing up and running! My ideal case is that you simply add a .env file with your Wyze credentials next to your docker compose and then do 'docker compose up' and magic happens.
@carTloyal123 let me know if you need any help with the auth API!
@mrlt8 I really only need to authenticate using basic credentials like api key, email, password etc. Then call a few endpoints. I am wondering if you might be interested in splitting out the Wyze auth/API code into another Python package so we can both use it and contribute to it as updates happen to the Wyze API. I know @seantarves has basically the same setup in his python module so perhaps he would be interested in this as well so everyone can use/contribute to one central Wyze API code base instead of it being split.
I'm bumping this up as I just went through the history here and it looks like there was never a solution?
Just got the doorbell cam pro and was pretty disappointed to see this when I restarted my bridge:
[WyzeBridge] [GW_BE1] doorbell not supported
Any new updates? Anyone get this working - maybe I missed a comment my apologies but I'm pretty sure I went through everything..... as the post is still open I figured it was still an issue.
@mjb83 thanks for the interest here, I'm glad to see the doorbell pro still has some people excited. I worked on update the Cryze application mentioned in this thread this past weekend and made some decent progress. It is not consumer ready yet but it is closer. At the moment, I am combining everything into a single docker container where you can set your Wyze credentials and then it will start to output raw video from the container. Biggest challenges at the moment: moderating when the video stream is on/off. Adding support for RTSP stream out instead of raw video. Improving bandwidth/processing. I hope to have time to work on these challenges this coming week. So it is being worked on, progress is just slow at the moment. If you are technical feel free to jump in! Thanks!
Also, there will be some work required to integrate with this bridge but I think the desired behavior will be from Cryze to RTSP instead of Cryze to docker-bridge to RTSP(or other format). Open to thoughts on this!