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.

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