deploy: 5362d36ac7

WiFi/index.html

@@ -1671,6 +1671,23 @@ fresh device with no saved SSID:</p>
 <code>WEBCONFIG_AP_PASSWORD</code>. It uses plain HTTP, so provision it in a trusted
 location. When WebConfig is running on the normal LAN, repeater and room-server
 builds require the node's admin password.</p>
+<p>On an expanded FULL profile with no saved SSID, this automatic setup AP has an
+absolute 30-minute window. Browser activity or a phone left associated with the
+AP does not extend it. If no SSID has been saved when the window expires,
+WebConfig closes and the ESP32 WiFi radio remains off automatically for the
+remainder of that boot. A reboot or power cycle starts a new 30-minute setup
+window; the timeout is deliberately not written to preferences. An
+administrator can still override the automatic cutoff with an explicit
+<code>start webconfig</code> command.</p>
+<p>Once an SSID is saved, the provisioning cutoff no longer applies. When WiFi is
+selected by <code>logging.output wifi|both</code>, the station stays enabled and keeps
+trying the saved network indefinitely: ESP automatic reconnect remains on and
+the explicit fallback advances through 15, 30, 60, 120, then 300-second retry
+intervals, remaining at five minutes until it reconnects. MQTT broker retries
+use their own backoff; a repeatedly failing broker eventually receives one
+probe every 30 minutes. Selecting <code>logging.output off|usb</code> keeps the MQTT bridge
+off, so saved credentials alone do not force WiFi on unless WebConfig is also
+enabled explicitly.</p>
 <p>The equivalent MQTT observer CLI setup is:</p>
 <pre><code class="language-text">set wifi.ssid Your WiFi Name
 set wifi.pwd Your WiFi Password
@@ -1826,9 +1843,10 @@ removes the MQTT wizard step and MQTT tab.</p>
 <p>In this case WebConfig owns WiFi only while it is needed. Stopping the portal
 disconnects WiFi and turns the WiFi radio off. There is no persistent MQTT
 connection keeping WiFi active.</p>
-<p>FULL MQTT and FULL logging repeater/room-server builds both provide these CLI
-controls and status checks. FULL MQTT includes the MQTT bridge; FULL logging
-does not:</p>
+<p>Unified FULL USB + WiFi and FULL logging-fallback repeater/room-server builds
+both provide these CLI controls and status checks. The unified profile includes
+the MQTT bridge; the fallback is used only where no matching MQTT environment
+exists:</p>
 <pre><code class="language-text">get wifi.ssid
 get wifi.status
 get wifi.powersave
@@ -1901,19 +1919,19 @@ role.</p>
 </tr>
 <tr>
 <td>Logging</td>
-<td>Enables USB/debug packet logging and disables the MQTT bridge. <code>get/set usb.logging</code> can silence or restore the live output until reboot. Logging output is not an MQTT uplink.</td>
+<td>Enables USB/debug packet logging and disables the MQTT bridge. CommonCLI roles persist <code>get/set usb.logging</code>; logging output itself is not a direct MQTT uplink.</td>
 </tr>
 <tr>
 <td>MQTT</td>
 <td>Builds explicit MQTT observer or WiFi-companion-MQTT targets with USB packet logging off. Non-companion ESP32 MQTT observers always use FULL expanded partitions.</td>
 </tr>
 <tr>
-<td>FULL ESP32</td>
-<td>Uses the board's MQTT target with logging off, expanded dual-OTA partitions, up to 254 neighbors, LoRa OTA, and full-size ESP32 features such as WebConfig where supported. Classic T-Beam MQTT observers retain their 50-entry table because their persistent discovery state exhausts internal DRAM at 254.</td>
+<td>FULL ESP32 USB + WiFi</td>
+<td>Uses the board's MQTT target with USB packet logging and direct WiFi MQTT together, expanded dual-OTA partitions, up to 254 neighbors, LoRa OTA, and full-size ESP32 features such as WebConfig where supported. <code>get/set logging.output off\|usb\|wifi\|both</code> persists the active paths. Classic T-Beam MQTT observers retain their 50-entry table because their persistent discovery state exhausts internal DRAM at 254.</td>
 </tr>
 <tr>
-<td>FULL ESP32 logging</td>
-<td>Uses the board's non-MQTT target with debug and packet logging enabled, session-only <code>get/set usb.logging</code> control, expanded dual-OTA partitions, up to 254 neighbors, and LoRa OTA.</td>
+<td>FULL ESP32 logging fallback</td>
+<td>Uses the board's non-MQTT target only when no matching WiFi MQTT environment exists. It keeps debug and packet logging, expanded dual-OTA partitions, up to 254 neighbors, and LoRa OTA. Persistent <code>usb.logging off</code> also provides normal output-off operation, so ESP-NOW FULL roles need no second non-logging image.</td>
 </tr>
 <tr>
 <td>LoRa-OTA no-external-sensors</td>
@@ -1925,12 +1943,13 @@ role.</p>
 logging, bridge, and LoRa-OTA builds on every supported platform. The classic
 T-Beam SX1262 and SX1276 MQTT observer repeaters retain 50 entries because their
 persistent MQTT discovery state leaves insufficient internal-DRAM margin at 254.</p>
-<p>The interactive Option 1 <strong>FULL everything</strong> choice selects the FULL logging
-profile: logging is enabled and MQTT is disabled. The standalone FULL ESP32
-profile and Profile 3 of the four-profile matrix use the matching MQTT target
-instead. Both FULL profiles include LoRa OTA, WebConfig where supported, up to
-254 neighbors, and expanded dual-OTA partitions. Target-specific internal-DRAM
-limits still apply.</p>
+<p>The interactive Option 1 <strong>FULL everything</strong> choice and the standalone FULL
+command select the unified USB + WiFi image when a matching MQTT target exists;
+otherwise they select the logging fallback. The build matrix no longer emits a
+separate standard logging image or non-MQTT FULL twin for a role covered by the
+unified image. All FULL profiles include LoRa OTA, WebConfig where supported,
+up to 254 neighbors, and expanded dual-OTA partitions. Target-specific
+internal-DRAM limits still apply.</p>
 <p>FULL images change the ESP32 partition layout. Flash the matching
 <code>*-merged.bin</code> once when installing that layout. A partition-layout change can
 invalidate NVS, including saved WiFi, MQTT, name, and admin settings. Later

_javascript/firmware_picker.js

@@ -37,6 +37,9 @@
     none: "None / normal operation",
     usb: "USB logging / USB-connected MQTT",
     wifi: "Wi-Fi MQTT observer",
+    both: "USB logging + Wi-Fi MQTT",
+    runtime: "Runtime selectable: off / USB / Wi-Fi / both",
+    "usb-runtime": "Runtime selectable: off / USB",
   });
 
   const OTA_LABELS = Object.freeze({
@@ -90,9 +93,10 @@
   });
 
   const HIDDEN_PROFILE_HARDWARE = Object.freeze([
-    // This legacy environment only changes ADVERT_NAME. The standard G3
-    // target provides the same firmware behavior, while all legacy files stay
-    // available through exact filename search.
+    // These legacy Station environments select a runtime radio-gain default
+    // or only change ADVERT_NAME. Their ordinary targets provide the same
+    // behavior, while all legacy files stay available through exact search.
+    "Station_G2_logging",
     "Station_G3_ESP32_logging",
   ]);
 
@@ -102,6 +106,9 @@
     // siblings; keep those files searchable without recommending them.
     "solarxiao_30S_repeater_lora_ota_no_external_sensors",
     "solarxiao_33S_repeater_lora_ota_no_external_sensors",
+    // Exact aliases of the unsuffixed Heltec V4 USB/BLE recipes.
+    "heltec_v4_companion_radio_usb_femon",
+    "heltec_v4_companion_radio_ble_femon",
   ]);
 
   let pickerInstanceCount = 0;
@@ -287,7 +294,13 @@
         /^(?:full|ble|usb|wifi|serial|ethernet)(?=$|[_-])/i,
         " "
       );
+      // Power saving and controllable FEM gain are persisted settings. Legacy
+      // filenames retain these tokens for exact search, but they are not
+      // distinct recommended firmware variants.
+      value = value.replace(/(?:^|[_-])ps(?=$|[_-])/gi, " ");
+      value = value.replace(/(?:^|[_-])fem(?:on|off)(?=$|[_-])/gi, " ");
     }
+    value = value.replace(/-full-usb-wifi/gi, "");
     value = value.replace(/-logging/gi, "");
     value = value.replace(/(?:^|[_-])full(?=$|[_-])/gi, " ");
     value = value.replace(/observer_mqtt/gi, " ");
@@ -307,11 +320,23 @@
     const lowerTarget = target.toLowerCase();
     const lowerTail = parts.tail.toLowerCase();
     const mode = modeForRole(parts.role, parts.tail);
-    const logging = lowerTarget.includes("observer_mqtt")
-      ? "wifi"
-      : lowerTarget.includes("-logging")
-        ? "usb"
-        : "none";
+    const unifiedLogging = lowerTarget.includes("-full-usb-wifi");
+    const fullLoggingFallback = parts.role !== "companion" &&
+      lowerTarget.includes("-full-logging");
+    const logging = unifiedLogging
+      ? "runtime"
+      : fullLoggingFallback
+        ? "usb-runtime"
+        : lowerTarget.includes("observer_mqtt")
+          ? "wifi"
+          : lowerTarget.includes("-logging")
+            ? "usb"
+            : "none";
+    const loggingModes = unifiedLogging
+      ? ["none", "usb", "wifi", "both"]
+      : fullLoggingFallback
+        ? ["none", "usb"]
+        : [logging];
     const feature = lowerTail.includes("-full") ||
       (parts.role === "companion" && mode === "full")
       ? "full"
@@ -334,6 +359,7 @@
       hardware: canonicalHardware(sourceHardware),
       role: parts.role,
       logging: logging,
+      loggingModes: loggingModes,
       mode: mode,
       feature: feature,
       variant: variant,
@@ -346,6 +372,47 @@
     return HARDWARE_ALIASES[value] || value;
   }
 
+  function isHiddenLegacyProfile(profile) {
+    const target = String(profile && profile.target || "");
+    const lowerTarget = target.toLowerCase();
+    return HIDDEN_PROFILE_HARDWARE.includes(profile.sourceHardware) ||
+      HIDDEN_PROFILE_TARGETS.includes(target) ||
+      (lowerTarget.includes("companion_radio_") &&
+        /(?:^|[_-])(?:ps|femoff)(?=$|[_-])/.test(lowerTarget));
+  }
+
+  function omitNrf52TransportsReplacedByFull(profiles) {
+    const fullKeys = new Set((profiles || []).filter(function (profile) {
+      return profile.role === "companion" && profile.mode === "full" &&
+        profile.installKinds.includes("zip");
+    }).map(function (profile) {
+      return profile.hardware + "\n" + profile.variant;
+    }));
+
+    return (profiles || []).filter(function (profile) {
+      const key = profile.hardware + "\n" + profile.variant;
+      const replacedAttachedTransport = profile.role === "companion" &&
+        (profile.mode === "usb" || profile.mode === "ble");
+      return !(replacedAttachedTransport && fullKeys.has(key));
+    });
+  }
+
+  function applyNrf52FullCompanionCapabilities(profiles) {
+    return (profiles || []).map(function (profile) {
+      const nativeNrf52Full = profile.role === "companion" &&
+        profile.mode === "full" && profile.installKinds.includes("zip");
+      if (!nativeNrf52Full) return profile;
+
+      // Current nRF52 Full Companion images expose two CDC ACM interfaces:
+      // framed Companion traffic on interface 00 and plaintext logging on 02.
+      // The saved USB logging gate covers only the second interface.
+      profile.logging = "usb-runtime";
+      profile.loggingModes = ["none", "usb"];
+      profile.dedicatedUsbLogging = true;
+      return profile;
+    });
+  }
+
   function hardwareFamilyFor(hardware, hardwareNames) {
     const value = String(hardware || "");
     const lowerValue = value.toLowerCase();
@@ -432,7 +499,7 @@
       profile.otaPackaged = profile.otaPackaged || file.otaPackaged;
     });
 
-    const profiles = Array.from(grouped.values()).map(function (profile) {
+    const visibleProfiles = Array.from(grouped.values()).map(function (profile) {
       profile.ota = profile.explicitOta ||
         (profile.otaPackaged ? "lora-receiver" : "none");
       profile.installKinds = INSTALL_ORDER.filter(function (kind) {
@@ -443,9 +510,11 @@
       });
       return profile;
     }).filter(function (profile) {
-      return !HIDDEN_PROFILE_HARDWARE.includes(profile.sourceHardware) &&
-        !HIDDEN_PROFILE_TARGETS.includes(profile.target);
-    }).sort(function (a, b) {
+      return !isHiddenLegacyProfile(profile);
+    });
+    const profiles = omitNrf52TransportsReplacedByFull(
+      applyNrf52FullCompanionCapabilities(visibleProfiles)
+    ).sort(function (a, b) {
       return a.target.localeCompare(b.target, undefined, {
         numeric: true,
         sensitivity: "base",
@@ -473,10 +542,17 @@
     const wantedFields = fields || FILTER_FIELDS;
     return wantedFields.every(function (field) {
       const value = filters && filters[field];
-      return !value || profile[field] === value;
+      return !value || profileFieldValues(profile, field).includes(value);
     });
   }
 
+  function profileFieldValues(profile, field) {
+    if (field === "logging" && Array.isArray(profile.loggingModes)) {
+      return profile.loggingModes;
+    }
+    return profile[field] ? [profile[field]] : [];
+  }
+
   function profileMatchesFacets(profile, filters, ignoredField) {
     const ignoredFields = new Set(
       Array.isArray(ignoredField) ? ignoredField : [ignoredField]
@@ -488,7 +564,7 @@
       if (field === "install") {
         return profile.installKinds.includes(value);
       }
-      return profile[field] === value;
+      return profileFieldValues(profile, field).includes(value);
     });
   }
 
@@ -501,15 +577,15 @@
       ? compatible.flatMap(function (profile) {
         return profile.installKinds;
       })
-      : compatible.map(function (profile) {
-        return profile[field];
+      : compatible.flatMap(function (profile) {
+        return profileFieldValues(profile, field);
       });
     return Array.from(new Set(values.filter(Boolean)));
   }
 
   function uniqueValues(profiles, field) {
-    return Array.from(new Set((profiles || []).map(function (profile) {
-      return profile[field];
+    return Array.from(new Set((profiles || []).flatMap(function (profile) {
+      return profileFieldValues(profile, field);
     }).filter(Boolean)));
   }
 
@@ -566,7 +642,7 @@
 
   function optionSort(field, a, b) {
     const roleOrder = ["companion", "repeater", "room", "sensor", "terminal", "kiss", "other"];
-    const loggingOrder = ["none", "usb", "wifi"];
+    const loggingOrder = ["none", "usb", "wifi", "both"];
     const otaOrder = ["none", "lora-receiver", "lora-source"];
     const featureOrder = ["standard", "full"];
     const modeOrder = ["standard", "full", "ble", "usb", "wifi", "serial", "ethernet", "mqtt", "espnow", "rs232"];
@@ -627,6 +703,23 @@
         "Full Companion can serve a host-supplied update to another node; it does not self-install that LoRa update."
       );
     }
+    if (profile.logging === "runtime") {
+      extra.push(
+        "Use get logging.output and set logging.output off|usb|wifi|both to choose the saved output mode. Avoid both when two consumers publish the same packets to one broker."
+      );
+      extra.push(
+        "With no saved SSID, the setup AP stays available for 30 minutes after each boot, then Wi-Fi powers off automatically until reboot or an explicit start webconfig command. A configured Wi-Fi mode keeps reconnecting instead."
+      );
+    } else if (profile.logging === "usb-runtime") {
+      extra.push(
+        "Use get usb.logging and set usb.logging off|on to choose and save normal output-off or USB packet logging."
+      );
+      if (profile.dedicatedUsbLogging) {
+        extra.push(
+          "This nRF52 Full Companion exposes two serial ports on one USB cable: interface 00 carries Companion/terminal/mOTA traffic and interface 02 carries plaintext logging. Match services by USB interface number instead of assuming tty or COM numbering."
+        );
+      }
+    }
     return common.concat(byKind[kind] || [], extra);
   }
 
@@ -649,7 +742,7 @@
 
     const facts = createElement("dl");
     facts.className = "firmware-picker-facts";
-    replaceFacts(facts, [
+    const factRows = [
       ["Target", profile.target],
       ["Connection / mode", labelFor("mode", profile.mode)],
       ["Logging", labelFor("logging", profile.logging)],
@@ -660,7 +753,14 @@
       ["File", asset.name],
       ["Size", formatBytes(asset.size)],
       ["Release", asset.releaseName],
-    ]);
+    ];
+    if (profile.dedicatedUsbLogging) {
+      factRows.splice(3, 0, [
+        "USB port split",
+        "Interface 00 Companion; interface 02 logging",
+      ]);
+    }
+    replaceFacts(facts, factRows);
     card.appendChild(facts);
 
     const actions = createElement("div");
@@ -986,11 +1086,15 @@
     flattenReleaseAssets: flattenReleaseAssets,
     parseFirmwareAsset: parseFirmwareAsset,
     parseTargetProfile: parseTargetProfile,
+    applyNrf52FullCompanionCapabilities:
+      applyNrf52FullCompanionCapabilities,
     canonicalHardware: canonicalHardware,
+    omitNrf52TransportsReplacedByFull: omitNrf52TransportsReplacedByFull,
     hardwareFamilyFor: hardwareFamilyFor,
     humanizeHardwareVariant: humanizeHardwareVariant,
     buildCatalog: buildCatalog,
     profileMatches: profileMatches,
+    profileFieldValues: profileFieldValues,
     profileMatchesFacets: profileMatchesFacets,
     facetValues: facetValues,
     uniqueValues: uniqueValues,

cli_build_matrix/index.html

@@ -365,6 +365,17 @@
     </span>
   </a>
   
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#canonical-bulk-build-policy" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Canonical bulk-build policy
+      
+    </span>
+  </a>
+  
 </li>
       
         <li class="md-nav__item">
@@ -1291,6 +1302,17 @@
     </span>
   </a>
   
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#canonical-bulk-build-policy" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Canonical bulk-build policy
+      
+    </span>
+  </a>
+  
 </li>
       
         <li class="md-nav__item">
@@ -1419,7 +1441,7 @@ retain 50 because their MQTT discovery tables are constrained by internal DRAM.<
 </tr>
 <tr>
 <td>Standard logging</td>
-<td>Logging does not remove commands by itself. It has the same CLI as the selected role/profile, adds the compiled logging behavior, and provides session-only <code>get/set usb.logging</code> control.</td>
+<td>Logging does not remove commands by itself. It has the same CLI as the selected role/profile and adds compiled logging behavior. CommonCLI roles persist <code>get/set usb.logging</code>. ESP32 roles covered by unified FULL and nRF52 Companions covered by dual-CDC Full Companion are not duplicated here.</td>
 </tr>
 <tr>
 <td>LoRa-OTA (<code>-ota-</code>)</td>
@@ -1430,12 +1452,16 @@ retain 50 because their MQTT discovery tables are constrained by internal DRAM.<
 <td>Always uses the expanded FULL partition profile. The build never substitutes a reduced CLI to fit the legacy application slot.</td>
 </tr>
 <tr>
-<td>FULL ESP32</td>
-<td>Uses the matching MQTT target with logging off and keeps the complete command surface supported by that role and hardware.</td>
+<td>FULL ESP32 USB + WiFi</td>
+<td>Uses the matching MQTT target with packet logging on, verbose debug off, and the complete command surface supported by that role and hardware. <code>get/set logging.output off\|usb\|wifi\|both</code> selects and persists the active output paths.</td>
 </tr>
 <tr>
-<td>FULL ESP32 logging</td>
-<td>Uses the matching non-MQTT target with debug and packet logging enabled, session-only <code>get/set usb.logging</code> control, and the complete command surface supported by that role and hardware.</td>
+<td>FULL ESP32 logging fallback</td>
+<td>Uses the matching non-MQTT target only when no WiFi MQTT sibling exists, with debug and packet logging enabled and the complete command surface supported by that role and hardware. Its persistent USB gate also covers output-off operation, avoiding a second FULL ESP-NOW image.</td>
+</tr>
+<tr>
+<td>nRF52 Full Companion</td>
+<td>Uses one physical USB connection with interface <code>00</code> for framed Companion/terminal/mOTA traffic and interface <code>02</code> for plaintext logging. It also provides BLE and source-only LoRa OTA. <code>get/set usb.logging</code> persistently gates only the logging interface.</td>
 </tr>
 <tr>
 <td><code>no_external_sensors</code></td>
@@ -1445,6 +1471,32 @@ retain 50 because their MQTT discovery tables are constrained by internal DRAM.<
 </table>
 <p><code>logging</code>, <code>OTA</code>, and <code>FULL</code> describe independent build features. Do not infer
 that a command is missing merely because <code>logging</code> appears in the filename.</p>
+<h2 id="canonical-bulk-build-policy">Canonical bulk-build policy</h2>
+<p>Bulk and release-matrix commands omit legacy names whose behavior is already
+available from a canonical image:</p>
+<ul>
+<li>Companion <code>_ps</code> names are replaced by the ordinary Companion image plus the
+  persisted <code>powersaving on|off</code> setting.</li>
+<li>Companion <code>_femoff</code> names are replaced by the matching controllable-FEM
+  image plus <code>radio.fem.rxgain on|off</code>. The old names remain explicit build
+  targets for compatibility.</li>
+<li><code>Station_G2_logging_*</code> and <code>Station_G3_ESP32_logging_*</code> hardware names are
+  replaced by their ordinary Station target. G2 boosted receive gain is the
+  persisted <code>radio.rxgain on|off</code> setting; the G3 alias changed only the
+  advertised default name.</li>
+<li>When an nRF52 board has a generated Full Companion, that one artifact
+  replaces its separate USB, BLE, and USB packet-logging Companion artifacts.
+  It provides BLE plus two USB CDC interfaces: interface <code>00</code> carries framed
+  Companion/terminal/mOTA traffic and interface <code>02</code> carries plaintext logs.
+  Its LoRa OTA support is source-only: it can serve a host file to another node
+  but has no staging store and cannot update itself over LoRa.</li>
+</ul>
+<p>The old aliases still work with <code>build-firmware</code> and
+<code>build-matching-firmwares</code>. Dedicated repeater LoRa OTA receiver images are not
+collapsed; they retain their exact storage, bootloader, role, and target
+identity contracts. ESP32 USB, BLE, WiFi, and Full Companion images also remain
+separate because Full changes partitions, RAM use, active transports, and power
+behavior.</p>
 <h2 id="complete-cli-policy">Complete CLI policy</h2>
 <p>The compact ESP32 CLI has been removed. MQTT observers and ESP-NOW bridges are
 automatically promoted to FULL builds with expanded partitions rather than
@@ -1459,7 +1511,7 @@ require MQTT or PSRAM.</p>
 <h2 id="discovery-invariant">Discovery invariant</h2>
 <p><code>discover.neighbors</code> sends the zero-hop node-discovery request used to refresh
 the repeater neighbor table. It is available in every repeater build profile,
-including standard, logging, OTA, FULL, and FULL logging builds.</p>
+including standard, logging, OTA, unified FULL, and FULL logging-fallback builds.</p>
 <p>The exact command is:</p>
 <pre><code class="language-text">discover.neighbors
 </code></pre>

cli_command_availability/index.html

@@ -1599,10 +1599,12 @@ own interface, so those build roles are not represented here.</p>
   remove commands by itself.</li>
 <li><strong>LoRa OTA</strong> - the explicit <code>-ota-</code> repeater or repeater-bridge artifact. Its
   optional external-sensor drivers are removed, but onboard GPS is retained.</li>
-<li><strong>FULL</strong> - the expanded-partition ESP32 artifact with LoRa OTA and the
-  complete parser. MQTT observers and ESP-NOW bridges always use this profile.</li>
-<li><strong>FULL logging</strong> - the expanded-partition ESP32 non-MQTT artifact with
-  logging, LoRa OTA, and the complete parser.</li>
+<li><strong>FULL unified</strong> - the expanded-partition ESP32 artifact with LoRa OTA, the
+  complete parser, USB packet logging, and direct WiFi MQTT. Its saved output
+  mode can be off, USB, WiFi, or both. MQTT observers use this profile.</li>
+<li><strong>FULL fallback</strong> - the expanded-partition ESP32 non-MQTT artifact used only
+  where there is no MQTT sibling. It has the complete parser and a saved
+  USB-logging on/off gate. ESP-NOW bridges use this profile.</li>
 </ul>
 <p>Cell values mean:</p>
 <ul>
@@ -1857,8 +1859,8 @@ fix, no WiFi connection, an inactive bridge, or an nRF52 bootloader without
 </tr>
 <tr>
 <td>Logging</td>
-<td><a href="../cli_commands/#control-live-usb-logging"><code>get/set usb.logging</code></a></td>
-<td>Logging artifacts; session-only live USB output gate</td>
+<td><a href="../cli_commands/#control-live-usb-logging"><code>get/set usb.logging</code>; unified FULL <code>get/set logging.output</code></a></td>
+<td>Logging artifacts; CommonCLI USB gate is persistent; unified ESP32 FULL selects off/USB/WiFi/both; nRF52 Full Companion gates its second USB port</td>
 <td>No</td>
 <td>Yes</td>
 <td>No</td>
@@ -2899,8 +2901,8 @@ fix, no WiFi connection, an inactive bridge, or an nRF52 bootloader without
 <th>Standard</th>
 <th>Logging</th>
 <th>LoRa OTA</th>
-<th>FULL</th>
-<th>FULL logging</th>
+<th>FULL unified</th>
+<th>FULL fallback</th>
 </tr>
 </thead>
 <tbody>
@@ -3186,8 +3188,8 @@ fix, no WiFi connection, an inactive bridge, or an nRF52 bootloader without
 </tr>
 <tr>
 <td>Logging</td>
-<td><a href="../cli_commands/#control-live-usb-logging"><code>get/set usb.logging</code></a></td>
-<td>Logging artifacts; session-only live USB output gate</td>
+<td><a href="../cli_commands/#control-live-usb-logging"><code>get/set usb.logging</code>; unified FULL <code>get/set logging.output</code></a></td>
+<td>Logging artifacts; CommonCLI USB gate is persistent; unified ESP32 FULL selects off/USB/WiFi/both; nRF52 Full Companion gates its second USB port</td>
 <td>No</td>
 <td>Yes</td>
 <td>No</td>

cli_commands/index.html

@@ -5150,8 +5150,13 @@ WiFi SSID, the command starts the open <code>MeshCore-Setup-XXXX</code> captive
 MQTT bridge, so run <code>set bridge.enabled off</code> first. Use <code>stop webconfig</code> to
 close either mode for the current boot. (<code>stop webconfig</code> does not change a
 saved <code>webui on</code>.)
-LAN mode otherwise remains active until reboot; setup mode stops after 10 minutes
-with no connected client.</p>
+LAN mode otherwise remains active until reboot. On expanded FULL builds, an
+unconfigured automatic setup AP receives one absolute 30-minute window per
+boot, then powers WiFi off even if a client remains attached; rebooting starts
+a new automatic window. An administrator can explicitly run <code>start webconfig</code>
+again without rebooting. Once an SSID is saved, the cutoff no longer applies
+and the selected WiFi/MQTT mode keeps reconnecting. Other setup sessions retain
+their profile's idle timeout.</p>
 <p>The saved <code>wifi.cli</code> setting defaults to <code>on</code>. Use <code>set wifi.cli off</code> to disable
 the <strong>CLI</strong> tab.
 <code>get wifi.cli</code> reports <code>off</code>, <code>on, waiting for WiFi client</code>, or <code>on, active</code>.
@@ -5171,7 +5176,8 @@ also stops the remaining block.</p>
 single-command mode. A command that stops WebConfig, changes its WiFi
 connection, disables <code>wifi.cli</code>, or reboots the node stops the remaining block
 and can close the page before its reply is collected.</p>
-<p>On FULL MQTT and FULL logging ESP32 repeater/room-server builds,
+<p>On unified FULL USB + WiFi and FULL logging-fallback ESP32
+repeater/room-server builds,
 <code>get wifi.ssid</code> reports the saved standalone WebConfig network and
 <code>get wifi.status</code> reports whether WiFi is unconfigured, off, connecting,
 running the setup AP, failed, or connected. A connected result includes the
@@ -5228,7 +5234,7 @@ remain available.</p>
 <p><strong>Usage:</strong> 
 - <code>discover.neighbors</code></p>
 <p>This command is available in every repeater build profile, including portable
-MQTT, standard, logging, OTA, FULL, and FULL logging artifacts. It does not
+MQTT, standard, logging, OTA, unified FULL, and FULL logging-fallback artifacts. It does not
 require MQTT or PSRAM.</p>
 <hr />
 <h3 id="discover-neighbor-scopes-mqtt-observer-neighbors-feature">Discover neighbor scopes (MQTT observer, neighbors feature)</h3>
@@ -5513,9 +5519,9 @@ decoded still emit their <code>RAW:</code> line. Transmitted packets emit the de
 summary.</p>
 <p>Ordinary <code>-logging-</code> artifacts keep packet logging separate from LoRa OTA.
 Use the separately named <code>-ota-</code> artifact when LoRa OTA is required. A
-<code>-full-logging-ota-</code> artifact is intentionally the exception: it combines
-logging with LoRa OTA and the expanded FULL feature set, while MQTT remains
-disabled.</p>
+<code>-full-usb-wifi-ota-</code> artifact combines USB packet logging, direct WiFi MQTT,
+LoRa OTA, and the expanded FULL feature set. A <code>-full-logging-ota-</code> artifact is
+emitted only when that hardware/role has no matching WiFi MQTT environment.</p>
 <h3 id="control-live-usb-logging">Control live USB logging</h3>
 <p><strong>Usage:</strong></p>
 <pre><code class="language-text">get usb.logging
@@ -5523,11 +5529,26 @@ set usb.logging on
 set usb.logging off
 </code></pre>
 <p>These commands are compiled into logging artifacts and control their live USB
-debug and packet output. The switch is session-only: every reboot starts a
-logging artifact with USB logging on. Turning it off does not disable CLI
-replies, Companion protocol frames, or essential non-debug serial messages.
-It also does not change the node-storage capture controlled by <code>log start</code> and
-<code>log stop</code>.</p>
+debug and packet output. CommonCLI roles save the setting in <code>/com_prefs</code>, so
+it survives reboot; first boot defaults to on. nRF52 Full Companion applies the
+gate only to USB interface <code>02</code>, its dedicated plaintext logging port. USB
+interface <code>00</code> continues carrying Companion, terminal, and serial mOTA traffic.
+Turning USB logging off does not disable CLI replies or Companion protocol
+frames. It also does not change the node-storage capture controlled by <code>log
+start</code> and <code>log stop</code>.</p>
+<p>Unified ESP32 FULL builds add one saved selector for both output paths:</p>
+<pre><code class="language-text">get logging.output
+set logging.output off
+set logging.output usb
+set logging.output wifi
+set logging.output both
+</code></pre>
+<p><code>usb</code> emits <code>RAW:</code> packets for a USB-connected service such as
+meshcoretomqtt. <code>wifi</code> enables the direct MQTT bridge configured by the
+<code>wifi.*</code> and <code>mqtt.*</code> commands. <code>both</code> intentionally duplicates the radio
+stream to both consumers; do not point both consumers at the same broker unless
+the downstream setup deduplicates messages. Fresh unified FULL installs start
+in <code>both</code> mode.</p>
 <h3 id="begin-capture-of-rx-log-to-node-storage">Begin capture of rx log to node storage</h3>
 <p><strong>Usage:</strong> <code>log start</code></p>
 <hr />

companion_radio_full/index.html

@@ -511,6 +511,23 @@
     </span>
   </a>
   
+    <nav class="md-nav" aria-label="USB Binary and text terminal modes">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#nrf52-dual-usb-serial-ports" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        nRF52 dual USB serial ports
+      
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
 </li>
       
         <li class="md-nav__item">
@@ -1341,6 +1358,23 @@
     </span>
   </a>
   
+    <nav class="md-nav" aria-label="USB Binary and text terminal modes">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#nrf52-dual-usb-serial-ports" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        nRF52 dual USB serial ports
+      
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
 </li>
       
         <li class="md-nav__item">
@@ -1498,11 +1532,15 @@ interactive menu item or run:</p>
 <pre><code class="language-bash">bash build.sh build-full-companion-firmwares \
   --firmware-version v1.17.0
 </code></pre>
-<p>Heltec <code>_femon</code> Companion firmware can switch the external FEM receive gain at
-runtime, so the Companion bulk-build commands omit the redundant legacy
-<code>_femoff</code> targets. Those targets remain available through an explicit
-<code>build-firmware</code> command for compatibility. In WebConfig, use the <strong>FEM RX
-boost</strong> switch. From the text terminal (USB, or TCP 5002 on ESP32), use:</p>
+<p>Canonical Companion bulk builds also omit legacy <code>_ps</code> and <code>_femoff</code> aliases.
+Power saving and controllable FEM receive gain are persisted runtime settings;
+the old names remain available through an explicit <code>build-firmware</code> command
+for compatibility. On nRF52, Full Companion replaces separate USB and BLE
+normal release artifacts whenever the exact board has both recipes. It also
+replaces the USB-only packet-logging artifact: one physical USB connection
+enumerates separate Companion and logging serial ports, so plaintext logs
+cannot corrupt binary frames. In WebConfig, use the
+<strong>FEM RX boost</strong> switch. From the text terminal (USB, or TCP 5002 on ESP32), use:</p>
 <pre><code class="language-text">get radio.rxgain
 set radio.rxgain off
 set radio.rxgain on
@@ -1693,9 +1731,29 @@ is active; do not enter the start token again after it appears.</p>
 <code>trace [recipient-name-or-prefix]</code>, plus local <code>ota</code>, <code>tempradio</code>, and
 <code>normalradio</code> controls. ESP32 builds also provide local
 WiFi credential, status, WebConfig, CLI-tab, and power-save controls. Logging
-artifacts additionally provide session-only
-<code>get/set usb.logging</code>; turning it off suppresses live USB diagnostics without
-disabling Companion frames or terminal replies.</p>
+artifacts additionally provide <code>get/set usb.logging</code>; turning it off
+suppresses live USB diagnostics without disabling Companion frames or terminal
+replies. nRF52 Full Companion saves this setting and applies it only to its
+dedicated logging port.</p>
+<h3 id="nrf52-dual-usb-serial-ports">nRF52 dual USB serial ports</h3>
+<p>Current nRF52 Full Companion firmware exposes two CDC ACM serial interfaces on
+one physical USB cable:</p>
+<ul>
+<li>USB interface <code>00</code> is the normal Binary Companion, text terminal, and serial
+  mOTA source port.</li>
+<li>USB interface <code>02</code> is a write-only plaintext packet/debug logging port. Host
+  input on this interface is ignored and cannot invoke firmware commands.</li>
+</ul>
+<p>On Linux these normally appear as two <code>/dev/ttyACM*</code> devices. Match the stable
+<code>/dev/serial/by-id/*-if00</code> and <code>*-if02</code> links, or use a udev rule matching
+<code>ID_USB_INTERFACE_NUM</code>, rather than assuming which tty number is assigned. On
+Windows they appear as two COM ports; identify them by USB interface instead of
+depending on a particular COM number. The bootloader may temporarily expose
+only its normal DFU serial interface while an update is active.</p>
+<p>Point MeshCore Companion software, <code>meshcli</code>, and <code>motatool</code> at interface <code>00</code>.
+Point a plaintext reader or USB-connected MQTT service at interface <code>02</code>. Use
+<code>set usb.logging off|on</code> through the Companion terminal to persist whether the
+second port emits output.</p>
 <p>ESP32 Full Companion exposes this same text terminal on TCP port 5002. Connect
 with <code>nc DEVICE_IP 5002</code>; no USB control token is needed. USB terminal mode and
 the TCP terminal share recipient, login, command, trace, and display state, so

firmware_picker/index.html

@@ -1511,6 +1511,10 @@ from the published firmware assets.</p>
 <td>Firmware connects directly to MQTT over Wi-Fi; this is not USB logging</td>
 </tr>
 <tr>
+<td>USB logging + Wi-Fi MQTT</td>
+<td>Unified FULL image sends to both paths; avoid two publishers aimed at the same broker unless messages are deduplicated</td>
+</tr>
+<tr>
 <td>No logging</td>
 <td>Normal standalone operation without the dedicated logging/MQTT profile</td>
 </tr>
@@ -1537,6 +1541,23 @@ partition layout.</p>
 <p>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.</p>
+<p>Current <code>full-usb-wifi</code> 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 <code>set logging.output off|usb|wifi|both</code>. 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 <code>set usb.logging off|on</code> 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 <code>start webconfig</code> remains
+available as an override. A saved SSID switches to the normal indefinite
+reconnect behavior instead.</p>
+<p>Current nRF52 Full Companion profiles also use one binary for normal attached
+Companion use and USB packet logging. One USB cable exposes interface <code>00</code> for
+Binary Companion, terminal, and mOTA source traffic, plus interface <code>02</code> for
+plaintext logging. The picker therefore omits the older separate nRF52 USB,
+BLE, and USB-logging Companion choices when the matching Full artifact exists.
+Use <code>set usb.logging off|on</code> to persist the second port's output state.</p>
 <h2 id="installation-methods">Installation methods</h2>
 <table>
 <thead>
@@ -1582,9 +1603,16 @@ and select the hardware-matched HEX, Serial DFU ZIP, or bootloader-update UF2.</
 <p>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 build choices such as FEM on/off,
-power saving, serial port, or no-external-sensors. Do not substitute a
-similarly named target.</p>
+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.</p>
+<p>For nRF52 hardware with a Full Companion image, the picker recommends that one
+normal image instead of separate USB, BLE, and USB-logging images. Full
+Companion provides both attached transports and a dedicated plaintext logging
+port without mixing logs into framed Companion traffic. Exact filename search
+still finds old aliases from earlier releases.</p>
 
 
 

lora_ota_automation/index.html

@@ -1577,8 +1577,10 @@ rejects an attempt to use the same port for both.</p>
 the mOTA data framing. On an nRF52 full Companion, the script uses that mode
 briefly for <code>ota status</code> and TempRadio commands. It then closes the CLI and
 starts <code>motatool</code>, whose existing <code>ota folder on</code> preamble switches the same
-USB port into exclusive mOTA mode. On an ESP32 Full Companion with serial
-folder support, <code>motatool --companion-terminal</code> keeps the ASCII session open
+USB interface <code>00</code> into exclusive mOTA mode. Its separate USB interface <code>02</code>
+continues to provide plaintext logging and is not a controller or source port.
+On an ESP32 Full Companion with serial folder support,
+<code>motatool --companion-terminal</code> keeps the ASCII session open
 while the same link carries framed folder requests. BLE remains available.</p>
 <h2 id="destination-requirements">Destination requirements</h2>
 <table>

ota_easy/index.html

@@ -1755,14 +1755,15 @@ firmware can still relay OTA packets opaquely during TempRadio.</p>
 speed optimization. This prevents the retained software Ed25519 fallback from expanding beyond the fixed
 in-place workspace; CC310 hardware crypto, hardware RNG mixing, telemetry history, and board-native features
 remain enabled.</p>
-<p>ESP32 <code>*-full-ota-*</code> artifacts retain all compiled features and enable LoRa OTA for every FULL role,
+<p>ESP32 <code>*-full-usb-wifi-ota-*</code> artifacts retain all compiled features and enable LoRa OTA for every FULL role,
 including room servers, sensors, observers, and bridges. A FULL image requires its expanded partition table:
 install the matching merged image over USB once before installing later non-merged FULL updates over LoRa.
 ESP32 MQTT observers and ESP-NOW bridges are always emitted as FULL artifacts; compact-CLI variants are no
 longer built.
-The <code>*-full-ota-*</code> profile uses MQTT with logging off. Use a <code>*-full-logging-ota-*</code> artifact when USB debug
-and packet logging are needed instead; that diagnostic profile explicitly disables MQTT and can produce
-substantial serial output.</p>
+The <code>*-full-usb-wifi-ota-*</code> profile compiles USB packet logging and direct WiFi MQTT into one image. Use
+<code>set logging.output off|usb|wifi|both</code> to persist the desired path. A <code>*-full-logging-ota-*</code> artifact is now
+only a fallback for a hardware/role combination without a WiFi MQTT target and can produce substantial
+serial output.</p>
 <h3 id="choose-the-source-radio">Choose the source radio</h3>
 <p>Use an OTA-enabled MeshCore node as the source. It receives the update folder
 from the computer, then advertises it over LoRa. ESP32 USB/WiFi companions and
@@ -1772,14 +1773,15 @@ serves host images but cannot stage or install one for itself. ESP32 full
 combines USB, BLE, and WiFi; nRF52 full combines USB and BLE because nRF52840
 has no WiFi.
 A small set of high-capacity, non-PSRAM classic ESP32 companions
-keep their normal image and provide a separate <code>-full-ota-</code> image with 100 contacts, 8 group channels, and
-a 16-frame offline queue. Install that variant's merged image over USB once before using it. Connect the
+keep their normal image and provide a separate <code>-full-logging-ota-</code> fallback with 100 contacts, 8 group
+channels, a 16-frame offline queue, and persistent USB output selection. Install that variant's merged
+image over USB once before using it. Connect the
 source by USB serial or, when supported, by WiFi. For an ordinary raw-text USB
 source, confirm that its USB CLI accepts:</p>
 <pre><code class="language-text">ota folder on
 </code></pre>
-<p>If an older build reports that <code>OTA_FOLDER_SERIAL</code> is not compiled in, install a current <code>-ota-</code> or
-<code>-full-ota-</code> build first. Do <strong>not</strong> use a KISS modem: KISS firmware is a TNC/KISS frame interface
+<p>If an older build reports that <code>OTA_FOLDER_SERIAL</code> is not compiled in, install a current <code>-ota-</code>,
+<code>-full-usb-wifi-ota-</code>, or applicable <code>-full-logging-ota-</code> build first. Do <strong>not</strong> use a KISS modem: KISS firmware is a TNC/KISS frame interface
 and does not provide the MeshCore CLI or the OTA-folder transport that <code>motatool serve</code> requires.</p>
 <p>An nRF52 <code>companion_radio_full</code> starts in USB Binary mode. Use
 <code>+++MESHCORE-TERM-START</code> for local TempRadio commands, then return with

ota_protocol/index.html

@@ -2097,8 +2097,9 @@ EndF trailer (fixed 56 bytes):
 LoRa OTA and carry <code>-ota-</code> in their filenames so they can seed a host folder over serial or TCP; they keep
 their target partition table rather than using the FULL profile. A small set of high-capacity, non-PSRAM classic ESP32
 companions cannot combine their configured contact, group-channel, and offline-queue capacities with LoRa
-OTA in internal DRAM. Their normal artifacts remain unchanged, and option 3 also emits <code>-full-ota-</code> and
-<code>-full-logging-ota-</code> variants with 100 contacts, 8 group channels, and a 16-frame offline queue. MQTT
+OTA in internal DRAM. Their normal artifacts remain unchanged, and option 3 emits a
+<code>-full-logging-ota-</code> fallback with 100 contacts, 8 group channels, a 16-frame offline queue, and a saved
+USB-logging on/off gate. MQTT
 observers and ESP-NOW bridges always use FULL builds because fitting them into the legacy slot would require
 removing CLI and role features. Except for those FULL roles and the ESP32-C6 case below, non-companion ESP32
 artifacts, including room, sensor, and repeater roles, must fit the legacy slot from <code>0x10000</code> up to
@@ -2134,21 +2135,27 @@ complete CLI.</p>
 during a settings save restores the last committed common preference image or publishes the completed new
 image; it does not leave a partially written <code>/com_prefs</code> file to fail on the next boot. A truncated legacy
 image is rejected before any partial radio or string fields are applied, then rewritten from safe defaults.</p>
-<p>Option 3 in <code>build.sh</code> emits <code>*-full-ota-*</code> and <code>*-full-logging-ota-*</code> ESP32 artifacts for
-FULL-capable non-companion roles and for the constrained companion fallbacks described above. MQTT observers
-and ESP-NOW bridges are emitted only with expanded FULL partitions. Menu option 8, or
-<code>build-full-esp32-firmwares</code>, builds the logging-off FULL
-artifacts from matching MQTT targets. Menu option 9, or <code>build-full-esp32-logging-firmwares</code>, builds the
-FULL logging artifacts from matching non-MQTT targets.
+<p>Option 3 in <code>build.sh</code> emits one <code>*-full-usb-wifi-ota-*</code> ESP32 artifact for each
+FULL-capable non-companion hardware/role that has a matching MQTT environment.
+It compiles USB packet logging and direct WiFi MQTT together. A
+<code>*-full-logging-ota-*</code> fallback is emitted only when there is no MQTT sibling;
+the old separate standard-logging and non-MQTT FULL twins are skipped for
+covered ESP32 roles. MQTT observers and ESP-NOW bridges are emitted only with
+expanded FULL partitions. Menu option 8, or <code>build-full-esp32-firmwares</code>,
+builds the unified profiles plus necessary fallbacks. Menu option 9, or
+<code>build-full-esp32-logging-firmwares</code>, builds only those fallbacks.
 FULL builds restore WebConfig, display support, optional external sensors, and the full role CLI and feature
 set,
 full ElegantOTA where that target declares the required library, and LoRa OTA for every included role,
 including room servers, sensors, observers, and bridges. They use expanded A/B partition
 tables: 1984 KiB application slots on 4 MiB boards and the framework's larger dual-OTA tables on 8 MiB
 and 16 MiB boards. Explicit <code>*_lora_ota_no_external_sensors</code> targets are not duplicated; their ordinary
-repeater build is the FULL, sensor-enabled counterpart. The <code>*-full-logging-ota-*</code> profile enables USB
-debug and packet logging and explicitly disables MQTT. Install a matching
-<code>*-full-ota-*-merged.bin</code> or <code>*-full-logging-ota-*-merged.bin</code> over USB once to write the expanded partition
+repeater build is the FULL, sensor-enabled counterpart. The
+<code>*-full-usb-wifi-ota-*</code> profile enables USB packet logging and MQTT, with a
+persistent <code>logging.output</code> selector; its verbose internal debug remains off.
+The fallback <code>*-full-logging-ota-*</code> profile enables USB debug and packet
+logging and has no MQTT target. Install a matching
+<code>*-full-usb-wifi-ota-*-merged.bin</code> or <code>*-full-logging-ota-*-merged.bin</code> over USB once to write the expanded partition
 table. After that, its matching non-merged FULL application image can be installed through USB, WiFi OTA,
 or LoRa OTA. Do not install a non-merged FULL image onto a node that still has its old partition table.</p>
 <blockquote>

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":"Introduction","text":"<p>Welcome to the MeshCore documentation.</p> <p>Below are a few quick start guides.</p> <ul> <li>Frequently Asked Questions</li> <li>Firmware Picker</li> <li>CLI Commands</li> <li>LoRa CLI Host Service</li> <li>Filter Policy Playground</li> <li>Telemetry Decoder</li> <li>CLI Availability by Firmware Build</li> <li>Easy LoRa OTA: ESP32 and nRF52 firmware updates</li> <li>Scripted LoRa OTA: Bash and PowerShell</li> <li>nRF52 repeater OTA with external QSPI</li> <li>nRF52 bootloader updates over LoRa</li> <li>MeshTower V2 microSD self-updates</li> <li>GPS Tracking</li> <li>Companion Protocol</li> <li>Companion Offline Message Queue</li> <li>Full Companion: ESP32 and nRF52</li> <li>Packet Format</li> <li>QR Codes</li> </ul> <p>If you find a mistake in any of our documentation, or find something is missing, please feel free to open a pull request for us to review.</p> <ul> <li>Documentation Source</li> </ul>"},{"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. For example, a logging repeater is not an MQTT observer, and a WiFi companion does not publish to MQTT unless its target name also contains <code>mqtt</code>.</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 USB, BLE, or serial companion 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; 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>"},{"location":"WiFi/#how-the-mqtt-bridge-works","title":"How the MQTT bridge works","text":"<p>The MQTT bridge is an outbound observer. It does not subscribe to MQTT topics and does not inject broker messages into LoRa.</p> <p>For a received packet, the flow is:</p> <pre><code>LoRa radio -&gt; successful packet parse -&gt; MQTT capture queue -&gt; broker slots\n                                  \\----&gt; normal MeshCore filtering/handling\n</code></pre> <p>Packets transmitted by the node can also be queued according to <code>mqtt.tx</code>. Receive capture happens before the packet is passed to the normal MeshCore flood filters and forwarding decision. A packet may therefore be observed on MQTT even when a later scope, path, region, duplicate, or repeat rule prevents the node from forwarding it over LoRa.</p> <p>MQTT publication and LoRa repetition are separate:</p> <ul> <li><code>set repeaLine truncated
+{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"],"fields":{"title":{"boost":1000.0},"text":{"boost":1.0},"tags":{"boost":1000000.0}}},"docs":[{"location":"","title":"Introduction","text":"<p>Welcome to the MeshCore documentation.</p> <p>Below are a few quick start guides.</p> <ul> <li>Frequently Asked Questions</li> <li>Firmware Picker</li> <li>CLI Commands</li> <li>LoRa CLI Host Service</li> <li>Filter Policy Playground</li> <li>Telemetry Decoder</li> <li>CLI Availability by Firmware Build</li> <li>Easy LoRa OTA: ESP32 and nRF52 firmware updates</li> <li>Scripted LoRa OTA: Bash and PowerShell</li> <li>nRF52 repeater OTA with external QSPI</li> <li>nRF52 bootloader updates over LoRa</li> <li>MeshTower V2 microSD self-updates</li> <li>GPS Tracking</li> <li>Companion Protocol</li> <li>Companion Offline Message Queue</li> <li>Full Companion: ESP32 and nRF52</li> <li>Packet Format</li> <li>QR Codes</li> </ul> <p>If you find a mistake in any of our documentation, or find something is missing, please feel free to open a pull request for us to review.</p> <ul> <li>Documentation Source</li> </ul>"},{"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. For example, a logging repeater is not an MQTT observer, and a WiFi companion does not publish to MQTT unless its target name also contains <code>mqtt</code>.</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 USB, BLE, or serial companion 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; 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>"},{"location":"WiFi/#how-the-mqtt-bridge-works","title":"How the MQTT bridge works","text":"<p>The MQTT bridge is an outbound observer. It does not subscribe to MQTT topics and does not inject broker messages into LoRa.</p> <p>For a received packet, the flow is:</p> <pre><code>LoRa radio -&gt; successful packet parse -&gt; MQTT capture queue -&gt; broker slots\n                                  \\----&gt; normal MeshCore filtering/handling\n</code></pre> <p>Packets transmitted by the node can also be queued according to <code>mqtt.tx</code>. Receive capture happens before the packet is passed to the normal MeshCore flood filters and forwarding decision. A packet may therefore be observed on MQTT even when a later scope, path, region, duplicate, or repeat rule prevents the node from forwarding it over LoRa.</p> <p>MQTT publication and LoRa repetition are separate:</p> <ul> <li><code>set repeaLine truncated

sitemap.xml

@@ -2,138 +2,138 @@
 <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
     <url>
          <loc>https://mikecarper.github.io/MeshCore/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/WiFi/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/cli_build_matrix/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/cli_command_availability/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/cli_commands/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/companion_offline_queue/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/companion_protocol/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/companion_radio_full/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/docs/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/faq/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/filter_tool/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/firmware_picker/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/flood_filtering/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/gps_tracking/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/halo_keymind_settings/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/host_cli_service/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/kiss_modem_protocol/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/lora_ota_automation/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/mbedtls-tls-footprint/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/nrf52_power_management/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/number_allocations/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/ota_easy/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/ota_meshtower_v2_sdcard/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/ota_nrf52_bootloader_update/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/ota_nrf52_qspi/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/ota_protocol/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/ota_user_guide/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/packet_format/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/payloads/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/qr_codes/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/rak3401_mota_chain/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/stats_binary_frames/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/telemetry_decoder/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
     <url>
          <loc>https://mikecarper.github.io/MeshCore/terminal_chat_cli/</loc>
-         <lastmod>2026-08-23</lastmod>
+         <lastmod>2026-08-24</lastmod>
     </url>
 </urlset>