Wyze, a company founded only in 2017, is poised to disrupt the consumer IP camera market by combining American marketing and Chinese manufacturing to deliver far lower prices for IP cameras (starting at $19.99).
The company recently announced selling 1 million cameras in their first year of sales, which is unprecedented. Their well-produced marketing video overviews that:
IPVM investigated numerous sources and import records to better understand what Wyze is doing and how they have a real shot at disrupting the consumer IP camera market. Inside this note, we:
Explain what competitive gap Wyze is exploiting
Estimate revenue and growth rate for Wyze
Examine import records and sources / suppliers for Wyze
Explain how 2020 revenue of $100 million is feasible for the company
Consider profitability / profit margins
Review product and support key points
Examine success with Amazon
Look at competitive threats from Dahua, Hikvision, more
I have one of these that I tested for my mother to use as a way to keep an eye on my grandmother when her health was failing. I have to say, that while this is not a security camera in its reliability, build, usability, motion detection accuracy, etc. It is damn impressive what it can do for $20 and Im dumbfounded how they can host it on the cloud for this nominal amount with no recurring charges...
Wyze currently utilizes a service called ThroughTek to send the video clips to AWS for storage. According to the Reddit post, this saved them a lot of money on development.
For viewing, the product does establish a P2P connection according to the Mixergy interview:
Yun: ...And then, the live stream is P2P, so it’s not go through any cloud relay.
Additionally, calculating costs with AWS shows that costs come out to about $0.02-$0.03 cents per unit per month for the raw storage necessary for 12 second motion trigger clips stored for 14 days. This certainly does still accumulate over time. They would lose $0.24-$0.36 out of their margin at the end of the first year. At worst, this could be
This is where the metrics are problematic. Even if they've managed to get the cost to fractional cents, this certainly does eat into profits that the company would have made if they cameras stay up for longer than their warrantied time.
The equation all boils down to their gross per unit margin and the average per unit usage of storage on AWS they've noticed online. With those numbers the ongoing viability is determined.
This just goes to show you what american software and user interface can do to a cheap chinese camera. They are selling at a price point in which you cant go wrong.
I question their profitibility though. To support that many people (more than likely initial high level employees), design your own software, and marketing costs (despite them saying they didnt have the money to spend on marketing), I cant imagine them making any money at all with such razor thin margins. Who knows.
You would have to have money saved up for a very long time, and/or have investors backing your company to have a real shot at this.
There was indeed a VC firm to back them called iSeed Ventures. This is not uncommon and with the pedigree of the founders having come from Amazon, the seed money they would be able to start off with would not be small. They haven't publicly announced additional funding rounds since and they have only increased the volume of their orders from China over time according to the numbers on Panjiva. That alone is a very healthy sign.
Yun: It’s a drone distributor. So the first thought out of Amazon is we saw emerging category which is consumer drones. So we started as a very early distributor of a brand called DJI. That’s a copter shop. So after that, we started Autel Robotics which we are . . . we started to make our own drone brand.
Yun Zhang is also running Autel Robotics, which is being used as a sister location for shipping for Wyze Labs. This is shown in one of their Panjiva profiles. What this brings to light is that Yun Zhang does have some experience running distribution as is and currently leveraging resources from Autel Robotics to further the growth of Wyze.
Overall, the efficiency of this business model is what allows it to grow as quickly as it has. Combine that with the low cost of manufacturing this product is evidenced by its relatives on Alibaba and the question of their profitability becomes less of a mystery and more about whether they've been able to avoid mistakes and setbacks.
Physically, it's either the same or a very similar product. Both the Wyze cameras and Xiaomi can accept firmware from https://openip.cam/
It shows that they are using a very similar chipset at least. Yun Zhang is also quoted as saying the following from the Mixergy Interview:
Yun: The physical part is the same. The company that’s working the camera with us also working with Xiaomi . . . well, the Xiaomi version camera. But the app is a new app, we created it for U.S. consumers, and the firmware is too.
I had bought one of these about a year ago just to play around and it is impressive what you get for $20 I had to replace the valve on the water line for my fridge and before I turned the main water feed back on I set up the Wyze camera to view the replaced valve. I was able to view it on my phone while I turned the water on to make sure there were no leaks.
This is the same approach Dropcam took at first, writing firmware that runs on somebody else's hardware. It is a good way to minimize startup costs, and defray building your own stuff until you get a better feel for your market.
I expect at some point Wyze is going to have to come up with their own hardware, at least to the extent that it somewhat unique to them and less of a direct OEM kind of deal. They will probably want to do this soonish, so that as they scale up the company, and back-end services, there is less worry about older product being incompatible with newer offerings, or just cumbersome to implement on.
They will also likely roll out a subscription model of some sort, this is becoming the standard GTM strategy for consumer IoT companies. I would guess it would be less around just paying for storage, and more about advanced features and integrations with other home IoT devices.
With a good cloud backend and a subscription base, they could easily expand to other super low cost home IoT devices. A $20 smart thermostat would be very achievable for example. As would a $20 smart doorbell. At that point they wouldn't need to even be technically profitable on the hardware if they had good data on subscription revenue and TLV for the average subscriber.
Without some kind of subscription revenue plan this would not be an attractive business from a venture standpoint, and they would likely not have raised the money they have (even with their pedigrees).
Their business model may be completely different than what we know of today.
Selling at $20 with 14 day cloud event recording is not going to be a sustainable model.
Even with ThroughTek out of Taiwan, unless they have some special deal with them.
Maybe the model is collecting data in some way to create a new revenue stream. This is one of the reason I question Wyzecam. When it becomes so cheap, we need to consider the possibility that your data might not be protected.
I assume you've looked at throughtek.com and kalay.io ...
Yes, they basically provide an SDK that app implementors can use to set up P2P connections to software running on their devices. They also run cloud infrastructure that allows the two ends to find each other, and, for cases where a P2P connection can't actually be made, they provide servers that relay traffic between the two parties. Many of those servers are located in China.
Loads of cheap Chinese manufacturers use Throughtek. I don't have any knowledge of this, but I think it's very likely that the manufacturer of the hardware that Wyze uses provided an SDK that already used Throughtek. Wyze added their own login authentication on top of the P2P connection so that Throughtek doesn't have the ability to access Wyzecam users' cameras.
There's a bit more discussion at this reddit thread, including a short response from a Wyzecam employee, and more info on Throughtek from the developer of tinycam, who reverse engineered the authentication scheme in order to add support for Wyzecam to the app he sells.
The reddit forum also has multiple rounds of people complaining that their wyzecams were talking to servers in China. I believe this likely occurs when a relay needs to be used because P2P failed. Wyzecam has said they're working to eliminate the use of China-based servers, but, from discussion on other threads, it sounds like this avoidance of Chinese servers was at least initially implemented as a list of IPs to avoid -- so it tended to break when Throughtek added new servers. I'm not sure if they eventually moved to a better system.
I should note that I used the words "Chinese server" because that's how the people on threads like this one and others described the issue in complaining about it. The thread has some examples of both Taiwanese and Chinese servers on it.
Throughtek is paid by the camera manufacturers, who are mainly Chinese. I imagine that Throughtek needs to have servers in China because there are many Chinese users of the cameras for which they provide P2P service -- and, because of the great firewall, some or all of their servers outside China don't work from inside China. I expect they also have many servers outside China. I'd guess that their client software will try several servers (perhaps without caring about the location) and pick an accessible one with a low latency from the point of view of the endpoint initiating the connection.
There are no US-based companies that I know of that provide the same service that Throughtek does, i.e. a generic P2P-based mechanism to connect a client app to a port on a serving device. I work at a startup that had considered whether we should try to offer a service like theirs, but it's unclear whom the customers would be in the US. One could target all manufacturers of IoT devices, including camera manufacturers, but the trend among them at the moment is do everything in the cloud.
One step up from generic network connections are services that target a specific type of data (e.g. voice or video), so WebRTC providers can be thought of as P2P providers for a specific type of service. There are are a number of US-based WebRTC providers for voice and conferencing applications, e.g. Twilio. I'm not aware of any manufacturers using them to connect to cameras though.
For an unspecified user (i.e. probably a nontechnical one) accessing an unspecified device (i.e. probably not a well-maintained firewall or router designed to be exposed directly to the internet), I would say P2P is far more secure than port forwarding, as long as the P2P infrastructure is run by someone who protects it properly. What you lose by using P2P is that you risk not being able to access your device at all if the P2P infrastructure is down or blocked at your location.
This is very interesting. We also looked at Throughtek when we were trying to figure out best way to connect cameras to a cloud. There are a lot of concerns here - stability for 24/7 continuous viewing and streaming, reliability over different network conditions (nat, firewall, isp, different countries and regions), scalability - how many viewers can simultaneously access camera or servers without degradation, etc...
Tight integration between Throughtek and camera (manufacturer) is a huge benefit imo.
Yes, p2p is more secure conceptually. There are different issues thought - danger that someone can discover and compromise a lot of cameras in a single swoop.
We (3dEYE) provide for few major camera manufacturers option to connect cameras to 3dEYE or AWS cloud. Where camera will initiate connection and connect to cloud directly in P&P fashion to avoid potential network and ISP issues with NAT and firewalls. Camera can be managed either through API, ONVIF or through camera UI (over tunneled http/https). Streaming is done over webRTC, rtmp, dash and hls streaming. After we have done integration for ourselves we noticed interest from our clients to have such P&P service a a separate product for them to use in their own cloud infrastructure.
In your comment Arup about US WebRTC providers, are you suggesting to use WebRTC as a transport to access camera or something else? In such case if you solve camera registration and discovery i guess you would create Throughtek alternative. The missing link would be to make camera talk WebRTC.
Compromise of the P2P infrastructure doesn't have to mean that someone compromises a lot of cameras in a single swoop. If the camera and the user authenticate each other after the P2P connection is set up, they're protected from a compromise of the P2P infrastructure, and they're also protected in case the P2P provider itself wanted to view the video on your cameras.
From what I have read, Wyzecam added this sort of authentication, so that they don't have to trust Throughtek. I have a feeling that many other manufacturers that use Throughtek may not have worried about this issue as much, and thus that it's probably easy to view cameras that have a default username and password via Throughtek if you know the camera's id.
Re: WebRTC ... I wasn't talking about any specific application, but rather just responding to Sean's question as to whether there are any US-based P2P providers. You're right that a discovery and signalling mechanism needs to be added on top of basic WebRTC to get you a Throughtek-like system based on WebRTC. I have not checked, but I would expect that WebRTC providers would provide at least an example of such an implementation to save their clients a lot of duplicated work.
I was referring to a situation where p2p client in a camera most likely run as a root. So remote code execution would be a one vector of attack regardless of user password for a camera. But yes, without argue, P2P is more secure then port forwarding.
Yes, there are quite a few providers and webRTC servers with RTSP ingest capabilities and code examples. Most known OS project would be Kurento. For full solution one would also need (except signaling) a way to discover, communicate, manage, get stream and push data back into camera (audio, ptz, etc..).