From 0d7ba5473f9185f1af24c696e806709ddfec18b0 Mon Sep 17 00:00:00 2001 From: Jakub <106778416+MarekZegare4@users.noreply.github.com> Date: Mon, 31 Aug 2026 10:17:32 +0200 Subject: [PATCH] docs(companion): require hosts to keep polling on unknown packet types 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 --- docs/companion_protocol.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/docs/companion_protocol.md b/docs/companion_protocol.md index 0fa31677..205834a6 100644 --- a/docs/companion_protocol.md +++ b/docs/companion_protocol.md @@ -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