Ah, ok, a qualified “fine”, then.
So an ISP router. Cool.
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.
@spamoni4 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?
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.
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.
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
@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.