feat(companion): frames for device-originated messages 馃馃 - #3447
Open
MarekZegare4 wants to merge 2 commits into
Open
MarekZegare4 wants to merge 2 commits into
MarekZegare4 wants to merge 2 commits into
Conversation
Adds RESP_CODE_CONTACT_MSG_SENT_V3 (0x1E) and RESP_CODE_CHANNEL_MSG_SENT_V3 (0x1F) so firmware that sends messages on its own (bot auto-replies, on-device keyboard input) can mirror them into the companion app's history, which today only ever sees inbound traffic and messages the app itself sent. See meshcore-dev#3225. Both ride the existing offline-queue / MSG_WAITING / SYNC_NEXT_MESSAGE pipe and reuse the RECV_V3 byte layout, with the pubkey field holding the recipient instead of the sender and the SNR byte reserved. Requires app_target_ver >= 3; there is no pre-V3 shape, so older apps are skipped. Mainline never calls these -- nothing in companion_radio self-originates messages -- so this is API surface for custom builds, and the linker drops both functions when unused (identical flash usage before/after). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
CMD_SYNC_NEXT_MESSAGE drains a shared queue, so a host that only advances its polling loop on packet types it recognizes stalls on the first unknown one, and everything queued behind it stays undelivered until the next PACKET_MESSAGES_WAITING. This already bit clients when PACKET_CHANNEL_DATA_RECV (0x1B) was introduced; spelling it out so the next added type doesn't repeat it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
MarekZegare4
marked this pull request as ready for review
September 18, 2026 23:27
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
1 participant
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.
Refs #3225.
Adds
RESP_CODE_CONTACT_MSG_SENT_V3(30) andRESP_CODE_CHANNEL_MSG_SENT_V3(31),plus
queueSentMessage()/queueSentChannelMessage(), so firmware that sendsmessages on its own (bot replies, on-device keyboard) can mirror them into the
app's history. They use the existing offline queue and
CMD_SYNC_NEXT_MESSAGE,with the RECV_V3 layout (pubkey = recipient, SNR byte reserved). Needs
app_target_ver >= 3; older apps are skipped.Mainline never calls them, so this only adds API surface for custom builds.
Flash usage is identical with and without the change.
Compatibility: a host that stops polling on an unknown packet type stalls the
queue. The second commit documents that hosts must keep polling on any
response, as already happened with 0x1B.
Builds: Heltec_v3_companion_radio_ble.