For what it’s worth I’ve never had to reboot a camera to get it to reconnect. However, rebooting the WAP always has the effect of getting the camera to reconnect. I’ve tried this with multiple brands and models of routers including Asus, Unifi, and Linksys. I will say that the Unifi AC Pro I tested with was impossible to use with the cameras as it showed 70-99% spectrum utilization over 2.4Ghz with only 3 cameras connected and no other devices. This caused Blue Iris to repeatedly report no signal every few seconds.
First I wanted to thank Wyze for including this feature on the roadmap.
I agree with @DeanSmith, if I’m recording to an NVR, live view or play back by the app would just be secondary or to check notification. What I want to make sure is I have a good quality recording on my NVR and that’s the priority, so if ever there’s an event, I’m pretty sure I can get a good evidence from my NVR, even if that event includes the camera being stolen or destroyed.
More power and I hope you continue this customer community involved development of your products.
1 Like
I’m experiencing this exactly. Shorly after starting two cameras on the Unifi AC Pro the utilization maxes out and the latency from the devices renders them unusable. This seems really odd given Unifi AC Pros are much better than most SOHO WiFi routers. Has anyone done any analysis of the wireless traffic? Are the cameras doing anything they shouldn’t causing these issues?
Do you have any suggestions for either a Windows or Android app to use?
Always looking for new tools.
I have 2 AC Pros and 5 cameras with no utilization issue. Edit: Be sure you don’t have airtime fairness enabled.
Just came across this information today. I had seen posts about RTSP here a few days ago and wanted to pass along the information. Hopefully you will incorporate the ability to transfer the video stream securely. Food for thought …
Researchers were able to hack surveillance systems and replace video feeds
Researchers looking into the security of IoT devices used in smart buildings discovered they could replace video feeds from surveillance systems with arbitrary footage.
Researchers at Forescout set up a test environment that used building automation systems (BAS) to integrate video surveillance (IP cameras), smart lighting (Philips Hue), and an IoT system designed to integrate components in other subsystems for things such as monitoring energy consumption and space utilization, or predicting infrastructure maintenance needs. During their testing, the researchers found that encrypted protocols for video streaming (SRTP, RTP over TLS), file transfer (SFTP), and web management (HTTPS) were either not supported or not enabled by default. This effectively opens up the system to attacks such as “traffic sniffing and tampering, including sniffing credentials and sensitive information, including patient information in hospitals or video footage,” said the researchers.
To demonstrate what could be done due to the lack of encrypted protocols, the researchers abused RTSP (Real-Time Streaming Protocol) and RTP (Real-time Transport Protocol) traffic. “When the NVR [network video recorder] tries to establish a connection with a camera, it issues a sequence of RTSP commands: OPTIONS, DESCRIBE, SETUP, and PLAY,” explained the researchers. These messages can be interfered with by an attacker, which will cause the NVR to no longer be able to connect to the camera. The attacker can also do this by abusing RTP by dropping packets and forcing the NVR to end the current session. This allows the attacker to carry out one of the following effects:
- A frozen image from the original footage is seen on the NVR
- A green image is shown because both streams interfere with each other
- The streamed footage from the attacker machine is seen on the NVR
Explaining how streaming footage from an attacker’s machine is possible, the researchers said that “[w]hen the NVR tries to establish a new session, capture the SETUP request and change the client port to a different one. This results in making the camera stream to the port specified by the attacker instead of the one initially requested by the NVR. After sending the PLAY command, the NVR will wait for traffic on the port which it specified in the SETUP request, but the camera will stream to a different port.”
The researchers added that the model and brand of the camera equipment isn’t important and that as long as they rely on insecure streaming protocols the attacks will work. They also said that a Shodan search revealed more than 4.6 million vulnerable devices located mostly in China, the U.S., and Brazil.
Great tip and heads up, this is a serious security issue indeed. First I hope our camera can handle/support either of the SRTP, RTP over TLS or SFTP protocols because encryption can be a great toll to the processor if it doesn’t support it. Secondly I hope that Wyze developers would consider this on the roadmap for future upgrade.
Are there any plans to integrate RTSP into the main firmware eventually or atleast in the next iteration of the Wyze Cam?
I can practically guarantee this will not happen. Hardware limitations being the first reason and also the fact the Wyze Cams are “cloud cameras”. They are therefore inherently different than IP cameras/RTSP which rely on comparatively primitive and outdated streaming technologies. Although I understand that some people still rely heavily on RTSP, it makes longterm sense to rather focus on developing newer technologies and integrations based on them.
1 Like
My experience with RTSP.
I’m using an Amcrest NVR. The first firmware definitely had issues, and I couldn’t keep any of my cameras connected for longer than about 4 hours.
I submitted a ticket to support, and was instructed to try the newest firmware. So I went ahead and updated both of my cameras, and found that the latest version was even worse for my NVR. I can get a connection established, and it works great, but only stays connected for about 30 minutes now.
Just like others, if I disable/re-enable RTSP, or regenerate the URL, it works again.
Maybe I’m doing something wrong? Is anyone else using an Amcrest device and having success with Wyze RTSP?
Please… Wyze, any update with this?
If the V2 and Pan’s hardware are reaching their limits which is causing these problems with this firmware, if I may suggest, if you can make this a dedicated RTSP only firmware without others bells and whistles features that could be compromising the streaming process, please consider it. Because the way I see it, most people who wish and need this wanted the highest possible quality and continuous recording of video on their NVR/NAS or BlueIris, ZoneMinder or other CCTV server application. Of course motion and sound notification would be a bonus, but if we’re sure that we have a quality recording that we could retrieve from our NVR/NAS, I think it will be fine without person detection, motion tagging and even cloud recording.
I would say with V3 tho
The new firmware didn’t really do anything different for me, I’ve kind of given up on getting rtsp to work reliably. Too many ‘no signal’ in BI with no actual packet loss measured, >95% wifi signal on all 3 cameras. I have a 720p30 Wannsview cam that i got used for 10 bucks and it doesn’t seem to have these issues (and sadly has better picture quality since it is quadruple the bitrate of wyze), I’m assuming there’s still a software problem. I switched to a brand new nighthawk xr500 just to rule that out as well,
They have it, its just a seperate firmware.
I wasn’t able to use my AC Pro, it just causes far, far, far too many issues. I instead am using an old Archer C9 (a good wifi router on it’s own), and it works fine. That said, with 5 cams streaming over a 20Mhz 2.4Ghz network, it’s maxed out.
That said, the RTSP streams have tons of issues still, and so I’m thinking about just giving up on trying to reliably use them for RTSP. I’ve been using Shinobi (ffmpeg backend). After a while they just stop giving a reliable video signal.
I wish I could reliably reboot the cams and Shinobi every X hours… it’d probably make for a more reliable feed. Maybe they just get too warm and the CPU scales back or something. Who knows. It’s frustrating when you go look for video and all you have is nothing. 
I have 5 cameras streaming to Blue iris on a server, network traffic into that server is about 1 mB/s, in the day with color picture.
your 5 cameras are not “maxing out” your router.
the upload in the snap is remote desktop out to my other machine.
these streams are measured in kB not mB.
Right and wrong.
Right in that theoretically, it can push more. Realistically, with the amount of networks in my area, very unlikely. Let me just say, attempting to do anything on that network while those are streaming is a pretty sad experience.
Also, maybe I’m pulling a higher bitrate or something, because mine all streaming at once is using between 6.5-7Mbps…
The speeds Trusselo listed are equal to 7.3Mbps. Mbps (Megabits per second) and MBps (Megabytes per second) are not the same thing, they are a difference of a factor of 8. FWIW, my cameras pull between 60KBps and 250KBps each (480Kbps to 2Mbps).
Also, I can confirm that regardless of the low bandwidth usage, enterprise routers will accurately measure that when these cameras have an active video stream, they crowd the entire spectrum of a single WAP’s usable channel range. This is why you see poor performance when multiple cameras are in use.
If there was a way to give each camera to a separate WAP on a different 20mhz section of the full 2.4Ghz spectrum, I think that most of the issues would go away. However, that should not be needed as other brands of cameras do not produce these symptoms when sharing the same 20mhz. It’s possible that these cameras send out many small packets instead of larger ones, causing more dense use of the available airtime.
I could be incorrect in some of my assumptions here, but this is what i’m concluding after hours testing 5 different relatively expensive WAPs/Routers in WAP mode and recording how often a “No Signal” occurs along with each WAP’s individual logging statistics. During this time I did not receive a ‘No Signal’ from another brand 2.4Ghz 720p30 wireless cam on the same network, nor did a receive a ‘No Signal’ from any wired camera on the same network, each of which use significantly more bandwidth than Wyze.
1 Like
I’m having issues with the AC Pro, as well. But my entire network is Ubiquiti and I’m not willing to fiddle with the network just to fix the cameras.
Any idea of the Xiaomi RTSP hack plays well with the AC Pros?
would the cameras run any better with an SD card to use as a buffer?
would it be a worthwhile update to the firmware?