Wyze Cam V2 Support?

Having the same issues as well I posted this in reddit for help asking here also

Using black Wyzecam v2 with USB A/A 3.0 in Pi 3B 1.2

I'm getting this message in dmesg when OctoPrint boots..
Relevant messages

[ 2.391803] usb 1-1.4: new high-speed USB device number 5 using dwc_otg

[ 2.522523] usb 1-1.4: New USB device found, idVendor=18d1, idProduct=0001, bcdDevice= 3.10

[ 2.528543] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3

[ 2.531670] usb 1-1.4: Product: HD USB Camera

[ 2.534705] usb 1-1.4: Manufacturer: Ingenic Semiconductor CO., LTD.

[ 2.537711] usb 1-1.4: SerialNumber: Ucamera001

[ 9.582627] uvcvideo: Failed to query (GET_INFO) UVC control 6 on unit 2: -32 (exp. 1).

[ 9.602066] uvcvideo: Failed to query (GET_INFO) UVC control 9 on unit 2: -32 (exp. 1).

[ 9.608514] uvcvideo: Failed to query (GET_INFO) UVC control 4 on unit 2: -32 (exp. 1).

[ 9.614265] uvcvideo: Failed to query (GET_INFO) UVC control 11 on unit 2: -32 (exp. 1).

[ 9.615819] uvcvideo 1-1.4:1.0: Entity type for entity Processing 2 was not initialized!

[ 9.615838] uvcvideo 1-1.4:1.0: Entity type for entity Camera 1 was not initialized!

[ 9.616245] input: HD USB Camera: HD USB Camera as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4/1-1.4:1.0/input/input0

[ 9.616717] usbcore: registered new interface driver uvcvideo

[ 9.616724] USB Video Class driver (1.1.1)

[ 9.670889] usb 1-1.4: Warning! Unlikely big volume range (=10240), cval->res is probably wrong.

[ 9.670908] usb 1-1.4: [5] FU [PCM Playback Volume] ch = 1, val = -7168/3072/1

[ 9.671683] usb 1-1.4: Warning! Unlikely big volume range (=3072), cval->res is probably wrong.

[ 9.671698] usb 1-1.4: [6] FU [Mic Capture Volume] ch = 1, val = -1536/1536/1

[ 9.923514] bcm2835-codec bcm2835-codec: Device registered as /dev/video10

[ 9.923555] bcm2835-codec bcm2835-codec: Loaded V4L2 decode

[ 9.931543] bcm2835-codec bcm2835-codec: Device registered as /dev/video11

[ 9.931579] bcm2835-codec bcm2835-codec: Loaded V4L2 encode

[ 9.938354] bcm2835-codec bcm2835-codec: Device registered as /dev/video12

[ 9.938393] bcm2835-codec bcm2835-codec: Loaded V4L2 isp

[ 13.347170] uvcvideo: Failed to query (GET_DEF) UVC control 6 on unit 2: -32 (exp. 2).

I've tested the WyzeCam in Windows 10 and it works fine as webcam so confident that the camera firmware flash is working. I've tried all the usb ports on the pi. Cam doesn't show up in lsusb. I've seen other posts with the above error but can't find the solution.
thanks in advance for any assistance.

I'm seeing the same exact messages. The camera works great on my mac. Maybe it's a driver issue with rpi? I've tried

  • different cables usb2 and usb3
  • changing camera settings/resolutions
  • changed the pi power adapter in case it wasn't getting enough juice to also run the camera

The main error that I see repeatedly is uvcvideo: Failed to query (GET_DEF) UVC control 6 on unit 2: -32 (exp. 2).

I get those same messages. The only issue I had with my Wyze cam is needing to reboot to get octoprint to recognize it.

That specific Failed to query (GET_DEF) message isn't an issue. I get those consistently, but it doesn't affect the camera's functionality. It's just referring to functions it attempted to query the camera about support for (default values, pan/tilt, etc.) but was unable. The uvcvideo driver on the RPi should automatically adjust how it communicates with the camera after a few of those failures.

What I have been seeing though at seemingly random times is the camera ceasing to work, and having to unplug and plug it back in, and then either run a few commands to reset the physical device drivers and service, or reboot the pi, to get the camera feed back. This is a persistent issue, but sometimes I can go hours or even days without it happening. The errors I see directly related to the issue are:

usb 1-1.1.3: reset high-speed USB device number 46 using dwc_otg
usb 1-1.1.3: device descriptor read/64, error -110
usb 1-1.1.3: device descriptor read/64, error -110
usb 1-1.1.3: reset high-speed USB device number 46 using dwc_otg
.... [continues in this loop a few times]
usb 1-1.1.3: device not accepting address 46, error -71
usb 1-1.1.3: USB disconnect, device number 46
usb 1-1.1.3: new high-speed USB device number 47 using dwc_otg
usb 1-1.1.3: New USB device found, idVendor=18d1, idProduct=0001, bcdDevice= 3.10
usb 1-1.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1.1.3: Product: HD USB Camera
usb 1-1.1.3: Manufacturer: Ingenic Semiconductor CO., LTD.
usb 1-1.1.3: SerialNumber: Ucamera001
uvcvideo: Found UVC 1.00 device HD USB Camera (18d1:0001)
uvcvideo: Failed to query (GET_INFO) UVC control 2 on unit 1: -110 (exp. 1).
... [at this point outputs these  "Failed query" messages with the -110 code (for control numbers 1-11), followed by...]
uvcvideo: Failed to query (129) UVC probe control : -110 (exp. 26).
uvcvideo: Failed to initialize the device (-5).
... [it then usually loops through the same disconnect, reconnect, error, disconnect...., a few times]

It's possible this could be tied to UVC quirks that need to be permanently implemented for the camera to function reliably - this is fairly common with inexpensive USB cameras that don't implement communication standards properly. However - the "reset high-speed USB device number XX using dwc_otg" error, based on what I have read, is usually related to the device not getting enough power, and has occurred with other devices on the RPi, specifically the 3B/3B+, due to hardware limitations of how much power it can send to USB devices. The suggested solution is getting an externally-powered USB hub, and plugging the camera into that. I'm playing around with modifications to UVC quirks in the meantime, but if anyone wants to try the hub thing and post back results, it would be interesting to see if it helps!

Also, that said, if anyone wants to try the potential mitigation with UVC quirks, run this command on your Pi (may need to run it as root - run 'sudo -s' beforehand), and reboot:

 echo "options uvcvideo quirks=0x126" > /etc/modprobe.d/uvcvideo.conf

As an update, I've been running for the past 14hrs with no issues yet using the quirks modification. Not totally out of the woods yet, but it looks promising!

I finally got it working on my end. I'm not sure if this was the main issue but I was using -f 10 when it wasn't part of a supported format. For those debugging, use

tail /var/log/webcamd.log to view the errors for your webcam.

If you see the "Unable to set format", you need to update octopi.txt to match a format listed when executing v4l2-ctl --list-formats-ext. In my case, the only formats that were listed were 30fps so once I updated to -f 30, everything started working.

Quick update - sadly it doesn't seem the quirks modification resolved it. I seemed to have more stability for a little while, but it's still dying anywhere from every couple hours to every day. Has anyone else experienced instability, and if so, how have you resolved it?

Hey guys, I'm curious if any of the stock firmware streams are non-rstp encapsulated h264 format? I think the HLSWebcam plugin might be able to hook into this if so, would just need to do some testing.

Wyze released a USB webcam firmware - https://support.wyzecam.com/hc/en-us/articles/360041605111-Webcam-Firmware-Instructions
It can be the quick solution for those who have the camera close enough for USB cable.

When speaking about HLS - we are using FFMpeg for this, which is a Swiss knife of video streaming. We can ingest virtually any stream if we have enough CPU performance.

Yeah, I'm aware of the USB webcam option, but in general think it would be better having the processing of the stream/image creation offloaded to the device itself if it supports it, so really just proxying the provided stream to the HTML video tag seems like a legitimate solution, assuming we can get a stream format the Wyze 2 cam can output and the video tag in your viewmodel can handle.

Just glancing at the code of your control viewmodel it seems you are detecting if the stream URL can be ingested by the video tag if I remember correctly, which an HTML video tag can handle a pure h264 file, just not sure how well that works with a stream. For example 2 years ago I made this plugin, but didn't really develop it any further.

Sorry to resurrect an old comment, but does this change get overwritten when OctoPi updates? I just looked at mine and it was reverted to the original setting.

Have we got a final solution to this? I'm running the custom firmware on my wyze

What format is your URL in? I copied the image url and I can open that in the browser but octoprint doesn't seem to like it

Hi everyone interested in making Dafang-Hacked cameras working with OctoPrint. I've just posted this on github, but I think it wouldn't hurt copying my solution here:

For all OctoPrint users - you can have a nice workaround for getting camera to work with your printer which does not require any transcodings. You basically need to do two things to make it work:

  1. Remove login requirement from /cgi-bin/currentpic.cgi You can do it by modifying /config/lighthttpd.conf on SD card (just find section starting with "# Support letsencrypt SSL cert paths" and replace with code below):
# Support letsencrypt SSL cert paths
# (we don't want to upgrade to SSL nor auth' this path)
$HTTP["url"] !~ "^/.well-known/(.*)|^/cgi-bin/currentpic.cgi" {

	$HTTP["scheme"] == "https" {
		auth.backend				= "htdigest"
		auth.backend.htdigest.userfile = "/system/sdcard/config/lighttpd.user"
		auth.require = ( "/" => ("method" => "basic", "realm" => "all", "require" => "user=root"))
		alias.url = ( "/viewer" => "/system/sdcard/DCIM/" )
		$HTTP["url"] =~ "^/viewer($|/)" { server.dir-listing = "enable" }
	}

I've added |^/cgi-bin/currentpic.cgi over there in regexp to disable password request for getting snapshots.
2. Use https://micam.local/cgi-bin/currentpic.cgi in your Webcam snapshots section (use whatever hostname/IP you have instead micam.local ), and also install SnapStream plugin and point it to https://micam.local/cgi-bin/currentpic.cgi

1 Like

There is also the OpenMiko project that adds mjpg stream support natively from the Wyze V2.

Wow, great, didn't knew about it, will try.

Have you had experience with OpenMiko yourself? I have a few Xiaofang 1Ss, and I cannot find an indication it is not compatible with this model, but after flashing camera is not working. I reverted back to Dafang-Hack, but really would like to get MJPEG over HTTP working, maybe you have an idea if you have used the same camera.

I have, but only on a Wyze Cam V2. I haven't used it in a while, but believe it's still functional. You can SSH to the device once it's connected to debug, yet I wouldn't know how. You may want to ask on their slack channel.

Confirmed openmiko wouldn't work on Xiaofang 1S as it has 64 Megs of RAM and it requires 128 minimum. I also I've tried to compile mjpg_streamer for Dafang-Haks, but it seems I don't have enough experience with build tools. My executable shows "segmentation fault". Stuck on my solution so far.