Include runtime ESP-NOW in Full ESP32 repeaters

docs/cli_build_matrix.md

@@ -110,7 +110,7 @@ getters; relaying a command over LoRa keeps its remote restrictions.
 | nRF52 repeater/room-server/sensor release pair | `full-ota` retains the complete supported sensor recipe; `reduced-ota` omits declared optional sensor drivers. Both include verified LoRa OTA, use the same logical target identity and exact storage/layout contract within the pair, and retain the role's normal commands. Repeaters/room servers also verify `retry.preset`. RAK3401 and RAK4631 reduced builds retain GPS where compatible and INA219/INA226/INA260/INA3221 I2C voltage/current monitors. External QSPI/SD targets also publish both choices. Companion/Terminal Chat and KISS roles do not enter this policy. |
 | ESP32 MQTT observer or ESP-NOW bridge | Always uses the expanded FULL partition profile. The build never substitutes a reduced CLI to fit the legacy application slot. |
 | FULL ESP32 USB + WiFi | Uses the matching MQTT target with packet logging, USB debug defaulting off, and the complete command surface supported by that role and hardware. Debug verbosity can be enabled only for diagnostics compiled into that image. `get/set logging.output off\|usb\|wifi\|both` selects and persists the active output paths; `get/set usb.debug` separately saves USB verbosity. |
-| FULL ESP32 logging fallback | Uses the matching non-MQTT target only when no WiFi MQTT sibling exists, with debug and packet support compiled and the complete command surface supported by that role and hardware. USB debug defaults off; `get/set usb.debug` selects verbose output independently of packet capture. Its persistent USB master also covers output-off operation, avoiding a second FULL ESP-NOW image. |
+| FULL ESP32 logging fallback | Uses the matching non-MQTT target when no compatible MQTT sibling exists, preserving its hardware and role CLI. Full LoRa repeaters also include runtime ESP-NOW with `set espnow.enabled on\|off` and `get espnow.running`; newly combined modes default off. Dedicated images remain only for measured capacity exceptions. USB debug defaults off; `get/set usb.debug` selects verbose output independently of packet capture. |
 | nRF52 dual-CDC Full Companion | Fresh installs expose only interface `00`; it starts as an ASCII terminal and automatically hands a complete `<` frame to framed Companion. The same interface also carries exclusive serial mOTA traffic. `set usb.logging on reboot` adds output-only interface `02` for ASCII RAW/RX/TX records and optional debug. Alternatively, `set usb.logging stream reboot` keeps CLI replies and packet records on interface `00` for unmodified one-port serial bridges; Binary Companion and serial mOTA require logging off on that port. BLE and source-only LoRa OTA remain available. `get/set usb.logging` persistently controls whether the logging interface is present; `get/set usb.debug` changes verbosity without a reboot. Send CLI/control queries to interface `00`, not the log endpoint. |
 | ESP32 single-TTY Full Companion | Every ESP32 Full image starts with the ASCII terminal on its one USB TTY and automatically hands a complete `<` frame to framed Companion. On 1.17.1.5, run `set powersaving off` first. `set usb.logging on` switches that TTY to an input-capable plaintext RAW/RX/TX logging terminal and makes framed Companion unavailable on USB; `set usb.logging off` stops logging but leaves the TTY in normal ASCII mode. `get/set usb.debug` separately controls saved verbose diagnostics, defaulting off. The terminal stop token or a valid incoming framed probe then performs the ordinary switch to Binary Companion. A saved logging-on setting starts directly in that logging terminal and disables automatic frame detection. BLE, WiFi, and source-only LoRa OTA remain available. ESP32 Full uses Arduino-ESP32 2.x where supported; RC32 and ESP32-C6 keep their board-required Arduino 3.x platform but still expose only one TTY. |
 | `no_external_sensors` | Trims selected optional environmental/ranging drivers and their settings; it does not remove generic I2C, core repeater discovery, routing, or runtime RS-232 commands. RAK3401 and RAK4631 profiles retain the four common INA I2C voltage/current monitors. GPS-preserving RAK nRF52 OTA profiles retain their GPS commands and provider; RAK4631 defaults the bridge to UART 2 because RAK12501/L76K GPS uses UART 1. Legacy target suffixes remain stable for OTA identity compatibility. |

docs/espnow_bridge_setup.md

@@ -11,10 +11,13 @@ LoRa network A <--> Repeater A <-- ESP-NOW --> Repeater B <--> LoRa network B
 
 ## 1. Choose the firmware
 
-Install the exact board's **Full ESP-NOW bridge repeater** image on each board.
-The target name ends in `_repeater_bridge_espnow`; a standard Heltec V4 uses
-`heltec_v4_repeater_bridge_espnow`. Full/MQTT and Full Companion images are
-different choices. See the [firmware picker guide](firmware_picker.md).
+Install the exact board's **Full repeater** image on each board. ESP-NOW is
+included as a runtime transport on supported ESP32 Full repeaters. Newly
+combined ordinary repeaters leave it off until explicitly enabled; that
+choice is saved across reboot. Boards with measured capacity exceptions keep
+separate `_repeater_bridge_espnow` images. Historical dedicated target names
+remain available for direct builds with their original bridge-on defaults.
+Full Companion is a different role. See the [firmware picker guide](firmware_picker.md).
 
 Open each board's [USB console](https://flasher.meshcore.io/console) at
 115200 baud and run:
@@ -23,8 +26,10 @@ Open each board's [USB console](https://flasher.meshcore.io/console) at
 get bridge.type
 ```
 
-The answer must be `espnow`. `mqtt`, `rs232`, or `none` means that image does
-not provide the ESP-NOW bridge described here.
+The answer can be `espnow`, `mqtt+espnow`, or `rs232+espnow`. Confirm the
+independent ESP-NOW control is present with `get espnow.enabled` and
+`get espnow.running`. The `espnow` commands select this transport without
+changing another bridge in a combined image.
 
 ## 2. Set each board's LoRa network
 
@@ -33,7 +38,7 @@ the radio settings used by the network on that board's side. Use `Bridge-A`
 for the first board and `Bridge-B` for the second, or choose your own names.
 
 ```text
-set bridge.enabled off
+set espnow.enabled off
 set name Bridge-A
 set radio <freq>,<bw>,<sf>,<cr>
 reboot
@@ -60,14 +65,14 @@ case-sensitive secret on each board, using 1-15 characters. Channel `6` is
 an example; both boards must use the same channel.
 
 ```text
-set bridge.enabled off
+set espnow.enabled off
 set bridge.channel 6
 set bridge.format wrapped
 set bridge.secret YourSharedKey
 set bridge.source tx
 set bridge.delay 500
 set repeat on
-set bridge.enabled on
+set espnow.enabled on
 ```
 
 These settings are saved across reboot. Bridge changes apply immediately;
@@ -78,15 +83,15 @@ Stopping it first lets you finish configuring both sides before connecting them.
 
 | Option | Choices and purpose |
 | --- | --- |
-| `bridge.enabled` | `on` starts the bridge; `off` stops it and keeps its saved settings. |
+| `espnow.enabled` | `on` starts ESP-NOW; `off` stops it and keeps its saved settings. Independent of MQTT or RS-232. |
 | `bridge.channel` | The 2.4 GHz channel, 1-13. Match it on both boards. This is separate from the LoRa frequency in `set radio`. |
 | `bridge.format` | `wrapped` is the default for this two-repeater setup and uses the shared secret. `raw` connects to primary-ESP-NOW nodes such as `Generic_ESPNOW` or `SenseCapIndicator-ESPNow`; it ignores the secret. Both peers must use compatible formats. |
 | `bridge.secret` | A matching, case-sensitive value of 1-15 characters for `wrapped` mode. It separates bridge groups; it is not strong encryption. MeshCore's own message encryption remains in place. |
 | `bridge.source` | `tx` crosses packets this repeater transmits on LoRa, after its forwarding decisions; use this for the setup above. `rx` crosses received packets before those decisions and can pass traffic the local repeater would not forward. |
 | `bridge.delay` | Wait before processing a packet received from the other bridge, in milliseconds. Range: 0-10000. Start with the default `500`. |
 | `repeat` | `on` enables normal LoRa forwarding; `off` disables forwarding. Keep it `on` on both bridge repeaters. Normal routing, scope, and packet-filter rules still apply. |
-| `bridge.type` | Read-only firmware capability. It must report `espnow` for this guide. |
-| `bridge.running` | Read-only runtime state. `on` means the local bridge started; it does not prove the other board is reachable. |
+| `bridge.type` | Read-only firmware capability, including combined transports. |
+| `espnow.running` | Read-only ESP-NOW runtime state. `on` means the local bridge started; it does not prove the other board is reachable. |
 
 This fork uses **`set bridge.source tx`** or **`rx`**. Some upstream guides
 use `logTx` and `logRx`; those are not the command values used here.
@@ -99,8 +104,8 @@ LoRa repeater, see [raw ESP-NOW compatibility](WiFi.md#wifi-companion-setup).
 Run on both boards:
 
 ```text
-get bridge.enabled
-get bridge.running
+get espnow.enabled
+get espnow.running
 get bridge.channel
 get bridge.format
 get bridge.secret
@@ -127,6 +132,12 @@ If it does not work:
   and check the networks' forwarding and scope rules.
 
 A running bridge keeps the device awake, even with device power saving enabled.
+ESP-NOW shares the WiFi radio: use the connected WiFi network's channel when
+WiFi is active. Browser OTA pauses ESP-NOW on ordinary non-MQTT repeaters,
+reports that pause, and resumes saved-enabled ESP-NOW when OTA is stopped.
+A failed OTA start restores the bridge. The RS-232 transport remains available
+on combined boards while ESP-NOW is paused.
+
 For every command's full details, see the [bridge CLI reference](cli_commands.md#bridge-when-bridge-support-is-compiled-in).
 
 For a broader comparison with a Linux-based bridge, see the

docs/firmware_picker.md

@@ -193,17 +193,21 @@ 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. Choose Wi-Fi MQTT under **Logging / MQTT**; it is an output mode,
-not a second connection choice. Repeaters may still offer separate ESP-NOW or
-Ethernet bridge firmware because those paths use different compiled drivers.
+not a second connection choice. Full ESP32 LoRa repeaters include runtime
+ESP-NOW when capacity permits; dedicated ESP-NOW images remain for measured
+capacity exceptions. Ethernet still needs its exact hardware recipe.
 
 For commands and option explanations, follow the
 [ESP-NOW bridge setup guide](espnow_bridge_setup.md).
 
 An ESP-NOW bridge target keeps LoRa as its primary mesh radio. Expanded ESP32
-Full repeater and room-server images combine ESP-NOW with WiFi MQTT in the
-same firmware. MQTT and ESP-NOW are independent runtime transports: use
-`set mqtt.enabled on|off` for MQTT and `set bridge.enabled on|off` (or
-`set espnow.enabled on|off`) for ESP-NOW, so either or both can run. Both use
+Full LoRa repeaters include ESP-NOW, including boards without an MQTT
+recipe. Existing MQTT-backed Full repeater and room-server images combine
+both transports. Use `set espnow.enabled on|off` for ESP-NOW and, where
+supported, `set mqtt.enabled on|off` for MQTT. Newly combined ordinary
+repeaters start with ESP-NOW off until explicitly enabled, including the first
+upgrade from unmarked legacy preferences. Later reboots preserve that setting.
+On combined RS-232 boards `bridge.enabled` controls the UART independently. Both use
 one 2.4 GHz radio, so when both are enabled the ESP-NOW bridge channel must
 match the connected WiFi access point's fixed channel. ESP-NOW-only mode does
 not require WiFi credentials. Its runtime
@@ -214,8 +218,8 @@ backward-compatible bridge-to-bridge default using `bridge.secret`) or `raw`
 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
+Companion; choose the combined `heltec_v4_repeater` Full firmware and enable
+ESP-NOW to make that board the LoRa/ESP-NOW gateway. Use its exact merged artifact when
 changing roles or partition layouts.
 
 ## Share a selection