I discovered that one of my cameras has been offline for an unknown length of time (likely around 7 days so definitely more than one day).
I never got a notification from Wyze for this offline camera. Never got a push notification on the app. Never got an email. These are actions that I would expect from this kind of service.
Have you seen any documentation or feature listed anywhere that gave you that expectation?
You never get any notification if a camera goes offline. At least that’s how Wyze is.
It’s rooted in the way TCP/IP (internet’s comm protocol) works. Basically, there’s no way to be absolutely sure that one end of the connection is no longer connected.
What they do in this case is to “guess”, depending on inactivity time, when one end is offline, which can be wrong sometimes depending on network conditions.
The key thing here is my language means that I WOULD expect this action from this kind of service. I.e. without knowing the nitty gritty details,
There are various internet-of-things cloud connected services similar to Wyze that have a feature which is basically logic:
“If device connection has been offline or non existent for length of time, flag an alert”
My friends who use different security services like Ring or Arlo will get a notification when there is an outage like this. (A power loss or otherwise).
I also have a solar system which has a connected telemetry device telling me how many pounds of sunlight I’ve saved etc… etc…. And this gateway device will alert me when it has gone offline for longer than a day.
No I haven’t read all the documentation sorry. Been busy trying to request a feature and deal with Wyze chats and contact us page.
I refuse to believe that this can’t be done. Yes I understand what you mean with regards to TCP IP.
I still firmly believe that you could burry some logic in the backend of Wyze that counts up the persistence of a device going offline and generate a notification to the account after a certain delay.
I say this because other devices with other companies do this.
I’m asking Wyze to update and add features.
What’s the point of me having a camera if an unexpected breaker trip or squirrel causes a camera to lose power and I don’t know about it?
Yes, it can be done. I did this with several projects, but like I said, the time to wait until you declare the other end is dead, is quite arbitrary. It’s Wyze’ call.
There are also plenty of IOT companies that don’t have it including big brand cameras like Blink (I don’t recall seeing it with Ring either but I’ll take your word). It definitely isn’t a feature I’d “expect”, but if it is important to you, is the sort of thing you should verify before purchasing if it isn’t specifically stated as a feature.
You can set this up yourself with an on premise or even remote monitoring service. Using a remote one would be a bit more complex but is doable, and both can be done for free. The on-prem would require a PC that is always online though.
Are you referring to UDP?
These cameras are sending TCP heartbeats at regular intervals, Wyze servers know when they’re offline very quickly and reliably.
Definitely not. You can’t use UDP for what Wyze is doing.
If they are doing this, it’s a simple matter to implement what the OP wants. They are not doing this just based on inaction on Wyze part.
More edit -
Sending heartbeats isn’t the way to solve this issue. It’s a very expensive solution in terms of resources like any polling solution. The standard way, is to implement a watchdog timer. That is; every time you expect a response, you initiate a concurrent process that starts a count down timer. When that timer lapses, and you haven’t received a response, you then declare the other end is dead.
I hope Wyze is reading this, and hopefully they implement this.
Sure sure. Advice for the informed consumer is great and I respect that you are entitled to your opinions but kindly don’t tell people what they should do without understanding more context. Context here being that it would be very hard to find this specific feature listed among all the other things they use to sell and market these cameras.
My question to you is: if Wyze had a feature which notified you if a camera broke or was offline, would you find value in that? Would you appreciate that?
Again I argue that this is a critical feature that should be included. A cam user needs to know when their cameras are not working. Otherwise what’s the point of having them? I pay Wyze and I rely on them to store video in the event I have property theft here where I live. I want to know when my cameras are offline so I can fix them.
When I logged into my app, I discovered that the camera was offline. Wyze knows that the camera is offline.
This can be observed through the freshness of the data and the updated or it could be observed through watchdogs like P alludes to. Point is that Wyze already knows the camera is Offline.
The symptom and the sign is the camera is offline.
The problem could be anything. Doesn’t matter. The issue still presents itself as “offline” to Wyze.
When this problem exists it should trigger a notification so that the owner/user will try to address the issue because they are informed.
As an analogy think about cars and all the alerts you can have in a car to inform the driver that there is an issue that needs to be addressed.
What is the point of having TPMS if it didn’t tell the driver that one of the sensors was bad or the tire pressure was low.
The Wyze app knows it’s offline because the router told it so. The router probably has its own watchdog timer.
The Wyze backend? I’m not so sure. Sure it can try to determine (and might even know), but even if knows (based on the watchdog timer), it’s not doing anything about it.
Good discussion. Different points of view. Some I agree with, some I don’t.
I do agree with:
To me this says the heavy lifting has already been done. Wyze knows within about 3 minutes if the camera is “Offline”.
I’m never one to minimize development time/cost but this one looks minimal. Offline gets an event logged and a notification. Maybe a bit of UI work.
I would appreciate such a notification.
It takes a few seconds once a day to check and see if you cameras are online or off line. 
The video stream uses UDP. It is separate from the control messages.
I don’t know what you’re talking about, in order for the cams to stay online and not hit TCP timeouts, heartbeats are sent regularly, just like any other device that needs to traverse NAT. They’re tiny and cost hardly anything compared to video. It keeps the session active. It is already in place, they know when your cams are online and offline, they just don’t have any sort of alerting for it. Watch your active sessions in your router, each cam constantly has a couple sessions to AWS and some cams have additional ones to other hosting providers. Fire up a live stream and you’ll see new separate UDP connections on your LAN.
That’s for operating systems and other things that aren’t constantly communicating. When you have a constant connection, you simply wait for x number of missed heartbeats and declare it down. In some cases you can initiate a connection in the reverse direction but not with typical home internet users due to the overload/hide NAT. It isn’t that different from a watchdog type setup except in this case the OS can’t probe things, and it can be much more reactive as it knows exactly when to expect those heartbeats (some OS watchdogs use heartbeats for the same purpose).
So instead you assume it exists?
Absolutely, it would also be nice to get a notification if an SD card failed. However I do not come here and demand it or say it is broken just because I think it would be a nice feature to have and made some assumptions.
And obviously, I disagree. You’re expecting a bit much from a camera that costs between $20 and $40 and runs off wifi. If your situation is that critical you need a hardwired, closed loop system going to an NVR. Those systems have much more robust monitoring and alerting for all kinds of possible issues in the system.
I do not disagree that it would be a nice feature to have, but I’m also not holding my breath. Unless they see it driving new subscriptions or new camera sales, they do not seem to be paying attention to any other feature requests.
To be clear, I absolutely think it would be a useful feature (along with one for SD card issues or other problems) and it shouldn’t be that hard to put in place. However, seeing how various other trivial asks have been ignored (for example the thread last year where Wyze asked users to vote on what new automations should be added, only to never add any), I wouldn’t get my hopes up. And I disagree that it is Wyze’s fault that OP assumed it was a feature then is upset that it isn’t.
You’re totally lost. The app never talks to your router. My app never even talks directly to my cams since they are on an isolated network with no direct communication.
Not Wyze, They’re not sending the video stream via udp. Why would Wyze ask you to login if the underlying protocol is udp?
They absolutely use UDP for the video stream. Even the heartbeats when the cam is idle are using UDP.
Authentication and control uses TCP. Video stream and other traffic uses UDP.
It is not one or the other. Devices can have multiple simultaneous connections.
If you don’t believe me, look in your router’s netstat (if it has it).
Or look at mine
Idle cam, haven’t looked at it all day, simply sending heartbeat/keepalive messages (if you watch it long enough, it will likely establish a TCP session every so often for authentication).
Proto NATed Address Destination Address State
udp Wyze-FrontStairs.intra.foo.net:57475 ec2-35-81-136-54.us-west-2.com:8000 ASSURED
After bringing up live stream (which goes via Wyze servers in my case, but would be the same on the LAN):
Proto NATed Address Destination Address State
tcp Wyze-FrontStairs.intra.foo.net:57489 ec2-52-26-201-149.us-west-2.c:28003 ESTABLISHED
udp Wyze-FrontStairs.intra.foo.net:57475 ec2-52-26-201-149.us-west-2.c:28003 ASSURED
udp Wyze-FrontStairs.intra.foo.net:57475 ec2-3-228-114-222.compute-1.a:40951 ASSURED
udp Wyze-FrontStairs.intra.foo.net:57475 ec2-3-141-121-179.us-east-2.c:49971 ASSURED
udp Wyze-FrontStairs.intra.foo.net:57475 ec2-52-20-100-241.compute-1.a:49961 ASSURED
udp Wyze-FrontStairs.intra.foo.net:57475 ec2-35-81-136-54.us-west-2.com:8000 ASSURED
This is an OG cam. My Panv3 still uses some of their old hosting providers in addition to AWS, but same idea.
It had been 7 days or more since I had checked the app. I hear you bud. !