Research confirmation of annunciations

[mortenfyhn]

As I said in #15, I like the "low predicted" notification because I sometimes miss it when it's only on the pump. But it's annoying to get it in two places.

Choose one:

1. Somehow make the alert only show up on the watch, not on the pump
2. Make the alert show up on the watch only after a while, so I get a chance to dismiss it on the pump first
3. Make dismissing the alert on the watch also dismiss it on the pump (is this possible?)

[palmarci]

1. i think the only way is to disable that feature
2. plausible
3. i don't think it is possible due to the pump's design philosophy ("secondary display')

[mortenfyhn]

I also think 2 is the reasonable way to do this. And perhaps some setting for choosing which alarms to forward to the watch at all.

But it's kind of interesting. Do you know if anyone has looked into whether the pump supports 0x0F99 Confirm Annunciation or similar? I never looked into that.

[palmarci]

I myself have certanly not researched Confirm Annunciation, but i do not remember it from the GATT discovery days. Probably worth a look though

[palmarci]

This is very much needed, because it is a pain in the ass, especially when hitting a hypo while driving

[palmarci]

🤖 Written by an AI at Pal Marci's request.

Tested Confirm/Snooze Annunciation on hardware, 2026-09-28: blocked by pump authorization.

Build: f712dda72 on branch refactor/minimed-dedicated-task ("Snooze/Confirm Annunciation probe" in src/fw/services/minimed/minimed_session.c). Pump: 780G, MMT-1885, firmware 8.12.2.

What the probe does. Once per boot, 45 s after polling starts, the watch subscribes to IDD Command Data (0x0107) and the IDD Command Control Point (0x0106). It reads IDD Annunciation Status (0x0103), then sends 0x0F99 Confirm Annunciation and 0x0F69 Snooze Annunciation. Both are SAKE-encrypted the same way as the Status Reader requests that already work. Both use instance ID 0xFFFF, which no annunciation has. A pump that implements them should answer "Procedure not applicable" (0x74), one that doesn't "Opcode not supported" (0x70). No real alarm is touched either way.

Result:

23:50:36  minimed: annunc status read failed err=0x0000 len=4
23:50:36  minimed: annunc probe snooze: write err=0x0108
23:50:37  minimed: annunc probe confirm: write err=0x0108

• Both subscriptions succeed.
• Both writes are rejected at the ATT layer with 0x08 Insufficient Authorization, and no Response Code indication follows. The pump refuses every write to the Command Control Point from a link that has only done SAKE, before it looks at the opcode. So we still don't know whether Confirm/Snooze are implemented.
• The Annunciation Status read itself works: the value is 1 byte, flags only, and no annunciation was shown at the time. (The probe logs this as "read failed" because it expects a full record. That's a logging issue, not a read failure.)

Likely gate. Set Bolus goes through the same Command Control Point, and MiniMed Mobile does an extra step before it can bolus. It hands the pump a public key through the Secure Control Point (0x0109, "PublicKeyExchangeApiImpl"), and the pump answers valid/invalid key data. That is probably what authorizes Command CP writes. Where that key comes from, and whether the pump accepts one from us, is the next thing to find out.

Status of the three options:

1. Show the alert only on the watch: still only possible by turning it off on the pump.
2. Delay the watch alert so it can be dismissed on the pump first: needs no pump support, so it remains the practical route for now.
3. Dismiss on the watch = dismiss on the pump: depends on the Secure Control Point authorization above.