If it’s anything like the Alexa integration won’t it still be mostly pointless for a doorbell? WebRTC might be a game changer but I think currently 10-20 second waits are the norm.
I don’t know enough about it to know, but I had assumed that 10-20 or more second connection waits were partially because of all the routing through multiple servers and nodes (router, modem, ISP, which may route it through backbone cable or satellite or who knows what, multiple channels to Wyze Server, then who knows how many connections to get over to Amazon/Google and different internal connections, then back several channels to your ISP then to your modem, then router, then back to the display device…I think that’s a big reason it takes so long. We’re talking thousands of miles and dozens of different connections before it comes back, many requiring some kind of authentication or encryption/decrytion of the information and retransmitting it in the right way.
By contrast, I would expect that WebRTC could theoretically just go from the Cam to the router, to the display. Only a few feet total, and possibly just a single node in between them (the router) without all the insanity and delays and points of failure. I would expect they could easily get it down to within a couple of seconds. I thought I remembered WyzeFrederik saying something about a 4 second expectation (I could be mistaken).
That still may be a little long for a doorbell unless you have it start loading while someone is walking up your sidewalk before they press the button. So, perhaps we could set a detection zone for the sidewalk, use the detection zone (currently in beta), and when it detects a person in that area it starts to load the doorbell cam onto the Alexa/Google Display. By the time they get to the door, you can see them and start talking (or not…it starts muted on the app, and I assume displays would allow this too). Seems reasonable if done that way.
Apparently even the “old” way should allow local communication across your home network. I can’t figure out what the long delays are (not unique to Wyze either).
Under good network conditions, the first frame should render on a device with within six seconds from when the TLS handshake completes. Optimize startup latency by adjusting key frame rates and buffer times of the stream.
You can return a local URI on the same network as your device, or you can return a remote URI accessible from anywhere with an Internet connection. You should return a URI that makes the most sense for your device cloud configuration. Whether you return a local or remote URI, you must meet all requirements including the use of TLS 1.2.
In general, a URI isn’t reachable both locally and remotely by default. You can make the URI accessible locally and remotely through domain purchasing or port forwarding. These solutions are technically challenging, so provide this solution only if your customers need both local and remote URI access.
Some good feedback. I have a small tv mounted in portrait orientation on my basement wall as a fake window. I was using an old wyzecam mounted sideways outside and tinyCam Monitor Pro to stream the feed.
Hooking up the new doorbell, I went into tinyCam’s camera settings and checked the status to find out what channel the doorbell was on. Switched the channel, and done. No rotation needed. The 4:3 aspect ratio is odd on a 16:9 screen, but it works. I set my firetv stick to use the H264 HW decoder and get a solid 20 fps.
I got my doorbell awhile back but the weather hasn’t been conducive to installing it. That may change this weekend.
Those that have installed it - what do you think about the electronic chime? I haven’t heard it. I’m a little afraid it will sound “Cheesy” like a lot of electronic chimes do.
So what’s the consensus? Sound ok?
I didn’t care much for the modern tunes or animal sounds but the classic chimes are very realistic.
And loud! That tiny speaker is way louder that one would expect.
At least one of the classic chimes are really good (#6 Doorbell 1 - my wife and daughter didn’t really like most of the other sounds as a doorbell noises, though they could be useful for other things if the chime is ever allowed to work with rules). And it does go louder than my real mechanical chime ever did and it’s more reliable than my old mechanical chime. It’s a big winner IMO.
Only downside is that there is no way to constantly record. No SD card nor RTSP. If I want to basically constantly record the best I can do is to remove the detection zone and turn up the sensitivity so it will record all motion, but then it is totally worthless for notifications because it would give notifications for all cars and people across the street too. If I want notifications I have to set a detection zone, but then it rarely records anything, so either way there is a big fail when it comes to recording options, even WITH Cam Plus…but as for the chime itself, I like it. Though it would be nice if we could add and select our own sounds for the chime eventually, there is at least one classical doorbell chime that is really good (#6 Doorbell 1)
For what it’s worth I just discovered today how to do continuous recording in TinyCam Pro. I thought I had it on but it was only doing motion detection events. (I just had to hit the Play button under Background Mode). This will probably work for your doorbell?
Oh yeah, I didn’t even think about that. I did know that TCP can do continuous recording. You’re right, that IS a potential solution! Maybe I will do that. I was thinking I’d be stuck having to leave another camera watching the front of my house just to have this capability, but TCP is a great alternative. Thanks for the reminder.
My only real hesitation is whether I want a constant stream through my internet.
- Comcast only allows me up to 1TB/mo before overcharges. I haven’t ever exceeded this by myself, but when we rented out our basement and allowed the tenants to share the wifi, we went over once…then I set up bandwidth monitors and limitations to make sure that never happened again while they were here…but I’m still cautious now. Shame TCP isn’t 100% local RTSP or this would be perfect.
- It might increase problems with the Router since they can only handle so many connections at a time before spazzing out and collapsing connectivity frustrating everyone. having one connection dedicated just for the doorbell to constantly stream may not be worth it…
I will have to consider this. Might be worth it, maybe even just on a certain schedule or something. At least it makes it possible to record constantly when desired. Thanks for the reminder!
What, no - TinyCam is just as local as the Wyze app as far as I understand. There’s nothing on the “Internet” side for video to travel to / relay from. I don’t think bandwidth is a concern. (Just the usual authentication to Wyze servers.)
FYI I just found a gap in my TinyCam recording coinciding with a Wyze motion event. Camera must have been too busy. Also this was a rare person detection failure (Wyze flagged as motion only).
Edit: Correction, no gap in TinyCam. I just had to zoom in on the timeline for finer grain control. The frames/second needs to be tweaked though. I just bumped it from 5 to 10 fps. I’m sure the storage on my poor little Fire tablet will thank me.
What’s the lag like between pressing the button and having the chime sound?
I put a Ring doorbell and chime in my mom’s house and the lag is borderline unacceptable to me. I think it must message Ring’s servers which then send a command to sound the chime back down. Her internet service is kinda slow so I think that’s making it worse.
So what’s the lag like on the Wyze product?
Wait, I’ve misunderstood this all this time? I thought that even with the Wyze app that everything was steamed to the Wyze servers and relayed back to our app… Are you saying that only the authentication goes to Wyze servers and then the stream connects directly like we’re told things will start doing with WebRTC connecting locally to Google/Alexa?
But then wouldn’t it continue streaming if internet drops mid-stream after it’s already authenticated?
You are a well informed one who I trust, do you have anything to reference to help me understand that? I’ve apparently misunderstood all this time.
I thought that Only tcp server steamed locally after getting the stream feeds routed through the internet… So the initial feed to the TCP server was by internet (hence the terrible choppiness) but anything that connected to that TCP server would then be local.
It’s hard for me to believe it’s all steamed 100% local minus authentication since I can’t tell a difference in quality between when I’m using the same network as the cams vs mobile data or away from home… But if it is steamed locally sometimes I’d love to hear/read more!
My chime has no noticable lag as far as I can tell, though it is only 20-30 feet away for mine. If there is one it’s less than a second for me.
The chime connects directly to the doorbell on a different signal, so it doesn’t need to route through the internet first.
No way. They would have gone out of business by now relaying all that traffic. The only hits they get are for authentication and hand off to the P2P provider. The Throughtek / TUTK P2P service (3rd party) establishes a direct link between your phone and your camera. On your LAN it doesn’t even have to. It took me a long time to find this again, the most authoritative post from Wyze on the process:
Of course for event recordings the camera does have to upload clips to Wyze servers. But not for any live or SD card viewing. Some more interesting info below.
Here is more information on this from Wyze. Click on “How does Wyze protect my Live Stream and Event videos”.
Yes. The only stream going through Wyze servers are the ones going to Google and Alexa prior to WebRTC. We had to do that to get a chance to convert the RTMP output from the camera to RTSP for Alexa and MEPG-DASH for Google. There was also a requirement to have a public IP to be able to connect to the streams.
As mentioned, that is prior to WebRTC. Once we have converted a camera to use eWebRTC, there is no need to send the stream to the Wyze servers anymore. I believe a direct connection is established using SDP between the camera and the consumer of the video even if the consumer is not on the local network.
Oh, thank you for the correction. I had not realized that in the cases of Alexa and Google device viewing that you are in fact relaying video. (I don’t think this changes my earlier answer about TinyCam not using it.)
Is there a way to determine when a particular camera has converted to using WebRTC?
Your response was totally correct.
For the moment, none of the google streaming is on WebRTC except about 100 cameras for development tests and validation.
For Alexa, we have 900K cameras already converted. So most likely if the camera has been used for streaming on Alexa in the last month, it has been converted.
There is no obvious signs that a camera is converted or not but of when being local the steaming appear real time, that’s a sure signs that WebRTC is being used.
Oh and Tinycam is using the Tutk protocol for streaming, not the RTSP or mpeg-dash protocol.
Okay thanks. I suppose I can test by starting an Alexa view and then killing the router. But is this protocol change based on accepting firmware updates or is it entirely determined at your back end?
I most definitely have WebRTC on my Alexa show devices then. I just tested it with my pancam and a V2 and the lag was less than a second, including the audio. It’s even better than recorded video on the SD card (which often has an audio lag). It was REALLY REALLY GOOD. I love it!
I also tried streaming my Video doorbell, and of course, it failed on google with the WCO icon:
but it did stream to my Alexa Echo Show, though sideways:
Which is awesome, way better than not having any video like I swear we were originally told at launch (that the aspect ratio was incompatible with Alexa/Google Streaming). Though I just saw your post in the other thread saying that now you’re going to have to revoke Alexa Streaming because people keep filing tickets complaining that it is sideways/landscape. Sad, sideways video is so much better than no video at all like we’re going to get now…though if you’re trying to avoid getting tickets about it, I’d think taking away support will just get people filing tickets that it’s not working, instead of it being sideways, right? Might be just as easy to reply to the complainers that it has to be sideways, though if they install their doorbell sideways then it can show right-side up on Alexa.
When the VDB did stream to my Echo Show, it had a really bad lag/delay. I am guessing the VDB was not set up with WebRTC like the other cams were? My other cams were basically real-time, but the VDB had a lag of over 10 seconds, maybe as much as 20 seconds. This indicates to me that it was not WebRTC even though the others were. And it sounds like the VDB is just being revoked from support anyway, so I guess it doesn’t matter.
There is no noticeable lag to hearing the plug in chime. It is nearly instant.