Support for Wyze Video Doorbell Pro?

[terryhonn]

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? ;-)

[mrlt8]

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).

[carTloyal123]

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?

[carTloyal123]

@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.

[mrlt8]

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.

[carTloyal123]

Looks like the enr field is empty for the dbpro. What is that field for usually?

[carTloyal123]

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.

[mrlt8]

Wyze uses the enr to authenticate with camera over tutk (authkey, password, challenge response, etc).

I believe IoTVideoSdk requires an accessToken and accessID..?

[mrlt8]

Can't find anything in English, but this seems to be the relevant documentation: https://cloud.tencent.com/document/product/1131/42244

[carTloyal123]

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.

[holocronology]

Is the DBP now working?

[carTloyal123]

@holocronology Not up and running yet, have been slowly looking into it still since it uses a different framework than the other cams.

[22gred]

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?

[RayfenWindspear]

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 :facepalm: [\rant]

[Gletob]

@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.

[is33]

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

[mrlt8]

Preview image is coming from the Wyze API. You can manually pull a new image (if available) from the /thumb/cam-nam.jpg endpoint.

[mmatus1112]

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...

[holocronology]

Is this even still being worked on?

[carTloyal123]

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

[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

[Z1mDMan]

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!

[holocronology]

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.

[kedrosng]

/thumb/cam-nam.jpg

i saw the thumbnail but not a updated one.

[RayfenWindspear]

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.

[kedrosng]

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 ?

[kedrosng]

https://streamable.com/97u0yb

Here is the video showing google home hub connecting doorbell pro

[mrlt8]

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.

[carTloyal123]

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

[praveenvj1979]

I can also see the screenshot now. However the video stream is still not supported.

[carTloyal123]

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!

[mrlt8]

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?

[carTloyal123]

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!

[carTloyal123]

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.

[aquariuz23]

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!

[carTloyal123]

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!

[22gred]

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 https://github.com/mrlt8/docker-wyze-bridge/issues/276#issuecomment-1965557861, or unsubscribe https://github.com/notifications/unsubscribe-auth/A5WCUOHM5APS57GZXWXCXMTYVUQD5AVCNFSM5LO4ZWOKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJWGU2TKNZYGYYQ . You are receiving this because you commented.Message ID: @.***>

[carTloyal123]

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

https://github.com/mrlt8/docker-wyze-bridge/issues/276#issuecomment-1965557861,

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.

[22gred]

Great! Good luck! I bought some OG's right after they came out thinking I could use the special Wyze firmware to communicate directly with software on my PC, only to discover that Wyze had quit supporting that firmware, and it was only for the cam V3 in any case. If you get it working. I will definitely give you some support!

On Mon, 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)

https://github.com/mrlt8/docker-wyze-bridge/issues/276#issuecomment-1965557861 ,

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 https://github.com/mrlt8/docker-wyze-bridge/issues/276#issuecomment-1965683290, or unsubscribe https://github.com/notifications/unsubscribe-auth/A5WCUOEWXPYRBF7OCVMR3FTYVVBJDAVCNFSM5LO4ZWOKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJWGU3DQMZSHEYA . You are receiving this because you commented.Message ID: @.***>

[aquariuz23]

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.

[22gred]

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) https://github.com/mrlt8/docker-wyze-bridge/issues/276#issuecomment-1965557861,

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 https://github.com/mrlt8/docker-wyze-bridge/issues/276#issuecomment-1965683290, or unsubscribe https://github.com/notifications/unsubscribe-auth/A5WCUOEWXPYRBF7OCVMR3FTYVVBJDAVCNFSM5LO4ZWOKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJWGU3DQMZSHEYA. You are receiving this because you commented.

[carTloyal123]

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?

[carTloyal123]

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 !

[terryhonn]

@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...

[lflondonol92]

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?

[carTloyal123]

@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.

[mrlt8]

@carTloyal123 let me know if you need any help with the auth API!

[carTloyal123]

@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.

[mjb83]

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.

[carTloyal123]

@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!

[carTloyal123]

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!