[codex] Add exact MC0 MeshCore DM routing#66
Draft
n30nex wants to merge 1 commit into
Draft
Conversation
bf704a2 to
58755eb
Compare
This was referenced Jun 20, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
short_idkept as display-only metadata.ready,no_key,not_messageable),to_addr/to_namemismatch rejection, and a bounded V0 MC0NODESresponse.to_addrsends, unambiguous name fallback, duplicate names, missing keys, and mismatched address/name targets.IDENTITYand assertaddr_format=meshcore-pubkey-hex.scripts/tdeck_smoke.pyno-stub esptool argument spellings for the installed esptool version.Why
MC0 previously accepted
to_addr, but the resolved node still collapsed back to a display-name send path in the SX1262 backend. That could misroute DMs when names collide or when one name is a substring of another. MeshCore companion clients need stable public-key identity before the USB/BLE bridge can be treated as a real compatibility surface.Local validation
git diff --checkpython -m py_compile scripts\mc_companion_usb_smoke.py scripts\tdeck_smoke.py scripts\fetch_tdeck_artifact.pypio run -e native.pio\build\native\program.exe --selftest.pio\build\native\program.exe --simtestA local
pio run -e tdeck-meshcoresanity compile was attempted before the smoke-script fix but hit the 5-minute tool timeout without useful output. The authoritative firmware binary below came from GitHub Actions.GitHub Actions artifact
tdeck-meshcore-firmware-58755eb715f639ccc2a799d6ea380b3eb667d960sha=58755eb715f639ccc2a799d6ea380b3eb667d960,env=tdeck-meshcore,meshcore_enabled=1,budget_status=passfirmware_bytes=1579984,firmware_slot_pct=30.14,static_ram_bytes=230196COM8 hardware validation
COM8 only; COM11 and COM29 were present and not targeted.
scripts\tdeck_smoke.py --port COM8 --env tdeck-meshcore --no-stub-upload --skip-build --artifact-dir .pio\ci-artifacts\tdeck-mc0-exact-dm-58755eb ...cc:8d:a2:0d:14:28; bootloader, partitions, boot_app0, and firmware hashes verified by esptool.id,sys,companion mc hello,companion mc status,companion mc test.c86a84a412fb64d5adce8114a6b3c0aec881baa0a742a76f9e85c30bc1ad5460;short_id=MC-c86a84a4;MeshCore MC0 protocol selftest: PASS.HELLO,IDENTITY,STATUS,NODES,EXIT;IDENTITYreportedaddr_format=meshcore-pubkey-hexand the same 64-hex pubkey.Meshtastic on, MeshCore onwith Balanced airtime.