mirror of
https://github.com/mikecarper/MeshCore.git
synced 2026-11-12 10:07:33 +00:00
deploy: 236d12610c
This commit is contained in:
mikecarper committed
1 parent
eca775de2e
commit
9d8ea3f71a
4 files changed
+165
-1
No files matched your search
@@ -7751,6 +7751,12 @@
|
||||
<!-- meshcore-hosted-doc-link:end -->
|
||||
|
||||
<h1 id="cli-commands">CLI Commands</h1>
|
||||
<p>For hardware-specific app templates, use <code>get hardware</code>, then prefix a command
|
||||
with <code>@board/role</code>, for example <code>@Heltec_tower_v2/r ota pull A1B2C3D4 flash</code>.
|
||||
<code>/r</code> means repeater, <code>/s</code> room server, <code>/c</code> Companion and <code>/n</code> sensor. Other
|
||||
hardware replies <code>OK - skipped (hardware/role)</code>. A short <code>@#<hardware-id>/r</code>
|
||||
form is also available. See <a href="../fleet_management/#hardware-and-role-conditions">hardware and role conditions</a>
|
||||
for signed fleet use, availability and OTA prerequisites.</p>
|
||||
<p>For SolarXiao Base/Advanced/MPPT automatic detection, manual overrides, live
|
||||
battery/MCU readings and charger controls, see <a href="../solarxiao_power/">SolarXiao carrier profiles</a>
|
||||
(<code>get solar</code>, <code>get solar readings</code>, <code>set solar.board auto</code>, <code>get mppt</code>, <code>set mppt</code>).</p>
|
||||
|
||||
@@ -1475,6 +1475,45 @@
|
||||
<nav class="md-nav" aria-label="Supported controls">
|
||||
<ul class="md-nav__list">
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#hardware-and-role-conditions" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
Hardware and role conditions
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
<nav class="md-nav" aria-label="Hardware and role conditions">
|
||||
<ul class="md-nav__list">
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#sd-backed-receivers" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
SD-backed receivers
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
</nav>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#packet-budget" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
Packet budget
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#two-packet-delivery" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
@@ -2706,6 +2745,45 @@
|
||||
<nav class="md-nav" aria-label="Supported controls">
|
||||
<ul class="md-nav__list">
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#hardware-and-role-conditions" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
Hardware and role conditions
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
<nav class="md-nav" aria-label="Hardware and role conditions">
|
||||
<ul class="md-nav__list">
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#sd-backed-receivers" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
SD-backed receivers
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
</nav>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#packet-budget" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
Packet budget
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#two-packet-delivery" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
@@ -2978,6 +3056,64 @@ Each receiving node reserves the Unix-second sequence in durable storage
|
||||
including after reboot or a lost reply. Retry an uncertain command with a fresh
|
||||
sequence; the operation should be chosen to be idempotent.</p>
|
||||
<h2 id="supported-controls">Supported controls</h2>
|
||||
<h3 id="hardware-and-role-conditions">Hardware and role conditions</h3>
|
||||
<p>Use <code>get hardware</code> on a node to find its hardware name, role and short ID:</p>
|
||||
<pre><code class="language-text">> hw=heltec_tower_v2 role=repeater id=536D28C9
|
||||
</code></pre>
|
||||
<p>Prefix a command with <code>@board/role</code> to run it only on matching hardware:</p>
|
||||
<pre><code class="language-text">@Heltec_tower_v2/r ota pull A1B2C3D4 flash
|
||||
@#536D28C9/r ota pull A1B2C3D4 flash
|
||||
</code></pre>
|
||||
<p>The second line is the shorter spelling of the first. <code>/r</code> selects repeaters,
|
||||
<code>/s</code> room servers, <code>/c</code> Companions and <code>/n</code> sensors. Omit <code>/role</code> to match any
|
||||
role on that board; <code>@*/r</code> selects any repeater. Hardware names ignore case and
|
||||
accept underscores for spaces. Use the reported name or ID: board names can
|
||||
differ between builds with different storage or radio hardware.</p>
|
||||
<p>These prefixes work in ordinary authenticated admin CLI queues as well as signed
|
||||
fleet commands. A mismatched node replies <code>OK - skipped (hardware/role)</code> and
|
||||
does not run the inner command, so an app can continue its template queue.
|
||||
Sensor and Companion guards work in their ordinary CLI; signed fleet reception
|
||||
remains limited to repeaters and room servers.
|
||||
For example, after the existing fleet enrollment:</p>
|
||||
<pre><code class="language-text">fleet send 3 get hardware
|
||||
fleet send 3 @Heltec_tower_v2/r get radio2
|
||||
fleet send 3 @#536D28C9/r ota pull A1B2C3D4 flash
|
||||
fleet send 3 @*/s get radio2
|
||||
</code></pre>
|
||||
<p>Fleet OTA pulls require a specific hardware name or short ID, <code>/r</code> or <code>/s</code>,
|
||||
the exact eight-hex-digit manifest ID from <code>ota ls</code>, and the <code>flash</code> destination.
|
||||
The normal <a href="../lora_ota_automation/">LoRa OTA setup</a>, temporary-radio requirement,
|
||||
image compatibility checks and signer policy still apply. Explicit installation,
|
||||
rescue and bootloader commands are not added to fleet control. An existing
|
||||
autoinstall setting retains its normal effect.</p>
|
||||
<h4 id="sd-backed-receivers">SD-backed receivers</h4>
|
||||
<p>The same <code>flash</code> destination selects the receiver's configured OTA store,
|
||||
including microSD on the SD-enabled MeshTower V2 and adaptive RAK4631/RAK15002
|
||||
receiver builds. It does not force internal-flash staging. Use the hardware
|
||||
identity reported by <code>get hardware</code>, not the SD module's name:</p>
|
||||
<pre><code class="language-text">fleet send 3 @Heltec_tower_v2/r ota pull A1B2C3D4 flash
|
||||
fleet send 3 @RAK4631/r ota pull 11223344 flash
|
||||
</code></pre>
|
||||
<p>Each ID must identify that board's update. SD installation requires a usable
|
||||
card, the matching SD-capable bootloader and a signed package from a trusted
|
||||
signer. Check <code>ota self</code> and <code>ota storage</code> through individual admin CLI before
|
||||
starting. An SD socket or an archive-only firmware build does not enable
|
||||
installation; SD Companions and the legacy RAK15002 seeder remain sources only.
|
||||
SD partial downloads remain on the card for resume. Keep the card inserted
|
||||
through download and installation; the receiver does not move an active
|
||||
transfer to internal storage if the card is removed. See
|
||||
<a href="../ota_meshtower_v2_sdcard/#automatic-storage-selection">MeshTower SD storage selection</a>
|
||||
and <a href="../ota_nrf52_qspi/">RAK4631 storage options</a>.</p>
|
||||
<p>The prefix is covered by the existing command signature and consumes the normal
|
||||
command-byte budget; no extra packet format is needed. Its short ID is a
|
||||
32-bit FNV-1a hash of the hardware name after lowercasing and replacing spaces
|
||||
with underscores. It is a selector, not an authentication or compatibility key.
|
||||
Ordinary unguarded commands retain their existing behavior. Older firmware
|
||||
rejects guarded commands; both endpoints need this support for signed fleet use.
|
||||
Fixed-size STM32 builds omit hardware guards with fleet control. Run password,
|
||||
private-key backup, replay-recovery and interactive <code>region load</code> commands
|
||||
without a guard so their existing special handling remains in charge.</p>
|
||||
<h3 id="packet-budget">Packet budget</h3>
|
||||
<p>The Companion automatically uses <strong>one or two LoRa packets</strong>, depending on the
|
||||
signed command's size. Whole-fleet commands fit <strong>87 ASCII bytes</strong> in one packet
|
||||
or <strong>230 bytes</strong> across two. Targets consume some of that allowance:</p>
|
||||
@@ -3101,6 +3237,18 @@ Reboot or changing enrollment discards the partial transfers.</p>
|
||||
<td><code>clock</code>, <code>clock sync</code>, <code>time <epoch-seconds></code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Hardware identity</td>
|
||||
<td><code>get hardware</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>OTA download</td>
|
||||
<td><code>@board/r ota pull <manifest-id-8-hex> flash</code> (<code>/s</code> for rooms)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>OTA progress</td>
|
||||
<td><code>ota status</code>, <code>ota stats</code>, <code>ota self</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Profile diagnostics</td>
|
||||
<td><code>get radio2.status</code>, <code>get radio2.timing</code></td>
|
||||
</tr>
|
||||
|
||||
@@ -2741,6 +2741,16 @@ canonical MeshTower V2 repeater target. Its SD OTA target ID <code>0A9DBBF0</cod
|
||||
hardware ID <code>Heltec_tower_v2</code>, application layout, and artifact names remain
|
||||
unchanged. The required Full and Reduced sensor choices use that same target.
|
||||
Existing SD users need no configuration change.</p>
|
||||
<p>Firmware with <a href="../fleet_management/#hardware-and-role-conditions">hardware-aware fleet commands</a>
|
||||
can start a download on this receiver with:</p>
|
||||
<pre><code class="language-text">fleet send 3 @Heltec_tower_v2/r ota pull A1B2C3D4 flash
|
||||
</code></pre>
|
||||
<p>Replace the example ID with the signed update's eight-digit ID from <code>ota ls</code>.
|
||||
<code>flash</code> selects this build's OTA store, including SD when a usable card is
|
||||
selected. The private fleet enrollment, temporary-radio window, trusted signer
|
||||
and matching SD-aware bootloader are still required. This command starts the
|
||||
download; explicit installation remains an individual admin operation, and an
|
||||
already-enabled trusted autoinstall policy retains its normal effect.</p>
|
||||
<p>The build aliases <code>Heltec_tower_v2_repeater</code> and
|
||||
<code>Heltec_tower_v2_repeater_lora_ota_no_external_sensors</code> resolve to this primary
|
||||
target. An installed internal-only image has a different OTA identity and
|
||||
|
||||
@@ -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":"Home","text":"<p>View this page on MeshCore Docs.</p>"},{"location":"#meshcore-documentation","title":"MeshCore documentation","text":""},{"location":"#start-here","title":"Start here","text":"<p>Current stable release: 1.18.0.1 USA Cascade. Read what changed, which boards benefit and the known limitations in one place.</p> I want to... Start here See what is new or fixed 1.18.0.1 release notes Download firmware for my board Firmware picker Install an update Update guide Turn a feature on or off Feature controls by role Find a command CLI reference Troubleshoot a device FAQ"},{"location":"#detailed-guides","title":"Detailed guides","text":"<ul> <li> <p>SolarXiao Base/Advanced/MPPT detection and battery controls</p> </li> <li> <p>Feature switches by role and Full Companion features</p> </li> <li>Firmware update guide, easy LoRa OTA, and scripted LoRa OTA</li> <li>CLI commands, availability by build, and radio profiles</li> <li>Private fleet management: signed filtering and secondary-radio commands for a fleet or one node</li> <li>Room history, moderation, and information board: optional persistent chat and local Wi-Fi room access</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>Test Results - hardware and build evidence, with the tested versions</li> <li>Research - design notes, diagnostics, and historical update-chain studies</li> <li>Old Releases - historical release notes and supporting files</li> </ul> <p>Found a mistake or missing information? Edit the documentation.</p>"},{"location":"WiFi/","title":"WiFi","text":"<p>View this page on MeshCore Docs.</p>"},{"location":"WiFi/#wifi-and-mqtt-by-firmware-type","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-dependenLine truncated
|
||||
{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"],"fields":{"title":{"boost":1000.0},"text":{"boost":1.0},"tags":{"boost":1000000.0}}},"docs":[{"location":"","title":"Home","text":"<p>View this page on MeshCore Docs.</p>"},{"location":"#meshcore-documentation","title":"MeshCore documentation","text":""},{"location":"#start-here","title":"Start here","text":"<p>Current stable release: 1.18.0.1 USA Cascade. Read what changed, which boards benefit and the known limitations in one place.</p> I want to... Start here See what is new or fixed 1.18.0.1 release notes Download firmware for my board Firmware picker Install an update Update guide Turn a feature on or off Feature controls by role Find a command CLI reference Troubleshoot a device FAQ"},{"location":"#detailed-guides","title":"Detailed guides","text":"<ul> <li> <p>SolarXiao Base/Advanced/MPPT detection and battery controls</p> </li> <li> <p>Feature switches by role and Full Companion features</p> </li> <li>Firmware update guide, easy LoRa OTA, and scripted LoRa OTA</li> <li>CLI commands, availability by build, and radio profiles</li> <li>Private fleet management: signed filtering and secondary-radio commands for a fleet or one node</li> <li>Room history, moderation, and information board: optional persistent chat and local Wi-Fi room access</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>Test Results - hardware and build evidence, with the tested versions</li> <li>Research - design notes, diagnostics, and historical update-chain studies</li> <li>Old Releases - historical release notes and supporting files</li> </ul> <p>Found a mistake or missing information? Edit the documentation.</p>"},{"location":"WiFi/","title":"WiFi","text":"<p>View this page on MeshCore Docs.</p>"},{"location":"WiFi/#wifi-and-mqtt-by-firmware-type","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-dependenLine truncated
|
||||
Reference in new issue
Block a user