dandri/HaloKeymind
1
0 Fork 0
mirror of https://github.com/mikecarper/MeshCore.git synced 2026-10-23 08:43:48 +00:00
Code Issues Packages Projects Releases Wiki Activity

deploy: b80971b85f

Browse Source
This commit is contained in:
mikecarper committed 2026-08-11 22:55:36 +00:00
1 parent ed7640db1e
commit 5fc8e8e7f9
4 files changed
+23 -21
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

cli_command_availability/index.html
+4 -4
View File
@@ -1870,8 +1870,8 @@ fix, no WiFi connection, an inactive bridge, or an nRF52 bootloader without
</tr>
<tr>
<td>Clock sync</td>
<td><a href="../cli_commands/#estimate-and-correct-repeater-time-after-startup"><code>get/set clock.sync.*</code>; <code>clock.sync.mesh now</code></a></td>
<td>Repeater; <code>clock.sync.internet</code> needs MQTT</td>
<td><a href="../cli_commands/#estimate-and-correct-infrastructure-node-time-after-startup"><code>get/set clock.sync.*</code>; <code>clock.sync.mesh now</code></a></td>
<td>Repeater, sensor, and room server; <code>clock.sync.internet</code> needs MQTT repeater</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
@@ -3309,8 +3309,8 @@ fix, no WiFi connection, an inactive bridge, or an nRF52 bootloader without
</tr>
<tr>
<td>Clock sync</td>
<td><a href="../cli_commands/#estimate-and-correct-repeater-time-after-startup"><code>get/set clock.sync.*</code>; <code>clock.sync.mesh now</code></a></td>
<td>Repeater; <code>clock.sync.internet</code> needs MQTT</td>
<td><a href="../cli_commands/#estimate-and-correct-infrastructure-node-time-after-startup"><code>get/set clock.sync.*</code>; <code>clock.sync.mesh now</code></a></td>
<td>Repeater, sensor, and room server; <code>clock.sync.internet</code> needs MQTT repeater</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
cli_commands/index.html
+16 -14
View File
@@ -1074,10 +1074,10 @@
</li>
<li class="md-nav__item">
<a href="#estimate-and-correct-repeater-time-after-startup" class="md-nav__link">
<a href="#estimate-and-correct-infrastructure-node-time-after-startup" class="md-nav__link">
<span class="md-ellipsis">
Estimate and correct repeater time after startup
Estimate and correct infrastructure-node time after startup
</span>
</a>
@@ -3520,10 +3520,10 @@
</li>
<li class="md-nav__item">
<a href="#estimate-and-correct-repeater-time-after-startup" class="md-nav__link">
<a href="#estimate-and-correct-infrastructure-node-time-after-startup" class="md-nav__link">
<span class="md-ellipsis">
Estimate and correct repeater time after startup
Estimate and correct infrastructure-node time after startup
</span>
</a>
@@ -5383,7 +5383,7 @@ Station G2/G3 targets default to <code>off</code>.</p>
- The nRF52 hardware cannot stop a watchdog after it has started. Disabling is persisted immediately, then the current firmware stops feeding it so the board performs one watchdog restart within 60 seconds. It remains off after that restart.
- This setting is nRF52-only. The SoftDevice flash deadlock does not apply to ESP32, whose existing watchdog behavior is unchanged.</p>
<hr />
<h4 id="estimate-and-correct-repeater-time-after-startup">Estimate and correct repeater time after startup</h4>
<h4 id="estimate-and-correct-infrastructure-node-time-after-startup">Estimate and correct infrastructure-node time after startup</h4>
<p><strong>Usage:</strong>
- <code>get clock.sync</code>
- <code>get clock.sync.status</code>
@@ -5401,22 +5401,22 @@ Station G2/G3 targets default to <code>off</code>.</p>
- <code>get clock.sync.samples</code>
- <code>set clock.sync.samples &lt;3-16&gt;</code></p>
<p><strong>Defaults:</strong>
- <code>clock.sync.mesh</code>: <code>on</code> for nRF52 repeaters; <code>off</code> for other builds
- <code>clock.sync.mesh</code>: <code>on</code> for all repeater, sensor, and room-server builds
- <code>clock.sync.mesh.edge</code>: <code>on</code>
- <code>clock.sync.internet</code>: <code>off</code>
- <code>clock.sync.drift</code>: <code>3600</code> seconds
- <code>clock.sync.samples</code>: <code>9</code></p>
<p>When either source is enabled, the repeater makes its first clock-bootstrap
<p>When either source is enabled, the node makes its first clock-bootstrap
attempt after 30 minutes of uptime, or immediately when the configured number
of fresh evidence sources has been collected, whichever comes first. A
successful estimate changes the RTC only when the absolute difference is
<strong>greater than</strong> <code>clock.sync.drift</code>; correction can move the clock forward or
backward. A valid estimate within the threshold counts as a successful sync
without changing the clock. Seven days after each successful estimate, the
repeater evaluates time again; the seven-day deadline therefore starts from the
node evaluates time again; the seven-day deadline therefore starts from the
last successful estimate rather than from boot. This is a lazy uptime deadline:
the check runs on the first normal loop/wake after it becomes due and does not
wake the device by itself. If no source or consensus is available, the repeater
wake the device by itself. If no source or consensus is available, the node
retries every 30 minutes, and newly collected evidence triggers another
immediate evaluation once the configured source count is present. Every reboot
starts with the initial bootstrap attempt. An existing saved setting always
@@ -5514,12 +5514,14 @@ one sender can claim multiple names and inflate the edge-mode vote count.</p>
<p><code>clock.sync.internet</code> is available on WiFi MQTT repeater-observer builds. Its
initial and seven-day queries run on the MQTT/WiFi task and are read-only until
the repeater applies the configured drift test. Failed queries retry after 30
minutes. On other repeater builds, the preference can be stored but status
reports that internet time is unavailable. MQTT builds retain their existing
startup NTP behavior required for MQTT/TLS/JWT operation; this setting controls
the additional delayed drift checks. Startup NTP is always preferred when it
minutes. On other infrastructure-node builds, the preference can be stored but
status reports that internet time is unavailable. MQTT builds retain their
existing startup NTP behavior required for MQTT/TLS/JWT operation; this setting
controls the additional delayed drift checks. Startup NTP is always preferred when it
succeeds, regardless of this setting.</p>
<p>Changing any <code>clock.sync.*</code> setting starts a new attempt for the current boot.
<p>Sensor and room-server builds support mesh clock consensus and report
<code>clock.sync.internet</code> as unavailable. Changing any <code>clock.sync.*</code> setting starts
a new attempt for the current boot.
Settings are persistent in <code>/clock_sync</code>; samples and schedule state are not.</p>
<p>A backward correction is intentionally allowed, but peers that already recorded
a later timestamp from this node may temporarily reject its lower timestamps as
halo_keymind_settings/index.html
+2 -2
View File
@@ -1425,13 +1425,13 @@ set flood.retry.ignore none
</tr>
<tr>
<td><code>clock.sync.mesh</code></td>
<td>Defaults on for nRF52 repeaters and off for other builds; a saved setting overrides that default. It estimates UTC as soon as the configured number of fresh signed-advert or valid Public-channel sources is collected, with a 30-minute bootstrap/retry timer when evidence is still insufficient, then repeats lazily seven days after each successful estimate. New evidence retriggers evaluation after a no-consensus result. <code>clock.sync.mesh now</code> queues an immediate LoRa-only attempt without bypassing quorum or source suppression. Only timestamps from firmware build time through build time plus ten years are recorded. Successful CLI, GPS, or WiFi/NTP clock updates suppress LoRa time collection until reboot; after reboot LoRa is the fallback if NTP cannot sync. Status reports the reason a clock was not set; its <code>.table</code> and <code>.1</code> through <code>.16</code> forms inspect collected samples.</td>
<td>Defaults on for all repeater, sensor, and room-server builds; a saved setting overrides that default. It estimates UTC as soon as the configured number of fresh signed-advert or valid Public-channel sources is collected, with a 30-minute bootstrap/retry timer when evidence is still insufficient, then repeats lazily seven days after each successful estimate. New evidence retriggers evaluation after a no-consensus result. <code>clock.sync.mesh now</code> queues an immediate LoRa-only attempt without bypassing quorum or source suppression. Only timestamps from firmware build time through build time plus ten years are recorded. Successful CLI, GPS, or WiFi/NTP clock updates suppress LoRa time collection until reboot; after reboot LoRa is the fallback if NTP cannot sync. Status reports the reason a clock was not set; its <code>.table</code> and <code>.1</code> through <code>.16</code> forms inspect collected samples.</td>
<td><code>get clock.sync.mesh</code>, <code>set clock.sync.mesh &lt;on|off&gt;</code>, <code>clock.sync.mesh now</code>, <code>get clock.sync.status[.table|.1-.16]</code></td>
<td><code>set clock.sync.mesh on</code></td>
</tr>
<tr>
<td><code>clock.sync.mesh.edge</code></td>
<td>Defaults on so edge repeaters can collect clock evidence when all packets arrive through one relay path. Verified evidence is observed before the forwarding decision, so <code>repeat off</code> and forwarding filters do not prevent collection. Signed adverts are deduplicated by public key and Public-channel timestamps by case-insensitive display name; all may share one receive path. Public display names are unauthenticated and can be spoofed. Changing this setting clears current clock samples.</td>
<td>Defaults on so edge infrastructure nodes can collect clock evidence when all packets arrive through one relay path. Verified evidence is observed before the forwarding decision, so disabled forwarding and forwarding filters do not prevent collection. Signed adverts are deduplicated by public key and Public-channel timestamps by case-insensitive display name; all may share one receive path. Public display names are unauthenticated and can be spoofed. Changing this setting clears current clock samples.</td>
<td><code>get clock.sync.mesh.edge</code>, <code>set clock.sync.mesh.edge &lt;on|off&gt;</code></td>
<td><code>set clock.sync.mesh.edge on</code></td>
</tr>
search/search_index.json
+1 -1
View File
@@ -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>CLI Commands</li> <li>Filter Policy Playground</li> <li>Telemetry History Decoder</li> <li>CLI Availability by Firmware Build</li> <li>Easy LoRa OTA: ESP32 full images and nRF52 deltas</li> <li>Scripted LoRa OTA: Bash and PowerShell</li> <li>MeshTower V2 microSD self-updates</li> <li>GPS Tracking</li> <li>Companion Protocol</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 repeat on|off</code> controls whether an observer repeats eligible LoRa packets;</li> <li><code>set bridge.enabled on|off</code> starts or stops the MQTT bridge;</li> <li><code>set 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>Frequently Asked Questions</li> <li>CLI Commands</li> <li>Filter Policy Playground</li> <li>Telemetry History Decoder</li> <li>CLI Availability by Firmware Build</li> <li>Easy LoRa OTA: ESP32 full images and nRF52 deltas</li> <li>Scripted LoRa OTA: Bash and PowerShell</li> <li>MeshTower V2 microSD self-updates</li> <li>GPS Tracking</li> <li>Companion Protocol</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 repeat on|off</code> controls whether an observer repeats eligible LoRa packets;</li> <li><code>set bridge.enabled on|off</code> starts or stops the MQTT bridge;</li> <li><code>set Line truncated