doorbell v1 - do not update fw

[vincom]

wyze video doorbell v1 had fw ending in 333 and would no longer work in wyze bridge, tried old and new bridge versions but all failed, had an unused never installed doorbell with original fw 4.25.0.267 on it and works fine with wyze bridge.
once added to the wyze app it asked to update fw, with option to never ask again, did not update and checked box to never ask again.
i do not remember updating fw on first doorbell.
afaik we can not revert fw manually, hitting the reset button on back of doorbell did not reset to original fw

edit: error received pertaining to my first doorbell on 333 fw was "IOTC_ER_TIMEOUT" from docker bridge for windows running on windows 10 ,not a vm machine .
i forgot to mention i remotely connect to my moms doorbell without issues, it is on 4.25.1.316 fw , all good on that one.
i connect via blueiris on pc and ip cam viewer v7.3.3 on android to a few v3 cams and the v1 doorbells

[cheme75]

wyze video doorbell v1 had fw ending in 333 and would no longer work in wyze bridge, tried old and new bridge versions but all failed, had an unused never installed doorbell with original fw 4.25.0.267 on it and works fine with wyze bridge.

once added to the wyze app it asked to update fw, with option to never ask again, did not update and checked box to never ask again.

i do not remember updating fw on first doorbell.

afaik we can not revert fw manually, hitting the reset button on back of doorbell did not reset to original fw

If I have vm issues on windows pc, I'll swap out my db and try it - I have 2 new v1 orig unopened I was too lazy to sell and not worth much anymore. I got the .333 fw a little while back and it was fine until yesterday. But could be they added code to block access a while back planning for this.

Db has micro usb port on back that can power it and seems to connect to a pc but I never could access anything.

[vincom]

the first doorbell was working fine on the bridge then out of blue it would not connect anymore to the bridge, maybe wyze changed something on their end, worked fine on the wyze app.
i powered on the second doorbell via usb to test and it worked out of the box with the bridge, i use blueiris and hardly ever use the wyze app to monitor anything, after a couple of days using the wyze app i missed using blueiris to monitor my front door, lucky i found the other doorbell i had gotten a couple of years ago, but i would of bought another as they are cheap enough, assuming it had old fw on it

[vincom]

edit: received error from docker bridge pertaining to my first doorbell "IOTC_ER_TIMEOUT"
i forgot to mention i remotely connect to my moms doorbell without issues, it is on 4.25.1.316 fw , all good on that one

[cheme75]

edit: received error from docker bridge pertaining to my first doorbell "IOTC_ER_TIMEOUT"

i forgot to mention i remotely connect to my moms doorbell without issues, it is on 4.25.1.316 fw , all good on that one

Just coinsidently, my homebridge and scrypted hd crapped out and couldn't even get spirited to fix it, 15 yrs on a laptop drive is decent. Just bad timing. So stuck in another old drive I hope will last a bit longer. Will get homebridge going first since I got more stuff on it.

Anyway, from trying to process all the info, the normal docker config is bridge mode on Windows which is what seems most difficult to fix since host mode wont work on Win. But seems like some devices on older fw are still slipping thru. Also remote connections I think use p2p or relay, not lan mode. But I tried "any" mode and it didn't work. I'm guessing wyze stuck code in recent fw planning this block as they push their own web viewing subscription. Plus it seems any fw may be blocked if in bridge mode regardless. So that's an issue for the developer to fix if possible or change the info to eliminate windows or others that can't run host without a PhD in coding.