mirror of
https://github.com/mikecarper/MeshCore.git
synced 2026-10-23 18:02:29 +00:00
deploy: fe9d48ea69
This commit is contained in:
mikecarper committed
1 parent
71cf33871a
commit
a2abca3d47
3 files changed
+34
-5
No files matched your search
@@ -502,6 +502,26 @@
|
||||
});
|
||||
}
|
||||
|
||||
function omitLegacyObserverCompatibilityProfiles(profiles) {
|
||||
const targets = new Set((profiles || []).map(function (profile) {
|
||||
return String(profile && profile.target || "").toLowerCase();
|
||||
}));
|
||||
|
||||
return (profiles || []).filter(function (profile) {
|
||||
const target = String(profile && profile.target || "");
|
||||
// Same-partition ESP32 migrations publish the ordinary target's Full
|
||||
// image with its established mOTA identity. The former observer-named
|
||||
// Full image remains in the release for deployed devices that still use
|
||||
// that identity, but it is not a second picker choice when the exact
|
||||
// successor is present. Keep an unmatched observer image visible: it
|
||||
// may still be the only compatible recipe for that hardware/role.
|
||||
const successor = target.replace(
|
||||
/_observer_mqtt_?(?=-full-usb-wifi$)/i, ""
|
||||
);
|
||||
return successor === target || !targets.has(successor.toLowerCase());
|
||||
});
|
||||
}
|
||||
|
||||
function applyFullCompanionCapabilities(profiles) {
|
||||
return (profiles || []).map(function (profile) {
|
||||
if (!isFullCompanion(profile)) return profile;
|
||||
@@ -681,10 +701,12 @@
|
||||
}).filter(function (profile) {
|
||||
return !isHiddenLegacyProfile(profile);
|
||||
});
|
||||
const profiles = applyMergedStandardUsbLoggingCapabilities(
|
||||
applyMergedRak4631RepeaterCapabilities(
|
||||
omitTransportsReplacedByFull(
|
||||
applyFullCompanionCapabilities(visibleProfiles)
|
||||
const profiles = omitLegacyObserverCompatibilityProfiles(
|
||||
applyMergedStandardUsbLoggingCapabilities(
|
||||
applyMergedRak4631RepeaterCapabilities(
|
||||
omitTransportsReplacedByFull(
|
||||
applyFullCompanionCapabilities(visibleProfiles)
|
||||
)
|
||||
)
|
||||
)
|
||||
).sort(function (a, b) {
|
||||
@@ -1773,6 +1795,8 @@
|
||||
applyFullCompanionCapabilities,
|
||||
canonicalHardware: canonicalHardware,
|
||||
omitTransportsReplacedByFull: omitTransportsReplacedByFull,
|
||||
omitLegacyObserverCompatibilityProfiles:
|
||||
omitLegacyObserverCompatibilityProfiles,
|
||||
omitTransportsReplacedByDualCdcFull:
|
||||
omitTransportsReplacedByFull,
|
||||
omitNrf52TransportsReplacedByFull:
|
||||
|
||||
@@ -3547,6 +3547,11 @@ plaintext CLI/logger and disables framed USB Companion until logging is turned
|
||||
off and the normal ASCII-to-binary mode switch occurs. nRF52 Full Companion
|
||||
retains its optional dedicated interface <code>02</code>.
|
||||
Exact filename search still finds old aliases from earlier releases.</p>
|
||||
<p>For same-partition ESP32 infrastructure migrations, the picker similarly
|
||||
recommends the ordinary target's exact-identity Full image when it is present.
|
||||
The former observer-named Full image remains available through exact filename
|
||||
search for deployed devices that still use that mOTA identity; it is not shown
|
||||
as a second recommended configuration.</p>
|
||||
<h2 id="maintaining-the-runtime-directions">Maintaining the runtime directions</h2>
|
||||
<p>The online picker and downloadable HTML use the same command renderer.
|
||||
Hardware-specific controls are enabled only when <code>_data/firmware_controls.json</code>
|
||||
|
||||
@@ -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>1.17.1.5 Markdown audit</li> <li>1.17.1.5 USA Cascade release</li> <li>Feature switches by role: Companion, Repeater, Room Server, Sensor</li> <li>USB web console</li> <li>Full Companion feature switches</li> <li>Frequently Asked Questions</li> <li>Firmware Picker</li> <li>Temporary Radio Test Command Generator</li> <li>CLI Commands</li> <li>LoRa CLI Host Service</li> <li>Filter Policy Playground</li> <li>Telemetry Decoder</li> <li>Management Report Decoder</li> <li>CLI Availability by Firmware Build</li> <li>Classic ESP32 image memory budget</li> <li>Full Companion contact caches and capacity trials</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>Full Companion USB CLI and binary switcher</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. 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>"},{"location":"WiFi/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":"Introduction","text":"<p>Welcome to the MeshCore documentation.</p> <p>Below are a few quick start guides.</p> <ul> <li>1.17.1.5 Markdown audit</li> <li>1.17.1.5 USA Cascade release</li> <li>Feature switches by role: Companion, Repeater, Room Server, Sensor</li> <li>USB web console</li> <li>Full Companion feature switches</li> <li>Frequently Asked Questions</li> <li>Firmware Picker</li> <li>Temporary Radio Test Command Generator</li> <li>CLI Commands</li> <li>LoRa CLI Host Service</li> <li>Filter Policy Playground</li> <li>Telemetry Decoder</li> <li>Management Report Decoder</li> <li>CLI Availability by Firmware Build</li> <li>Classic ESP32 image memory budget</li> <li>Full Companion contact caches and capacity trials</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>Full Companion USB CLI and binary switcher</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. 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>"},{"location":"WiFi/Line truncated
|
||||
Reference in new issue
Block a user