I don’t even know why I bother asking. Faith in all that was once great about Wyze has eroded to zero, yet here I am.
When will the doorbell pro be integrated it with Web View?
I know you won’t tell us. I know you’ll just merge this into some “wishlist” 
SIGH… I wish you knew that this is a user to user forum, and not a Wyze site… SIGH
Uh huh so what is a Wyze site if being hosted on Wyze servers doesn’t count 
but seriously my actual phone and chat tech support has gone so terribly downhill this is just as bad. I honestly hope you’re having a better experience than I. I’ve been a huge promoter of this brand since the beginning and I just can’t now. The Wyze employees that frequent these forums are helpful as they can be, but the technical difficulties are becoming too much. I don’t know if this is an airport, but I think I might have to announce my departure soon 
I can’t say for sure, but I believe this is actually coming. Firstly they finally started adding some battery cameras to the web portal with the BCPros, then they started adding doorbells to the web portal starting with the VDBv2. Just within the last 1-2 weeks or so I believe they added the original Video Doorbell v1. It finally shows up in my list of devices and never has before.
I think the only devices they have left to add now are the WCO’s and the VDBPro, and I am sure they are coming. Previously they told us they wouldn’t add Battery cams…and now they do. They previously told us they wouldn’t add VDB’s, and now they do. They no longer say Battery cameras and Video Doorbells aren’t supported because they’ve been adding them in, even the old VDBv1. So, it is my belief that the VDBPro is going to gain compatibility soon, especially since it can be used with wired power just like the BCPros can be used with wired power. But the best indication is that they finally added the original VDBv1 to be compatible, which is a great sign that they are adding older models into the web portal now too!
Though, I don’t work for, speak for or represent Wyze, I am just speaking my opinion based on the progress I am seeing recently, including updates from just this very month.
It sure would be nice if you’re right, but I think the doorbell pro’s architecture will be a limiting factor. 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 to stream and control the camera like the rest of their products.
It’s pretty telling that they finally added a blurb to the web view saying the doorbell pro is unsupported. The chime is also a factor I think. Only one of the devices connects to your WiFi and that’s the chime. Then the chime talks to the doorbell via Bluetooth. I think they want to move towards all devices using the same SDK and now that they’ve released a new doorbell that cannot talk to the chime… I think the writing is on the wall.
Architecturally, the pro is a one off in their lineup and newer released products stray away from the pro’s way of doing things, except for that they seem to want to get all cams using WebRTC protocol and I think the pro does, still, Think about the flow of traffic, as a battery operated device, they do what they can t o save battery, I think chime sends Bluetooth wake commands to it and for all I know the the live stream goes through the chime before displaying in the Wyze app.
But hey, I could baa be wrong 
I had to put a shortcut in my Wyze app that I can tap to reboot the doorbell because it often disconnected and I don’t want to have to walk over to it and manually reboot the doorbell so it can re-establish its connection to the chime.
Good thoughts, though I believe I can overcome some of that FUD (Fear/Uncertainty/Doubt) with some info:
I believe the OG cams are also manufactured by Gwell (their model number matches the VDBPro model structure) and I believe they also use webRTC instead of TUTK (so they don’t work in Docker Wyze Bridge either because they aren’t TUTK), but they are already supported and streaming on the web portal.
I can’t be 100% certain but I believe the Battery Cam Pros and possibly the Floodlight Pros are also in this category because Docker Wyze Bridge is able to stream any Wyze camera that uses Throughtek, and it can’t use any of those models because they supposedly aren’t using TUTK (and I was of the understanding that they were only struggling with the Gwell models not having TUTK). YET, ALL of those camera models are already supported on the Web Portal, which indicates that it not the problem. There are already cameras manufactured from Gwell on the web portal, and there are definitely cameras not using TUTK on the web portal, therefore neither of those variables are a real obstacle because we already have some of those on the web portal working right now.
To add another point worth mentioning, all the cameras connect to Google and Alexa displays using WebRTC, so I don’t really believe webRTC is an impediment anyway because every single camera uses webRTC already. I wouldn’t be surprised if they eventually move away from Throughtek to have most or all of their newer cameras stick to WebRTC instead since they all already use it for some things.
This could be true. It may be why the WCO’s are also currently unsupported because they also go through a hub instead of a direct connection. I wouldn’t think that is a huge barrier though since all of those can stream on Google/Alexa, so what’s the difference? If it was that big of an issue, then why does it even stream to the app? I don’t think the relaying is a big issue.
I could be wrong, but only time will tell. This is something we could ask them in their next AMA,
#AMA2ASK (reminder to myself to ask about it)
Yes, you are right that the OG cams are also in the same Gwell boat as the doorbell pro, but I still think it is telling that the OGs are fully supported in Web View while the Doorbell Pro is listed as “incompatible”… of course, their support site has mistakes soooo… lol if you look here at the bottom they list the Floodlight Pro in both sections: fully compatible and non-compatible events only.
Have you seen the work carTloyal123 is putting in trying to get the Gwell based cam streams? It’s cool but complicated. Basically, the solution he’s working on will be to run two servers via docker containers: one to be a video proxy in the form of an android application and the other responsible for coordinating the actions of the video proxy. It looks like the OGs are close, but I’m not sure if he’s overcome the need to wake the doorbell from the chime to get the stream going. He’s stated that 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 and I guess it has come down to the fact they basically need to emulate an Android app to control the stream.
The video proxy is responsible for connecting to your Wyze Gwell based camera and sending those video frames to the cryze-server application. The video proxy waits and listens for specific wyze login info and a device id. Once the proxy has both of those it will connect to your camera and send video frames through the server on a specified websocket channel. The proxy is packaged in a Linux (tested on Ubuntu) Docker container.
Check it out here:
Thanks for sharing! I had not seen that project yet! That is exciting.
I used to use docker Wyze bridge and am about to install Scrypted to connect my cameras to home assistant but I’m not sure if Scrypted overcame the Gwell obstacle either. Seeing this project is exciting news. I appreciate you sharing that.
Oh, I went full on ADD+OCD recently trying to figure this out. As far as I can tell, you are basically deciding between 3 actively developed solutions, but none of them except Cryze are close to getting full functionality from the Gwell based camera. Additionally, the used to be a solution to remove any hosted services ands keep all camera traffic local to your network by flashing new firmware and the Wyze developers even provided the RTSP firmware, but hardware changes led to its deprecation and Wyze pulled the firmware download site. Now, it looks like all the different solutions just use the Wyze Node api wrapper and/or the unofficial Wyze api.
With standardized unofficial API wrappers that didn’t force you to flash the firmware, all these other developers have taken that part off their plate.
Most of it is driven by users wanting to implement and control their Wyze devices through solutions like Home Assistant or Hubitat. I have a Hubitat but might add home assistant one day into the mix just to ensure I have all opens options at my fingertips.
I guess that brings me to your three options:
Camera device to Docker Bridge to HA
Camera device to Scrypted to HA (via Scrypted’s own native Wyze plugin)
Camera device to Scrypted to HA (via the Docker Bridge)
I’ve lost my thread of thought 
anyway, there’s a lot of people out there working on a lot of different solutions and the way this dang doorbell pro is implemented grrrr lol they are ALL struggling to find the answer.
TL;DR, there’s no current solution for OG or Doorbell Pro, but I think the Cryze will be the first to get it, actually I think that’s the only one trying and others are waiting to see if he can do it. Scrypted is cool for integrating cameras in general, especially if you want to record to your own servers, etc. so if you go that way you should compare the new native plugin vs the docker bridge to see which fits your needs best. Then depending on which smart assistant you want, Siri, Alexa, or Google, you will have even more decisions lol
You would most likely just decide if you want to go straight from the docker bridge to HA, from the docker bridge to Scrypted then to HA, or from the Scrypted native plugin to HA.
But what smart assistant do you use to interact with HA. Siri, Alexa, or Google assistant? If it’s Siri then you could add HomeBridge to get you directly into HomeKit and in case you want EVEN more possible points of failure you can add a Hubitat too m 
And of course slap two docker containers into the mix for Cryze once that’s all laying flat 
I’m sure I’m missing stuff, but that’s what I got for now.
Well…that’s not necessarily ENTIRELY accurate…we can run TinyCam Pro in server mode to get an RTSP stream for basically every camera model. You can run it through an Android Emulator like BlueStacks. You can side Load it into Windows Subsystem for Android. You can run it on a smart TV. You can run it on an old Android phone or Tablet. Then you have an RTSP URL that you can plug in to anything that accepts RTSP streams.
The cofounder of TinyCam has even been a Wyze employee since Fall of 2020 and he gets every model functioning into TinyCam within a short time after launch and then RTSP streams are available for them through that method. I have even used to used it for this.
I kind of want to use Scrypted because of all the built-in custom detections it offers. If I use Docker Wyze bridge then I’ll also have to load a separate docker like Frigate to do everything I want. Might as well handle both with the same docker, and another user on here convinced me Scrypted is optimized and more efficient than other other options like Frigate, so I’m going to at least try it out, especially since it has the native Wyze option built in.
I have Alexa and Google Assistant connected to Home Assistant, and while I don’t use Siri or iOS (except in rare occasions to check something for someone on forums here), I do have the Homebridge and HomeKit plugin so I can use certain devices which are compatible with HomeKit (for example, I need this to connect my Aqara Presence sensors to Home Assistant). I also have a habitat elevation, though I haven’t used it since I switched primarily to Home Assistant as my core driver with a Nabu Casa subscription. So, I also now use the local Home Assistant voice projects to control things at home. Mostly I use Alexa and Google the other way around…instead of controlling Home Assistant with Google/Alexa, I control Google/Alexa with Home Assistant…use them to Announce things, etc, and I will push some Home Assistant entities into Google/Alexa too, but mostly just use them for announcements. I’m working to switch to mostly local audio.
So yeah, I very well may end up checking out Cryze once I get everything else settled. I am glad you mentioned it. I really wasn’t aware of it’s existence before today. That is very appreciated! 
Worst case scenario I was thinking I might run a TinyCam Pro Server just for the Gwell or non-TUTK cameras to get RTSP URLs, but it seems maybe Cryze will make it so that isn’t needed after all. 
I came across TinyCam but for some reason I got the impression it hasn’t been actively developed or maybe if was the extra Frigate stuff I didn’t want to get sucked into, I don’t remember now. Yea, once Cryze gets a little more polish, I might have to check it out too.
Wait. Wyze pulled the RTSP firmware and still refuses to provide an API?
If this is true then Wyze is trash.
They weren’t pulled as much as they were “De-listed” for security purposes (they don’t have the recent critical security updates, so it would be irresponsible of them to advertise using firmware that is currently vulnerable), but if you want them, they are still available directly from Wyze…because if you’re desperately going to use it anyway, it’s better for you to get directly from Wyze than a 3rd party who might have maliciously modified it:
They said they stopped listing it because they didn’t have the resources to continue devoting to a separate firmware branch, but it’s still technically available to anyone who wants to take the responsibility upon themselves to handle any needed security updates, etc.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.