mikecarper
6d6c89e411
Add selectable shared ESP-NOW channels, raw/wrapped bridge compatibility, and bounded fragmentation for maximum-size packets.\n\nGive ESP32 Full profiles WiFi coexistence, stabilize WebConfig and USB terminal lifecycles, and keep disabled bridges stopped during observer updates.\n\nUpdate generated UI, firmware selection, documentation, and regression coverage.
13 KiB
Firmware picker
Pick the choices in any order. Every selection narrows all the other controls to firmware combinations that were actually built in the current release set.
The picker reads public release metadata from GitHub. It does not upload device information. Hardware names, target names, and download links come directly from the published firmware assets.
Loading release information...
For a new installation, choose the exact board and role, prefer a FULL / complete profile when it is available, and select Erase & fresh install (merged .bin). Narrower profiles remain available when their reduced transport or feature set is intentional.
Pick in any order. Use Any to clear one choice, or clear everything with the button below.
<div class="firmware-picker-control firmware-picker-select-control" data-role="hardware-variant-control" hidden>
<label for="firmware-picker-hardware">Hardware variant</label>
<select id="firmware-picker-hardware" data-field="hardware" disabled>
<option value="">Choose hardware first</option>
</select>
</div>
<fieldset class="firmware-picker-control firmware-picker-radio-control firmware-picker-wide" data-radio-field="install" disabled>
<legend>Install operation</legend>
<div class="firmware-picker-radio-options" data-field="install">
Loading install choices...
</div>
</fieldset>
<fieldset class="firmware-picker-control firmware-picker-radio-control" data-radio-field="role" disabled>
<legend>Firmware role</legend>
<div class="firmware-picker-radio-options" data-field="role">
Loading roles...
</div>
</fieldset>
<fieldset class="firmware-picker-control firmware-picker-radio-control" data-radio-field="logging" disabled>
<legend>Logging / MQTT</legend>
<div class="firmware-picker-radio-options" data-field="logging">
Loading logging choices...
</div>
</fieldset>
<fieldset class="firmware-picker-control firmware-picker-radio-control" data-radio-field="ota" disabled>
<legend>OTA capability</legend>
<div class="firmware-picker-radio-options" data-field="ota">
Loading OTA choices...
</div>
</fieldset>
<div class="firmware-picker-control firmware-picker-select-control">
<label for="firmware-picker-mode">Connection / bridge mode</label>
<select id="firmware-picker-mode" data-field="mode" disabled>
<option value="">Loading modes...</option>
</select>
</div>
<fieldset class="firmware-picker-control firmware-picker-radio-control" data-radio-field="feature" disabled>
<legend>Feature profile</legend>
<div class="firmware-picker-radio-options" data-field="feature">
Loading profiles...
</div>
</fieldset>
<div class="firmware-picker-control firmware-picker-select-control">
<label for="firmware-picker-variant">Firmware variant</label>
<select id="firmware-picker-variant" data-field="variant" disabled>
<option value="">Loading variants...</option>
</select>
</div>
<div class="firmware-picker-form-actions firmware-picker-wide">
<button type="reset" data-action="clear" disabled>Clear all choices</button>
</div>
Exact firmware match
Recommended download
No exact firmware matched
Browse all firmware releasesAdvanced: search current release filenames
Use this for uncommon board suffixes or expert recovery. A filename match is not a board-identity check.
Filename containsWhat the choices mean
| Choice | Use |
|---|---|
| Companion | A phone, computer, or host application controls the radio |
| Repeater | Standalone mesh relay |
| Room Server | Hosts room conversations and history |
| Sensor / telemetry | Publishes supported sensor data |
| Terminal Chat | Standalone serial-terminal interface |
| USB logging / USB-connected MQTT | Node remains attached to a computer over a data-capable USB cable |
| Wi-Fi MQTT observer | Firmware connects directly to MQTT over Wi-Fi; this is not USB logging |
| USB logging + Wi-Fi MQTT | Unified FULL image sends to both paths; avoid two publishers aimed at the same broker unless messages are deduplicated |
| No logging | Normal standalone operation without the dedicated logging/MQTT profile |
| LoRa OTA enabled / receiver | Install-capable profile that can stage an exact matching update received over LoRa |
| LoRa OTA source only | Full Companion serving a host-supplied update to another node without self-installing it |
Connection and bridge choices depend on the selected role. Companion firmware
may offer Full, combined USB + Bluetooth, Bluetooth, USB, Wi-Fi, serial, or
Ethernet transports.
Normal repeater firmware includes runtime-controlled RS-232 support where the
board has room; use set bridge.enabled on after configuring bridge.uart and
bridge.baud. The Wio-E5 remains the capacity exception and offers a separate
RS-232 image. Repeaters may also offer separate ESP-NOW, Ethernet, or MQTT
observer modes.
An ESP-NOW bridge target keeps LoRa as its primary mesh radio. Its runtime
bridge.format setting chooses the peer protocol: wrapped (the
backward-compatible bridge-to-bridge default using bridge.secret) or raw
(direct MeshCore ESP-NOW LR frames for Generic_ESPNOW,
SenseCapIndicator-ESPNow, and other primary-ESP-NOW nodes). This is one
firmware choice, not two board images. Match bridge.channel to the primary
nodes' espnow.channel before selecting set bridge.format raw.
For Heltec V4 specifically, companion_radio_full is still a LoRa-primary
Companion; choose the existing heltec_v4_repeater_bridge_espnow firmware to
make that board the LoRa/ESP-NOW gateway. Use its exact merged artifact when
changing roles or partition layouts.
FULL versus standard
For a new installation, use the FULL / complete profile when it exists and the board has enough flash. FULL profiles keep the complete supported feature set and CLI. Standard profiles remain useful for boards without a FULL build, for an intentionally narrower transport, or when retaining an existing compatible partition layout.
Changing between standard and FULL ESP32 layouts requires the exact-board merged image over USB. A running application cannot safely move its own active and inactive partitions.
Current full-usb-wifi profiles use one binary for no external output, USB
packet logging/USB-connected MQTT, direct WiFi MQTT, or both. The picker shows
that same exact binary for each compatible logging choice; select the saved
runtime mode with set logging.output off|usb|wifi|both. A FULL logging-fallback
profile is listed only when no WiFi MQTT sibling exists; it appears for both
the no-output and USB choices because set usb.logging off|on is persistent.
On a fresh unified FULL install with no saved SSID, the setup AP and WiFi radio
remain available for 30 minutes per boot, then turn off automatically until the
next reboot or power cycle. An explicit administrator start webconfig remains
available as an override. A saved SSID switches to the normal indefinite
reconnect behavior instead.
Full Companion profiles use one binary for USB, BLE, ordinary Wi-Fi on ESP32,
source-only LoRa OTA, Terminal Chat, optional USB packet logging, and any
board-qualified serial or Ethernet Companion transport. Bulk builds therefore
omit separate attached-transport, Terminal Chat, and USB-logging artifacts
whenever the exact Full recipe exists. RAK4631 repeater and room-server
Ethernet images remain separate roles. Fresh installs default to logging off.
Heltec V3 and base OLED V4 Full images also contain the former direct Wi-Fi
MQTT Companion capability, configured at runtime through WebConfig, so their
separate companion_radio_wifi_mqtt artifacts are omitted from canonical
builds as well.
When Full Companion does not fit but a matching USB Companion does, that USB
artifact also supplies Terminal Chat and replaces its standalone release image.
Heltec E290 and T190 now publish one Full USB + BLE + WiFi Companion; their old
combined and single-transport names are explicit-build compatibility aliases.
SSD1306 Full Companion builds use set display.rotation 90|180|270; 0
restores the board default, so a separate rotated release image is not
recommended.
Ordinary non-OTA roles also use one artifact for normal operation and USB
logging. Select the saved mode with set usb.logging off|on; no -logging-
artifact is emitted. KISS, BLE-only Companion, and constrained LoRa-OTA
receiver images retain their protocol/partition contracts and do not inherit
plaintext USB logging.
nRF52 Full Companion keeps the multi-role primary interface on 00; it starts
as an ASCII terminal and automatically hands a complete < frame to Binary
Companion. set usb.logging on reboot adds its plaintext interface 02.
Every ESP32 Full Companion instead exposes one USB TTY. Logging is off by
default, so the TTY serves the ASCII/Binary Companion switcher. Use
set usb.logging on to turn that same TTY into an input-capable plaintext
CLI/logging stream; framed Binary Companion is unavailable on USB while
logging owns it. set usb.logging off stops the logs and leaves the TTY in
the normal ASCII terminal, matching a fresh Full installation. Send
+++MESHCORE-TERM-STOP, or let a Companion app send a valid framed probe, to
switch from there to Binary Companion. BLE and Wi-Fi Companion remain usable
while the USB TTY is logging. ESP32 Full builds use the repository's
Arduino-ESP32 2.x base where the board supports it; RC32 and ESP32-C6 retain
their board-required Arduino 3.x platform but still expose only one USB TTY.
A second ESP32 CDC interface is not part of the release profile.
Installation methods
| File | Use |
|---|---|
-merged.bin |
Erase/fresh install, recovery, role migration, or partition-profile change on ESP32 over USB |
Non-merged .bin |
Update an existing same-board, same-role, same-partition installation |
.zip |
Native nRF52 Serial DFU update package; it is not an extra archive |
.uf2 |
UF2 bootloader drag-and-drop install or update |
.hex |
Erase/recovery flash with a supported wired programmer |
Never send a merged ESP32 image through browser OTA or LoRa OTA. Back up the node configuration and verify every filename suffix before flashing.
LoRa OTA and OTAFIX
An OTA receiver build installs the receiving/staging firmware. A later LoRa update still needs an exact target identity, compatible partition signature, matching radio settings, and the correct update package.
nRF52 LoRa OTA requires an OTAFIX bootloader built for the exact board. There is no universal bootloader file. Use the latest stable OTAFIX release and select the hardware-matched HEX, Serial DFU ZIP, or bootloader-update UF2.
Hardware and variant names
Hardware families with multiple released targets get a second hardware-variant menu. It separates revisions, display type, expansion kit, radio/PA layout, pin map, and other physical differences without crowding the first menu. The firmware-variant menu separately exposes choices that still require different code or wiring, such as serial port or no-external-sensors. Companion power saving, controllable FEM receive gain, and radio-chip receive gain are saved settings rather than separate recommended firmware files. Do not substitute a similarly named physical target.
The picker recommends one Full Companion image instead of separate USB, BLE,
ordinary WiFi, and USB-logging images. On ESP32, logging is off by default so
the one USB TTY starts in ASCII and automatically changes to framed Companion
when a complete < frame arrives. Enabling logging gives that TTY to the
plaintext CLI/logger and disables framed USB Companion until logging is turned
off and the normal ASCII-to-binary mode switch occurs. nRF52 Full Companion
retains its optional dedicated interface 02.
Exact filename search still finds old aliases from earlier releases.