Wyze Cam v2 and Octoprint (as of 12Jan2021)

12 JAN 2021 EDIT: Good day. As info, OpenMiko v0.0.12 is now available for download and install, if so desired. Url: https://github.com/openmiko/openmiko/releases/tag/v0.0.12.

The primary reason for this forum post update is to provide some additional information surrounding the secure implementation of OpenMiko on one's WCv2. Be advised that a password change with the passwd command in an ssh session will NOT survive a reboot unless specific steps are taken. From OM Dev, @tachang:

"... just change the password [via ssh passwd command] and copy the /etc/shadow to /config/overlay/etc/shadow. "

28 DEC 2020 EDIT: Good day. As info, OpenMiko v0.0.9 is available for download here: https://github.com/openmiko/openmiko/releases/download/v0.0.9/openmiko_firmware.bin
This build brings automatic day/night mode to the table, switching from Color to IR and back again, based on ambient light detected in the FOV. Note that image is not processed for gray scale, but rather has the natural purple hue that the IR filter and diodes provide. Kudos to @tachang (OM Dev) and user @The_Piranha for respectively implementing and requesting this feature. Additionally, CURL is included in this build (in v0.0.7/v0.0.8 CURL was missing in the FW which was causing day/night mode being only manually triggerable via use of external CURL executable). Those commands can now be ran organically from a SSH session, should the need to manually control either the IR filter or the IR Illumination diodes exist. Also, I've made a request to see if there is a means to trigger a snapshot and have it saved locally on the uSD, which could enable use of the WCv2 as a photogrammetry sensor (with focus adjustment or replacement with a NFOV/Macro lens) - we'll see if that gains any traction. Take care and Happy New Year. GTFO 2020. Hopefully everyone has a blessed 2021!

EDIT: As info, it has been observed that the switch back from night mode to day mode may be a bit problematic in that it looks to sometimes gets stuck in night mode. One can SSH in and issue the commands needed to force the reversion back to day mode. or just wait it out as I've found it to often resolve itself. Regardless, the details of the ssh curl commands follow:

Turn on/off the infrared cutoff filter:
curl -d value=1 <-- Day mode
curl -d value=0 <-- Night mode

Turn on/off the infrared LEDs:
curl -d value=1 <-- Night mode
curl -d value=0 <-- Day mode

Also, please note that, in night mode, it is not grayscale as one might expect. The image is presented with the purple hue that the LEDs and IR filter bring in. OM Dev @tachang may or may not elect to include the gray scale post-processing - TBD.

Additionally, manually adjusting focus is doable, with camera disassy (voiding warranty). One means is detailed in the following video - YMMV: https://www.youtube.com/watch?v=Ldg1pIjrdvo

21 DEC 2020 EDIT: Good day and Happy Holidays! As info, OpenMiko v0.0.7_prerelease is available for download here: https://github.com/openmiko/openmiko/releases/tag/v0.0.7-prerelease
This seems to fix any issues that were present in v0.0.5. Additionally, OM Dev added the ability to stow and deploy the IR Cutoff Filter (the click you hear when the camera is booting), and to enable/disable the IR Illumination Diodes. Both of these features work well (if on Windows, one may need to install a Curl Binary for Windows (https://curl.se/windows/)). Reportedly the unit also has automatic night detection (haven't tested yet). Some URLs are updated - streams can be accessed using the following URLs:

rtsp://IP:8554/video3/unicast    <-- H.264 streamed via RTSP
rtsp://IP:8554/video5/unicast    <-- lower resolution RTSP
http://IP:8080/?action=stream    <-- MJPEG streamed over HTTP
http://IP:8080/?action=snapshot  <-- JPEG snapshot

12 DEC 2020 EDIT: Ok, so I just learned that there is another feature of OpenMiko that I wasn't aware of. OpenMiko v0.0.5 also serves RTSP encapsulated feed on port 8554 - rtsp://ip:8554/unicast - substantiated just a few minutes ago: https://i.imgur.com/ZqGchGG.jpg
Also, be advised that OpenMiko dev has advised that it is prudent to consider leaving the uSD card inserted as, if installed, it is used as swap memory. This might be the reason that it has a tendency to hang as detailed below (dev did mention boot timing issue as a culprit too)...

05 DEC 2020 EDIT: There seems to be a potential tendency for the current version of OpenMiko to possibly hang on the first run after a reboot/power cycle. It has been observed that running a couple of commands from the ssh shell might go a long way in helping to resolve this. The OM devs are actively working the FW to resolve same. If you get a hang, try these two commands after logging into the camera via ssh:

killall videocapture
/usr/bin/videocapture /etc/videocapture_settings.json

I understand that these commands bring the video streaming service out of a background context and runs it in the foreground. If this works for you, please take a minute or two to report same over on the OM slack channel.. Thanks. ~MHz

01 Dec 2020 Original Post

(Most of this is a repeat of the information that was provided in spurts on the OctoPrint Discord channel #support-webcam. I've elected to regurgitate it herein for historical and ease of reference purposes, given that content on Discord often has a shorter shelf life than forum posts. With that...)

I've been led to understand that the lowest effort implementation of streaming and snapshots within OctoPrint is via IP cameras that serve mjpeg imagery over html. This is the direction I chose to pursue for my own implementation. Having had my printer since this past fall (first print was on 17 Sep 2020), and also being an electronics hobbyist it was less than a week that I elected to install OctoPrint and start making timelapse videos because, well, yeah, because I could and I found it intellectually gratifying to do so.

At that early point I began using a cheap (I mean really cheap - sub $10 USD when sourced offshore) ESP32-CAM running custom firmware (https://github.com/easytarget/esp32-cam-webserver) to achieve this. I already had that camera/controller pair and it was a natural progression to print a case for it and get it serving images into OctoPrint. The issues this unit has that I have come to be displeased with is that the frame rates are horrid when the resolution is turned up to what most would consider minimum resolution in 2020. While it is capable of good resolution, the image quality is less than stellar and is served very slowly (at least with the firmware I was using (one that enabled the control and use of the illumination LED (required as anything less than bright light and the image quality fell off a cliff))).

As I was getting frustrated with the ESP32-CAM, I started hitting the Octoprint Forums and the Discord Server. I came across several instances where folks were working really hard to get the Wyze Cam v2 (WCv2 hereinafter) units instantiated as the image capture devices for OctoPrint. Some of these examples can be observed here:

My takeaways were/are:

  1. One can use stock Wyze Cam FW and be locked into their ecosystem of apps, servers, and tools - and be left with no OctoPrint-compatible WCv2 functionality (currently).

  2. Use Wyze's WebCam FW and live with a requirement for a physical USB connection to the Pi via USB-A to USB-A cable. This is acknowledged as a likely good solution for many OctoPrint users, if the cpu cycle overhead is not too impacting in a negative manner. It requires a static connection to the Pi via USB and serves the video via USB like a traditional webcam. The Wyze Webcam FW breaks their other feature sets of the Wyze IP cam. More Wyze Webcam FW info:

  1. Use Wyze's RTSP FW and live with a requirement for transcoding and restreaming to make use of the Wyze Cam v2 RTSP imagery within OctoPrint, as RTSP is overtly not supported natively by OctoPrint. The Wyze RTSP FW too breaks the standard feature sets of the stock Wyze IP cam. It is perceived by myself that this is a pretty convoluted implementation and may require a separate box to run the transcoding and restreaming services, as doing so on a Pi 3B/3B+ that is also an OctoPrint server will likely have detrimental print outcomes due to the additional load imputed by these services impacting print quality. I've no frame of reference on a Pi 4 2/4/8GB units, so I defer to others to comment if it can handle doing so concurrently (OctoPrint + transcoding/restream). From my perspective - ugh... In addition to the info linked to above, one can find additional details regarding Wyze RTSP FW and transcoding and restreaming of same at the following links:
  1. Use a third-party IP Cam FW that serves MJPEG imagery over HTTP, and configuring OctoPrint to make use of same. ... Jackpot - this is what I want ... But, I couldn't find any reliable firmware for the WCv2 that seemed to offer the desired functionality - MJPEG streaming/snaps via http. grr

Lurking on the Discord server, I started to develop relationships therein. And, soon thereafter, at the behest of Jim (@jneilliii), I ended up taking the plunge and got a WCv2 and started to do what I do in evaluating what was needed to get this unit, which has, imo, really good image quality along with a wicked good price point ($20-$25 USD from most online retailers), to operate with OctoPrint sans direct connection to the OctoPrint Server and sans having to implement a complex transcoding/restreaming framework.

In short, success is being observed/experienced via working with a custom OSS firmware (OpenMiko) developer (Jeff Tchang @tachang) for this camera, which whom I engaged and inquired about the viability of using his package as a starting point for getting the WCv2 to become one of the goto units for OctoPrint setups. Considering a fiscal investment of $20-$25 USD and using a custom FW that is being actively developed, I perceive this approach to be a low risk endeavor for many folks to consider.

WCv2 Internals Heads-up:

There was a discovery during this process that merits bringing to the surface: The WCv2 units have shipped with different model of image sensors therein - namely the jxf22, jxf23, and possibly the jxf23a. It is prudent to note that the OpenMiko dev doesn't have an older unit that has a jxf22 sensor therein. His and mine both have the jxf23 sensors and this is all drafted with same in mind. Jim has an older model with the jxf22 sensor therein and OpenMiko hasn't yet been demonstrated to be functional with same. Jim and Jeff spent some time chasing it, but it was determined that until Jeff gets one in hand, he'll focus on supporting the jxf23/jxf23a sensors (and w/e sensors eventually ships in the WCv3 that is imminent to hit the streets in the coming weeks/months). So, the concern surrounding OpenMiko not working with the WCv2 is likely applicable only if one has or gets a used camera that is aged, or buys a 'new' unit from a vendor that has had them in their inventory for quite some time (somewhat unlikely given their commodity pricing model).

Installing and using OpenMiko:

Now that all of that diatribe has been asserted, if you are interested in attempting to make use of OpenMiko on your WCv2, please reference the following:

Note: Use of the OpenMiko FW on the Wyze Cam v2 is a use at your own risk endeavor:
- 'No expressed or implied warranty' is overtly asserted.
Note: Use of the OpenMiko FW entirely wipes out the existing OEM FW and is known to have the following limitations:
- NO Interoperability with the Wyze Enterprise Servers, Apps, third-parties, etc.
- At this early juncture, OpenMiko is solely limited to serving MJPEG video and JPEG snapshots over http.
- NO IR Camera Functionality (yet)
- NO IR Illuminator Functionality (yet)
- NO Audio detection/encoding/streaming (yet)
- NO Audio reproduction/two-way audio (yet)
- NO OSD display of Date/Time/etc. (yet)
- NO Video/Audio Recording to removable media (yet)
Note: The OEM FW Bootloader is not altered and should be able to support reverting back to OEM FW when desired:
- just follow Wyze's OEM FW Loading/Update guidance.

Installation/Setup ('windows-savvy' author here, with absolutely no *nix skills to speak of... :)):
- As a prepatory step, if on windows, with camera disconnected/powered down, one may be able to open a command prompt and do an 'arp -a' to possibly see a list of LAN IPs currently in use (to aid in finding the IP of the camera after the OpenMiko FW is loaded, via process of elimination, in case router UI isn't able to aid in this...).
- Download OpenMiko v0.0.5 from here: https://github.com/openmiko/openmiko/releases/tag/v0.0.5
- Download wpa_supplicant.conf from here: https://github.com/openmiko/openmiko/raw/019db75da8bf0f818f9cbb463b0381be79f6a9f4/overlayfs_dafang/config/wpa_supplicant.conf.dist, saving locally for editing.
- Edit wpa_supplicant.conf to put your WiFi AP SSID and PW therein (retain the quotes, be sure your editor is configured for linux line endings):
- A FAT32 uSD is needed (I use a 4GB uSD) - which doesn't necessarily need to be blank, but there should be no 'demo.bin' or 'wpa_supplicant.conf' files thereon.
- Rename the previously downloaded fw file to demo.bin, saving to the uSD's root dir when done.
- Save the edited wpa_supplicant.conf (containing your WiFi AP's vitals) to the uSD's root dir when done.
- Apply the FW .bin upgrade typical for the Wyze Cam v2 (powering down the camera and inserting the uSD, holding the reset button down, plugging in the uUSB, while holding the reset down until the status LED goes solid blue, after which you can release the button and wait patiently :)).
- Once FW completes loading (couple of minutes), it should reboot (sound of IR filter cycling should be detectable), after which, in another a minute or three (FW loading),
- It will then attempt to connect to the WiFi AP detailed in wpa_supplicant.conf.
- After a short bit, if LAN connectivity ends up being good (check your router's UI/do another 'arp -a'),
- Using putty or other client, SSH in (ip:as_assigned port:22 UN/PW: root/root) and copy wpa_supplicant.conf from the uSD to the flash-memory mapped folder: cp /sdcard/wpa_supplicant.conf /config/overlay/etc/wpa_supplicant.conf
- Remove uSD card (not required, but affirms operations sans uSD) and bounce it (removing uUSB and Reinserting it, to cycle power) - once it reboots and reconnects, it should start to serve imagery over http via mjpeg-streamer:
- Snapshot URL: http://<ip_as_assigned>:8080/?action=snapshot <-- on-demand snapshots for time-lapse/OctoLapse
- Stream URL: http://<ip_as_assigned>:8080/?action=stream <-- video stream @ ~5-15-ish fps (slower when serving multiple streams)
- This is coming along rather quickly, thanks to the OpenMiko (https://github.com/openmiko/openmiko) dev and project creator, Mr. Jeff Tchang (@tachang) and contributors (i.e. Eric Bina) - Kudos, gentlemen.
- For additional support, join the slack channel for the OpenMiko project: https://join.slack.com/t/openmiko/shared_invite/zt-j7kdxkwy-I60EbX586dO9OusdcvTMWw
- @tachang hangs out at Octoprint's Discord Server too - in the #support-webcam room.

Whew. Ok, glad that is done. Take care. Peace. I'm out.



Amazing! I have a wyze cam that has been sitting idly since I couldn't get the RTSP URL working in octoprint, going to give this a try! Thanks

You're most welcome! Good luck.


Happier than a 'pig in smeg'; this kills two birds with one stone for me: WyzeCam in Octoprint (MJPEG) and HomeKit (RTSP). Will be grabbing 0.0.7 now since it's a 'license to kill (bugs).'

1 Like

@MegaHurtz Glad to help by posting results. This project for sure needs more traction. As of right now it's running but unstable. I'll be working further with him to provide any logs he may need. Right now as of 11:52pm eastern there have been a total of 3 hard locks that occurred running normal as intended. I'll be updating and testing the 0.0.9 .bin when I am able to tomorrow after potentially posting some event logs from an independent piece of equipment not one of his dev devices. Regards ~TP

I am having issues installing 0.0.9 onto a wyze cam v2. I made sure the "wpa_supplicant.conf" file was set to UNIX under notepad++, demo.bin was on the root. The camera just flashes orange after hearing the clicking sound for the IR sensor.

I went back and tried to install the wyze RTSP firmware and had no issues.

The only thing I think I have found being the issue is my wi-fi is setup for WPA2-PSK rather then WPA-PSK. I edited the file to reflect WPA2-PSK but could not see it on the network.

Does it need to be set as WPA-PSK by chance? Using a 64GB MicroSD FAT32 (same one used for Wyze FW installation).

EDIT: /var/log directory gets created OK.

nightmode off
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed

0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (7) Failed to connect to port 8081: Connection refused
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed

0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (7) Failed to connect to port 8081: Connection refused
WARNING: /usr/bin/nightmode.sh off
returned 1792

Messages log (doesn't seem to intriguing): https://pastebin.com/CAhWbQ4G


Did you get this resolved? If not, it may be useful to note that there are newer versions which may address the problem you are/were having. OM is up to v 0. 0.12, I perceive. You can reattempt install, if so desired.

For additional assistance, I recommend hopping on the OP #supportWebcam channel discord server, or hitting up the OM Slack #general channel.


I’m having this exact same issue. Did you ever figure it out? Thanks!

I am having a difficult time trying to figure out how to ssh into my Wyze V2. I am working on a mac and followed the instructions to put the demo.bin and wpa_supplicant file on the SD card. I used Atom to make the wpa file with my internet login and PW. I loaded the firmware as instructed but I do not see the camera on the router UI (Google nest).
The yellow light is flashing. Not sure if that means it is not connected to the net although I am certain it is not because it does not show up in my list of devices.
Even if it did connect to the net, when I ssh in, I literally type: ssh ip:as_assigned port:22 UN/PW: root/root ? or is it ssh ip:as_assigned where "as_assigned" equals the actual ip address? Additionally what does UN/PW represent - do I replace "UN/PW" with my internet Username/Password? Does "root/root" also get replaced with something?
I apologize for being such a noob but I am really stuck right there!
Thank you in advance for your help and thank you for figuring all this out!!

I think the problem is that it is just not logging into the network. I can't see it on my list of devices at the router. I have the camera plugged to a wall wart and additionally plugged into the raspberry pi4 running octopi. I have an A to A cable for that.

Hi ! I found this thread on google of course, looking to see my Wyze V2 in octoprint. I've already adjusted my focus ring to get better close up video. I've tried the USB method with the Wyze webcam fimware, but i found it way too slow and complicated with VLC.

So ! i went with v0.0.12 of openmiko. I must say that it is working at my first try! So now i can see my Ender 3 v2 in Octoprint and Octopod (ios) without any delay now. Pretty happy !

I must suggest that we create the directory to put the wpa_supplicant.conf file in the first try, so we don't have to remove the SD card again and get the SD card get corrupted because of the removal.

I input the stream in the Stream URL + the Snapshot URL in the Timelapse Recordings section, but what about the path to FFMPEG ? Because in the Octoprint web page i can see this error message: " Timelapse not fully configured". I didn't see anything about it in the doc ? I saw in /etc/openmiko.conf a setting about ENABLE_RECORDING=0 but does it work ? It seem to enable a v4l2rtspserver witch is not really documented... I think it is not related and i need to install ffmpeg myself to put in the Octoprint Settings ?

I will try to input the Time and Date into the feed, the timezone is set UTC, we need to change that too, i'll look into it if i have some time and report back.

EDIT: I found my problem, downloaded ffmpeg and put the complete path there and is it okay. They also put the time in the watermark, so i'm not sure if now i need the time/date on the live video :wink: