Updating the brain, the toolchain and the fleet firmware

The routine order: brain first, then the ESPHome toolchain if offered, then firmware with a canary. Ethernet gates, refusals, rollback and the SSH fallbacks.

Settings › Devices › Firmware › Updates → Check for updates. Needs Ethernet: the brain reads the latest published release from plausible-deniability.net (a small public manifest — the source repository is private, so kits no longer ask GitHub) and compares it with the running brain and each device's firmware. Offline kits keep the baked version and say so. Update DSC-Brain runs the self-update command configured on the Pi. If the card shows a manual instruction instead, this image has no self-update command: update from a workstation with the deploy script, or by hand over SSH (table below). The brain restarts and the page reloads on the new bundle; confirm the version on About.

Product libraries. DSC-KitLib (lights, equipment) and DSC-NuteLib (nutrients, feed charts, growing media) update separately from the brain, under Settings › Integrations › Libraries. The brain reads the library manifest daily; Check for updates reads it now. Install vX downloads the file, checks its size and checksum and swaps it in without a restart; Back to vX returns to the version it replaced. Install updates automatically is off by default. A release that needs a newer brain says so and is not offered.

Settings › Devices › Firmware shows installed vs latest vs pinned min. Update ESPHome → x.y.z hands the job to the host helper, which installs the version and restarts the ESPHome dashboard; the card streams the log. It is refused when offline, when the target is below the pin, when the target is already installed, under 1.5 GiB free, or while a build job is running. Roll back to X reinstalls the version the last successful change came from. A newer ESPHome the firmware cannot yet build on shows Newer ESPHome held back.

Same card. Canary Probe 2 first compiles and flashes one probe over the air. Wait for Canary OK (the probe reports the new version). Then Release the rest (N, hub last); each device is compiled and flashed in turn by the build worker. Reflash whole fleet is the one-click path. A failed job stops the queue at that seat (Probe update failed); fix it from the job log or Logs ↗ in the ESPHome dashboard and re-queue just that seat.

Devices › Firmware: every row on the expected stamp and online. Overview fleet chip ok. Kit › Inventory all in-service devices online.

• Toolchain: Roll back to X, or the pip command below.
• Firmware: re-queue the seats after rolling the toolchain back; the same YAML on the previous ESPHome reproduces the previous binary. Hub and panel must keep a matching ESP-NOW command tag.
• Brain: every brain deploy leaves a rollback point under /opt/dsc-hub-rollback/<time>/ — the previous image tagged dsc-hub-brain:rollback-<time>, its source, its dashboard entry and a ROLLBACK.txt with the two commands that bring it back (the five newest are kept). Or Settings › System › Backup › Import the last export.

All of these need the kit's firmware secrets file on the Pi (/opt/dsc-hub/firmware/v4/secrets.yaml, mode 0600). The Firmware card shows No firmware secrets when it is missing.

The toolchain lives in the dsc user's venv. Running it as root creates root-owned build caches that later break the dashboard's builds.

Guide contents  ·  Maintenance & updates  ·  Troubleshooting  ·  Digital Stealth Care

DSC-Brain user guide · Updating the brain, the toolchain and the fleet firmware · this page is edited on the site; the Notion original was retired after the mirror