WARNING - Beware of "Wyze Test" Android app V2.6.371

That’s crazy. I wonder what’s causing it? I’m going try the same test. Out of curiosity, were you actively using the app during this time (Viewing videos, etc) or was that all background?

I just reset my cellular statistics on iOS, about 5 minutes ago to test it out. I’m connected to WiFi. I pulled up a live view, I looked at SD recordings, and looked at a few cloud event videos. With that activity, it used 301KB of cell data. It’s not terribly high usage, but since I’m on WiFi, it should probably be zero.

301KB isn’t enough for nearly any actual video data, so it doesn’t seem like THAT is going over cellular while connected to WiFi. (For me at least)


Thanks for comparing this, that is useful. In my test I called up a group live feed of 4 cameras, and every once in a while I quit the app and reloaded it so they could see any ‘initial’ links that occur. So over the period of an hour, it was mostly group live streaming, with about 5 app reloads.

I also wonder what is causing it. When you are on WiFi, the data should go there, and not over cellular.

If you used 300KB of cell data when connected to WiFi, that is an issue. In theory, there should be NO leakage to cell when you are connected to WiFi, as you said.

I agree, it’s an issue. I was just trying to determine how large of an issue.

I’m doing a little more testing now. I’ve already determined that the cellular leak is related to live view and/or SD card playback. It does NOT happen when viewing event videos. I’ll update in a few more minutes. I’m trying to determine if it’s a steady leak while Live View or playback is happening, or if it’s a momentary leak when the stream begins/ends. I’m streaming steadily for a few minutes in order to determine this, so give me a few minutes.

1 Like

Thanks! For me, I didn’t see much leakage before I turned cellular off for the Wyze app months ago, but I didn’t use my iPhone much for watching feeds when I was in WiFi. I used my iPad for that. Your new information about it not being related to event videos may help them track down the issue. :grin:

Okay, so I just tried two five-minute tests (Almost to the second) In my testing:

  • 5 minutes of live view streaming for one camera used 3.6MB of cellular data.
  • 5 minutes of SD card playback for one camera used 2.8MB of cellular data.
  • No amount of “event” playback causes any cellular data usage, nor does anything else I’ve found in the app.

That rate may vary a bit. I’m not sure if live view is always more than playback, for example. I’d have to test further to figure that out, but it’s not super important anyway.

Based on that rate, it doesn’t seem like video data itself is going over the cellular connection, because I would expect that usage to be higher. But it DOES seem to be a constant leak while in live view or playback. (If they’re sent as separate streams, that amount of data might be the audio feed, for example.)

It could also be audio UPLOAD. (Not necessarily either/or, but if so, that may be why live view uses a bit more data than playback. Although I’m not sure if that’s consistent or not) I didn’t manually start a two-way audio session, but I know that if you view video in the car, for example, the way it connects to Bluetooth implies that it’s listening to you as soon as the video starts streaming, even if you haven’t tried to start the two-way audio session.

I might be able to do a little more testing and figure this out… If the data usage stays about the same while I DO use two-way audio, for example, it would seem to imply that this is part of the culprit.

I could also test the difference with a multi-camera view, but since @Newshound’s usage was more than twice as much as mine would be at 1-hour scale, it would seem that more cameras streaming = more cellular leaking

Not the first time this concept has been brought up.

Yes, but the first time we have Wyze’s attention to the issue, so make the most of it. The base fact is, there is a leak over cellular when using WiFi. Why? There should be no leak, and the app works fine when you turn cellular data off for the app.

Yeah. I was aware of that, that’s why I thought to make the connection to two-way audio. (The Bluetooth behavior is a separate thing, but since it’s obviously engaging the microphone when you’re in live view and the amount of data seems about right for an audio stream, it makes sense that this might be where the cellular leak is occurring.)

I just tried a third 5-minute test – this time with the two-way audio button held down the entire time during a livestream. During this test, it used 4MB of cellular data. But compared to the other results – 3.6 and 2.8 – this difference might just be matter of stream quality/signal strength. I think I’ll try the two-way audio test one more time and see if the results are any different.

For 4 cams in live feed group mode, I was getting about a 8 MB/min leak over cellular when I was connected to WiFi.

1 Like

A little more than double my average. In group mode, it streams the video in SD instead of HD, so if it’s related to the video, it makes sense that it wouldn’t be quadruple. But since the video and audio streams use a variable bitrate, it’s hard to do a one-to-one comparison unless I know my (and your) average bitrate over the same time period, which I don’t. It’s probably a little more consistent if I’m comparing myself to myself since my OWN bitrate is more likely to be similar to my OWN bitrate from 5 minutes ago. But tough to be exact.

If it’s audio related and I make more noise during one 5 minute period, the data would probably be higher. Likewise if it’s video related and more cars pass during one 5 minute period. Not to mention differences in signal strength.

It is easy to be exact. When you are connected to WiFi, NOTHING should be going over cellular. :wink:

Ha. Well, that’s true. :slight_smile: It’s tough for the testing to be exact

Yeah, I think hat will always vary on what you are viewing, and what routines are broke.

I did a couple more 5-minute tests and ended up with 3.9MB and 3.6MB, respectively with and without two-way audio. I’ve gotten a slightly higher number both times, when two-way audio is initiated, but it’s within the margin of error every time, so it’s not really conclusive. If it IS listening the whole time, and this is the source of the cellular leak, I wouldn’t really expect to see it higher when two-way audio is initiated. But I’m not sure whether I’m ACTUALLY seeing higher usage or not. It may just be normal variances.

I think I’m gonna quit for now, but this should give the Wyze team a good starting point for what to look into tomorrow, @WyzeGwendolyn. In summary:

  • It’s definitely related to live streaming and SD card playback
  • It doesn’t seem like enough data to suggest that the entire video is being sent over cellular data, but…
  • It seems like it could be the camera’s audio feed, and/or…
  • It could be the phone’s microphone feed for two-way audio (Which may or may not be happening whether two-way audio is engaged or not)
1 Like

Again, ANY cellular leakage is wrong when you are on WiFi. Audio is usually insignificant compared to video, and in my tests the leak was larger, but audio was muted.

Yep, I agree. My audio was also muted. I didn’t test that difference (audio muted vs not muted) but I feel like the audio data would probably get sent regardless. The fact that it’s available immediately when you unmute it seems to suggest that. (Otherwise, I’d expect a buffer period before the audio starts, like the video does when it first starts)

Thanks people for all the continued testing.
To stay within my data limits I’ll probably use my easy way out for now.
I’ll use my Amazon Fire and turn my phone off :slight_smile:

I think there is a glitch in iOS 13. I reset the statistics last night but look at my screenshot. Does not look right.

By the way I am on iOS 13.2.2 production.

The Current Period is showing 0 minutes?

That’s under “Call Time”. So saying you haven’t made any calls since you reset the statistics.

Ah, makes sense. I guess they label them for a reason! :mask: