bias = hop * step + hop^2 * BOT_HOP_GROW_MILLIS
Bumps hop_step 3000->2000, adds BOT_HOP_GROW_MILLIS=400, raises cap
15000->50000 and TTL 75000->95000. Forces re-default of hop_step on
existing bots via BOT_PREFS_VERSION 5->6.
Gap between adjacent hops now grows with hop count (3200ms at hop 1
all the way to 8000ms at hop 8), so a far bot reliably has time to
hear a near bot's reply through the mesh before its own scheduled
fire time -- previous linear bias kept the gap constant at 3000ms,
which wasn't enough at 6+ hops where reply propagation takes ~5-10s.
Upstream MeshCore only added ${cmesh_bot_production.build_flags} to
Heltec V3 and RAK 4631 companion envs. Every other companion build
target (~129 envs across 64 boards) compiled without CMESH_BOT_ENABLED,
so the bot code was stripped at preprocessing and the firmware behaved
like stock MeshCore (no replies on #bot).
Caught when a tester reported the Heltec V4 build wouldn't respond to
commands. The fix isn't board-specific -- it applies to every variant
in the release matrix.
Adds scripts/enable-bot-on-companion-envs.py: scans
vendor/MeshCore/variants/*/platformio.ini, finds every
*_companion_radio_(usb|ble) env, injects ${cmesh_bot_production.build_flags}
into its build_flags block (idempotent). Hooks into apply-patches.sh
so every local / CI build picks it up.
Choosing a script over a vendor patch keeps us robust to upstream
adding new boards: we don't have to maintain a per-variant patch.
Patches 0006-0011 each pushed the vendor submodule pointer at a local
git-am commit that doesn't exist on github.com/meshcore-dev/MeshCore,
so CI's submodule fetch failed every time. Reset the recorded pointer
to upstream main (910b1bee), same as we did after patch 5. CI's
apply-patches.sh step applies the patch queue at build time, so the
working tree is unaffected.
Shortens BOT_PREFS_INITIAL_FLOOD_ADVERT_MILLIS from 120000 to 5000 so
the bot announces itself to the whole mesh ~5s after boot instead of
2 minutes after boot. Recurring flood interval still 24h (upstream
default); ask if you want that tightened.
Bumps base/jitter/hop_step/cap/TTL ~25% for more reliable token
suppression at the multi-hop edge. Bumps BOT_PREFS_VERSION 4 -> 5 to
force re-default of hop_step_ms on existing bots. Test bumped
many_hops.path_hash_count 10 -> 20 so the cap-check still trips with
the new 15000ms cap.
- BOT_HOP_STEP_MILLIS_DEFAULT 1500 -> 2500
- BOT_HOP_BIAS_MAX_MILLIS 8000 -> 12000
- BOT_RESPONSE_PENDING_TTL_MILLIS 45000 -> 60000
- BOT_PREFS_VERSION 3 -> 4 (forces re-default of hop_step_ms on existing
bots that saved the old 1500 value)
- writeAckResponse + executeTest: drop the literal "ack " prefix so test
responses now start with "@[sender] ..."
Field test showed two bots with token-matching `[1865]` responses both
firing because the far bot scheduled its reply before the near bot's
reply could propagate back through the mesh. New hop step gives ~5-8 s
of margin at the 4-hop boundary.
The auto-discovery of known bots via the suffix only fed DM suppression,
which is moot since DMs are encrypted to one recipient. Channel
coordination now lands via patch 7's request token mechanism, which
doesn't need the suffix. Removes the marker, writeBotAdvertName,
isBotAdvertName, autoLearnKnownBotAdvert, and getAdvertNodeName; reverts
all four advert sites to use _prefs.node_name directly. Removes the
test_bot_advert_marker host test. Manual 'bot known add' from CLI still
works for explicit DM suppression.
Bots now prefix every response with a 4-hex request token derived from
the request fingerprint. Peers parsing the prefix can suppress their own
pending response for the same request, fixing duplicate replies on #bot
even for commands whose response text varies per bot (ack/test/hello/
status/roll/dice/path/trace/stats/time/lora/id/neighbors).
Patches 0001-0006 re-exported (cosmetic series-count bump 1/6 -> 1/7).
Move the AUTO_ADD_OVERWRITE_OLDEST assignment to after _store->loadPrefs()
so existing bots with autoadd_config=0 saved on flash get the bit set on
every boot. Previously the assignment was in the constructor (before
load), so loadPrefs() would overwrite our default with the persisted
zero, meaning the fix only took effect on factory-fresh prefs.
- All self-advert paths (CMD_SEND_SELF_ADVERT, CMD_EXPORT_CONTACT,
MyMesh::advert()) now use bot advert name with [MCBOT] suffix when
bot_prefs.enabled, via new getAdvertNodeName() helper
- Initial flood advert at 120s after boot instead of 24h, so other
nodes see [MCBOT] in the contact name shortly after the bot boots
- AUTO_ADD_OVERWRITE_OLDEST set by default on CMESH_BOT builds, so
bots don't silently stop accepting contacts when the table fills
Patches 0001-0005 re-exported (cosmetic series-count bump 1/5 -> 1/6).
GitHub deprecated Node.js 20 for actions; runners will force Node 24 by
June 2 2026. Opting in now via the documented FORCE_JAVASCRIPT_ACTIONS_TO_NODE24
env var instead of pinning every action version. Applied to both
firmware-build (PR check) and release (tag-driven) workflows.
The submodule had been pointing at a local MeshCore commit that included
all 5 patches applied on top of upstream. That commit only exists in the
local working tree — CI's `submodules: recursive` checkout couldn't
fetch it from github.com/meshcore-dev/MeshCore and failed with
"fatal: not our ref d2ad3ac8".
Resets vendor/MeshCore to upstream main (910b1bee, the same base our
patches were authored against) so CI can fetch it normally, and adds an
explicit `apply-patches.sh` step to the firmware-build workflow before
the verify and build steps run. The release workflow already applies
patches explicitly so no change there.
Subsequent verify/build steps set MESHCORE_SKIP_APPLY_PATCHES=1 to avoid
re-applying patches on the now-dirty tree.
Adds the project metadata and CI/release workflow needed to publish this
repo under Colorado-Mesh/meshcore-bot-firmware.
- LICENSE: MIT with attribution to upstream MeshCore (also MIT)
- README: rewritten with badges, supported boards, install paths (web
flasher / PlatformIO / esptool), bot command table, layout map,
development quickstart
- CONTRIBUTING: submodule + patch-queue workflow, what-goes-where,
patch hygiene rules, PR expectations
- RELEASE: cmesh-bot-vX.Y.Z tag scheme + procedure
- CHANGELOG: Keep-a-Changelog format, seeded with the hop-coordination
fix and patch-5 utility commands
- Issue templates: bug_report (with bot stats prompt), feature_request,
config.yml (no blank issues, link to upstream + community)
- Pull request template: layer checklist, verification gates,
prefs-schema impact prompt
- .github/workflows/firmware-build.yml: keep PR check on representative
envs (Heltec V3, RAK 4631 USB+BLE), add concurrency cancellation for
PRs, scope cache key to PIO config hash
- .github/workflows/release.yml: NEW; triggers on cmesh-bot-v* tag or
manual dispatch, enumerates all 133 *_companion_radio_(usb|ble) envs
from vendor/MeshCore/variants/, shards across 8 parallel matrix jobs,
aggregates artifacts into a single draft release
- scripts/verify.sh: respect MESHCORE_SKIP_APPLY_PATCHES like
build-representative.sh does, so verify works when vendor already has
patches applied as commits
- .gitignore: add .forge.bak.*/ for forge backup directories
Bundles in-progress utility commands (TIME, LORA, ID, NEIGHBORS), neighbor
tracking, received_at_timestamp / personalized acks, and per-hop response
delay coordination. Tunes the coordinator so multi-hop senders actually get
responses: hop step 5s→1.5s, hop bias capped at 8s, pending TTL 15s→45s.
Verified on Heltec V3 bench bot: responds to #bot at 2, 4, and 6 hops.
BOT_PREFS_VERSION bumped 2→3, so existing bots will reset bot prefs (channel
names, known bots) to defaults on first boot of this firmware.
