Beta App and Firmware: 11/12/19

Wyze Test v2.6.371 still seems to be sucking data a bit on WiFi 3.6GB since this morning. Very light usage on my part.
@WyzeArthur @WyzeGwendolyn is this the wave of the future? Before almost ALL data was local.
I would like some confirmation that 2.6.40 is not going to use a lot of data before I upgrade or I’ll have to flash to an older . apk. :frowning:

2 Likes

Are you guys using Complete Motion Capture? If so, it’s obviously going to use more data if it gives you longer clips more often. It seems like the minimum clip length with CMC is 17-18 seconds. Even if you’re viewing the same number of clips with the same frequency, it’s still probably downloading the whole video. So I’d expect data usage to spike by at least 50%. If your average clip lengths are 24 seconds, I’d expect it to be about double.

Nope.

On 1 camera, but I’ve been using it since it’s introduction, and that SHOULD have gone through WiFi, not mobile data.

1 Like

@gemniii, we’re looking into the data issue. That is specific to the specific app version you were testing.

1 Like

Thanks,
@Newshound and others are playing with it on iOs and finding similar data usage in

I’m going to get this info to the team immediately. Thanks!

2 Likes

Looks like Kyle is already on it. He said we were looking into the data issue and I hadn’t realized it extended beyond your test app. Thanks, gemniii!

1 Like

Yes, I’m embarrassed to say I noticed the issue months ago from reports here in the forum, but didn’t formally report it. When I saw the reports I looked at my leak, and it was minimal, so I just turned off cellular access for the Wyze app and assumed someone from Wyze would notice the other posts. The app still works wonderfully when cellular data is turned off if you have WiFi available. Turns out my leak was minimal because I use my WiFi-only iPad to monitor my cams, not my iPhone.

In my test tonight I found the leakage can be QUITE robust. In an hour I leaked 100 MB to cellular data when I was on WiFi, which is 2.4 GB a DAY! Yikes.

I have since formally submitted a ticket for Kyle, #379089. My test tonight was on the current production app 2.5.53.

Well, we’re just happy to have this information now. Thanks, Newshound!

1 Like

Perhaps someone is using your data authorized or not e.g. hacking via wifi etc. Not hard to do as i’ve done it myself when I couldn’t afford internet. Just sayin. Hope i’m wrong.

The celluar data leak he’s talking about has been reproduced by others. It’s a real thing. They’re looking into it.

1 Like

Stuff happens, but was the file uploaded without QA? Also, and just as important, do you not have a Release Manager? From many years of experience in software releases, you must - must - have a release manager. If you employ this process, a wrong file upload should NEVER happen! A developer MUST hand off to a third party (QA/Release Manager) and NEVER, NEVER, NEVER upload his/her own code. This is basic SDLC!!! Frankly, your statement of feeling ‘silly’ is very churlish. This is not a silly mistake, it is a fundamental disabuse of basic software development procedure, not to be so lightly passed off as being ‘silly’. If you don’t get this, then you are taking a very good product into a realm of future hurt - for the consumer!

It’s someone’s debugging log being sent to his phone, and not removed prior to the final build :grin:

What now? Are you talking about the source of the cellular leak? Did they pinpoint it? I didn’t see that.

Nah, just kidding, but that’s a possible cause of the data leak. Considering the wrong file was uploaded to a production machine, I wouldn’t be surprised.

¯\_(ツ)_/¯ Sh–… tuff happens. The company just turned 2 years old. They’re still working out the kinks and establishing processes, I’m sure. “Move fast and break things” was Facebook’s official developer mantra for more than a decade. That’s how things work in this world. Innovation requires experimentation. It takes a while to stabilize infrastructure and establish perfect processes, especially when the company is small and they don’t have the resources to test 1000 different real-world scenarios.

1 Like

Hey, I know. I used to work at a startup like Wyze, worked 65+ hours a week.

1 Like

Never in the software world has “Move fast and break things” been a mantra when you are producing a deliverable - NEVER. I don’t want to rip into Wyze, because I think they make a great product, but there is no excuse for lack of Software Development Lifecycle Process (SDLC) - Never! Using the example of Facebook is a falsehood - people are buying the Wyze product to protect themselves, not having a little chat on a social media platform. I am wholly on the side of Wyze, and just wish to point out that this shortcoming is not acceptable to be seen as a ‘mistake’.

It should be noted that the damage was fairly limited. It was only pushed to the beta testers, who had to manually update it, and the update was pulled almost immediately.

But I don’t think they “accept” it. They specifically said that they’ve changed their process based on this incident. Frankly, they’d be idiotic NOT to. The incident cost them real dollars, since it was necessary to replace bricked devices. So I’m sure no one is singing the “unacceptable” tune more than the company itself.

1 Like