Merge meshcore-dev dev with companion and board integrations

docs/cli_commands.md

@@ -1174,7 +1174,7 @@ capacity. Remote use follows the existing administrator-command permissions.
 
 **Set by build flag:** `LORA_FREQ`, `LORA_BW`, `LORA_SF`, `LORA_CR`
 
-**Default:** `869.525,250,11,5`
+**Default:** `869.618,62.5,8,5`
 
 **Note:** Requires reboot to apply. If RXPS is enabled and the saved minimum
 level/preamble cannot safely cover the new radio timing, the command reply
@@ -1345,7 +1345,7 @@ preamble. LoRa OTA treats v1.17.1.5 as that capability boundary.
 **Parameters:**
 - `frequency`: Frequency in MHz
 
-**Default:** `869.525`
+**Default:** `869.618`
 
 **Note:** Requires reboot to apply
 
@@ -2275,7 +2275,7 @@ installed images need an updated build. See the [setting-dispatch audit](cli_set
 **Parameters:**
 - `value`: Direct transmit delay factor (0-2)
 
-**Default:** `0.2`
+**Default:** `0.3` (Repeater) - `0.2` (Room Server, Sensor)
 
 **Note:** Same collision-avoidance random window as `txdelay`, but applied to direct (non-flood, routed) traffic. The default is lower because direct packets are addressed to a specific next hop, so far fewer nodes compete to retransmit them.
 
@@ -2426,7 +2426,7 @@ reduce unnecessary recoveries when no traffic is expected.
 **Parameters:**
 - `hours`: Interval in hours (3-168)
 
-**Default:** `12` (Repeater) - `0` (Sensor)
+**Default:** `47` (Repeater, Room Server) - `0`, disabled (Sensor)
 
 ---
 
@@ -2438,7 +2438,12 @@ reduce unnecessary recoveries when no traffic is expected.
 **Parameters:**
 - `minutes`: Interval in minutes rounded down to the nearest multiple of 2 (61 becomes 60) (60-240)
 
-**Default:** `0`
+**Default:** `2` on a factory-fresh node, then `0` (disabled) once configured.
+
+**Note:** A new install ships with a 2 minute zero-hop advert interval. Saving
+any setting resets an interval below the 60 minute minimum to `0`, on the
+assumption that the node has now been deliberately configured. To keep zero-hop
+adverts running, set an explicit value in the 60-240 range.
 
 ---
 

docs/companion_protocol.md

@@ -588,12 +588,12 @@ a raw byte count.
 - Registered application/community namespaces occupy `0x0100`-`0xFEFF`; the remaining nonzero ranges are reserved for internal or development use. See the [Registered data_type values](#registered-data_type-values) table below.
 
 **Limits**:
-- Maximum payload length is `MAX_CHANNEL_DATA_LENGTH = MAX_FRAME_SIZE - 9 = 167` bytes.
+- Maximum payload length is `MAX_GROUP_DATA_LENGTH = MAX_PACKET_PAYLOAD - CIPHER_BLOCK_SIZE - 3 = 165` bytes.
 - Larger payloads are rejected with `PACKET_ERROR` (`ERR_CODE_ILLEGAL_ARG`).
 
 **Response**: `PACKET_OK` (0x00) on success, or `PACKET_ERROR` (0x01) with one of:
 - `ERR_CODE_NOT_FOUND` (2) - unknown `channel_idx`
-- `ERR_CODE_ILLEGAL_ARG` (6) - invalid `path_len`, reserved `data_type` (`0x0000`), or payload larger than `MAX_CHANNEL_DATA_LENGTH`
+- `ERR_CODE_ILLEGAL_ARG` (6) - invalid `path_len`, reserved `data_type` (`0x0000`), or payload larger than `MAX_GROUP_DATA_LENGTH`
 - `ERR_CODE_TABLE_FULL` (3) - outbound send queue is full; retry later
 
 **Inbound datagrams** are delivered to the host via `RESP_CODE_CHANNEL_DATA_RECV` (0x1B); see [Receive Channel Data Datagram](#receive-channel-data-datagram).

docs/faq.md

@@ -621,8 +621,8 @@ Mac: python3 should be already installed.
 
 Then it should be the same for all platforms:
 ```
-python3 -m venv meshcore
-cd meshcore && source bin/activate
+python3 -m venv meshcore-venv
+cd meshcore-venv && source bin/activate
 pip install -U platformio
 git clone https://github.com/meshcore-dev/MeshCore.git
 cd MeshCore

docs/nrf52_power_management.md

@@ -190,11 +190,19 @@ Power management status can be queried via the CLI:
 | `get pwrmgt.bootreason` | Returns reset and shutdown reason strings                             |
 | `get pwrmgt.bootmv`     | Returns boot voltage in millivolts                                    |
 
-On boards without power management enabled, all commands except `get pwrmgt.support` return:
+On boards without power management enabled, `get pwrmgt.source` and
+`get pwrmgt.bootmv` return:
 ```
 ERROR: Power management not supported
 ```
 
+`get pwrmgt.support` returns `unsupported`. `get pwrmgt.bootreason` is not
+compiled out at all and answers on every board: `getResetReason()` and
+`getShutdownReason()` are virtuals on the base board class, so a board that
+does not override them reports `Not available` rather than an error. ESP32
+boards override the reset half with `esp_reset_reason()`, so they return a real
+reset reason and `Not available` for the shutdown reason.
+
 ## Debug Output
 
 When `MESH_DEBUG=1` is enabled, the power management module outputs:

docs/terminal_chat_cli.md

@@ -249,11 +249,6 @@ set lon {longitude}
 ```
 Sets your advertisement map longitude. (decimal degrees)
 
-```
-set dutycycle {percent}
-```
-Sets the transmit duty cycle limit (1-100%). Example: `set dutycycle 10` for 10%.
-
 ```
 set af {air-time-factor}
 ```