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.
- 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
.
feel free to take/use/modify as needed.
- 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.
- 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:
-
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.
-
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 
.
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.