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.
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.
@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.
@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.