30 Nov 2021 Update: Good day all. Happy holidays! I hope that 2021 was kinder to all of you than 2020 was, and that you're looking forward to 2022 with anticipation of all things good.
This update is simply to appraise those of you who are interested in the latest unofficial information with OpenMiko and the Wyze Cam family. OM continues to be actively developed and is currently sitting at version 0.0.32. If you review the change log, you will note some likely pleasant benefits from changes made this year. One can peruse the release notes for higher fidelity details. Highlights:
- Gray Scale Night Mode (No More Purple.!.)
- Configurable OSD with Date/Time Stamp
- Improved Frame Rates for some of the streams
- OM FW self upgrade ability
- FFMPEG updates to enable YouTube streaming with the WCv2
- [Limited?] Audio support
- Horizontal/Vertical Image Flip ability
- More under the hood items
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 http://IP:8081/api/ir_cut <-- Day mode
curl -d value=0 http://IP:8081/api/ir_cut <-- Night mode
Turn on/off the infrared LEDs:
curl -d value=1 http://IP:8081/api/ir_led <-- Night mode
curl -d value=0 http://IP:8081/api/ir_led <-- Day mode
(17Jan22 Edit): If SSH'd into camera, the IP to use in the above curl commands is 127.0.0.1. Otherwise, if sending the curl command from a different machine, use the local LAN IP address.
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. (17Jan22 Edit) Night mode is now grayscale. 
Additionally, manually adjusting focus is doable, with camera disassy (voiding warranty). One means is detailed in the following video - YMMV: Wyzecam Focus Ring - YouTube
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 (curl for 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 (17Jan22 URL edits for latest FW changes):
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.jsonI 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:
-
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).
-
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:
- https://wyzelabs.zendesk.com/hc/en-us/sections/360008414591-Webcam-Firmware-Update
- Using the WyzeCam as a Webcam for Your Computer or OctoPrint | Automated Home Party
- 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:
- https://wyzelabs.zendesk.com/hc/en-us/articles/360026245231-Wyze-Cam-RTSP
- https://www.reddit.com/r/octoprint/comments/eoz25z/octoprint_and_wyze_cam/
- 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:
[EDIT: THE FOLLOWING Italicized Text IS NO LONGER APPLICABLE - RETAINED FOR HISTORICAL PURPOSES]
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):
...
ssid="YourSSID"
...
psk="YourPassword"
...
- 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: Create Account | Slack
- @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.
~MHz
