Repository navigation
fix: match the published CC880 device family (#95) - #96
Merged
Merged
Conversation
Medtronic publishes the complete device-family vocabulary, unauthenticated, at GET /patient/v2/configuration/public — the same host the bridge already talks to. #93 added the six Minimed Flex model prefixes and, alongside them, guessed the family token as a FLEX substring match. The published document settles it. personal.device.family.to.model.mapping lists sixteen families, and system.settings.transfer.feature.config.device.mapping independently maps "CC880" to the display name "MiniMed™ Flex". So CC880 is the Flex family, and the six models #93 added do appear under it. isBleDevice() now matches the exact published token CC880, so a family-only payload is detected without relying on deviceModel being present. Before this, isBleDevice('CC880', undefined) returned false — reproducing #91's silent zero-data fetch, the failure mode a Flex user actually hits, since monitor/data returns deviceFamily while medicalDeviceFamily is undefined on the patient path and models are not guaranteed. The FLEX substring match is kept as a fallback for the display-name spelling the vendor also publishes ("Minimed™ Flex"), on the same reasoning that SIMPLERA_SYSTEM may arrive as "Simplera™ system". Audited against all sixteen published families: none contains FLEX, so no real device is misrouted today, and CC880 detection never depended on it since that token has no FLEX in it. The residual looseness — a substring match also accepts nonsense like "REFLEX" — is documented rather than eliminated and is deliberately not pinned as a contract, so a later contributor can tighten the matcher without rewriting an assertion that enshrined it. New test classifies the entire published vocabulary: all sixteen families, each with its expected verdict and a stated reason. CC840, EAGLE, GST, NMX7, NMX8, GM and INSTINCT are deliberately left unmatched — nothing confirms they are BLE-paired, and routing a non-BLE device down the BLE endpoint is its own silent failure. The table means a family Medtronic adds later is a decision someone makes rather than a gap that surfaces weeks later as "the bridge uploaded nothing". Its completeness check is a self-consistency guard, not a vendor-change detector, and is labelled as such. Caveat: this is Medtronic's published configuration, not an observation of a monitor/data response. It establishes the vocabulary, not which field carries it or in what casing. #81 stays open until a token confirms. Tests: 323 passing (baseline 298). npm run typecheck clean.
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.
Summary
Medtronic publishes its complete device-family vocabulary, unauthenticated, at:
Two keys in that document settle what #93 had to guess:
personal.device.family.to.model.mappinglists all sixteen published familiessystem.settings.transfer.feature.config.device.mappingmaps"CC880"to the display name"MiniMed™ Flex"So
CC880is the Minimed Flex family, and the six model prefixes #93 added (MMT-8062/8063/8082-8085) all appear under it.#93 added those models correctly but guessed the family token as a
FLEXsubstring match. That guess misses:which reproduces #91's silent zero-data fetch — and on exactly the payload that matters, because
monitor/datareturnsdeviceFamilywhilemedicalDeviceFamilyis undefined on the patient path, so models are not guaranteed. The model list only rescues it when a model happens to be present.What changes
isBleDevice()matches the exact published tokenCC880, so a family-only payload is detected.FLEXsubstring match is kept as a fallback for the display-name spelling the vendor also publishes ("MiniMed™ Flex"), on the same reasoning thatSIMPLERA_SYSTEMmay arrive as"Simplera™ system". Audited against all sixteen published families: none containsFLEX, so no real device is misrouted today, andCC880detection never depended on it.CC840,EAGLE,GST,NMX7,NMX8,GMandINSTINCTare deliberately left unmatched — nothing confirms they are BLE-paired, and routing a non-BLE device down the BLE endpoint is its own silent failure of the wrong shape. Matching only the one family the vendor names is the asymmetry that makes sense: a missedCC880is a silent zero-data fetch (Minimed Flex pump (MMT-8062 family) not BLE-detected — silent zero-data fetch, reported live upstream #91); a wrong match is a wrong-shaped response.Verification
Revert-verified three ways: emptying the token set, deleting the
FLEXline, and reverting toorigin/maineach fail the suite. Zero false positives introduced — the other fifteen published families keep their prior verdict, and near-misses (CC880X,XCC880,CC88,CC,AC880) are all rejected by the exact-token set.Caveat, stated plainly
This is Medtronic's published configuration, not an observation of a
monitor/dataresponse. It establishes the vocabulary; it does not prove which field carries it or in what casing on the wire. #81 stays open until a token confirms.Closes #95. Refs #81, #91.