Outdoor cam loses connection after power outage - and it's my fault

[carverofchoice]

You have some excellent thoughts and you are clearly solution and prevention oriented which is an awesome skill.

@rbhateja

The summary seems to be that this could be a hardware problem, not necessarily firmware, so there’s nothing that can be done and it’s no one’s fault. May be I’m oversimplifying but that’s kind of a rough gist.

It’s hard to know for sure, but I wanted to present a possibility along those lines. you understood my alternate example. Having said that, you could still absolutely be correct that the firmware has a bug in it. I don’t want to say that isn’t also a possibility.

@rbhateja

There are always solutions. There could be a BIST (built-in self-test) routine that is run every time the device goes through boot up to diagnose hardware problems. Many systems do this.

I don’t know whether it does or doesn’t, but it seems plausible that it does not. Regardless, I do think that self-test routines are a lot more complicated and less guaranteed than most people realize. I addressed that a little bit in another thread here:

@carverofchoice

Hi professional QA tester here. The quoted request is based on a misunderstanding of the nature and complexities of programing. Anyone with any professional programming or QA testing experience will explain that what is being sought here is absolutely guaranteed 100% utterly impossible for ANY company in our current situation with electronics and using programming to ever promise anyone.

Let me give you a quite simple example. In the following control flow example, this “simple” program consists of up to only FOUR decisions. Just 4 decisions and a loop (even with just 4 decision trees, it could’ve been made almost doubly more complicated if we expanded the decisions on the far right and each subsequent decision…but we’re keeping it as simple as possible). For this SUPER SIMPLE piece of programming/code, if you were to EXHAUSTIVELY test every possible combination of execution with a limit of only 20 cycles, then if it took the tester 5 minutes to execute each test sequence, then complete testing on this small piece of code with as few as 14 lines of code and 4 total decisions to make, it would take the testers ONE BILLION YEARS to finally test everything to be sure it was “fixed period and without exception and in all manner.” One billion years on even the absolute simplest code because even for something so simple it seems almost worthless, there are actually roughly 100 quadrillion sequences of just this stupid easy program.

If a person says, “yeah, but you can run most of the tests automatically and fast for each test case instead of a human testing each case.” Fair enough point in some cases (not always true, but we’ll pretend it is in this case). Let’s assume that each test now only takes FIVE MICRO SECONDS instead of 5 minutes. That’s a more than fair adjustment. That means complete testing on this small piece of code with as few as 14 lines of code and 4 total decisions to make, it would take automatic testing NINETEEN YEARS to finally test everything to be sure it was “fixed period and without exception and in all manner.”

Basically, if anyone is looking for a promise from Wyze (or ANY company that uses programming of any sort) that something is 100% fixed without bugs, etc…it’s NEVER, NEVER going to happen. They would have to be completely insane to ever promise anyone that. Research has proven this fairly conclusively, and that is just for the most simple of code…let alone all the other huge complexities of millions of lines of code and decisions and loops actually being used. Everything Wyze has is infinitely more complex than this smallest of tiny programs.

A promise of no bugs will never be forthcoming. It’s nearly impossible. Best we can do is get indications that most things work okay most of the time with few known critical errors reported with any frequency. It also means if a person wants more stability they should stick to production versions of firmware and software and stay away from beta like the plague. Beta is for helping to test and find the most common and critical bugs and problems which almost for sure, guaranteed, exist in some form…some of them we will find immediately, some of them might take billions of years of testing to discover, but statistically it is pretty guaranteed there are bugs.

If such guarantees are needed, then I would suggest giving away or selling all Wyze devices now because this promise is not only not EVER coming, it is absolutely impossible. Wyze can not possibly eliminate every single bug within our lifetimes. It would be hard enough if their code was only a few lines long and a single product. With everything they have and the amount of code they are using…impossible, utterly and completely impossible. It’s not their fault, it’s math. It’s normal.

This is why I say that it is possible it IS still a firmware issue (it’s hard to know). Even if this didn’t happen to 99% of other people who got the firmware update, that doesn’t mean the bug isn’t there and it might affect some people like this. It is mathematically IMPOSSIBLE to ever exhaustively test every single piece of code even when it is just a few lines long and a few small decisions. So, it absolutely could be that. It may not even be possible for anyone to ever know for sure. That is why I said:

@carverofchoice

I don’t think anyone can answer WHY it happened, and I am not sure the WHY would change anything even if we could know what the WHY is.

The end result is, regardless of WHY, the next step is to try to set it up again. Your experience will be tracked and if a pattern emerges of other reporting the same thing, then a comparison can be made between the logs and the cause can be narrowed down and explored. It is hard to do much on a single use-case without other confirmations to help figure out what happened.

If I find any similar examples I’ll be sure to pass them on with yours so Wyze can figure out the cause, resolve it and prevent it in the future.