deploy: 51d74a200e

_javascript/firmware_picker.js

@@ -1600,17 +1600,21 @@
     if (profile.role === "repeater") toggle("Repeat mesh traffic", "set repeat", "get repeat");
     if (info.rs232 && infrastructure) {
       const mode = chosen.mode;
+      // MQTT images keep the historical bridge.enabled ESP-NOW alias.
+      // Their independently saved UART uses the transport-specific controls.
+      const uartSetting = info.mqtt ? "rs232.enabled" : "bridge.enabled";
+      const uartRunning = info.mqtt ? "rs232.running" : "bridge.running";
       section("RS232 bridge" + (mode === "rs232" ? " - selected" : ""), [
-        { label: "On", commands: ["set bridge.enabled on", "get bridge.running"] },
-        { label: "Off", commands: ["set bridge.enabled off"] },
-        { label: "Set baud", commands: ["set bridge.enabled off", "set bridge.baud 115200", "set bridge.enabled on"] },
+        { label: "On", commands: ["set " + uartSetting + " on", "get " + uartRunning] },
+        { label: "Off", commands: ["set " + uartSetting + " off"] },
+        { label: "Set baud", commands: ["set " + uartSetting + " off", "set bridge.baud 115200", "set " + uartSetting + " on"] },
       ].sort(function (a, b) {
         return mode === "standard" ? Number(b.label === "Off") - Number(a.label === "Off") : 0;
       }), "Use the UART and pin map for this exact board. Canonical GPS-enabled RAK4631 uses UART2; select it with set bridge.uart 2 while the bridge is stopped. UART1 needs a compatible GPS-free image.");
     }
     if (info.espnowBridge && infrastructure) {
       // Combined images need the transport-specific switch: bridge.enabled
-      // controls the UART when RS-232 is compiled alongside ESP-NOW. Older
+      // keeps its historical meaning for the primary transport. Older
       // dedicated ESP-NOW releases retain their original bridge.* commands.
       const independentEspnow = info.rs232 || info.mqtt;
       toggle("ESP-NOW bridge", independentEspnow ? "set espnow.enabled" : "set bridge.enabled",

cli_build_matrix/index.html

@@ -2596,6 +2596,18 @@ available from a canonical image:</p>
   target remains directly buildable with its bridge-on default but is omitted
   from bulk releases. Browser OTA pauses ESP-NOW while leaving RS-232 running;
   <code>stop ota</code> restores ESP-NOW when its saved setting is on.</li>
+<li>Full Heltec V3, Wireless Stick Lite V3, RAK3112 and LilyGo T-LoRa V2.1-1.6
+  MQTT repeaters retain RS-232 alongside MQTT and ESP-NOW. The first three
+  use UART2 with RX on GPIO5 and TX on GPIO6; T-LoRa uses UART2 with RX on
+  GPIO34 and TX on GPIO25. Use <code>set rs232.enabled on|off</code> and
+  <code>get rs232.running</code> independently of <code>mqtt.enabled</code> and <code>espnow.enabled</code>.
+  <code>bridge.baud</code> and <code>bridge.uart</code> configure the UART. Old MQTT preferences
+  do not enable this newly added UART; its saved intent needs a validated
+  UART profile marker. Historical <code>bridge.enabled</code> keeps its ESP-NOW meaning
+  in MQTT images and its UART meaning in non-MQTT images. Full qualification
+  verifies the linked UART driver even when compiling observer sources for a
+  normal repeater, and resumed release selection rejects Full images without
+  that proof.</li>
 <li>MeshTower V2 repeaters use
   <code>Heltec_tower_v2_sdcard_repeater_lora_ota_no_external_sensors</code> as the one
   canonical target. Its SD OTA target <code>0A9DBBF0</code>, hardware ID

cli_commands/index.html

@@ -10794,6 +10794,14 @@ still overrides the first-boot default after an update.</p>
 bridge actually started in this boot; they can differ after a hardware conflict,
 missing credentials, or a transient initialization failure. Normal merged
 repeater images default to <code>off</code>; dedicated bridge images may default to <code>on</code>.</p>
+<p>Full MQTT repeaters with RS-232 expose three independent transports. Use
+<code>set rs232.enabled on|off</code> and <code>get rs232.enabled</code> for saved UART intent;
+<code>get rs232.running</code> reports the actual UART state. <code>mqtt.enabled</code> and
+<code>espnow.enabled</code> select the other two transports. In MQTT images the historical
+<code>bridge.enabled</code> alias controls ESP-NOW; in non-MQTT UART images it controls
+RS-232. <code>bridge.baud</code> and <code>bridge.uart</code> change only UART configuration, without
+restarting MQTT or ESP-NOW. The new UART mode starts off when upgrading old
+MQTT preferences and retains explicit settings across reboots.</p>
 <hr />
 <h4 id="add-a-delay-to-packets-routed-through-this-bridge">Add a delay to packets routed through this bridge</h4>
 <p><strong>Usage:</strong>
@@ -10918,7 +10926,9 @@ non-PSRAM variants opt in with <code>MQTT_NEIGHBORS_WITHOUT_PSRAM</code>.</p>
 <p><strong>Parameters:</strong>
 - <code>rate</code>: Integer baud rate from <code>9600</code> through the board's compiled
   <code>BRIDGE_MAX_BAUD</code> (commonly <code>500000</code>); for example <code>115200</code>. Stop the bridge
-  with <code>set bridge.enabled off</code> before changing it, then enable it again.</p>
+  with <code>set rs232.enabled off</code> in a combined MQTT image, or
+  <code>set bridge.enabled off</code> in a non-MQTT UART image, before changing it.
+  Enable the UART again with the matching switch.</p>
 <p><strong>Default:</strong> <code>115200</code></p>
 <hr />
 <h4 id="view-or-change-the-uart-used-by-the-bridge-rs-232-only">View or change the UART used by the bridge (RS-232 only)</h4>
@@ -10933,7 +10943,8 @@ non-PSRAM variants opt in with <code>MQTT_NEIGHBORS_WITHOUT_PSRAM</code>.</p>
   provider and therefore does not expose either GPS path.</p>
 <p>The setting is persistent and restarts an enabled bridge immediately. Normal
 repeater artifacts start with <code>bridge.enabled off</code>; configure the UART and baud
-rate before running <code>set bridge.enabled on</code>. On the canonical RAK4631 runtime
+rate before running <code>set bridge.enabled on</code>. Combined MQTT images use
+<code>rs232.enabled</code> for that independent UART setting. On the canonical RAK4631 runtime
 image, UART 1 is reserved even if the bounded boot probe hears no RAK12501.
 Silence cannot prove that a cold L76K is physically absent, and that module
 remains powered by the shared WB_IO2/3V3_S rail. Use UART 2. UART 1 requires an

espnow_bridge_setup/index.html

@@ -2400,6 +2400,10 @@ Stopping it first lets you finish configuring both sides before connecting them.
 <td><code>on</code> starts ESP-NOW; <code>off</code> stops it and keeps its saved settings. Independent of MQTT or RS-232.</td>
 </tr>
 <tr>
+<td><code>rs232.enabled</code></td>
+<td>On combined UART images, starts or stops RS-232 independently of MQTT and ESP-NOW. Use <code>get rs232.running</code> to check the live UART.</td>
+</tr>
+<tr>
 <td><code>bridge.channel</code></td>
 <td>The 2.4 GHz channel, 1-13. Match it on both boards. This is separate from the LoRa frequency in <code>set radio</code>.</td>
 </tr>

firmware_picker/index.html

@@ -2641,8 +2641,10 @@ both transports. Use <code>set espnow.enabled on|off</code> for ESP-NOW and, whe
 supported, <code>set mqtt.enabled on|off</code> 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 <code>bridge.enabled</code> controls the UART independently. Both use
-one 2.4 GHz radio, so when both are enabled the ESP-NOW bridge channel must
+On combined RS-232 boards without MQTT, <code>bridge.enabled</code> controls the UART.
+Full Heltec V3, WSL3, RAK3112 and T-LoRa V2.1 MQTT images also retain RS-232;
+use <code>set rs232.enabled on|off</code> and <code>get rs232.running</code> for their independent
+UART. MQTT and ESP-NOW 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
 <code>bridge.format</code> setting chooses the peer protocol: <code>wrapped</code> (the

research/firmware_memory_budget/index.html

@@ -2181,7 +2181,11 @@ is excluded because its silicon-specific reservations are only known at boot.
 Classic ESP32 additionally retains its existing 8 KiB <strong>static DRAM</strong> check.</p>
 <p>The policy adds allowances for task stacks, radio packet pools, screen objects
 and pixel buffers, filesystem/sensor allocations, enabled wireless stacks,
-MQTT connections, OTA scratch and transient allocations. A 160x80 ST7735
+MQTT connections, OTA scratch and transient allocations. ESP32 images with
+RS-232 reserve another 8 KiB even when UART defaults off: 4 KiB for the
+source-bounded bridge object and 4 KiB for the UART driver and buffers. This
+keeps runtime UART enablement in the budget beside MQTT and ESP-NOW.
+A 160x80 ST7735
 framebuffer needs 25,602 bytes; an OLED allowance is 4 KiB. nRF52 Full with that
 color framebuffer must have at least 72 KiB available before startup allocations.
 Headless and OLED devices use their own smaller totals. The JSON lists each

role_feature_switches/index.html

@@ -2704,6 +2704,18 @@ from some portable builds. The USB browser console still works without it.</p>
 <td><code>get bridge.enabled</code>, <code>get bridge.running</code>, <code>get bridge.type</code></td>
 </tr>
 <tr>
+<td>Independent RS232 in combined Full MQTT images</td>
+<td><code>set rs232.enabled on</code></td>
+<td><code>set rs232.enabled off</code></td>
+<td><code>get rs232.enabled</code>, <code>get rs232.running</code></td>
+</tr>
+<tr>
+<td>Independent ESP-NOW in combined Full images</td>
+<td><code>set espnow.enabled on</code></td>
+<td><code>set espnow.enabled off</code></td>
+<td><code>get espnow.enabled</code>, <code>get espnow.running</code></td>
+</tr>
+<tr>
 <td>MQTT periodic status publication</td>
 <td><code>set mqtt.status on</code></td>
 <td><code>set mqtt.status off</code></td>

search/search_index.json

@@ -1 +1 @@
-{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"],"fields":{"title":{"boost":1000.0},"text":{"boost":1.0},"tags":{"boost":1000000.0}}},"docs":[{"location":"","title":"MeshCore documentation","text":"<p>Choose firmware with the firmware picker. For help with a device already in service, start with the FAQ.</p>"},{"location":"#current-release","title":"Current release","text":"<ul> <li>1.17.1.8 USA Cascade release notes</li> <li>Test Results \u2014 validation archive and 1.17.1.8 Preview 1 qualification evidence</li> </ul>"},{"location":"#documentation","title":"Documentation","text":"<ul> <li>Feature switches by role and Full Companion features</li> <li>Firmware update guide, easy LoRa OTA, and scripted LoRa OTA</li> <li>CLI commands, availability by build, and radio profiles</li> <li>Companion protocol, packet format, and QR codes</li> </ul> <p>The navigation groups the remaining guides under Documentation, including board-specific updates, networking, power, and protocol references.</p>"},{"location":"#tools","title":"Tools","text":"<ul> <li>Firmware picker and USB web console</li> <li>Notification builder and temporary radio test builder</li> <li>Filter policy playground, telemetry decoder, and management report decoder</li> </ul>"},{"location":"#engineering-records","title":"Engineering records","text":"<ul> <li>Research \u2014 design notes, diagnostics, and historical update-chain studies</li> <li>Old Releases \u2014 historical release notes and supporting files</li> </ul> <p>Found a mistake or missing information? Edit the documentation.</p>"},{"location":"WiFi/","title":"WiFi and MQTT by Firmware Type","text":"<p>MeshCore itself does not require WiFi or the internet. LoRa packet exchange, repeating, room servers, companions, and sensors can all operate without either. WiFi is added by particular ESP32 firmware targets for one or more of these purposes:</p> <ul> <li>a TCP connection between a WiFi companion and a phone or computer;</li> <li>the WebConfig browser interface;</li> <li>MQTT uplinking from the radio to internet or LAN brokers;</li> <li>WiFi-assisted OTA services on builds that include them;</li> <li>ESP-NOW bridging, which uses the ESP32's 2.4 GHz radio but is not a connection   to a WiFi access point.</li> </ul> <p>The firmware role and the build profile are separate choices. USB logging does not itself provide MQTT. MQTT-capable Full Companions include that feature without <code>mqtt</code> in their filename; check the artifact capability manifest. See feature switches by role for the different Companion and infrastructure controls and the USB web console.</p>"},{"location":"WiFi/#quick-reference","title":"Quick reference","text":"Firmware target or role Infrastructure WiFi MQTT What WiFi does <code>*_repeater</code> Build-dependent on ESP32 No FULL builds provide WebConfig, browser OTA, and the TCP 5001 LoRa-OTA seeder while WiFi is active <code>*_repeater_observer_mqtt</code> Yes Yes Uplinks heard and selected transmitted LoRa packets; repeating remains enabled by default <code>*_room_server</code> Build-dependent on ESP32 No FULL builds provide WebConfig, browser OTA, and the TCP 5001 LoRa-OTA seeder while WiFi is active <code>*_room_server_observer_mqtt</code> Yes Yes Runs the room server and uplinks radio traffic <code>*_companion_radio_wifi</code> Yes No Exposes the MeshCore companion protocol on TCP port 5000 <code>*_companion_radio_wifi_mqtt</code> Yes Yes Runs both the TCP companion interface and the MQTT uplink <code>*_companion_radio_full*</code> ESP32, subject to board/transport selection Where compiled on ESP32 Includes supported USB/wireless transports; configure MQTT through WebConfig Dedicated USB, BLE, or serial companion (not Full) No No Uses the transport named by the target instead <code>*_repeater_bridge_espnow</code> Build-dependent on ESP32 No Uses ESP-NOW for its bridge; <code>bridge.format wrapped|raw</code> selects legacy bridge framing or primary-ESP-NOW compatibility; a FULL build also exposes the TCP 5001 LoRa-OTA seeder whenever WiFi is usable RS232 bridge No No Bridges through a serial interface Ethernet repeater/room server No WiFi No Uses wired Ethernet for its role-specific network interface <code>*_sensor</code> Build-dependent on ESP32 No A FULL ESP32 sensor can expose the TCP 5001 LoRa-OTA seeder through its browser-OTA setup AP Terminal-chat or KISS modem No in current targets No Uses LoRa and its role-specific local interface <code>*_lora_ota_no_external_sensors</code> On demand on ESP32 No Lean LoRa-OTA repeater image; ESP32 builds retain the compact <code>start ota</code> browser uploader <p>Direct on-device WiFi and MQTT are currently ESP32 features. nRF52, STM32, and the currently enabled RP2040 targets do not run this MQTT bridge. An nRF52 connected to a Raspberry Pi can still be logged or uplinked by software on the Pi, but that is a separate host-side bridge rather than MQTT running in the radio firmware.</p>"},{"Line truncated
+{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"],"fields":{"title":{"boost":1000.0},"text":{"boost":1.0},"tags":{"boost":1000000.0}}},"docs":[{"location":"","title":"MeshCore documentation","text":"<p>Choose firmware with the firmware picker. For help with a device already in service, start with the FAQ.</p>"},{"location":"#current-release","title":"Current release","text":"<ul> <li>1.17.1.8 USA Cascade release notes</li> <li>Test Results \u2014 validation archive and 1.17.1.8 Preview 1 qualification evidence</li> </ul>"},{"location":"#documentation","title":"Documentation","text":"<ul> <li>Feature switches by role and Full Companion features</li> <li>Firmware update guide, easy LoRa OTA, and scripted LoRa OTA</li> <li>CLI commands, availability by build, and radio profiles</li> <li>Companion protocol, packet format, and QR codes</li> </ul> <p>The navigation groups the remaining guides under Documentation, including board-specific updates, networking, power, and protocol references.</p>"},{"location":"#tools","title":"Tools","text":"<ul> <li>Firmware picker and USB web console</li> <li>Notification builder and temporary radio test builder</li> <li>Filter policy playground, telemetry decoder, and management report decoder</li> </ul>"},{"location":"#engineering-records","title":"Engineering records","text":"<ul> <li>Research \u2014 design notes, diagnostics, and historical update-chain studies</li> <li>Old Releases \u2014 historical release notes and supporting files</li> </ul> <p>Found a mistake or missing information? Edit the documentation.</p>"},{"location":"WiFi/","title":"WiFi and MQTT by Firmware Type","text":"<p>MeshCore itself does not require WiFi or the internet. LoRa packet exchange, repeating, room servers, companions, and sensors can all operate without either. WiFi is added by particular ESP32 firmware targets for one or more of these purposes:</p> <ul> <li>a TCP connection between a WiFi companion and a phone or computer;</li> <li>the WebConfig browser interface;</li> <li>MQTT uplinking from the radio to internet or LAN brokers;</li> <li>WiFi-assisted OTA services on builds that include them;</li> <li>ESP-NOW bridging, which uses the ESP32's 2.4 GHz radio but is not a connection   to a WiFi access point.</li> </ul> <p>The firmware role and the build profile are separate choices. USB logging does not itself provide MQTT. MQTT-capable Full Companions include that feature without <code>mqtt</code> in their filename; check the artifact capability manifest. See feature switches by role for the different Companion and infrastructure controls and the USB web console.</p>"},{"location":"WiFi/#quick-reference","title":"Quick reference","text":"Firmware target or role Infrastructure WiFi MQTT What WiFi does <code>*_repeater</code> Build-dependent on ESP32 No FULL builds provide WebConfig, browser OTA, and the TCP 5001 LoRa-OTA seeder while WiFi is active <code>*_repeater_observer_mqtt</code> Yes Yes Uplinks heard and selected transmitted LoRa packets; repeating remains enabled by default <code>*_room_server</code> Build-dependent on ESP32 No FULL builds provide WebConfig, browser OTA, and the TCP 5001 LoRa-OTA seeder while WiFi is active <code>*_room_server_observer_mqtt</code> Yes Yes Runs the room server and uplinks radio traffic <code>*_companion_radio_wifi</code> Yes No Exposes the MeshCore companion protocol on TCP port 5000 <code>*_companion_radio_wifi_mqtt</code> Yes Yes Runs both the TCP companion interface and the MQTT uplink <code>*_companion_radio_full*</code> ESP32, subject to board/transport selection Where compiled on ESP32 Includes supported USB/wireless transports; configure MQTT through WebConfig Dedicated USB, BLE, or serial companion (not Full) No No Uses the transport named by the target instead <code>*_repeater_bridge_espnow</code> Build-dependent on ESP32 No Uses ESP-NOW for its bridge; <code>bridge.format wrapped|raw</code> selects legacy bridge framing or primary-ESP-NOW compatibility; a FULL build also exposes the TCP 5001 LoRa-OTA seeder whenever WiFi is usable RS232 bridge No No Bridges through a serial interface Ethernet repeater/room server No WiFi No Uses wired Ethernet for its role-specific network interface <code>*_sensor</code> Build-dependent on ESP32 No A FULL ESP32 sensor can expose the TCP 5001 LoRa-OTA seeder through its browser-OTA setup AP Terminal-chat or KISS modem No in current targets No Uses LoRa and its role-specific local interface <code>*_lora_ota_no_external_sensors</code> On demand on ESP32 No Lean LoRa-OTA repeater image; ESP32 builds retain the compact <code>start ota</code> browser uploader <p>Direct on-device WiFi and MQTT are currently ESP32 features. nRF52, STM32, and the currently enabled RP2040 targets do not run this MQTT bridge. An nRF52 connected to a Raspberry Pi can still be logged or uplinked by software on the Pi, but that is a separate host-side bridge rather than MQTT running in the radio firmware.</p>"},{"Line truncated