But here is a bit of how I set it up and some pics of it in action. Pardon the upside down shots of the nozzle, I did not mount it, just had it sitting next to the nozzle and the point was just to check the resolution and image quality.
To set up the cam, you can refer to this post, which goes into more depth on multicam setup, but in a nutshell:
1. First connect the camera to the USB port where it will be plugged in and boot the Pi. If you already have a camera configured, check out the multicam setup info from the Octoprint docs, or my prior post linked above.
2. I already had a file named webcam2.txt set up (which is required for multicam) and it lives here:
/boot/octopi.conf.d/webcam2.txt
3. I ran "ls /dev/v4l/by-id/" to first get the long name (what I would call it) for the endoscope camera, which is:
"/dev/v4l/by-id/usb-Generic_ICT_Camera_200901010001-video-index0":
UPDATE 9/17/2022: I still need to test this camera on another device to see if the cut outs are due to the camera or the host it was connected to. However last night I ordered this camera, which I think could be used as a nozzle camera, and it has some benefits over the endoscope types of cameras for mounting and cooling. The problem however may be (edit) the focal length, but it may be that a small lens could be used to get a close view so I am also gonna order some cheap lenses to test it with. If it works I will post some updated designs and may try to work the camera into the stealthburner (that is the ultimate goal at least), but I will first try it out on the CR10S Pro.
UPDATE 10/7/2022: I did not test the endoscope camera on another device, but I have since experienced this same issue with another camera on the Pi, so I suspect the issue is with the Pi. I found this post on the Octoprint Community Forum and it looks like something I should try. I will test it again if the issue can be resolved on the Pi.
UPDATED 10/8/2022: Well this is strange, but I have been testing the other camera I have (OV5640), which has also been locking up. I tried changing "type=forking" to "type=simple" but that had the effect of causing webcamd to reset every few seconds. I then found this post by Foosel (Octoprint creator) and it says that the type should be "simple", however (again) with "simple" webcamd restarts constantly. So the behavior I am seeing appears to be opposite what was reported in the linked thread (simple causes webcamd to restart constantly and forked seems to be stable, but locks up). I may end up re-imaging the pi with the latest version (I am running 1.8.4 currently on this pi). In any case, the issues with the locking up on the cameras seems to be related to the Pi/Octoprint and not something wrong with the cameras.