deploy: 0fdf7901db

cli_commands/index.html

@@ -6877,7 +6877,11 @@
 RX-only mode, cross-transmission policy, and optional radio preambles.</p>
 <p>For supported Full Companions, see <a href="../radio_profiles/#meshtext-channel-chat">Meshtext channel chat</a>
 for <code>mt-</code> channels and the explicit <code>send mt.nodeinfo &lt;channel slot&gt;</code> command.
-Chat remains plain text; NodeInfo is sent only when that command is requested.</p>
+Chat remains plain text. A separate GPS-free NodeInfo is sent after the first
+successful chat transmission per used channel/identity per boot; the explicit
+command can also request one. MT heard-repeat retries use the Companion's
+<code>flood.retry.count</code>, with the metadata cap and <code>flood.retry.advert</code> gate for
+NodeInfo.</p>
 <p>See <a href="../carrier_wave/">carrier-wave RF checks</a> for <code>cw on [seconds]</code>,
 <code>cw2 on [seconds]</code>, and stopping a carrier with <code>off</code>.</p>
 <p>For keyed Morse TX, use <code>morse send TEST DE N0CALL</code> and <code>morse stop</code>.
@@ -10902,6 +10906,17 @@ ineligible even with <code>flood.retry.advert on</code>.</p>
 <p>The <code>infra</code>, <code>rooftop</code>, and <code>mobile</code> defaults and <code>retry.preset</code> command in this
 section apply to infrastructure roles. Companion does not expose repeater
 bridge or prefix retry filters.</p>
+<p>On builds with <a href="../radio_profiles/#heard-repeat-retries">Meshtext channel chat</a>,
+<code>flood.retry.count</code> also limits retries of the node's own MT channel text.
+Retries reuse the original encoded packet and stop after hearing a matching
+forwarded copy with a lower remaining hop limit. This is not a recipient ACK
+or a delivery guarantee. NodeInfo permits at most one additional transmission,
+only with nonzero retry count and <code>flood.retry.advert on</code>, and waits an extra
+minute beyond its airtime-based delay. These settings never enable relaying of
+received MT traffic or apply MeshCore prefix/bridge rules to MT packets.
+<code>set mt.hops 0</code> disables heard-repeat retries, without suppressing the original
+chat or its first-use NodeInfo. <code>get mt.retry</code> reports retry/heard/exhausted
+counters, pending work and the configured count without changing settings.</p>
 <p><strong>Search terms:</strong> flood tx retries, flood retry attempts, flood retransmissions, broadcast retries.</p>
 <p><strong>Usage:</strong>
 - <code>get flood.retry.count</code>

radio_profiles/index.html

@@ -1405,6 +1405,23 @@
     </span>
   </a>
   
+    <nav class="md-nav" aria-label="Meshtext channel chat">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#heard-repeat-retries" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Heard-repeat retries
+      
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
 </li>
         
       </ul>
@@ -2624,6 +2641,23 @@
     </span>
   </a>
   
+    <nav class="md-nav" aria-label="Meshtext channel chat">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#heard-repeat-retries" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Heard-repeat retries
+      
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
 </li>
         
       </ul>
@@ -3237,6 +3271,7 @@ presets are unavailable in the supported EU868 plan. Use these CLI commands:</p>
 get mt.region
 get mt.slot
 get mt.hops
+get mt.retry
 get mt.node
 get mt.shortname
 set mt.node !12345678
@@ -3284,19 +3319,25 @@ name is the longest complete UTF-8 prefix that fits. The saved value is not
 changed. <code>set mt.shortname default</code> clears the override and uses the last four
 hexadecimal digits of the effective MT node ID. This does not change the
 MeshCore node name, add a label to chat text or transmit anything.</p>
-<p><code>send mt.nodeinfo &lt;channel slot&gt;</code> explicitly queues <strong>one</strong> standard
+<p>After the first chat packet actually finishes transmitting on a configured MT
+channel, the Companion queues a separate, GPS-free <code>NODEINFO_APP</code> broadcast.
+This happens once per used channel and sender identity per boot, not for every
+chat message. A rejected or failed chat send does not trigger it. There is no
+NodeInfo transmission just from booting, receiving traffic, changing settings
+or joining a channel, and there is no periodic NodeInfo timer.</p>
+<p><code>send mt.nodeinfo &lt;channel slot&gt;</code> still explicitly queues <strong>one</strong> standard
 <code>NODEINFO_APP</code> broadcast on the selected configured MT channel. The slot is
 the Companion channel index, not <code>mt.slot</code> (the frequency slot). The packet
 contains the actual sender ID, the global MeshCore node name as its long name
 (UTF-8-safe truncated to 24 bytes), the effective short name, <code>CLIENT_MUTE</code>
-(no relaying), and the no-DM flag. It omits MAC, public keys and unsupported
-metadata. The usual radio2 TX-mode, pending-TX, airtime and profile guards
-apply. The reply says <strong>queued</strong>, not delivered or acknowledged.</p>
-<p>There are no automatic NodeInfo advertisements: not at boot, on a timer, when
-names change, when chat is sent, or in response to received packets. Received
-NodeInfo is still ignored; this backend does not maintain a node database.</p>
-<p>Outgoing Meshtext chat and explicitly requested NodeInfo set <strong>OK to MQTT</strong>
-on by default, allowing a compatible receiving gateway to upload those packets.
+(no relaying), and the no-DM flag. Both automatic and explicit NodeInfo omit
+GPS/coordinates, MAC, public keys and unsupported metadata. The usual radio2
+TX-mode, pending-TX, airtime and profile guards apply. The reply says
+<strong>queued</strong>, not delivered or acknowledged.</p>
+<p>Received NodeInfo is still ignored; this backend does not maintain a node
+database.</p>
+<p>Outgoing Meshtext chat and automatic or explicitly requested NodeInfo set
+<strong>OK to MQTT</strong> on by default, allowing a compatible receiving gateway to upload those packets.
 This does not start an MQTT client, bridge networks, request a reply, or mark
 the packet as having arrived through MQTT. The 228-byte text limit is unchanged.</p>
 <p>Region, frequency slot, hop limit, shortname and node-ID override are saved
@@ -3379,12 +3420,12 @@ Outgoing MT chat is plain text exactly as entered, with the sender node ID in
 the standard radio header. It contains no custom name envelope or NodeInfo.
 Incoming text uses the exact sender-ID prefix <code>!12345678:</code> before the received
 payload when passed to the MeshCore app. Changing the shortname only changes
-future manually requested NodeInfo, not chat or the packet's sender ID;
+future NodeInfo, not chat or the packet's sender ID;
 <code>set mt.node</code> changes the actual Meshtext sender ID. Neither setting change
 emits advertisements. A successful
 send response means <strong>queued</strong>, not acknowledged by a remote node. This backend
 does not relay MT packets or provide ACKs, administrative commands, direct
-messages, automatic node-info adverts or a node database. MeshCore emergency forwarding
+messages, periodic node-info adverts or a node database. MeshCore emergency forwarding
 does not apply to MT traffic. Interoperability is with stock peers' PSK channel
 text using AES-CTR, not AES-CCM. AES-CTR channel traffic is not authenticated;
 successful decoding is not proof of sender identity.</p>
@@ -3403,6 +3444,36 @@ airtime, particularly LongFast, can leave substantial MeshCore receive gaps.
 The compatible protocol's fixed short preamble also does not provide the scan-aware long
 preamble described below. Do not treat this as continuous coverage of both
 networks or guaranteed message delivery.</p>
+<h4 id="heard-repeat-retries">Heard-repeat retries</h4>
+<p>MT channel chat uses the Companion's saved <code>flood.retry.count</code> budget: <code>0</code>
+disables retries, and <code>1</code>–<code>15</code> allows that many extra transmissions after the
+initial send. Locally originated MT traffic is hop zero for the
+<code>flood.retry.path</code> gate, so a gate of <code>0</code> still permits it; the group-data gate
+does not apply to channel text. <code>mt.hops 0</code> disables heard-repeat retries
+because peers cannot forward a packet with no remaining hop budget; the
+original chat and its first-use NodeInfo still transmit normally.
+Retries keep the exact encoded payload and
+packet ID, allowing peers to recognize duplicates. They use conservative,
+airtime-based flood spacing and the normal CAD and airtime limits rather than
+transmitting continuously.</p>
+<p><code>get mt.retry</code> is read-only diagnostics: it reports retry transmissions,
+matching heard repeats, exhausted retry sequences, pending work and the
+configured retry count. Use <code>set flood.retry.count</code>, not this getter, to change
+the budget.</p>
+<p>A matching over-air copy with a lower remaining hop limit cancels the retry
+sequence. Merely receiving another message, an unchanged-hop copy or a packet
+with the same ID but different payload does not. A heard repeat indicates a
+compatible peer forwarded the packet; it does <strong>not</strong> confirm that a particular
+person or app received it. This does not add DM delivery receipts or ACKs.</p>
+<p>NodeInfo follows the metadata retry cap: at most one extra send, only when
+<code>flood.retry.count</code> is nonzero and <code>flood.retry.advert</code> is <code>on</code>. Its wait adds
+one minute to the airtime-based delay, matching the conservative self-advert
+policy. Turning retry count off cancels retained retries. Channel, identity,
+settings or radio-profile changes invalidate retained work rather than sending
+it on a different network. The bounded pending-frame storage may reject a new
+send when full. Other people's MT packets are never forwarded by this backend;
+MeshCore repeater prefix/bridge IDs and flood-filter rules are not MT routing
+rules.</p>
 <h2 id="choose-whether-traffic-crosses-between-profiles">Choose whether traffic crosses between profiles</h2>
 <pre><code class="language-text">get radio2.cross
 set radio2.cross auto

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":"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>Feature switches by role and Full Companion features</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-specific local interface <code>*_lora_ota_no_external_sensors</code> On demand on ESP32 No LeaLine 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>Feature switches by role and Full Companion features</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-specific local interface <code>*_lora_ota_no_external_sensors</code> On demand on ESP32 No LeaLine truncated

terminal_chat_cli/index.html

@@ -2541,11 +2541,30 @@ connection. Use the WiFi MOTA seeder on port 5001 for a host folder over WiFi.</
 send mt.nodeinfo 0
 channel 0 Hello
 </code></pre>
-<p>Use a configured <code>mt-</code> channel slot. The explicit <code>send mt.nodeinfo</code> command
-queues one standard name/ID advertisement; chat carries only the entered text.
-There are no automatic NodeInfo sends or responses. The long name comes from
-the existing node name; <code>get mt.shortname</code> shows the effective four-byte short
-name. These commands are not added to smaller or feature-disabled builds.</p>
+<p>Use a configured <code>mt-</code> channel slot. Chat carries only the entered text. After
+the first successful over-air chat transmission per used channel/identity per
+boot, the firmware queues a separate standard name/ID NodeInfo advertisement.
+<code>send mt.nodeinfo</code> can also request one explicitly. Neither contains GPS or
+coordinates. No NodeInfo is sent just from booting, configuration, receiving
+traffic or a timer. The long name comes from the existing node name;
+<code>get mt.shortname</code> shows the effective four-byte short name. These commands
+are not added to smaller or feature-disabled builds.</p>
+<p>MT chat uses <code>flood.retry.count</code> (<code>0</code>–<code>15</code>) to retry when no matching forwarded
+copy is heard. A heard repeat stops retries, but is not a recipient delivery
+receipt. NodeInfo has at most one retry, only with a nonzero count and
+<code>flood.retry.advert on</code>, with an extra one-minute wait. For example:</p>
+<pre><code class="language-text">get flood.retry.count
+set flood.retry.count 3
+set flood.retry.advert on
+get mt.retry
+</code></pre>
+<p><code>get mt.retry</code> shows retry/heard/exhausted counters, pending work and the
+configured count; it does not change settings. With <code>set mt.hops 0</code>, no peer
+can forward a copy, so heard-repeat retries are disabled. The original chat
+and first-use NodeInfo are unaffected.</p>
+<p>This does not make the Companion relay other people's MT packets. See
+<a href="../radio_profiles/#heard-repeat-retries">heard-repeat retries</a> for the airtime
+limits, exact-packet matching and cancellation rules.</p>
 <p>Local means a connection directly to the node: USB, BLE or WiFi/Ethernet
 Companion protocol, a TCP terminal, or the browser CLI on the LAN. These
 connections can use the following commands when the role and build include