Unknown session frames aren't reassembled — multi-fragment device posts (e.g. c490) decode only their first fragment

[kb1ibt]

Summary

_process_notification's unknown-cmd branch decrypts a single raw BLE packet, whereas telemetry frames go through _process_telemetry_packet, which reassembles fragments first. Any non-telemetry session frame that spans more than one notification is therefore never reassembled — only fragment 1 reaches _decrypt_payload, so it can't decode. The C2000 G2 (A1783) posts exactly such a frame — cmd=c490, ~372 bytes cleartext — every ~9 minutes, and it's currently lost.

Background — what c490 is

While monitoring an Anker SOLIX C2000 G2 (A1783) — which connects on the shared C1000 G2 family profile (CapturingC1000G2) — the device posts an unsolicited frame on its own timer, roughly every 540 s. It's not a request/response we drive.

• Pattern 03010f, cmd=c490, not in _TELEMETRY_COMMANDS, no future registered → falls into the unknown-message else branch.
• Decrypts with the same AES-CBC session key SolixBLE already negotiates (_decrypt_payload).
• 372 bytes of cleartext once reassembled — readable ASCII inside (A1763, charging_pps_series_c_0005), and consecutive frames differ in only a handful of isolated byte positions (i.e. it's plaintext, not still-ciphertext — a CBC change would avalanche).

It carries a useful device-state rollup (displayed SoC, pack voltage, cumulative energy, a runtime estimate). The payload semantics are out of scope for SolixBLE — this issue is purely about the transport not delivering the frame intact.

Root cause

In SolixBLE/device.py::_process_notification, the session-message branch splits into:

• telemetry (cmd in _TELEMETRY_COMMANDS) → _process_telemetry_packet(payload, cmd), which reassembles fragments (payload[0] high nibble = index, low nibble = total), strips the header byte, then decrypts;
• unknown (else) → decrypts payload directly.

The unknown branch:

1. never reassembles — it operates on one BLE packet, so a multi-fragment frame like c490 only ever presents fragment 1; and
2. doesn't strip the fragment-header byte before decrypt (telemetry does, via payload = payload[1:]), which is what the len(payload) % 16 == 15 realign trick is compensating for on the single-packet path.

So multi-fragment non-telemetry frames can't decode at all, and the branch quietly DEBUG-logs the failure.

Proposed fix

Route unknown session frames through the same fragment path as telemetry:

• extract the fragment reassembly from _process_telemetry_packet into a small shared helper (index/total from payload[0], buffer by cmd, join in order, strip header);
• have the unknown branch reassemble → decrypt → _parse_payload, same as telemetry;
• optionally surface the result via a callback/hook (e.g. an on_unknown_frame(cmd, parameters) or a debug-frames callback) so downstream consumers can opt into non-telemetry frames instead of them only reaching the logger.

This keeps telemetry/negotiation/future-awaited handling untouched.

We have a working implementation

We're already doing exactly this downstream via a SolixBLEDevice subclass that intercepts unknown session frames and reassembles them with your fragment scheme, in production against a live A1783. Happy to open a PR that folds it into the base class (with a multi-fragment reassembly test) — wanted to check first whether you'd prefer the result surfaced via a callback vs. just reassembled-and-logged, and whether extracting a shared _reassemble helper off _process_telemetry_packet fits how you'd like it structured.

[kb1ibt]

Update — c490 turns out to be periodic telemetry, which sharpens the case here.

I've now fully decoded the c490 device-post that motivated this issue, and the key finding is that it's a form of telemetry — a compact state rollup the unit posts on its own every ~9 minutes (a device→app post, not a request/response we drive). So it belongs in the same conceptual bucket as the _TELEMETRY_COMMANDS that already get reassembled; it's dropped today only because its cmd isn't in that allowlist, so it falls into the unknown-message else branch that skips fragment reassembly.

Using the downstream reassembly implementation, concretely:

• It's genuinely multi-fragment — 372–376 bytes decrypted, spanning several notifications — so the single-packet decrypt in the unknown branch can't recover it; it needs the same reassembly telemetry gets.
• Its length varies (I've observed 372 / 373 / 374 / 376) as the payload's protobuf-style varint fields cross byte boundaries under load. So it isn't a fixed-size frame a naive handler could special-case — reassemble-then-parse is the only robust path.
• Reassembled, it decodes to a full device summary: SoC, output power, input/solar power, pack voltage, a bidirectional time-to-full/to-empty estimate, and a charge/idle/discharge flow-state — each cross-validated against the cloud/app telemetry across idle, solar charging, and AC-load discharging.

So the fix here isn't just "handle an odd unknown frame" — it's "don't silently drop a periodic telemetry post." That reinforces both halves of the earlier proposal: route unknown session frames through the existing fragment-reassembly path, and — since this is telemetry a consumer would want — surface the result via a callback/hook rather than only a debug log.

The working implementation is ready to PR whenever you'd like; still happy to match whatever you prefer on the surfacing API (callback vs. log-only) and on extracting a shared _reassemble helper off _process_telemetry_packet.

[flip-dots]

So this was something I was aware of but ignored since to gain any benefit from it you would need to do a bunch of other things (how to store alternate telemetry packets, how to handle availability, and add even more complication to the docs) and not gain all that much benefit from it since most of the important data is in the regular telemetry messages so its not something I have seriously considered until now.

The code around the printing of unknown packets pre-dates the support reading of multi packet telemetry data (and it was assumed that the format for that was unique to telemetry packets) which is why reading these multi payload packets is only supported for the telemetry packets. In hindsight I suppose it's obvious that all packets use it (with the 00 present at the beginning of single packet payloads and the ignoring of the first byte of the payload when manually requesting telemetry).

The solution I am leaning towards is performing that packet re-assembly for all packets perhaps in a dedicated function called in _process_notification which would allow the use of the existing _listen_for_packet function to listen for the re-assembled packets which should help for your use case but I am not sure about this yet, give me some time (probably a few days) to play around with it and see what I like best.

What I envision is that you could use that to write some code inside the C1000G2 class that listens for these packets and then exposes the data in them in some way. I don’t think adding direct support for caching multiple telemetry data types in the parent class is a good idea yet since the current structure will only hold one data packet at a time, not all devices send these packets, and I would like to avoid making too many big changes at once.

[flip-dots]

I have taken a look and it's more complicated than I hoped, I have not yet been able to find a universal way to decode multi-fragment packets.

As far as I can tell, information about how many fragments there are and which fragment a packet contains is usually encoded just before the payload in the format used in older style Anker Solix devices but seemingly only for telemetry packets.

The format used for the multi-fragment telemetry packets in older devices is as follows:

<HEADER 2B> <LENGTH 2B> <PATTERN 3B> <CMD 2B> <FRAG INFO 1B> <PAYLOAD bB> <CHECKSUM 1B>

So for these two telemetry packets from a C1000 we have fragment 1/2 and fragment 2/2

ff09 fd00 03010f c402 12 1e0e

ff09 3900 03010f c402 22 788d

But then also from a C1000 we have:

ff09 1a00 03010f 484a 6e 744378c57c16ca8ab3a40bebb6f39807

And this is not following the expected format since 6e does not decode to anything useful.

Looking at the telemetry packet from a prime power bank we get:

ff09 da00 030111 4300 57 e9a883d95e4

And we also see no fragment information is there.

Looking at some negotiation packets from a C300 we get:

ff09 0e00 030001 0801 00 a1010152
ff09 1b00 030001 0803 00 a10102a202fd00a30144a40101a50102ff

Now this would seem to imply that 00 means fragmentation is not used, but prime style devices don’t have that 00.

There is a whole bunch of additional test data in the tests for negotiation and packet processing which have more examples but I am not seeing a clear pattern of how exactly the app is meant to know if it needs to use multi fragment/packet decoding or not.

I also noticed that I don’t actually have any test data for fragmented payloads for newer prime style devices so if you have any logs/captures of those exchanges they would be useful.

Let me know if you have any ideas/insight on this, I will probably keep looking into it but I am not seeing any nice solutions yet.

[kb1ibt]

Following up with the newer-device fragmented captures you asked for — plus a hypothesis on the "how do you know it's fragmented" question that I think your own examples actually support.

C1000-G2-family fragmentation looks identical to your older telemetry

From a live DEBUG capture, the encrypted telemetry (c421, c900) fragments exactly like your c402 examples — pattern 03010f, frag byte right after the cmd, high nibble = index / low nibble = total:

c900:  ff09 fd00 03010f c900 12 a3781f…    (frag 1/2, len 253)
       ff09 8900 03010f c900 22 009fbb…    (frag 2/2, len 137)
c421:  ff09 fd00 03010f c421 12 018a1b…    (frag 1/2, len 253)
       ff09 8900 03010f c421 22 016ad9…    (frag 2/2, len 137)
c490:  ff09 fd00 03010f c490 12 c57bc9…    (frag 1/2, len 253)  ← summary-level telemetry, just not in the allowlist; fragments identically
       ff09 9900 03010f c490 22 bc44e1…    (frag 2/2, len 153)  → reassembles to a 372 B device summary
negotiation:  ff09 3900 030001 0829 00 a10103…   (same `00` you see)

And the key point for this issue: that c490 (shown above) reassembles with the identical logic and decodes to a full device summary. c490 is telemetry too — the summary-level rollup (pack voltage, remaining_time, flow-state) that sits above the fine-grained c421/c900 stream — so the only reason SolixBLE skips it is that it isn't in _TELEMETRY_COMMANDS. It isn't special; the allowlist just omits it — and gating reassembly on that allowlist is exactly what drops it.

The discriminator you're missing is a constant you already have

I think you're looking for a flag that isn't there — the real signal is each packet's LENGTH vs the device's expected full-fragment length, and you already track that per device: _EXPECTED_TELEMETRY_LENGTH (253 for c1000g2 and most classes). It's currently defined-but-unused — nothing reads it — but it's exactly the gate:

• LENGTH == expected (253) → the message filled a whole notification → more is coming (a non-final fragment).
• LENGTH < it → the final piece — the last fragment of a run, or a standalone single packet.

That one comparison explains all your odd cases without special-casing:

• 484a — LENGTH 1a00 = 26 B, well under 253 → standalone single. So 6e is just payload, not a frag byte — you were right it "doesn't decode as a fragment," because it isn't one; you shouldn't read a frag byte there at all.
• Prime power bank 4300 — LENGTH da00 = 218 < 253 → single, no reassembly (matches "no frag info").
• Negotiation (len 14 / 27 / 57) → all short → singles.

So the universal rule:

Accumulate while packets arrive at _EXPECTED_TELEMETRY_LENGTH; a shorter packet closes the run — reassemble onto any buffer for that cmd, else emit it as a standalone single.

No per-command allowlist needed, and it naturally covers c490, prime, negotiation, and the 484a log packet. Wiring the constant you already define into _process_notification for all frames (not just _TELEMETRY_COMMANDS) is basically the whole fix. The frag byte (12/22), where the pattern carries it, is then a redundant index/total for catching drops/reordering.

One heads-up while you're in there: the Prime classes (prime_charger_250w / prime_charging_station_240w) have _EXPECTED_TELEMETRY_LENGTH = 198, but that's a stale, untested guess (the original file's docstring said so). On real hardware the Prime 250 W charger fragments its ca00 at 253 (253 + 101, same as c1000g2 — see below), so Prime should be 253, not 198.

A second family confirms the rule: the Prime charger

The Prime 250 W charger (A2345) streams ca00 on pattern 03010f, fragmented the same way — a 253 B fragment (12) + a 101 B fragment (22) → decodes via _A2345_0a00. So the 03010f + frag-byte + 253-byte-cap scheme isn't C1000-G2-specific; the Prime charger uses it too.

Two honest caveats on the Prime side: I don't have the power bank (4300 / 030111) you referenced — that's a different Prime device than my charger — and the 240 W station (A91B2) negotiates but hasn't streamed telemetry for me yet, so I can't confirm its framing. But across everything I have captured — C1000-G2 telemetry, c490, and the Prime charger's ca00 — every 03010f payload follows the same fragment scheme and the same 253 cap.

Full raw captures

Full-hex captures (unlisted gist): https://gist.github.com/kb1ibt/a7c0a23f5ebc0bfb81f85557907c4c30

• gist_c1000g2_fragments.txt — the C1000-G2 c421 + c900 fragment pairs (253 + 137) and the negotiation/session-setup frames.
• gist_c490_summary.txt — the c490 fragment pair (253 + 153) plus its 372 B reassembled cleartext.
• gist_a2345_ca00.txt — the Prime A2345 ca00 fragments (253 + 101), decoding via _A2345_0a00.

[kb1ibt]

One addendum on the length-gate above — I found where the 253-byte fragment cap actually comes from, and it makes the rule principled rather than a magic number: it's ATT_MTU - 3.

In a pklg of the app talking to one of these devices (the 240 W station), the client requests ATT MTU 527 and the device grants only 256 — so the link MTU is 256. A GATT Handle-Value-Notification is opcode(1) + handle(2) + value, so the value maxes at 256 - 3 = 253. Every full-length fragment is just a notification filled to the brim on a 256-MTU link — nothing in the ZX frame picks 253.

So the robust form of the gate isn't the hardcoded constant, it's the live MTU:

full_fragment = client.mtu_size - 3   # accumulate while len == this; a shorter packet closes the run

_EXPECTED_TELEMETRY_LENGTH = 253 is exactly that value baked in for Anker's MTU-256 firmware — correct today because every device grants 256, but deriving it from the negotiated MTU would survive a firmware that ever grants a larger one (at which point these frames would simply stop fragmenting). Either way it reinforces the earlier point: the fragmentation is a transport effect — the notification pipe is 253 bytes wide — with nothing to do with the cmd.

[kb1ibt]

Closing the loop on the 240 W station (A91B2) — it streams now, and confirms the framing from a third cipher family.

In the length-gate comment above I noted the station "negotiates but hasn't streamed telemetry for me yet." It does now, and the framing lines up with everything else here.

Telemetry is on 03010f, like the rest:

• 4a00 (0a00) — a ~240 B full-state rollup (per-port status + the AC-outlet switches), returned to a 4200 poll
• 4303 / 4302 (0303 / 0302) — a ~80 B AC/power summary it pushes on its own ~1/s

Both sit under the 253-byte cap, so they're single packets — no frag byte, decoded directly — another clean confirmation of the length-gate (short ⇒ final/single). The 4a00 is 240 B today; a larger state would cross 253 and fragment 12/22 exactly like the C1000-G2 and A2345 frames.

The useful part for this issue: it's a different cipher family, and reassembly doesn't care. The Prime charger (A2345) is AES-GCM, but the station is AES-CBC — it's actually in the base / C1000-G2 lineage, not the Prime one. The 03010f framing is identical regardless, because reassembly operates on the ciphertext, below the cipher-specific decrypt. That's a nice validation of the reassemble-all-in-_process_notification shape you're leaning toward: one reassembler sits under the GCM-vs-CBC split and covers every family, with the frag byte + length-gate as a pure transport concern and the cipher as a device-class concern layered on top.