Flash the Klingelbox firmware onto an ESP32-S3 straight from this page — no ESP-IDF, no Python, nothing installed. Die Klingel, lokal und ohne Cloud.
Release images are mirrored into this site by CI, because GitHub's own release downloads cannot be fetched by a web page. Every download is checked against its published size and SHA-256 before a single byte is written to your board.
For self-built images — including the 4 MB ESP32-S3 Zero build, which you produce with SDKCONFIG_DEFAULTS="sdkconfig.defaults;sdkconfig.defaults.4mb". A merged image (klingelbox-esp32s3-full.bin) goes at 0x0. The app-only image (klingelbox.bin) and the web-UI image (storage.bin) must never be flashed at 0x0 — they are OTA payloads, meant for POST /api/ota and POST /api/ota/webui. When in doubt, use a merged image at 0x0. Local files carry no checksum, so nothing can be verified for you here.
Plug the board's native USB port (USB-Serial/JTAG) into this computer with a cable that carries data — a charge-only cable shows no port at all. If the board does not appear in the port list, force the ROM bootloader (the "BOOT dance"):
Blanks the entire chip — firmware, Wi-Fi credentials, MQTT settings, every learned signal and the whole node graph are gone for good. Useful when a board is in a state you no longer trust. The chip itself cannot be bricked by this: its ROM bootloader is in mask ROM and is permanent, so a blank chip always comes back in download mode and can be reflashed here.
Either the cable is charge-only, or the board is not in download mode. Try a different USB cable first — it is the single most common cause. Then redo the BOOT dance above. On Linux, your user also needs access to the device node (typically membership of the dialout group, then log out and back in).
The board is powered but not listening. Redo the BOOT dance and press Connect & flash again. If another program holds the port — a serial monitor, the Arduino IDE, idf.py monitor, ESPHome — close it: only one process can own a serial port at a time.
The download did not arrive intact, so the page refused to write it. That is the intended behaviour — a truncated image at offset 0x0 leaves a board that cannot boot and cannot tell you why. Reload the page (bypassing the cache with Ctrl/Cmd+Shift+R) and try again.
Check that BOOT is not still held or jammed — see the warning above; that keeps the chip in the ROM download loader forever. Otherwise unplug and replug the cable. If it still does nothing, attach a serial monitor at 115200 baud and read the boot log; a wrong image for the board (a 16 MB image on a 4 MB ESP32-S3 Zero, say) shows up there as a partition-table or SPIFFS mount failure.
No. The ESP32-S3's first-stage bootloader lives in mask ROM and cannot be overwritten, so whatever is (or is not) in flash, the BOOT dance always brings the chip back into download mode. There is no sequence on this page that makes a board unrecoverable.