Open source firmware for the BIQU Panda Vent for Bambu P2S that has all the original features
plus many more to truly customize your vent system. 24 languages supported.

_{PandaVentOS is not affiliated with, endorsed by, or supported by BIQU or BIGTREETECH.
It is a reimplementation, not a modification of their firmware. "Panda Vent" is used only to name the hardware it runs on.}

• What Makes It Different
• Features
  • Lighting
  • Venting
  • Printer
  • Device
• Languages
• Screenshots
• What It Does Not Do
• Requirements
• Installation
  • Back Up First
  • First Install, By Hand
  • Updating, Over The Network
  • Going Back
• First Time Setup
• Settings Migration
• Documentation
• Project Layout
• Testing
• License

PandaVentOS reimplements what the factory application does, from its observed behaviour, and then goes past it. It is not a modified copy of BIQU's firmware and shares no code with it. The stock partition layout is untouched, so one upload puts the factory firmware back whenever you want it.

Why the fans and the speed are not there. They were, they worked, and the printer threw every one of them away. Measured on real hardware, one command at a time, on one connection: ledctrl comes back result: success and every gcode_line and print_speed comes back mqtt message verify failed.

The printer says so itself, in the fun field of its own report: bit 0x20000000 means unsigned commands are rejected. That needs Developer Mode, which is a separate switch underneath LAN Only Mode in the printer's network settings and only appears once LAN Only Mode is on and the printer has restarted.

A control that cannot work is worse than no control, so the ones that cannot are not offered. If your printer is in Developer Mode the firmware still speaks every one of those commands; only the web page stopped drawing them.

Twenty four, every one of them at full coverage. There is no partial translation: a language ships when all 402 strings are in it. A string that is somehow missing falls back to English rather than showing a raw key.

Arabic is right to left. The whole layout mirrors, not just the text.

Pick a language on first boot, or change it any time from the Settings page.

Dashboard, light	Dashboard, dark

Lighting	Camera

Settings	On a phone

• It does not control the printer beyond its lights. Everything under the printer's print command namespace is signature checked and refused, which its own firmware confirms; only the chamber and work lights are accepted. So no print speed, no fan control, no pause or resume from here.
• It reads the printer over the LAN only. The printer has to be in LAN Only Mode and reachable on the same network. There is no cloud path. Reading itself is never gated: every value arrives whatever mode the printer is in. Developer Mode is only about what the printer will accept, and the one write that gets through without it is the lights.
• It does not know where the flap is. There is no position encoder. The hall sensor's end bands are the limit switches, the same as stock, so the vent knows "open" and "closed" and nothing between them.
• It does not stop a jammed flap quickly. A group that misses its band is abandoned after about eight hundred milliseconds and latches a fault; there is no travel timeout beyond that.
• It is one flap, up to four motor groups, and two LED strips. Nothing here scales past the hardware it was written for.
• No warranty of any kind. Flashing third-party firmware can void yours. Read firmware/SAFETY.md and take the full backup it asks for.

There is a script, and it takes a backup before it writes anything.

git clone https://github.com/jeremykenedy/PandaVentOS.git
cd PandaVentOS
tools/install.sh

Any failure before step 5 leaves the device untouched. The backup is not optional and there is no flag to skip it.

If you would rather do it by hand, this is the part that matters. The whole 4 MB, offset 0 to 0x400000, including the bootloader, partition table, otadata, both app slots and NVS. BIQU publishes only the app image, so if you lose the bootloader there is nothing public to put back.

python3 -m esptool --chip esp32 --port <YOUR-PORT> -b 115200 \
  read-flash 0 0x400000 golden-full-4MB.bin

Read firmware/SAFETY.md before the first flash. It is short, and every rule in it is there because skipping it cost somebody a working vent.

The first install onto a vent still running BIQU's firmware needs a cable, once. It is not a preference. An OTA can only drop an application into a partition slot that already exists; it cannot write the bootloader or the partition table, so the image has to land at exactly the address it was linked for, and nothing the stock firmware serves will tell you where its slots are. A cable install writes the bootloader, the partition table and the app together, which is what makes every later update wireless.

It is also the only way to take a full 4 MB backup of a stock unit: stock has no /backup endpoint, so until this has been done once there is no image of that device anywhere.

cd firmware
idf.py build
idf.py -p <YOUR-PORT> flash

or tools/install.sh --port <YOUR-PORT>, which takes the 4 MB backup first and refuses to continue without it.

After this, never again: see Updating, Over The Network.

Every later update is a single upload. No cable.

tools/install.sh --network <device-ip>

That takes a fresh backup over the network first, then uploads, then waits for the device to come back. By hand it is:

curl -X POST -H 'OTA-Type: ota_fw' \
  --data-binary @firmware/build/pandaventos.bin \
  http://<device>/ota

Settings are migrated forward automatically.

tools/restore.sh --factory-bin <stock.bin> --factory <device-ip>      # over the network
tools/restore.sh --factory-bin <stock.bin> --factory --port /dev/...  # over a cable
tools/restore.sh --image <your-backup.bin>                            # your own 4 MB image, cable only
tools/restore.sh --list                                               # what backups you have

--factory puts BIQU's application image back. That image is theirs and is not redistributed here, so you supply your own copy with --factory-bin or PV_FACTORY_BIN; the script checks its size and prints its SHA-256 against the one this was tested with before it writes anything.

It does not restore your settings: the stock firmware does not understand this one's configuration and replaces it with its own defaults.

--image writes a full 4 MB image taken off your own device, which is the only thing that recovers a device that will not boot.

The stored configuration has changed shape several times. Every older layout is read and lifted forward field by field, so updating never asks you to set the device up again. tools/cfgmig runs a real stored blob through the real migration so that claim can be tested rather than believed.

The configuration lives in a 12 KB NVS partition shared with the Wi-Fi stack, and PV_CFG_MAX_BYTES fails the build if it grows past its budget. That check exists because the config once outgrew the partition, saves began failing, and a reboot lost everything. It cannot happen quietly again: a failed save is reported in the state document and shown on the page.

Every setting, what it does, and why it is there.

Released under the MIT license. The full text is in LICENSE.md.