Replaced EastMesh to MeshCoreTel across all the docs

AGENTS.md

@@ -2,7 +2,7 @@
 
 ## Purpose
 
-EastMesh layer on top of upstream MeshCore.
+MeshCoreTel-firmware layer on top of upstream MeshCore.
 
 **Default:** preserve upstream behavior.  
 Only modify code for clearly scoped EastMesh features:
@@ -97,7 +97,7 @@ Build with release-style metadata:
 
 ```bash
 export FIRMWARE_VERSION=v1.14.1
-export EASTMESH_VERSION=v1.0.1
+export MESHCORETEL_VERSION=v1.0.1
 bash build.sh build-firmware heltec_v4_repeater_mqtt
 bash build.sh build-firmware T_Beam_S3_Supreme_SX1262_repeater_mqtt
 ```
@@ -163,7 +163,7 @@ Current tag formats:
 
 ```bash
 git tag companion-wifi-v1.2.3
-git tag repeater-mqtt-eastmesh-v1.0.1
+git tag repeater-mqtt-meshcoretel-v1.0.1
 ```
 
 Rules:

RELEASE.md

@@ -12,20 +12,20 @@ Example:
 
 This value becomes the base `FIRMWARE_VERSION` used by the release workflows.
 
-## EastMesh Release Tags
+## MeshCoreTel-firmware Release Tags
 
 Push one or more of the following tag formats to trigger the matching firmware release workflow:
 
 - `companion-wifi-v1.2.3`
-- `repeater-mqtt-eastmesh-v1.0.1`
+- `repeater-mqtt-meshcoretel-v1.0.1`
 
 Use the upstream MeshCore version in `companion-wifi-v1.2.3`.
-Use the EastMesh release version in `repeater-mqtt-eastmesh-v1.0.1`.
+Use the MeshCoreTel-firmware release version in `repeater-mqtt-meshcoretel-v1.0.1`.
 
 Each tag triggers a separate workflow:
 
 - `companion-wifi-v*` builds companion WiFi firmware
-- `repeater-mqtt-eastmesh-*` builds repeater MQTT firmware
+- `repeater-mqtt-meshcoretel-*` builds repeater MQTT firmware
 
 You can push one, or more tags on the same commit, and they will all build separately.
 
@@ -35,18 +35,18 @@ During the GitHub Actions build:
 
 - `companion-wifi` uses the version in the tag as `FIRMWARE_VERSION`
 - `repeater-mqtt` uses `OFFICIAL_MESHCORE_VERSION` as `FIRMWARE_VERSION`
-- `repeater-mqtt` uses the EastMesh version from the tag as `EASTMESH_VERSION`
+- `repeater-mqtt` uses the MeshCoreTel-firmware version from the tag as `MESHCORETEL_VERSION`
 
 The resulting version string depends on the workflow:
 
 - `companion-wifi`: `v1.2.3-<commit>`
-- `repeater-mqtt`: `v1.2.3-eastmesh-v1.0.1-<commit>`
+- `repeater-mqtt`: `v1.2.3-vbart-meshcoretel-v1.0.1-<commit>`
 
 Example:
 
-- tag: `repeater-mqtt-eastmesh-v1.0.1`
+- tag: `repeater-mqtt-meshcoretel-v1.0.1`
 - repo variable: `OFFICIAL_MESHCORE_VERSION=v1.2.3`
-- resulting build version: `v1.2.3-eastmesh-v1.0.1-abcdef`
+- resulting build version: `v1.2.3-meshcoretel-v1.0.1-abcdef`
 
 ## Typical Release Flow
 
@@ -65,11 +65,11 @@ Example:
 
 ```bash
 git tag companion-wifi-v1.2.3
-git tag repeater-mqtt-eastmesh-v1.0.1
-git push origin companion-wifi-v1.2.3 repeater-mqtt-eastmesh-v1.0.1
+git tag repeater-mqtt-meshcoretel-v1.0.1
+git push origin companion-wifi-v1.2.3 repeater-mqtt-meshcoretel-v1.0.1
 ```
 
 ## Supported Tags
 
 - `companion-wifi-v1.2.3`
-- `repeater-mqtt-eastmesh-v1.0.1`
+- `repeater-mqtt-meshcoretel-v1.0.1`

docs/api.md

@@ -1,6 +1,6 @@
 # Repeater Web API
 
-This page documents the local HTTPS API exposed by EastMesh `*_repeater_mqtt` builds that support the web panel.
+This page documents the local HTTPS API exposed by MeshCoreTel-firmware `*_repeater_mqtt` builds that support the web panel.
 
 It is intended for:
 
@@ -65,7 +65,7 @@ Notes:
 
 The API runs on the repeater itself, so polling frequency matters.
 
-If the repeater is also running two MQTT connections, avoid frequent API polling. The current EastMesh usage pattern is:
+If the repeater is also running two MQTT connections, avoid frequent API polling. The current MeshCoreTel-firmware usage pattern is:
 
 - `60` second polling for stats
 - on-demand requests for everything else
@@ -288,12 +288,12 @@ curl -sk https://<repeater-ip>/api/command \
 
 The web panel saves settings by generating CLI commands and sending them through `/api/command`.
 
-That means your own tools can do the same for EastMesh-specific settings such as:
+That means your own tools can do the same for MeshCoreTel-firmware specific settings such as:
 
 - repeater identity fields
 - owner info
 - MQTT broker toggles
-- EastMesh MQTT owner metadata
+- MQTT owner metadata
 - radio settings supported by the repeater CLI
 
 This is a practical way to automate setup while preserving existing CLI semantics.

docs/boards.md

@@ -16,7 +16,7 @@ The tables below are built from the repo's PlatformIO board metadata and variant
 - `RAM` is the MCU's built-in RAM.
 - `PSRAM` is extra memory on some boards. More PSRAM usually means more headroom for UI, MQTT, and future features.
 - `GPS` uses `✅` when present and is blank when absent.
-- `SD` uses `✅` when the board is currently known to support the SD-backed archive path in EastMesh, `🧪` when the hardware likely supports TF/microSD but the board-specific integration still needs validation, and is blank when there is no current SD/archive support note.
+- `SD` uses `✅` when the board is currently known to support the SD-backed archive path in MeshCoreTel-firmware, `🧪` when the hardware likely supports TF/microSD but the board-specific integration still needs validation, and is blank when there is no current SD/archive support note.
 
 ## Start Here
 
@@ -122,8 +122,8 @@ This table includes all repeater MQTT targets currently defined in `variants/eas
 
 SD notes:
 
-- `✅` means the board is currently known to work with the SD-backed archive path in EastMesh.
-- `🧪` means the board hardware likely supports TF/microSD, but the EastMesh board-specific integration still needs validation before it should be treated as supported.
+- `✅` means the board is currently known to work with the SD-backed archive path in MeshCoreTel-firmware.
+- `🧪` means the board hardware likely supports TF/microSD, but the MeshCoreTel-firmware board-specific integration still needs validation before it should be treated as supported.
 - For the current stats archive, a `4 GB` `FAT32` microSD card is more than sufficient. Larger cards are also supported.
 
 ## `companion_radio_wifi` Boards With A Display

docs/index.md

@@ -1,10 +1,10 @@
-# MeshCore EastMesh Docs
+# MeshCoreTel-firmware Docs
 
-MeshCore-EastMesh keeps the upstream MeshCore firmware intact and adds an EastMesh layer on top for:
+MeshCoreTel-firmware keeps the upstream MeshCore firmware intact and adds an additional layer on top for:
 
 - `repeater_mqtt` builds with native WiFi, MQTT, and the optional local web panel
 - `companion_radio_wifi` builds for Wi-Fi-connected companion devices
-- EastMesh-specific release automation and versioning on top of upstream MeshCore releases
+- MeshCoreTel-firmware release automation and versioning on top of upstream MeshCore releases
 
 If you are just trying to pick a board or download firmware, start with:
 
@@ -26,26 +26,8 @@ If you are just trying to pick a board or download firmware, start with:
 
 ## Current Scope
 
-This docs site only covers the EastMesh-specific pieces in this repository.
+This docs site only covers the MeshCoreTel-firmware specific pieces in this repository.
 
 For general MeshCore behavior, radio operation, and upstream firmware concepts, refer to the upstream project:
 
 - [meshcore-dev/MeshCore](https://github.com/meshcore-dev/MeshCore)
-
-## Australian Regional References
-
-These references are community-maintained rather than official project documentation, but they are still useful for Australian regional setup notes, local conventions, and area-specific MeshCore references.
-
-### ACT / NSW / QLD / SA / TAS / VIC
-
-- [wiki.eastmesh.au](https://wiki.eastmesh.au/)
-- [wiki.meshcoreaus.org](https://wiki.meshcoreaus.org/)
-
-### Sydney
-
-- [nswmesh.au](https://nswmesh.au/)
-- [github.com/nswmesh](https://github.com/nswmesh/)
-
-### Brisbane
-
-- [wiki.mbug.com.au/en/Meshcore/Settings](https://wiki.mbug.com.au/en/Meshcore/Settings)

docs/migration.md

@@ -4,13 +4,13 @@ This page covers migrating from the previous firmware published at:
 
 - `https://github.com/xJARiD/MeshCore`
 
-to the EastMesh firmware published at:
+to the MeshCoreTel-firmware published at:
 
-- `https://github.com/xJARiD/MeshCore-EastMesh`
+- `https://github.com/VBart/MeshCoreTel-firmware`
 
-These steps are intended for existing repeater users moving to the new EastMesh `*_repeater_mqtt` firmware.
+These steps are intended for existing repeater users moving to the new `*_repeater_mqtt` MeshCoreTel-firmware.
 
-Start by downloading the correct EastMesh release for your board from:
+Start by downloading the correct MeshCoreTel-firmware release for your board from:
 
 - [Download and Flash Releases](./releases.md)
 
@@ -76,11 +76,11 @@ Notes:
 
 ## Legacy MQTT Commands
 
-Some MQTT CLI commands from the previous firmware do not apply in EastMesh and should not be migrated.
+Some MQTT CLI commands from the previous firmware do not apply in MeshCoreTel-firmware and should not be migrated.
 
-EastMesh stores its current Wi-Fi and MQTT uplink settings separately from the older firmware, so older broker and analyzer settings do not carry forward in a useful way. After flashing, re-enter the settings you still use now, rather than expecting the old MQTT bridge configuration to map across.
+MeshCoreTel-firmware stores its current Wi-Fi and MQTT uplink settings separately from the older firmware, so older broker and analyzer settings do not carry forward in a useful way. After flashing, re-enter the settings you still use now, rather than expecting the old MQTT bridge configuration to map across.
 
-These previous MQTT CLI commands no longer apply in EastMesh:
+These previous MQTT CLI commands no longer apply in MeshCoreTel-firmware:
 
 - `get mqtt.server`
 - `get mqtt.port`
@@ -89,11 +89,11 @@ These previous MQTT CLI commands no longer apply in EastMesh:
 - `get mqtt.analyzer.eu`
 - `get mqtt.config.valid`
 
-If you flash without erase first, some old values may still remain in flash in the background. The important point is that EastMesh does not use those old MQTT bridge values for its current uplink configuration, so users should not expect them to carry forward or have any effect.
+If you flash without erase first, some old values may still remain in flash in the background. The important point is that MeshCoreTel-firmware does not use those old MQTT bridge values for its current uplink configuration, so users should not expect them to carry forward or have any effect.
 
 ## Recommended Migration Flow
 
-1. Flash the new EastMesh firmware without erasing.
+1. Flash the new MeshCoreTel-firmware without erasing.
 2. Open the serial CLI or companion app.
 3. Set `wifi.ssid`, `wifi.pwd`, `mqtt.iata`, and `mqtt.status on`.
 4. Optionally set `mqtt.owner` and `mqtt.email`.

docs/releases.md

@@ -1,8 +1,8 @@
 # Download And Flash Releases
 
-EastMesh release assets are published on:
+MeshCoreTel-firmware release assets are published on:
 
-- <https://github.com/xJARiD/MeshCore-EastMesh/releases>
+- <https://github.com/VBart/MeshCoreTel-firmware/releases>
 
 There are currently two release tracks in this repo:
 
@@ -16,8 +16,8 @@ Download the asset that matches your board and firmware type.
 Examples:
 
 - `heltec_v4_companion_radio_wifi-v1.14.1-abcdef.bin`
-- `heltec_v4_repeater_mqtt-v1.14.1-eastmesh-v1.0.1-abcdef.bin`
-- `heltec_v4_repeater_mqtt-v1.14.1-eastmesh-v1.0.1-abcdef-merged.bin`
+- `heltec_v4_repeater_mqtt-v1.14.1-vbart-meshcoretel-v1.0.1-abcdef.bin`
+- `heltec_v4_repeater_mqtt-v1.14.1-vbart-meshcoretel-v1.0.1-abcdef-merged.bin`
 
 The important part is the board/env prefix:
 
@@ -46,7 +46,7 @@ Practical rule:
 
 The recommended flasher is:
 
-- <https://flasher.eastmesh.au/>
+- <https://meshcoretel.ru/ru/flasher>
 
 It includes native support for:
 
@@ -61,9 +61,9 @@ Recommended usage:
 
 ## Beginner Setup
 
-If this is your first time flashing EastMesh firmware, the easiest path is:
+If this is your first time flashing MeshCoreTel-firmware, the easiest path is:
 
-1. Open <https://flasher.eastmesh.au/>.
+1. Open <https://meshcoretel.ru/ru/flasher>.
 2. Select the firmware type you want: `Companion WiFi`, `Repeater MQTT`, or `Custom`.
 3. Flash the correct firmware for your board.
 4. Use the built-in setup tools in the flasher site to finish first-time configuration.
@@ -106,7 +106,7 @@ This applies to:
 
 ## Repeater MQTT Notes
 
-`repeater_mqtt` builds include the EastMesh MQTT additions. Depending on the board, they may also include the local web panel.
+`repeater_mqtt` builds include the MeshCoreTel-firmware MQTT additions. Depending on the board, they may also include the local web panel.
 
 Typical first steps after flashing:
 

docs/web-panel.md

@@ -1,6 +1,6 @@
 # Repeater Web Panel
 
-This page is for end users running an EastMesh `*_repeater_mqtt` build with the local web panel enabled.
+This page is for end users running an MeshCoreTel-firmware `*_repeater_mqtt` build with the local web panel enabled.
 
 It covers how to reach the panel, what each section does, and what to expect when using it on desktop or mobile.
 
@@ -205,7 +205,7 @@ This section includes:
 - `mqtt.iata`: selected from a curated east-coast/south-east list.
 - `mqtt.owner`: owner public key.
 - `mqtt.email`: owner contact email.
-- MQTT server toggles: `eastmesh-au`, `letsmesh-eu`, and `letsmesh-us`.
+- MQTT server toggles: `meshcoretel`, `letsmesh-eu`, and `letsmesh-us`.
 
 `UNSET - To be configured` is the default for new repeater MQTT installs until a real saved value exists.
 
@@ -263,7 +263,7 @@ Current in-memory history caps are:
 
 On boards with roughly `2 MB` PSRAM or more, stats history starts capturing from boot when `web.stats` is enabled, even if `/stats` has not been opened yet.
 
-Archive-backed restore requires `web.stats` enabled plus a mounted SD card on boards that support the EastMesh archive path.
+Archive-backed restore requires `web.stats` enabled plus a mounted SD card on boards that support the MeshCoreTel-firmware archive path.
 
 The main purpose of the SD card is to let the repeater retain and restore stats history for `/stats`. The archive keeps fast `.latest` snapshot files for quick restore and UTC-dated daily `.log` files for longer-term history. As a secondary option, those files can also be removed and inspected on a computer for deeper manual review.
 
@@ -315,8 +315,6 @@ On mobile:
 3. The local HTTP redirect listener on port `80` is released so OTA can take over that port.
 4. Continue with your normal OTA workflow.
 
-If an older build sends you through a strange redirect after `start ota`, use the web `Start OTA` button to begin the upgrade. This redirect issue is fixed in `repeater-mqtt-eastmesh-v1.3.11`.
-
 ### Use Historical Stats
 
 1. Enable stats if needed with `set web.stats on`.