• Profiles
    • About
    • Kontakt
    • Impressum
    • Buy me a Coffee
    • Datenschutzerklärung

    BannerNew1

    menu
    • Home
    • Projekte
      • Alpha One - Autonomer Roboter
      • Elektronik / Mechanik Projekte
      • Mikrocontroller Projekte
      • Software Projekte
      • Zukünftige Projekte
    • HOWTOs
      • 3D M-R-P
    • Allerlei Informationen
      • Technische Infos
      • Weitere Infos
      • Wer bin ich?
    • Links

    Thomas Walter Messmer QRCode

    Latest Articles

    • Tasmota Custom WebUI and CSS Style
    • Smart Meter Sensor with Tasmota
    • Crypto Wallet Recovery
    • 137 MHz BP Filter and Noise Source analysed with RTL-SDR Dongle
    • ROS Melodic on Raspberry Pi 3+
    • Instructions, manuals and datasheets for rare or old devices
    • How to switch on and off your 3d printer with your Raspberry Pi
    • Setting up OctoPrint on a Raspberry Pi for multiple printers
    • Product Image Requirements
    • Smoke detector to shutdown 3D printer

    Hot Spot

    • Setting up OctoPrint on a Raspberry Pi for multiple printers
    • Autokonzerne und deren Automarken
    • S-VHS Videorecorder und die Digitalisierung
    • RetroPie Controller Pairing Problems
    • Restauration von VHS Material mit VirtualDub, AviSynth und QTGMC, AvsP und WinFF

    What the Tag

    • Software 9
    • Raspberry Pi 4
    • AtMega 4
    • Motor 4
    • Robot Operating System 3
    • Raspberry 3
    • Problem 3
    • 3dprinter 3
    • printer 3
    • Robot 2

    BuyMeACoffee

    • Drucken

    Setting up OctoPrint on a Raspberry Pi for multiple printers

    Details
    Kategorie: HOWTOs
    Veröffentlicht: 30. Juli 2017
    Erstellt: 30. Juli 2017
    OctoPrint for multiple printers and webcams

    In this article, I will describe how to set up OctoPrint based on OctoPi on a Raspberry Pi 3 for multiple printers. For every printer, a separate OctoPrint instance with a different port must be started. If you want to use more than one webcam, you also have to start separate instances of MJPG-Streamer for each webcam. I have also added a link to another article where I give a short overview of how you can switch on and off your printers with the use of an n-channel relay module. First, we set up OctoPrint for just one printer and, after that works, for multiple printers and webcams.

     

    UPDATE from 23.12.2022 for OctoPi 0.18.0 (OctoPrint 1.8.6) running on Raspbian 10 Codename Buster.

    Can be different for Raspbian 11 Codename bullseye. Information for version 0.13.x and 0.17.x are removed.

    Necessary Components

    To run OctoPrint on a Raspberry Pi, not many components are needed.

    • Raspberry Pi 3 (RPi) or newer
    • MicroSD card with 8 GB or more
    • Power supply with at least >=2.0A better >=3.0A output current
    • A good quality USB power cable
    • A webcam if you like to see what your printer is doing
    • A printed case for the RPi

    If you want to set it up by using a connected HDMI Monitor and a USB keyboard, you also need the following

    • HDMI monitor
    • HDMI cable
    • USB keyboard

    So far, that's all you need to set up OctoPrint on your RPi. If you want to be able to switch your printers on and off, you can also have a look at this article: "How to switch on and off your 3d printer with your Raspberry Pi"

    Where to start with?

    The first step is to install the OctoPi image on your SD card. There are a lot of tutorials out there that show how to do it. The steps are quite straight forward if you use a Windows OS.

    • Download OctoPi image: http://octoprint.org/download/
    • Download Win32 Disk Imager: https://sourceforge.net/projects/win32diskimager/ or Etcher: https://etcher.io/ or use the Raspberry Pi Imager: https://www.raspberrypi.com/software/
    • Insert your SD card in your SD card reader
    • Choose the tool of your choice, open the *.img file and write it to the SD card.

    If you are using a Linux OS then I recommend this site: https://www.raspberrypi.org/documentation/installation/installing-images/linux.md

    After installing the firmware onto the SD card, we should be able to do some configurations in the octopi-wpa-supplicant.txt and octopi.txt file on the boot partition on the SD card. The octopi-network.txt file is no longer supported for network configurations. If you have used the Raspberry Pi Imager, you may have set your configuration in the advanced tab, so you can skip the next text block.

    The boot partition is the only folder you can see under a Windows system. I had some problems making some configurations with that file in earlier version. I wanted to create a Wi-Fi connection with a static IP, but nothing worked as it should because I made a mistake. If you make any mistake with your Wi-Fi connection in that file before the first boot, you have to correct it later directly in your system. So, it seems to me, that these files just used once after the first boot for creating the Wi-Fi connection. I recommend to not make any configurations for a Wi-Fi connection in that file. If you connect your RPi via an Ethernet cable to your router, you don't have to change anything if getting an IP over DHCP is okay for you. Therefore, a DHCP server must be running in your network.

    Connect a monitor via an HDMI cable to your RPi and also connect a USB keyboard to it. It is then possible to do the configuration locally without using the octopi-wpa-supplicant.txt and octopi.txt file or an SSH connection at this point.

    Set up the Wi-Fi connection

    In the newer Raspbian releases, we need to set our configuration in /etc/dhcpcd.conf. Do not modify the /etc/network/interfaces.

    sudo nano /etc/dhcpcd.conf

    For a static eth0 IP and a static wlan0 IP, we just add the following to the end of the file.

    interface eth0
    static ip_address=192.168.0.126/24
    static routers=192.168.0.254
    static domain_name_servers=192.168.0.254 8.8.8.8 fd51:42f8:caae:d92e::1

    interface wlan0
    static ip_address=192.168.0.125/24
    static routers=192.168.0.254
    static domain_name_servers=192.168.0.254 8.8.8.8

    Because we are using a WPA encrypted Wi-Fi connection, we have to modify the /etc/wpa_supplicant/wpa_supplicant.conf file.

    sudo nano /etc/wpa_supplicant/wpa_supplicant.conf

    Add a network which includes the SSID and the PSK of your Wi-Fi connection.

    network={
    ssid="beehive"
    psk="supersecurekey"
    }

    After a reboot, the RPi should be able to connect to your router, and you should be able to connect to it via SSH. Under a Windows system, you can use PuTTY or KiTTY for that.

    Basic configuration

    Some basic configurations like "Expanding Filesystem", "Change User Password", "Localisation Options" and more can be done by using the tool raspi-config.

    sudo raspi-config

    After you expanded the file-system (no longer necessary, in OctoPi 0.18.x, expanding is done automatically) and have finished with the raspi-config configurations it is time to set up your OctoPrint user, your printer and the rest of the OctoPrint configuration. Therefore, use your favorite browser to connect to the OctoPrint web server:

    http://<your pi's ip address>

    The next steps are nearly self-explaining, and you only need to set view things like build size and speeds. For a detailed documentation I recommend OctoPrint's documentation: https://docs.octoprint.org/en/master/

    Connect the different printers to the RPi

    Now it is your turn! Connect your printers, set up its profiles, play around with OctoPrint. Set up every printer you have and create a working profile for every. At this stage, you are then able to plug in all of your printers, but only able to connect to and print with one at once. During the first printer is printing, you are not able to connect to a second one without disconnecting the connection to your actually printing printer! When the first one has finished its job, then you are able to disconnect and connect to the second and print with this one. This is the reason why we need a separate instance for every printer, more about that later.

    Create some udev rules for individual printer device names

    It can be a mess to find the corresponding device for a specific printer. The device naming /dev/ttyUSB0 is generally made in sequential order. So, in this case, the first printer plugged in will get /dev/ttyUSB0 the second one /dev/ttyUSB1 and so on. It is not guaranteed, that this naming is the same after a reboot. So we will use udev to create some symlinks to devices that will have the same name and correspond to the same printer before and after a reboot. I use ttyMKC for my core printer and ttyANET for my Anet printer.

    First, we have to determine the differences of the respective devices, so we can give udev some attributes, so it can differ between the devices (printers). If you are lucky, your devices differ in a lot of attributes. It can also be that they are nearly equal or complete equal! In my case, only the attributes "KERNELS" and "devpath" were different.

    To determine the differences, you can do it manually by looking at the outputs of udevamd for the different devices. The following command is for /dev/ttyUSB0.

    udevadm info -q all -n /dev/ttyUSB0 --attribute-walk

    You can also pipe the outputs to files and use diff to get the differences.

    udevadm info -a -n /dev/ttyUSB0 > devInfoUSB0
    udevadm info -a -n /dev/ttyUSB1 > devInfoUSB1
    diff -u devInfoUSB0 devInfoUSB1

    Then we create a file 99-usb.rules for the udev rules

    cd /etc/udev/rules.d/ 
    sudo nano 99-usb.rules

    and insert the following two lines of code. Each line is a rule for each printer we want to use later.

    These two lines will only work in my case! You have to use the attributes which differ in your case!

    Not every attribute has to be different, but at least one attribute must be different!

    SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", ATTRS{devpath}=="1.3", SYMLINK+="ttyANET"
    SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", ATTRS{devpath}=="1.5", SYMLINK+="ttyMKC"

    Some more information about the udev rules can be found here: https://txlab.wordpress.com/2016/06/14/udev-rules-for-ttyusb-devices/

    Setting up one more instance of OctoPrint

    When your printers print over OctoPrint like they should and every printer has its individual device names e.g. /dev/ttyMKC and /dev/ttyANET we can go further to the next step, the setup of another instance of OctoPrint. Therefore, 3 main steps are necessary:

    • Copy OctoPrint directory
    • Copy and modify OctoPrint service script
    • Add new OctoPrint service script to autostart

    First, we copy the OctoPrint directory

    cp -R /home/pi/.octoprint /home/pi/.octoprint2

    Also make a copy of the OctoPrint service script.

    sudo cp /etc/systemd/system/octoprint.service /etc/systemd/system/octoprint2.service

     

    The next step is to modify the port and add a new basedir to the copied octoprint2.service.

    sudo nano /etc/systemd/system/octoprint2.service

    Some users have gotten problems with the configuration file. So now we also add the path to the configuration as an (--basedir) argument.

    Environment="PORT=5001"
    ExecStart=/home/pi/oprint/bin/octoprint serve --host=${HOST} --port=${PORT} --config /home/pi/.octoprint2/config.yaml --basedir /home/pi/.octoprint2/

    Just in case, we also add the config argument for the default script

    sudo nano /etc/systemd/system/octoprint.service

    the changes look like this:

    Environment="PORT=5000"
    ExecStart=/home/pi/oprint/bin/octoprint serve --host=${HOST} --port=${PORT} --config /home/pi/.octoprint/config.yaml --basedir /home/pi/.octoprint/ 

     

    With these arguments and a properly configured HaProxy you will be able to connect to your printers with a path like this

    http://<your pi's ip address>/mkc/ 

    but not over its ports

    http://<your pi's ip address>:5000

    That is exactly what we normally want!

     

    However, if you want to connect to it over its port, one option is to remove the host from the arguments list:

    ExecStart=/home/pi/oprint/bin/octoprint serve --port=${PORT} --config /home/pi/.octoprint/config.yaml --basedir /home/pi/.octoprint/

    Do the same for the script of the second instance as well.

    Be aware, that open, reachable and network-wide ports are a kind of security issue. So this is not recommended!

     

    The next step, to get a second instance automatically running after booting, is to reload the daemon list after a new service script is added.

    sudo systemctl daemon-reload

    You also need to enable the service with systemctl.

    systemctl enable octoprint2.service

    Start the service with:

    systemctl start octoprint2.service

    To check if the octoprint2.service has been added successfully and has been started, run systemctl as follows.

    systemctl status octoprint2.service

    That's it for the moment, if you don't get any errors it should work.

     

    Take a beer and make a break. But be aware, at this point, you will not be able to reach your new OctoPrint instance, therefore you need to configure HaProxy first.

    HaProxy Configuration

    OctoPi uses HaProxy as a reverse proxy for mapping and security reasons.

     

    If HaProxy is disabled and not used

    systemctl stop haproxy.service

    the web servers of the OctoPrint instances will be reachable on port 5000 and the second on port 5001 (e.g. http://<your pi's ip address>:5000)

    I don't recommend to disable HaProxy because you will lose a needful security barrier.

    In the newest version, to reach the instances over their ports, you have to remove the host from the daemon's arguments as described above.

    As said before, it is normally not necessary and not recommended reaching them over their ports.

     

    If you use multiple OctoPrint instances, and you want to make them reachable as a directory name instead of using a port, this can and must be done using HaProxy. Therefore, modify the /etc/haproxy/haproxy.cfg for your needs.

    First, make a backup of the original file.

    sudo cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.old

    Then open the config file.

    sudo nano /etc/haproxy/haproxy.cfg

    My haproxy.cfg looks like this and is configured for 3 printers also a SUNLU printer on port 5002:

    global
            maxconn 4096
            user haproxy
            group haproxy
            log /dev/log local1 debug
            tune.ssl.default-dh-param 2048

    defaults
            log     global
            mode    http
            compression algo gzip
            option  httplog
            option  dontlognull
            retries 3
            option redispatch
            option http-server-close
            option forwardfor
            maxconn 2000
            timeout connect 5s
            timeout client  15min
            timeout server  15min

    frontend public
            bind :::80 v4v6
            bind :::443 v4v6 ssl crt /etc/ssl/snakeoil.pem
            option forwardfor except 127.0.0.1
            use_backend mkc if { path_beg /mkc/ }
            use_backend anet if { path_beg /anet/ }
           use_backend sunlu if { path_beg /sunlu/ }
    use_backend webcam if { path_beg /webcam/ }
            use_backend webcam_hls if { path_beg /hls/ }
            use_backend webcam_hls if { path_beg /jpeg/ }
            default_backend webcam

    backend mkc
            acl needs_scheme req.hdr_cnt(X-Scheme) eq 0
            reqrep ^([^\ :]*)\ /mkc/(.*) \1\ /\2
            reqadd X-Scheme:\ https if needs_scheme { ssl_fc }
            reqadd X-Scheme:\ http if needs_scheme !{ ssl_fc }
            reqadd X-Script-Name:\ /mkc
            option forwardfor
            server octoprint1 127.0.0.1:5000
            errorfile 503 /etc/haproxy/errors/503-no-octoprint.http

    backend anet
            acl needs_scheme req.hdr_cnt(X-Scheme) eq 0
            reqrep ^([^\ :]*)\ /anet/(.*) \1\ /\2
            reqadd X-Scheme:\ https if needs_scheme { ssl_fc }
            reqadd X-Scheme:\ http if needs_scheme !{ ssl_fc }
            reqadd X-Script-Name:\ /anet
            option forwardfor
            server octoprint2 127.0.0.1:5001
            errorfile 503 /etc/haproxy/errors/503-no-octoprint.http

    backend sunlu
            acl needs_scheme req.hdr_cnt(X-Scheme) eq 0
            reqrep ^([^\ :]*)\ /sunlu/(.*) \1\ /\2
            reqadd X-Scheme:\ https if needs_scheme { ssl_fc }
            reqadd X-Scheme:\ http if needs_scheme !{ ssl_fc }
            reqadd X-Script-Name:\ /sunlu
            option forwardfor
            server octoprint3 127.0.0.1:5002
            errorfile 503 /etc/haproxy/errors/503-no-octoprint.http

    backend webcam
            reqrep ^([^\ :]*)\ /webcam/(.*)     \1\ /\2
            server webcam1  127.0.0.1:8080
            errorfile 503 /etc/haproxy/errors/503-no-webcam.http

    backend webcam_hls
            server webcam_hls_1 127.0.0.1:28126
            errorfile 503 /etc/haproxy/errors/503-no-webcam-hls.http

    For each backend, except for the webcam backend, it is important to define the correct X-Script-Name! I wasted a lot of time finding this necessary configuration parameter.

    When you have added all your backends and updated the backend list in your frontend configuration block, you can restart HaProxy or just wait and do the next and last step first.

     

    If you like to restart your second OctoPrint instance over the web interface, you need one more thing to change. Therefore, open OctoPrint's config file of the second instance.

    nano /home/pi/.octoprint2/config.yaml

    and change the service name in the restart command to octoprint2.

    serverRestartCommand: sudo service octoprint2 restart

     

    After a reboot, you should be able to connect to your two instances with

    http://<your pi's ip address>/mkc/
    http://<your pi's ip address>/anet/

    How to use a second webcam?

    The first webcam which is connected to the Rpi gets most of the time the device name /dev/video0 the second the device name /dev/video1 and so on.

    In the newest OctoPi version with the new Raspbian 10, they do a different video device handling than in the older version. I got 8 video devices even if there is no webcam or RaspiCam attached. For every new attached webcam (e.g. Logitech C270) I get 2 new devices. The first device is the video data and the second device provides meta data about the video data.

    If you are not sure about the naming of your webcams, check it with one of the following commands by using them before your webcam is attached and after it is attached to the RPi.

    ls /dev | grep "video*"
    ls -l /dev/v4l/by-id

    To test if you have found the correct device, start a mjpg_stream instance manually, but first, make sure that you have disabled all running webcamd services. Change /dev/videoX to the device you want to check (e.g. /dev/video0).

    sudo systemctl stop webcamd
    ./mjpg_streamer -o "output_http.so -w ./www-octopi -p 8080 -n" -i "input_uvc.so -d /dev/videoX -r 640x480 -f 10"

    If it works you should get a stream via VLC with this address.

    http://<your pi's ip address>:8080/?action=stream

    Setting udev rules for the webcam

    Now we ran into the same trouble as when we started connecting the different printers to the RPi. We have to create udev rules to get a device name which is the same every time we restart the RPi.

    To determine the differences we pipe the outputs to a file and use diff to get the differences. Be aware, that if your first attached webcam creates two devices, like video0 and video1 and your second webcam video2 and video3, you also have to find differences in the devices for the same camera. So first find differences from video0 (cam1) and video2 (cam2) then also find differences from video0 (cam1) and video1 (also cam1). The same for video2 (cam2) and video3 (also cam 2).

    udevadm info -a -n /dev/video0 > /home/pi/devVideo0
    udevadm info -a -n /dev/video1 > /home/pi/devVideo2
    diff -u /home/pi/devVideo0 /home/pi/devVideo2

    Then modify the 99-usb.rules file.

    cd /etc/udev/rules.d/
    sudo nano /etc/udev/rules.d/99-usb.rules

    and add the following two lines of code. Each line for each webcam we want to use. These two lines will only work in my case! You have to use attributes that differ in your case! Be careful with devpath attributes. Only use them if you find no other attributes that differ or if you know what you are doing!

    In my specific case, /dev/video0 (video data cam1) has an attribute serial which is not present in /dev/video1 (meta data cam1). The same occurs for /dev/video2 and /dev/video3 (cam2).  Also, the serial attributes from the two cameras differ, as you can see. Ideal for udev rules.

    SUBSYSTEM=="video4linux", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="0825", ATTRS{serial}=="69018540", ATTR{index}=="0", SYMLINK+="videoANET"
    SUBSYSTEM=="video4linux", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="0825", ATTRS{serial}=="C4898540", ATTR{index}=="0", SYMLINK+="videoMKC"

     

    Now we can start the default instance of Mjpg-Streamer with the device parameter -p /dev/videoMKC and a second instance with the device parameter -p /dev/videoANET. We can now make our settings in the daemon. First, make a backup of the first instance and a copy for the second instance.

    cd /root/bin/
    sudo cp /root/bin/webcamd /root/bin/webcamd.old
    sudo cp /root/bin/webcamd /root/bin/webcamd2
    sudo nano /root/bin/webcamd

    Because we use two daemons (for each camera one), we can no longer make our configuration in the /boot/octopi.txt file. We have to do the modifications directly in the daemon file but that's okay.

    You have 3 main options to get 1 camera per instance running, but be careful and do NOT use them at the same time!

    Surely there is a simpler and proper way out there.

    Take also care at this point, because every webcam configuration parameter which is set in the /boot/octopi.txt file will be used for every webcam daemon you start so the best is to do not add any camera configuration parameter to this file!

     

    1.) Let's look at the first one (recommended!)

    Be sure that the /boot/octopi.conf.d folder does not exist, or comment the directory check routine (begin of file) like this:

    #if [[ -d ${config_dir} ]]; then
    # cfg_files+=( `ls ${config_dir}/*.txt` )
    #fi

    Comment the "# add video device into options" in the startUSB() function.

    # add video device into options
    #options="$options -d /dev/$device"

    Now we add the -d parameter and the device to the camera_usb_options variable and the port parameter to camera_http_options. This then looks like this:

    camera_usb_options="-d /dev/videoMKC -r 640x480 -f 10"
    camera_http_options="-p 8080 -n --listen 127.0.0.1"

    We also make the changes in the file of the second webcam daemon.

    sudo nano webcamd2

    The modified file looks like this:

    camera_usb_options="-d /dev/videoANET -r 640x480 -f 10"
    camera_http_options="-p 8081 -n --listen 127.0.0.1" 

     

    2.) This second one uses a config file for each webcam, created in /boot (also recommended!).

    sudo nano /boot/cam-mkc.txt

    Add the camera configuration to this file.

    camera="usb"
    camera_usb_options="-d /dev/videoMKC -r 640x480 -f 10"
    camera_raspi_options="-fps 10"
    camera_http_webroot="./www-octopi"
    camera_http_options="-p 8080 -n --listen 127.0.0.1"

    Change the config files path to your newly created file in the webcamd daemon.

    cfg_files+=/boot/cam-mkc.txt

    Also, comment the "# add video device into options" in the startUSB() function.

    # add video device into options
    #options="$options -d /dev/$device"

    Don't forget to do the same for the second webcamd2 daemon.

     

    3.) The third one uses another approach (NOT recommended ATM). Here, we also use a config file for the camera. This method will work but during the first start of the service, the script possibly also tries to start other cameras, which leads to a nasty delay and an error during the startup, but it will work for the specified camera!

    You also need to comment the "# add video device into options" in the startUSB() function.

    # add video device into options
    #options="$options -d /dev/$device"

    Now create the /boot/octopi.conf.d directory if it not already exists

    sudo mkdir /boot/octopi.conf.d

    Also, create a config file with *.txt extension for your webcam in this new directory

    sudo nano /boot/octopi.conf.d/mkc.txt

    and add your camera config like this

    camera="usb"
    camera_usb_options="-d /dev/videoMKC -r 640x480 -f 10"
    camera_raspi_options="-fps 10"
    camera_http_webroot="./www-octopi"
    camera_http_options="-p 8080 -n --listen 127.0.0.1"

    For the second instance, you need to create a second directory and another config file in this new directory, like for the first instance.

    sudo mkdir /boot/octopi2.conf.
    sudo nano /boot/octopi2.conf.d/anet.txt

    and add your camera config

    camera="usb"
    camera_usb_options="-d /dev/videoANET -r 640x480 -f 10"
    camera_raspi_options="-fps 10"
    camera_http_webroot="./www-octopi"
    camera_http_options="-p 8081 -n --listen 127.0.0.1"

    and change the directory path in the webcamd2 daemon.

    config_dir="/boot/octopi2.conf.d"

     

     

    In this newer version, webcamd runs as a pure service, so we must treat it like one.

    At first, copy the existing webcamd.service

    sudo cp /etc/systemd/system/webcamd.service /etc/systemd/system/webcamd2.service

    and modify its content

    sudo nano /etc/systemd/system/webcamd2.service

    to the following

    [Unit]
    Description=the OctoPi webcam2 daemon with the user specified config
    ConditionPathExists=/etc/octopi_streamer/mjpeg

    [Service]
    WorkingDirectory=/root/bin
    StandardOutput=append:/var/log/webcamd2.log
    StandardError=append:/var/log/webcamd2.log
    ExecStart=/root/bin/webcamd2
    Restart=always
    Type=forking
    RestartSec=1

    [Install]
    WantedBy=multi-user.target

     

    You are ready to test the service.

    sudo systemctl start webcamd2

    If you want to check the status of the service.

    sudo systemctl status webcamd2

    We also want that this service starts automatically during booting

    sudo systemctl enable webcamd2

     

    Another step follows :) ... We have to make the new instance visible behind HaProxy.

    sudo nano /etc/haproxy/haproxy.cfg

    and add a new backend at the end of file

    backend webcam2
    reqrep ^([^\ :]*)\ /webcam2/(.*) \1\ /\2
    server webcam2 127.0.0.1:8081
    errorfile 503 /etc/haproxy/errors/503-no-webcam.http

    and a new line under "frontend public"

    use_backend webcam2 if { path_beg /webcam2/ }

    restart HaProxy

    sudo systemctl restart haproxy.service

    and your webcam should be reachable under http://<your pi's ip address>/webcam2/

     

    To use the second webcam stream directly in your OctoPrint web-interface, you also have to adapt the stream path

    /webcam2/?action=stream

    in your OctoPrint Webcam & Timelapse settings.

     

    If you want to create an instance for a third printer or webcam, just repeat the steps for the second one.

    An alternative approach would be to use a script which makes all the above steps automatically.
    A script which does exactly this can be found here: https://github.com/paukstelis/octoprint_deploy

    Comments powered by CComment

    Thomas Walter Messmer Logo

    Thomas Walter Messmer QRCode

    Latest Articles

    • Tasmota Custom WebUI and CSS Style
    • Smart Meter Sensor with Tasmota
    • Crypto Wallet Recovery
    • 137 MHz BP Filter and Noise Source analysed with RTL-SDR Dongle
    • ROS Melodic on Raspberry Pi 3+
    • Instructions, manuals and datasheets for rare or old devices
    • How to switch on and off your 3d printer with your Raspberry Pi
    • Setting up OctoPrint on a Raspberry Pi for multiple printers
    • Product Image Requirements
    • Smoke detector to shutdown 3D printer

    Hot Spot

    • Setting up OctoPrint on a Raspberry Pi for multiple printers
    • Autokonzerne und deren Automarken
    • S-VHS Videorecorder und die Digitalisierung
    • RetroPie Controller Pairing Problems
    • Restauration von VHS Material mit VirtualDub, AviSynth und QTGMC, AvsP und WinFF

    What the Tag

    • Software 9
    • Raspberry Pi 4
    • AtMega 4
    • Motor 4
    • Robot Operating System 3
    • Raspberry 3
    • Problem 3
    • 3dprinter 3
    • printer 3
    • Robot 2

    BuyMeACoffee

    Automatic Translation

     

    Copyright © 2025 Thomas Messmer's Blosite. Alle Rechte vorbehalten.
    Joomla! ist freie, unter der GNU/GPL-Lizenz veröffentlichte Software.
    www.template-joomspirit.com
    Back to top
    Wir benutzen Cookies

    Wir nutzen Cookies auf unserer Website. Einige von ihnen sind essenziell für den Betrieb der Seite, während andere uns helfen, diese Website und die Nutzererfahrung zu verbessern (Tracking Cookies). Sie können selbst entscheiden, ob Sie die Cookies zulassen möchten. Bitte beachten Sie, dass bei einer Ablehnung womöglich nicht mehr alle Funktionalitäten der Seite zur Verfügung stehen.

    Akzeptieren Ablehnen
    Datenschutzerklärung | Impressum