Mirrors/MeshCore-Solo
1
0
Fork 0
mirror of https://github.com/MarekZegare4/MeshCore-Solo.git synced 2026-11-01 02:11:57 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs(companion): require hosts to keep polling on unknown packet types

Browse Source 
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>
This commit is contained in:
Jakub
2026-09-19 01:18:43 +02:00
co-authored by Claude Opus 5
parent 919bf106b7
commit 0d7ba5473f
1 changed files with 8 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/companion_protocol.md
+8
View File
@@ -433,6 +433,14 @@ Byte 0: 0x0A
**Note**: Poll this command periodically to retrieve queued messages. The device may also send `PACKET_MESSAGES_WAITING` (0x83) as a notification when messages are available.
**Important**: a host must advance its polling loop — issue the next
`CMD_SYNC_NEXT_MESSAGE`, exactly as it would for a known type — on *any*
response to this command, including packet types it does not recognize. New
message-carrying packet types are added over time, and a host that only
advances on the types it knows will stall on the first unknown one: the queue
stops draining and the messages behind it stay undelivered until the next
`PACKET_MESSAGES_WAITING`. Only `PACKET_NO_MORE_MSGS` (0x0A) ends the loop.
---
### 8. Get Battery and Storage