mirror of
https://github.com/mikecarper/MeshCore.git
synced 2026-11-03 14:02:24 +00:00
deploy: e7b863494c
This commit is contained in:
mikecarper committed
1 parent
725adde11c
commit
b2fd3f16f2
8 files changed
+2877
-4
No files matched your search
@@ -3734,6 +3734,17 @@
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#diagnose-the-esp-now-bridge" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
Diagnose the ESP-NOW bridge
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
@@ -6781,6 +6792,17 @@
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#diagnose-the-esp-now-bridge" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
Diagnose the ESP-NOW bridge
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
@@ -12114,6 +12136,120 @@ still overrides the first-boot default after an update.</p>
|
||||
<h4 id="view-the-compiled-bridge-type">View the compiled bridge type</h4>
|
||||
<p><strong>Usage:</strong> <code>get bridge.type</code></p>
|
||||
<hr />
|
||||
<h4 id="diagnose-the-esp-now-bridge">Diagnose the ESP-NOW bridge</h4>
|
||||
<p>Available when the optional ESP-NOW bridge is compiled in. These are runtime
|
||||
diagnostics; no <code>BRIDGE_DEBUG</code> build flag is required.</p>
|
||||
<p><strong>Read-only commands:</strong></p>
|
||||
<pre><code class="language-text">get espnow.status
|
||||
get espnow.stats
|
||||
get espnow.stats rx
|
||||
get espnow.stats tx
|
||||
get espnow.stats drops
|
||||
get espnow.stats test
|
||||
</code></pre>
|
||||
<p>Status reports local state (<code>off</code>, <code>teardown-error</code>, <code>driver-error</code>,
|
||||
<code>channel-mismatch</code> or <code>ready</code>), then these compact fields:</p>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Field</th>
|
||||
<th>Meaning</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>ch</code></td>
|
||||
<td>Configured/actual 2.4 GHz channel; actual <code>0</code> means unavailable.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>fmt</code>, <code>src</code></td>
|
||||
<td>Packet format and configured LoRa packet source (<code>rx</code> or <code>tx</code>).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>wifi</code></td>
|
||||
<td>Shared WiFi enable setting, not proof of WiFi association.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>mode</code>, <code>ps</code>, <code>proto</code></td>
|
||||
<td>WiFi SDK mode and power-save integers, and protocol bitmask in hexadecimal. An unavailable mode or power-save query returns <code>-1</code>.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>q</code></td>
|
||||
<td>Current receive/transmit queue depths.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>last</code></td>
|
||||
<td>Last recorded SDK error stage/code, which may remain after recovery.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p><code>espnow.running on</code> means the local bridge initialized; it does not prove a
|
||||
peer is reachable. The statistics pages use these keys:</p>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Page</th>
|
||||
<th>Keys and meaning</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Default</td>
|
||||
<td><code>rx</code>: received callback frames; <code>mesh</code>: inbound MeshCore packets queued; <code>tx</code>: outbound MeshCore packets queued; <code>sent</code>: successful frame callbacks.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>rx</code></td>
|
||||
<td><code>frames</code>: received callback frames; <code>decoded</code>: parsed MeshCore packets; <code>mesh</code>: queued for mesh processing; <code>crc</code>: checksum failures; <code>bad</code>: malformed frames; <code>parse</code>: packet parse failures.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>tx</code></td>
|
||||
<td><code>req</code>: mesh TX requests; <code>queued</code>: mesh packets queued; <code>start</code>: SDK-accepted frames; <code>ok</code>: successful frame callbacks; <code>err</code>: SDK start failures; <code>cbfail</code>: failed frame callbacks; <code>timeout</code>: callback timeouts.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>drops</code></td>
|
||||
<td><code>rxq</code>: RX queue drops; <code>foreign</code>: foreign-group packets; <code>filter</code>/<code>dupe</code>: inbound filter/duplicate drops; <code>txq</code>: recorded local mesh TX rejection/final-failure decisions; <code>txfilter</code>/<code>txdupe</code>: outbound filter/duplicate drops; <code>big</code>: oversize TX drops.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>test</code></td>
|
||||
<td><code>queued</code>, <code>start</code>, <code>ok</code>, <code>fail</code>, <code>timeout</code>: probe TX stages; <code>rx</code>, <code>bad</code>: valid/invalid probes received; <code>txid</code>, <code>rxid</code>: last queued/received IDs in hexadecimal.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>Mesh admission means queued for normal processing, not confirmed LoRa
|
||||
forwarding or end-to-end delivery. Packet and frame counters have different
|
||||
units: fragmentation can produce several frames for one mesh packet. Counters
|
||||
survive bridge stop/start; reboot or the explicit reset starts a new window.
|
||||
Stopping or restarting the bridge clears pending queue work without classifying
|
||||
its delivery. These counters are not a complete end-to-end delivery ledger.</p>
|
||||
<p><strong>Local-only actions:</strong></p>
|
||||
<pre><code class="language-text">espnow test
|
||||
espnow test A1B2C3D4
|
||||
espnow resetstats
|
||||
</code></pre>
|
||||
<p>The optional test ID is exactly eight hexadecimal digits, case-insensitive,
|
||||
without <code>0x</code>, spaces or trailing arguments. Omitting it uses uptime in
|
||||
milliseconds. The reply <code>OK - test queued id=...; confirm on peer</code> confirms
|
||||
local queueing only. Read the other updated board's <code>get espnow.stats test</code>
|
||||
and match <code>rxid</code>, with an increased <code>rx</code>, to establish one-way probe receipt. Send a
|
||||
different ID from the other board to test the reverse direction.</p>
|
||||
<p>A probe is unencrypted, CRC-checked transport diagnostic data, not a MeshCore
|
||||
packet or a security token. It does not verify packet-format compatibility or
|
||||
<code>bridge.secret</code>, authenticate the peer or establish normal packet delivery.
|
||||
There is no automatic echo,
|
||||
retry or LoRa forwarding; older firmware ignores it. Resetting statistics
|
||||
does not restart the bridge or write preferences. Test/reset commands are
|
||||
rejected over LoRa; use a local console. Every reply fits the bounded CLI
|
||||
frame, and diagnostics do not print from WiFi callbacks.</p>
|
||||
<p>For a short USB debug capture, record both <code>get usb.logging</code> and
|
||||
<code>get usb.debug</code>, then enable both <code>set usb.logging on</code> and <code>set usb.debug on</code>.
|
||||
Run the test and restore both original settings. The ordinary image emits
|
||||
bounded <code>ESPNOW:</code> updates from its main loop at most once per second when
|
||||
diagnostic state changes, even with <code>BRIDGE_DEBUG=0</code>. Updates can be skipped
|
||||
when USB is busy; read the counter pages for exact values. The CLI counter
|
||||
pages and probes do not require either logging gate.</p>
|
||||
<p>See the <a href="../espnow_bridge_setup/#test-the-24-ghz-path-without-lora-forwarding">two-board diagnostic flow</a>.
|
||||
Do not include <code>get bridge.secret</code> or WiFi credentials in shared debug logs.</p>
|
||||
<hr />
|
||||
<h4 id="view-or-change-the-bridge-enabled-flag">View or change the bridge enabled flag</h4>
|
||||
<p><strong>Search terms:</strong> enable bridge, disable bridge, serial bridge, RS232 bridge.</p>
|
||||
<p><strong>Usage:</strong>
|
||||
|
||||
@@ -1455,6 +1455,45 @@
|
||||
</span>
|
||||
</a>
|
||||
|
||||
<nav class="md-nav" aria-label="4. Check the link">
|
||||
<ul class="md-nav__list">
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#test-the-24-ghz-path-without-lora-forwarding" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
Test the 2.4 GHz path without LoRa forwarding
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#locate-a-mesh-forwarding-failure" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
Locate a mesh forwarding failure
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#optional-short-usb-debug-capture" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
Optional short USB debug capture
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
</nav>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
@@ -2434,6 +2473,45 @@
|
||||
</span>
|
||||
</a>
|
||||
|
||||
<nav class="md-nav" aria-label="4. Check the link">
|
||||
<ul class="md-nav__list">
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#test-the-24-ghz-path-without-lora-forwarding" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
Test the 2.4 GHz path without LoRa forwarding
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#locate-a-mesh-forwarding-failure" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
Locate a mesh forwarding failure
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#optional-short-usb-debug-capture" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
Optional short USB debug capture
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
</nav>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
@@ -2618,16 +2696,22 @@ LoRa repeater, see <a href="../WiFi/#wifi-companion-setup">raw ESP-NOW compatibi
|
||||
<p>Run on both boards:</p>
|
||||
<pre><code class="language-text">get espnow.enabled
|
||||
get espnow.running
|
||||
get espnow.status
|
||||
get bridge.channel
|
||||
get bridge.format
|
||||
get bridge.secret
|
||||
get bridge.source
|
||||
get bridge.delay
|
||||
get repeat
|
||||
get radio
|
||||
</code></pre>
|
||||
<p>Expected: enabled and running <code>on</code>, matching channel/format/secret, source
|
||||
<code>tx</code>, delay <code>500</code>, repeat <code>on</code>, and the intended LoRa settings on each side.</p>
|
||||
<p>For the example above, expect enabled and running <code>on</code>, matching channel and
|
||||
format, source <code>tx</code>, delay <code>500</code>, repeat <code>on</code>, and the intended LoRa settings
|
||||
on each side. An existing <code>bridge.source rx</code> setup is also valid; diagnose
|
||||
the selected source rather than changing it just to match this example.
|
||||
Compare the shared secret privately; omit <code>get bridge.secret</code> from logs you
|
||||
share. <code>get espnow.status</code> distinguishes the configured channel from the actual
|
||||
2.4 GHz channel. Its <code>last</code> error stage/code is historical and may remain after
|
||||
recovery. A running bridge is not proof that the other board received anything.</p>
|
||||
<p>Send a message from a Companion on network A to one on network B, then reply
|
||||
from B to A. Check both directions; configuration readback alone does not test
|
||||
delivery.</p>
|
||||
@@ -2640,6 +2724,82 @@ delivery.</p>
|
||||
and secret; confirm each board's LoRa settings were applied with a reboot,
|
||||
and check the networks' forwarding and scope rules.</li>
|
||||
</ul>
|
||||
<p>If those saved settings already match, use the bounded test below before
|
||||
changing them again.</p>
|
||||
<h3 id="test-the-24-ghz-path-without-lora-forwarding">Test the 2.4 GHz path without LoRa forwarding</h3>
|
||||
<p>Updated ESP-NOW bridge firmware includes runtime diagnostics in the ordinary
|
||||
image. No <code>BRIDGE_DEBUG</code> build flag or continuous USB logging is needed. Use
|
||||
the USB console so a WiFi change cannot disconnect your diagnostic session.</p>
|
||||
<p>On both boards, start a fresh observation window:</p>
|
||||
<pre><code class="language-text">espnow resetstats
|
||||
get espnow.status
|
||||
get espnow.stats test
|
||||
</code></pre>
|
||||
<p>On A, send one probe:</p>
|
||||
<pre><code class="language-text">espnow test A1B2C3D4
|
||||
</code></pre>
|
||||
<p><code>OK - test queued id=A1B2C3D4; confirm on peer</code> means queued locally. On B, run
|
||||
<code>get espnow.stats test</code>: <code>rx</code> must increase and <code>rxid</code> must be <code>A1B2C3D4</code>.
|
||||
Then send <code>espnow test B1C2D3E4</code> on B and confirm that ID on A. The two
|
||||
commands are two one-way tests; there is no
|
||||
automatic reply or retry. Sender completion alone does not prove peer receipt.
|
||||
The optional ID is exactly eight hexadecimal digits, without <code>0x</code>; omitting
|
||||
it uses the current uptime in milliseconds as a correlation ID.</p>
|
||||
<p>These small, unencrypted CRC-checked probes test transport reachability only.
|
||||
They do not validate packet-format compatibility or the wrapped shared secret,
|
||||
authenticate the peer or prove MeshCore packet delivery. They are never
|
||||
injected into the mesh or forwarded
|
||||
onto LoRa. Older firmware ignores them and cannot report the received ID;
|
||||
use an updated peer for confirmation. Sending a probe and resetting
|
||||
statistics require a local connection; neither changes saved preferences.</p>
|
||||
<h3 id="locate-a-mesh-forwarding-failure">Locate a mesh forwarding failure</h3>
|
||||
<p>If both probe directions work, send one fresh identifiable message from a
|
||||
Companion on A's LoRa network and read these pages on both bridge boards:</p>
|
||||
<pre><code class="language-text">get espnow.stats
|
||||
get espnow.stats rx
|
||||
get espnow.stats tx
|
||||
get espnow.stats drops
|
||||
</code></pre>
|
||||
<p>Repeat in the opposite direction with a new message. Counters accumulate until
|
||||
<code>espnow resetstats</code> or reboot and survive an ESP-NOW stop/start. Inspect changes
|
||||
across the one message, rather than assuming old totals describe the current
|
||||
attempt.
|
||||
Stopping or restarting clears pending queue work without classifying delivery;
|
||||
the TX drop counter records local rejection/final-failure decisions, not every
|
||||
undelivered packet.</p>
|
||||
<ul>
|
||||
<li><strong>No source-side bridge TX request:</strong> check the configured source.
|
||||
<code>bridge.source rx</code> exports LoRa receptions; confirm the board heard the
|
||||
fresh message. <code>bridge.source tx</code> exports LoRa transmissions; confirm it
|
||||
forwards the message with repeat on and the intended routing, scope and
|
||||
flood-filter settings. Either source is valid.</li>
|
||||
<li><strong>TX requested but not sent:</strong> the TX/drops pages separate queued traffic,
|
||||
filtering, duplicates, size/queue drops and SDK start/completion failures.
|
||||
Check the configured/live 2.4 GHz channel and last error stage/code.</li>
|
||||
<li><strong>Peer sees frames but accepts no MeshCore packet:</strong> inspect RX rejection
|
||||
counters, format and the privately compared wrapped secret. A successful
|
||||
diagnostic probe does not rule out a packet-format or secret mismatch.</li>
|
||||
<li><strong>Peer admits the packet but no LoRa delivery follows:</strong> admission means
|
||||
queued for normal mesh processing, not a completed LoRa transmission. Check
|
||||
repeat, scope, filters, duplicate suppression and the destination network.</li>
|
||||
</ul>
|
||||
<p>An absent counter change narrows a stage; these checks do not assume a cause
|
||||
for a particular pair of boards.</p>
|
||||
<p>If both bridge boards also hear the same message directly on LoRa, normal
|
||||
duplicate suppression can discard its later bridged copy. That alone does
|
||||
not show a broken ESP-NOW link. This is a possibility to check with the
|
||||
counters, not an established cause of a reported delivery failure.</p>
|
||||
<h3 id="optional-short-usb-debug-capture">Optional short USB debug capture</h3>
|
||||
<p>For a brief observation window, run <code>get usb.logging</code> and <code>get usb.debug</code>
|
||||
and record both original settings. Enable both gates with <code>set usb.logging on</code>
|
||||
and <code>set usb.debug on</code>. The bridge emits bounded <code>ESPNOW:</code> status/counter
|
||||
updates from its main loop, at most once per second when diagnostic state
|
||||
changes. No <code>BRIDGE_DEBUG</code> build flag is required, and WiFi callbacks do not
|
||||
print to USB. Send the two probes or one fresh message, then restore both
|
||||
original settings. The CLI counter pages and probes do not require either
|
||||
logging gate. Use the counter pages for exact values; a busy USB console can
|
||||
skip a debug update. Do not include secrets or WiFi credentials in a shared
|
||||
capture.</p>
|
||||
<p>A running bridge keeps the device awake, even with device power saving enabled.
|
||||
ESP-NOW shares the WiFi radio: use the connected WiFi network's channel when
|
||||
WiFi is active. Browser OTA pauses ESP-NOW on ordinary non-MQTT repeaters,
|
||||
|
||||
@@ -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":"<p>Choose firmware with the firmware picker. For help with a device already in service, start with the FAQ.</p>"},{"location":"#current-release","title":"Current release","text":"<ul> <li>1.17.1.8 USA Cascade release notes</li> <li>Test Results \u2014 validation archive and 1.17.1.8 Preview 1 qualification evidence</li> </ul>"},{"location":"#documentation","title":"Documentation","text":"<ul> <li> <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>Research \u2014 design notes, diagnostics, and historical update-chain studies</li> <li>Old Releases \u2014 historical release notes and supporting files</li> </ul> <p>Found a mistake or missing information? Edit the documentation.</p>"},{"location":"WiFi/","title":"WiFi","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-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-specifiLine 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":"<p>Choose firmware with the firmware picker. For help with a device already in service, start with the FAQ.</p>"},{"location":"#current-release","title":"Current release","text":"<ul> <li>1.17.1.8 USA Cascade release notes</li> <li>Test Results \u2014 validation archive and 1.17.1.8 Preview 1 qualification evidence</li> </ul>"},{"location":"#documentation","title":"Documentation","text":"<ul> <li> <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>Research \u2014 design notes, diagnostics, and historical update-chain studies</li> <li>Old Releases \u2014 historical release notes and supporting files</li> </ul> <p>Found a mistake or missing information? Edit the documentation.</p>"},{"location":"WiFi/","title":"WiFi","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-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-specifiLine truncated
|
||||
@@ -600,6 +600,10 @@
|
||||
<loc>https://mikecarper.github.io/MeshCore/test-results/esp32_management_password_2026-10-19/</loc>
|
||||
<lastmod>2026-10-22</lastmod>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://mikecarper.github.io/MeshCore/test-results/espnow_bridge_diagnostics_2026-10-22/</loc>
|
||||
<lastmod>2026-10-22</lastmod>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://mikecarper.github.io/MeshCore/test-results/firmware_variant_consolidation/</loc>
|
||||
<lastmod>2026-10-22</lastmod>
|
||||
|
||||
Binary file not shown.
@@ -0,0 +1,73 @@
|
||||
{
|
||||
"schema_version": 1,
|
||||
"date": "2026-10-22",
|
||||
"source_commit": "40087820781b189e0136b0ce73928a717752a5c8",
|
||||
"source_clean_at_build": true,
|
||||
"firmware_version": "v1.18.0.1-halo-keymind-cascade-dev-40087820",
|
||||
"runtime_profile": "cascade",
|
||||
"radio_preset": "usa-cascade-fixed",
|
||||
"scope": "Host tests and clean canonical build/package checks only. No hardware flashed or contacted. Actual bridge pair failure remains unverified.",
|
||||
"physical_validation_performed": false,
|
||||
"builds": [
|
||||
{
|
||||
"requested_target": "heltec_v4_repeater",
|
||||
"platformio_environment": "heltec_v4_repeater_observer_mqtt",
|
||||
"build_profile": "full",
|
||||
"capability_verification_passed": true,
|
||||
"feature_reductions": [],
|
||||
"build_recipe_sha256": "44e773e27532c5e1a3e846a86dd1646631a8f7d03a9cbe9119e6237c765ec516",
|
||||
"capabilities_sha256": "dfb6df721a6051359ea69de83232930104a5e489cda9cc63c66a1f3e73fddcfe",
|
||||
"memory": {
|
||||
"passed": true,
|
||||
"available_internal_bytes": 202576,
|
||||
"largest_internal_region_bytes": 169808,
|
||||
"required_heap_bytes": 192656,
|
||||
"required_contiguous_bytes": 21184,
|
||||
"scope": "Linked capacity before runtime allocation; physical boot/load/soak validation remains required."
|
||||
},
|
||||
"memory_receipt_sha256": "8ba0fbad37ce56c7b3922dcdc8c76ee6742415bae0b8e7ed540f79224a3b93bf",
|
||||
"artifacts": [
|
||||
{
|
||||
"file": "heltec_v4_repeater_observer_mqtt-full-usb-wifi-ota-v1.18.0.1-halo-keymind-cascade-dev-40087820-merged.bin",
|
||||
"bytes": 2378472,
|
||||
"sha256": "2c3b15b2845cd30d796f42138d6ac0a24dbea4cb3d51f9e67c7e35aef51511f5"
|
||||
},
|
||||
{
|
||||
"file": "heltec_v4_repeater_observer_mqtt-full-usb-wifi-ota-v1.18.0.1-halo-keymind-cascade-dev-40087820.bin",
|
||||
"bytes": 2312936,
|
||||
"sha256": "31cd7feff5ee4db6c9df6a1ef2c73055cbe42e29739d7dbd9f76d4ad036ea8b5"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"requested_target": "heltec_v4_r8_tft_repeater",
|
||||
"platformio_environment": "heltec_v4_r8_tft_repeater_observer_mqtt",
|
||||
"build_profile": "full",
|
||||
"capability_verification_passed": true,
|
||||
"feature_reductions": [],
|
||||
"build_recipe_sha256": "aee9d9999eeed7cecb1d76c6914b80a6ff24ddae7c6a4895ceef50185a193780",
|
||||
"capabilities_sha256": "258f78349f727a9436ae902b99ce4abf5b666ebdd520622e9d6d017a8928c024",
|
||||
"memory": {
|
||||
"passed": true,
|
||||
"available_internal_bytes": 200344,
|
||||
"largest_internal_region_bytes": 167576,
|
||||
"required_heap_bytes": 190608,
|
||||
"required_contiguous_bytes": 21184,
|
||||
"scope": "Linked capacity before runtime allocation; physical boot/load/soak validation remains required."
|
||||
},
|
||||
"memory_receipt_sha256": "820bde1809e719cfbd636373f681368b98fd92f592866bbd88a81f236bc889cd",
|
||||
"artifacts": [
|
||||
{
|
||||
"file": "heltec_v4_r8_tft_repeater_observer_mqtt-full-usb-wifi-ota-v1.18.0.1-halo-keymind-cascade-dev-40087820-merged.bin",
|
||||
"bytes": 2392424,
|
||||
"sha256": "dca1c74564b9830e73859d20332a59de3ca0b17456544d4c3102201665577f9c"
|
||||
},
|
||||
{
|
||||
"file": "heltec_v4_r8_tft_repeater_observer_mqtt-full-usb-wifi-ota-v1.18.0.1-halo-keymind-cascade-dev-40087820.bin",
|
||||
"bytes": 2326888,
|
||||
"sha256": "23b827c27b46f5a3c6cae5257ca9940f2eb9bc7ccb0bc815c2d123ff18521e43"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
File diff suppressed because it is too large.
Load diff
@@ -2418,6 +2418,7 @@
|
||||
</ul>
|
||||
<h2 id="radio-and-rf">Radio and RF</h2>
|
||||
<ul>
|
||||
<li><a href="espnow_bridge_diagnostics_2026-10-22/">ESP-NOW bridge diagnostics: V4 and V4 R8 TFT Full build/host validation, 2026-10-22</a></li>
|
||||
<li><a href="radio2_simultaneous_receivers_2026-10-22/">V3/V4/T096 radio2 with two fixed witnesses, matched SF7/BW62.5 at preamble 32, 2026-10-22</a></li>
|
||||
<li><a href="solarxiao_room_2026-10-21/">SolarXiao Room Server power profiles and history build/host validation, 2026-10-21</a></li>
|
||||
<li><a href="solarxiao_basic_2026-10-21/">SolarXiao three power profiles build/host validation, 2026-10-21</a></li>
|
||||
|
||||
Reference in new issue
Block a user