So an ISP router. Cool.
Interesting take.
I have a tough time getting the āview from spaceā, both of the company total, and how that resides in the global whole.
If they donāt have a āview from spaceā they should get one. But I kinda expect they do.
But the jump zooms from macro to micro and back are likely a challenge, too. 
Amen Bruddah!!! 
Love the James Cagney video!
$200 for a single consumer router is insane in my opinion (even from Costco). Decent home routers fell to the $20-$50 level years ago and there is no good reason they need to cost more than that. Iāve seen some 3 node mesh systems at the $80 level (donāt know if theyāre any good).
The only question is finding the diamond in the rough like Wyze did with the first Xiaomi cameras.
At that $20-$50 level, you arenāt likely to see many (if any) updates, and you certainly canāt count on bug-free and exploit-free coding of the firmware.
Iāve also seen the insides of some of those bargain models, and they arenāt designed to last. They typically cheap out on the heatsink implementation and cook themselves over time, especially with high utilization.
If you were provided $10K and 30 days, do you think you could find it? 
(110M * .009% = ~10K ā¦ cheap!)
Buying them singly, the price hovered around $100 last year.
@spamoni sees TP-Link in his rear view mirror - a good place for it, maybe?
How much would doing heatsink right add to the cost of a bargain rig?
Literally talking about a slug of random metal with some fins moldedā¦
So, less than 110M?
Ā
/edit
Ā
If heatsink cost is negligibleā¦
Are these poorly cooled bargain routers a prime example of designed-in limited life?
If one designed-out the life/performance limiting features of an otherwise well-operating bargain routerā¦
ā¦would one then be gazing at that diamond in the rough?
Ā
To provide a piece of equipment that is similar to the already flooded router market, no, I probably would not buy it.
Now, if you go a step further, and add functionality to save videos and events locally and backed up to the cloud, that would get my interest. Currently, if I lose internet and I do not have sd cards in my cameras, I lose all recording capability. I also can not view recordings that are on the sd card without the cloud, unless I remove the card and read it on my computer.
Minimal specs would:
Cameras would have the option connect to the Router locally to upload video streams.
Videos would be saved locally to a USB SSD or Hard Disk instead of an sdcard.
The router would upload video streams to cloud. Or Better, cloud can ask router for stream to display instead of storing in the cloud.
Router would be dedicated to the Wyze Cams on their private network, and be able to co-exist on the same network by connecting via a WAN port to my network.
Router would have local web page to view locally stored and live streams.
This has the capability to provide the local secure storage most want, as well as reducing costs of the AWS storage in the cloud.
Hi @mccabet
Is your multiple cam streaming now fluid and reliable? What level of WiFi router are you using (per the OP)?
Do you think itās possible to design or source a low cost router that would stabilize connectivity and performance across the Wyze cam customer base?
How much would you be willing to pay for the device you propose?
All questions throughout the thread open to all.
-peep
Except you are not describing a router, but rather a smart Wyze hub. This almost reached production a few years ago.
Yet a bargain router I picked up because it was DD-WRT compatible turned out to have heatsinks that were literally just flat pieces of metal fastened over the chips. I wouldnāt be surprised if they didnāt even have heatsink compound underneath.
What I would like to see is a big heatsink (which my Linksys WRT-1200AC has) with a big low RPM fan (which it does not; I added a USB fan but had to be satisfied with 80mm).
MTBF vs MTTF
Mean Time Between Failures (MTBF) and Mean Time To Failure (MTTF) are also very similar metrics, and are often confused and used interchangeably.
The key difference between MTBF and MTTF is that MTBF applies to repairable systems, while MTTF is for non-repairable equipment.
Machines (or software) that can be repaired will have multiple failures over their lifetime, and so will have periods of time between failures, whereas non-repairable items, such as light bulbs, or SSDs, will function correctly for a period of time before failing permanently, and so only have one failure in their lifetime.
My network currently consists of a Ubiquity router as my network gateway to my 1GB Fiber ISP. I use two ASUS AC1900 as access points to cover the upstairs and downstairs. The 2.4 Ghz wifi is primarily used by my IOT devices ( Wyze Cams, outlets and bulbs, TP-Link Switches and outlets, etc). Camera streaming is not bad considering it goes to the cloud before I can view it. It has its good and bad days.
As one has described my proposal as a hub, it is no different than Smartthings, Hubitat, etc. Hubitat is local accessed with optional subscription cloud access.
To design a low cost router that can support a large number of connected devices is the challenge. Most routers on the market are focused on high bandwidth with out a thought to the growing number of devices that connect via wifi. Bandwidth is not the problem for IOT (Wyze Devices included), Bandwidth is an issue for surfing the internet by multiple users.
Cost wise, I would be comfortable paying up to $150 for a dedicated hub/router for Wyze only devices as described.
Which level (with the OP descriptions as a guide) would you say the Ubiquity with APs belongs to, and appx price?
Do you mean itās negotiated and authenticated through remote servers before the P2P kicks in? Or?
The TP-Link M9 Plus Iām using claims it can rock 100 devices, I only have 20-25 active at any time. Its Quality of Service (QOS) presets donāt include one for IP Cams (and the management app has no icons for Cams, either) which may suggest the focus of its design.
Iāve experimented with them all and settled on the Gaming setting. This may align with what you say about IoT devices and bandwidth: snappy response trumps bandwidth, I thought.
Frankly, there is no performance difference between QOS Gaming and Standard (no QOS) that I can tell. So sometimes I toggle it off. 
Good catch. @mccabet , it does not do that.
I wasnāt satisfied with the end of my last response (muddled) so this:
Ā
Local Router mediates these:
Streaming Live video
A. from cam to local client *
B. from cam to remote client *
Exchanging Event video
A. from cam to cloud
B. from cloud to local client
Ā
If Cam Plus may be substantial
Transmitting Playback video
A. from SD card to local client *
B. from SD card to remote client *
Ā
Including command data. Ā * P2P
No Local Router involvement:
Writing Playback video
A. intra cam to SD card
Ā
Imposes some cam CPU load
Ā - event only (intermittent)
Ā - continuous (continuous)
Receiving Event video
A. from cloud to remote client
Ā
Cell Phone, External WiFi Client
Ā
Corrections/additions welcome.
Ā
Ā
/add 1
Ā
Ā
/add 2
Ā
@peepeep Would a Wyze Modem come with Wyze customer support? Scary thought for most, I would think.
Hey Tod, they gotta spend (whatever they net out of) this somewhere, right?
And olā Dave said CS was job 1.
Iām guessing Wyze support people literally dream about all customers having the same router and ISP. I mean, I would, but maybe Iām ill-informed or projectingā¦ 
Re Wyze Cam Webview (in beta)
@peepeep: So streaming a Wyze cam from a web page is P2P, not mediated through AWS, correct? So ācost-freeā to Wyze, other than the load to its servers for P2P negotiation/authentication?
@carverofchoice: Apparently not. When streaming to the app it connects directly as described (not through AWS) and so it is mostly cost free for Wyze (besides the small authentication cost) when we stream cams, but Wyze is telling us here that this is NOT the case for the browser serviceā¦ they are using some kind of new AWS technology which has a limit of how many streams can be active at once and DOES cost them by usage. So this is different than how it works through the app. I am very curious why they didnāt build it to connect P2P directly like the app.
Re: Cam Sharing feature (which affects streaming experience and router load)
@peepeep: If I share a cam with twenty people*, and all twenty people and I access the camera to stream simultaneously, the camera will attempt to serve twenty-one requests simultaneously via P2P? Is that correct?
@carverofchoice: Overall, in theory, yesā¦ But in practical application it can only handle a few simultaneous requests. Someone tested the limit once, I think it varied between like 2-5 connections and then it would choke and end all the streams as I recall. The cams have a finite amount of RAM, processor, bandwidth capacity, etc. So technically if all 21 of you tried at the same time it would not actually try to serve you all, it would reject most, if not all of youā¦ Basically suffering a DDoS attack to take it offline.
* There is no limit to the number of users you can Share a cam with.
Sharing is set per cam.
Is this the communication mechanism of the new Wyze Cam Webview?
If so, is it the same (or similar) secure transport currently used when uploading Cam Plus Events to AWSā¦ but continuous?
This should allow multiple users with whom a cam is Shared to better stream Live View simultaneously.
Since the cam would be serving a single stream to AWS, and AWS serving that stream to users.
Freeing the under-powered cam to devote more resources to core functions.
Ā 
