Automation: wyzecam v3 auto detect when home/away. Also account for what can be argued as a engineering oversight

Hi Folks,
I am the new owner of a Wyzecamv3. I wanted to take a moment here and write a small document explaining some of the issues I came across and how I resolved them using both IFTTT and some basic scripting. Ill try to itemize them out so you know each issue I came across and how I overcame it.

  1. I might as well start with simple automatic detection of when im home or away and automatically turning on motion sensing. One of the things I wanted my wyze cam to do was detect if I leave home and automatically turn on motion sensing. After all, Out of sight out of mind. For this, I used IFTTT, which Wyze is capable of using. At first I simply configured jobs for “If disconnected from wifi, turn on motion sensing” and off respectably. I did find that this WORKED, however on my particular phone the app would simply die after a day or two of running. I did review the power settings and make sure android was not trying to optimize battery usage of the app, but this made no difference. In the end, I made two jobs using the “webhook” functionality of IFTTT. There are two jobs at this point (the free limit is 3, and 2 works perfect for my simpler needs.) turn motion sensing on and off. To trigger the webhook, I created one script that lives out on my router. You can find the Gist code here:
    Simple little script i wrote for IFTTT. It pulls a list of active clients from within my router, which is dd-wrt. Similar commands exist for tomato and openwrt. Refer to your device's documentation for how to use. Then if the user's MAC address is no longer detected, it can run your ifttt webhook url, or any other action you prefer to automate your IoT cameras, lights, etc. Script can be run at startup on whatever platform you wish and live in background. · GitHub . With all of this, my camera now intelligently detects when I leave home and enables for me, then disables soon as I park my car infront of the house :slightly_smiling_face: .

feel free to take/use/modify as needed.

  1. This is arguably a slight oversight of the Wyze software, but I found that when you configure motion detection on a schedule, this works great as is. Motion detection enables for the specified time then disables. However, if you have a scenario where you are away from your home for more than a day, this schedule causes problems. Instead of returning to the previous state of motion detection BEFORE the schedule, the scheduler simply turns OFF motion detection. This means that if you are gone more than a day, and turn on your motion detection before you leave, when your scheduled motion detection runs, it will DISABLE motion detection after, leaving you with none. I really hope the Wyze team reviews this and addresses this. I contacted support about it who only recommend adding it to the wishlist… except I find it absurd to add what is a design oversight to a feature request page. Its a simple fix…simply have the camera remember the previous state of settings and go back to them after a schedule completes NOT shut off.

In any event, to deal with this, I once again used a script with my ifttt webhook I created in step one to turn off motion detection. This script also lives in my router, but the code is a bit more generic and could be added to arguably any linux based system and scheduled at the end of your Wyze camera schedule. It simply tries to ping your device on the network to see if it is present, if not, sends out the webhook for ifttt to turn on motion sensing. Else, it does nothing, as you are home and your schedule is ending.

feel free to take/use/modify as you see fit.

  1. And final challenge I encountered was a bit absurd but a challenge nonetheless. For some strange reason I was finding that whenever I would connect to my Wyze cam, the camera would effectively cause my entire router to crash. Upon closer investigation, I found extremely high CPU utilization whenever I connected to my camera from my phone’s mobile data. If I connect locally within my LAN the utilization is a bit better but still bad, usually exceeding 50%. This makes no sense on my network as I do not even have enough upstream bandwidth to tax my router to that level. In short, the high utilization would overwhelm the router and actually cause its entire operating system to crash. Upon closer investigation, I found that the wyzecam found it necessary to open well over 1500 TCP sessions going to my carrier ISP. At one point it seemed to create around 1500 connections to my carrier for TCP streams for what I can only assume is video data. All of this was colliding with my firewall rules as I have a pretty aggressive list of known bad actors and hostile countries blocked. All of these checks were overwhelming my device and causing a literal crash. This is something I think the wyze team needs to investigate also. Very concerning when your device decides its ok to send 1500 requests to my cell carrier’s IP, most of which went unreplied (yay firewalls). I will keep an eye on this and if I can get it to reproduce again will post here with screenshots on my router showing the active tunnels. Again wyze team, please PLEASE look into this. Its concerning that your device literally was performing what could be interpreted as malicious activity to other servers. If this turns out to not be the case, your packets are not traversing firewalls correctly.

To address, in short, I made a rule at the top of my outbound filter for my firewall list that will effectively return packets associated to the camera’s IP (make a dhcp reservation for it in your router so the setting sticks) to the previous chain, bypassing the rule.

If you are affected and running stock firmware – Ive read issues with ASUS, ubiquiti, and the odd TP link. My recommendations to correct this are below:

IF you are on ASUS: log into your router’s configuration page, all asus routers have intrusion detection among other security scanning provided by trend micro. See if you can temporarily disable the protection to simply test to see if your problem persists. If it does not, you will need to somehow whitelist the camera against trend micro.

IF YOU ARE ON UBIQUITI: ubiquiti has similar scanning as well as cloud based GEOIP blocking (like I do) , try disabling this or whitelisting your camera, see if this fixes it.

TP link may have similar. Refer to router documentation regarding it.

TL/DR; above steps are my experience performing basic setup of the wyzecamv3. The couple issues/bugs are restated below:

  1. the camera seems to have problems with schedules, where if a feature was ON before the schedule run, it will turn OFF the feature after the run, even if it was on before the schedule even started. Please update this to remember previous state rather than simply turning off.

  2. please look into the network issue. What I discovered is frankly a bit disturbing. It shows either a glaring design bug, or worse, malicious code running on the device. in short, depending on firewall configurations, it literally performs a DOS against devices.

Thanks for reading and I hope this post helps someone :slight_smile: .


Very awesome report. You put a lot of good effort into all of that! Thank you for sharing.

@spamoni Check out #3 and see if it is related to the excessive bandwidth issues you were finding and if so, maybe send some of that information on to qsun or whoever he referred the issue to since they were looking into that type of stuff (assuming it is related).

I will say that Wyze has a location rule using GPS in beta testing right now. I am testing this feature and yesterday it worked to turn on my cam and sensor notifications when I left home and turned them back off when I returned home. So detecting home/away and setting up automations for things should be native to the Wyze platform very soon and available for everyone for free. It is very exciting.

I used to use IFTTT but basically boycotted them as soon as they started charging ridiculous amounts for a lot of things that used to be free, and severely choked off what would be available free. Not that I am opposed to paying for things in some cases, but I didn’t like the way they handled this at all. Now I use Home Assistant, and the unofficial Wyze API to do basically anything I used to use IFTTT for (and sometimes I use Tasker for things too).


Yes, my issues personally with IFTTT wasnt their services themselves, I came in after they became more restrictive. Personally, the only device I have with them is the wyze camera. So the simple on/off webhook commands are all I need leaving me fine with free tier. The rest of my setup was done via scripts as posted above.

Im very interested to hear what comes of the bandwidth consumption issue, as my research on the network crashing issue seemed to turn up a few similar sporadic reports of this. The other issue with scheduling I hope a developer comes by and sees. That would be a simple fix they could push out in a firmware update quite easily.

1 Like

I switched from TPLink to an ASUS router trying to correct my streaming issue I had with TPLink x60 Mesh. My issue was related to trying to live stream cameras while Live Events were being recorded. It would never work. Now that I am on the ASUS ZenWiFi, I don’t have those issues until I turned on the Trend Micro Security. I turned off the following items:

I think my issue is related to the Two-Way IPS and your explanation may have just confirmed this. I think with the amount of Data being sent, it is acting like a Denial of Service attack which may cause the live stream to stop working. Thanks to @carverofchoice for turning me onto this post.

Just so you know, in 1/2 hour my network passed 5 GB per camera which equated to 25 GB (average). This is excessive, especially since it was over 1/2 hour only.

I am going to turn back on Infected Device Prevention and Blovcking to see if this causes any issues.

Thanks for this thorough information.

1 Like

No problem at all. Infact, 25 GB of data is extremely excessive. Out of curiosity, do you know WHAT the camera is connected to? My bigger concern with that is some ISPs which have datacaps now (its a lovely way to gouge us…especially in monopolized areas). Also, where the heck is all of this data going? can you run a packet capture from your router? If on asuswrt, I think being based on tomato, they do allow ssh and should have a tcpdump or similar on the shell, this can be saved somewhere and opened with wireshark for further network analysis. In my case, when I observed the connections it had created, they were all pointing to a server apparently owned by my cellular carrier. It would be interesting to know where your cameras feel the need to send data to. Are your cameras always recording?

As for the router exhaustion in my testing I found the catalyst to be if you are on mobile data or on your wifi network. When connected to wifi, I think the camera determines that your phone is also present and sends the data locally, thus cutting some overhead as the firewall does not touch local traffic. If you are going to re-enable the protection features, I would say enable, then reboot both the camera and router, then test with mobile data first, then local. If the drops occur, Im pretty confident we found the smoking gun with these cameras.

Either way, I hope a developer reads these findings. This is something that needs to be looked into.

1 Like

When you say connected to, what are you asking? My Camera is connected to the ASUS ZenWiFi ax (xt8). I am on Verizon FiOS. No Caps and no issue with any devices on my network. I also use Googles DNS and not my providers.

Have not looked into this yet, was planning on analyzing this in the near future. Will also setup my Firewalla, took it out when I switched, to make sure things were working. But will do the stats soon.

I don’t limit my Camera’s at all. They are all outside and are allowed to record and capture 24x7 if needed.

My issue existed when on WiFi or on Cellular. No difference between the two.

Enabled, will do an exhaustive test today or tomorrow. Now that I know to trigger it, I can do my standard test and see if the issue happens. I have not enabled the Two-Way IPs yet. I think this is the setting which will kill me. Trying to do the test 1 piece at a time.

When you say connected to, what are you asking? My Camera is connected to the ASUS ZenWiFi ax (xt8). I am on Verizon FiOS. No Caps and no issue with any devices on my network. I also use Googles DNS and not my providers.

Hey, sorry for late reply. What I meant by that was which servers was the camera connected to when you see the excessive data. Are you able to gather anything about what servers it is talking to?

Also, curious on your findings, if you were able to reproduce the problem with it. I have had my camera in the bypass state now for a bit and no issues at all with it. Thanks for whatever you can let me know.

Sorry to resurrect an old thread, but I did actually find an update to the silly network flooding issue that was going on in the camera. I did some packet sniffing on my network and discovered that the following URL:

This server I noticed seems to be some type of aws authentication server for the camera. The best way to stop the flooding I found was to set below to your routers dns of choice. You can do this in your routers dnsmasq

Also, I wrote another script located here:

It can help monitor from the router side if you have custom firmware or a shell like i do. It monitors the nf_conntrack file on my router for the camera’s ip. Once the camera goes over a threshold, it can issue a reboot via ifttt and/or block the router on the network so it stops making new connections. just set it up in your firmware of choice and have it run in the background. Needs little resource and output can easily be piped to /dev/null to manage resource usage.

I hope the wyzeteam also notices this and makes sure that this is something they incorporate into the stock camera firmware.

A suggestion for them would be to resolve the ip at bootup and maybe store it somewhere, either a variable or maybe even just put it in resolv.conf so the camera has this locally, assuming its linux based.

Hope this helps someone.

1 Like

Impressive work! Thanks for sharing.

No problem! Note that 3 ips actually respond to that address:
they seem to have a round robin DNS response of sorts. I find it best to edit the hosts file of your device possibly based on the result of an nslookup…how do we get someone from the wyze team to take a look at this thread? Id love them to see and maybe know what to patch in firmware so other folks (average users especially) are not being bugged by this. Its fine for people like myself to hunt and find this but people who are not as knowledgeable should not be tasked with this type of fix…

You are right that the average person wouldn’t be capable of doing anything like this. I do know that Wyze has some employees browsing through the threads regularly, though often silently. Plus I know Jason reviews and passes on a lot of info from here.

Honestly, what you might want to do to make sure it gets attention is go post something about it in this week’s fix-it-friday thread here:

Even if this issue doesn’t get voted as the number one bug/issue, Jason still sends details about all the submissions to the appropriate managers over those projects, so he could definitely make sure it gets brought up with the correct team as an official fix-it-Friday report.

Seriously, go leave an entry in there describing the problem and the solution you found as something they could potentially implement to improve things. :+1: You can always summarize it in there and then link back here, or you can just type most of the explanation in there. Either way. That’s one good way to make sure it gets to the right people.

I’m not seeing how this is any kind of fix, or transferable? You’re blackholing one particular AWS host name, but the cameras are likely accessing dozens and dozens of different ones, and we haven’t determined WHY any individual host - the cams are accessing them for a reason after all - would be causing the perceived flooding.

The rebooting is a decent idea I suppose, although a daily reboot through a Wyze rule is a lot easier for most.

Based on the research ive done, the AWS host listed here is infact some type of credential endpoint. Being an AWS server is no surprise to me. Wyze uses AWS on their backend. In mine ive mainly traced connections between AWS, OVH, Akamai (which isnt a bad thing).

The dns entry I gave is not a black hole at all. If you look at my screenshot, There are three servers in a round robin configuration that respond to that address. The constant I found in the flood condition seems to be that the camera believes it lost connectivity to that service for whatever reason and proceeds to flood my cellphone carriers dns server with requests on port 10001 for it. This simply gives the camera what it wants so its always happy.

The nightly reboots are a good general maintenance practice. Googlng this it seems to be a generally recommended answer to general stability of the camera. :slight_smile: And besides, its a home security device that is an IoT appliance…the last thing you want to do is monkey with it, or come into a scenario where you need it, and it somehow became stale because…whatever happened. Cheap insurance I suppose.

Oh, so your approach is allowing the camera to go ahead and do its inquiries, but only allowing the flood locally instead of pounding your normal remote DNS resolver? Makes sense, but isn’t that still kind of a bandaid if it’s still hammering your LAN?..

Actually, its quite unlikely to flood. Ideally, you could have it in your camera’s hosts file so it doesnt even make it to the network. There are ways I could talk about here but that would basically void your warranty ;). On the network it should just get the ip from the local dns server and resolve. If you are worried about it hammering your network, you could use my misbehaving camera script I posted above to basically have your router monitor every 10 seconds for a threshold (mine is at 5000) that itll basically set some firewall rules to stop new connections, let the camera time out with whatever it is doing, then unblock and tell it to reboot.

Sadly wyzeteam really would need to fix this in the firmware itself, but my propesed fixes can help you in the meantime until if and when wyze decides to fix it.

I’m not worried about it at all. I think these misbehaviors are mostly benign. I was just clarifying that if the router is one’s DNS server then any repeated inquiries (“flood”) would still be crossing the local network. I understand your point that using localhost avoids that. Also, I recall several people observing that there were hard coded resolvers (perhaps even by IP address) in some Wyze firmware: I don’t think your solution addresses that situation. Thanks.