using motion detecting with Alexa takes way too long. With Blue Iris is almost instant…there’s an initial fee, but it’s well worth it… you can also use TinyCam which is free.
I purchased Blue Iris and never looked back.
It is kind of slow and there’s quite a bit of latency when displaying. I use a Show on my desk to pop up and display when someone comes to the door. Half the time that the mail comes the carrier is already gone by the time it comes up and shows the cam. Big difference vs watching the same cam in BI.
That second camera doesn’t appear that it would be very useful at night, given all the strong IR reflections from nearby objects.
Hello Lonnie,
This is one of my eight WOC’s I have around my house in various places. I just moved it to that location to try to see where the Coyotes were going when they came up my hill (the other two paths have Cam’s covering those paths, this area did not. It’s a temp spot for the camera until I move it to another location with less IR Reflections.
It’s been 'entertaining to see how many rats, mice, birds, coyotes frequent that area. (I live next to a wide open military base in Southern California)
SJ
Had a closer look at what’s happening.
I reflashed the rtsp firmware and performance in VLC on my PC became much more stable.
However when I put the feed into motioneye (on a test raspberry pi 3 with no other programs running), the CPU usage on the pi hit the roof, which seems to be the cause of the lag and eventual freezing. I also have a pi 4 running motioneye full time for my other V2 cams and it has no problem converting 4 streams. However, adding the V3 stream will simply bring motioneye to its knees.
I’m guessing that the stream bitrate is much higher for the v3 for some reason even though this isn’t reflected in image quality. Hopefully the folks at Wyze can work some magic and optimise the output.
Maybe try disabling audio for the cam in MotionEye if you can? Same happens with BI without a registry hack.
The bitrate isn’t very high on these. I show a range of ~70-125 kB/s in BI for mine depending on the moment. Much lower than any of my other cams. I don’t have V2s to compare but I’d be surprised if it’s much if any lower than that.
Hi there, thank you for sharing this feedback and sorry about the delayed response.
Please send me a private message with the logs.
Thank you.
I think I’ve got to the bottom of this after more research than I care to have done!
So now I’m pretty sure that this is mostly due to lack of hardware decoding/encoding on motioneye. Following some suggestions elsewhere I’ve swapped out motioneye for motioneyeos and CPU usage is now significantly lower. Also my test scenario involved pointing the camera at my TV. In doing so the pi simply couldn’t keep up with the amount of data being sent to it. When I pointed my camera outdoors, the lag was on par with my v2’s due to minimal scene changes in general and I get no freezing.
So everything works (at least for general home monitoring) so I’m happy for now!
However re the bit rate, I’m pretty sure it is at least 20% higher than the V2’s on average.
Someone posted test results and if I recall correctly the V3 bitrate is actually consistently much LOWER than that of the V2 due to the V3’s excessive compression.
Of course that might mean additional effort to decompress at the receiving end…
Also I have no idea whether that even applies to the RTSP stream.
Has anyone been able to get more insight on the audio issue with BI and this beta firmware version? I know that for a handful that registry hack works, but it’s not working for me and would love to get sound on my stream(s).
Hack doesn’t work for me either running BI 5.5.2.5.
Kind of interestingly I can enable audio on one of my V3s and it does not cause the same effect. The other two do. When enabled, the one that doesn’t still does not transmit audio. Audio does come over the app. Registry settings at 1 and 64 kbps G.711 a-law for all. Setup in BI same for all. Only difference that I can think of is that cam is the only one without an SD card which doesn’t seem particularly relevant.
Nothing seems to work. I have played with QoS on the router, replaced the antennas with higher dBi, reduced the number of devices, ignore audio, etc.
Nothing works. It still freezes and often when it starts recording. I get lots of those clips with something / someone moving and stuck for a long time then disappears because of the freeze. Very frustrating.
Wyze needs to look into this for sure.
Just wanted to chime in with my experiences here to see if anybody has any other workarounds. I’m running the beta RTSP version with my Wyze Cam v3 and the stream intermittently dies if internet access gets cut off for any reason.
This is very easily reproducible by setting a firewall rule in my gateway, and it doesn’t matter if the cam boots up with internet access already available. Once the FW rule is activated it takes maybe an hour or so until the stream starts randomly dropping making the cam totally useless for applications where there is limited internet connectivity.
Am I out of luck until this issue is patched in a next release (if ever), or should I just give up and go with a properly working RTSP camera?
I’ve not seen them drop off if I give them access when they start up and then block them but I’ve just done it as a test and not run mine for extended times like that. When they do drop off they’ll come back up fairly quickly so not that big of a deal in my case since they’re not critical cams. But, yeah, really shouldn’t be happening.
I don’t think that there’s any way around it so probably out of luck unless and until they change something. In other cases you could just let them have access in/out. Not ideal and shouldn’t be necessary but works. If losing Internet is causing it, then that’s a little different. I’d think that they’d be good once it’s back up but not?
I’m having trouble getting the Beta f/w to load. I just bought 2 cameras. I’ve tried all suggestions in this thread. Here’s what I’ve done without success on 2 cameras. I didn’t change the file name. There is no extra .bin at the end.
Tried a 32gb card formatted to fat32.
Reformatted on windows machine, Put bin file on card before initial setup. Did the power up while holding the setup button.
Setup the camera then added the bin and did the power up/ setup button.
Formatted the sd in the camera then added the bin after setup then power up/ setup button.
Tried all of the above with a 16gb fat32 card and same result.
I’ve looked for the RTSP option and f/w number after each attempt and not updated. Never see a purple light, just the solid red then flashing red with “Ready to connect”.
Anything else I should try?
1 Like
Not sure. Didn’t have any trouble with mine. One cam didn’t come up right at first. Restarted it and it was OK. The file that I used was named demo_wcv3.bin @ 9,477KB uncompressed. Extracted on PC and moved just that to the 32GB SD card that came with the cams. Bought another without a card and used one of the same cards from before in it and worked fine.
That’s the same file and size I’m using.
Okay so got the purple light working (and now have RTSP) after having the same problem (literally did at least 50 tries with no success). Did a lot of testing. First attempt with another micro sd card, it worked lol.
The relevant differences:
2GB, Kingston, fat32, non-bootable (non-working for firmware)
8GB, Sandisk, fat32, bootable (working for firmware)
The rest is probably as the Wyze documentation says though I did a bunch of files with variable naming as a further test.
I’m wondering if making it bootable is what does the trick. It would be kind of odd that a specific sd card I’ve been using with it to record streaming, etc and works perfectly fine that way but not for the firmware.
And if it were the size then yours should work. So it should either be bootable or specific micro sd cards do not work for firmware flashing despite otherwise working with it. Guess speed rating, etc could be another but again it works otherwise. Might not be bootable either unless everyone here just happened to have it bootable. So might just come down to specific cards do not work.
So I could narrow that down a bit more but that at least should help.
I tried ffmpeg on a Wyze Cam V2 with RTSP demo_v2_rtsp_4.28.4.49.bin.zip. It works as expected.
It does not work on a V3 with demo_v3_RTSP_4.61.0.1.zip.
The ffmpeg failure is Wyze V3 specific.
I have provided this info to Wyze Support and will now await feedback.
[UPDATE]
ffmpeg works on V2 and V3!!! User Error.
When I did the V2 “test” I re-created my “2 line” script from scratch. It worked. Today (the next day) I was able to discern the error/typo in my original V3 ffmpeg script. That took an embarrassingly long time 
1 Like
I just purchased a new Wyze Cam V3 with the intent of installing the RTSP firmware. I have followed all directions in every forum post I have found without luck. While holding down the setup button after power cycling, I get “ready to connect”. I know the button is properly held down because otherwise I don’t get the ready to connect message. I can never get to the purple light.
After seeing other posts stating that I had to use an SD card smaller than 32 gb, I tried a 16gb and 8gb SD card. I downloaded the v3 firmware and left the file name alone after extracting the zip as “demo_wcv3.bin”. I verified they are formatted Fat32 and even tried reformatting each of them both from Windows disk management as well as from the Wyze android app advanced options SD card format option. I tried it with the shipped firmware installed and also tried after I upgraded to the latest (non-RTSP) firmware. I tried downloading the firmware and building an SD card from both my personal and work computers. (Win 10)
I even tried to download the regular firmware and have it loaded via the same SD card procedure without luck. I am at a loss on what the issue could be and have exhausted all of my normal troubleshooting methods. (22 years as a systems engineer or higher, not my first rodeo) The camera doesn’t have any issues writing videos to the sd cards.
My only thought process at this point is either I have 2 SD cards that aren’t going to work for this process (one no-name the other adata) or there is something wrong with the formatting, partitioning (wiped and re-created already as a test) or camera as a whole.