Beiträge von dideldum

Zitat von wurzelsepp

dann wäre das eine Meldung an das Bfarm wert.

Tja, was soll ich sagen... Halte ich für ziemlich sinnlos.

Vor 2 oder 3 Jahren, als der Libre 2 mal viele viele Chargen hatte, bei denen kein Bluetooth funktionierte (das waren meiner Erinnerung nach über 100 Chargen, es müssen also sicherlich Tausende von Sensoren gewesen sein), da hatte ich das auch dem Bfarm gemeldet. Ich habe von denen nie auch nur eine Reaktion erhalten.

Das gleiche bei Easy Release Kathetern für die Dana. Da gab es eine Zeit, da waren die Verbindungsstecker zwischen dem Schlauchstück und dem Kanülen-Stück sehr schlecht gefertigt und hatten sehr große Hohlräume. Dadurch bildete sich dort trotz Entlüften eine ziemliche Luftblase im Bereich von ca. 1IE Volumen (das kann ich nur schätzen, messen konnte ich das leider nicht). Diese Luft konnte dann überraschend in das Kanülen-Stück wandern und zu fehlendem Insulin führen, Gerade bei Kindern ist eine fehlende IE ganz enorm. Wenn das Kind (und das war bei meiner Tochter der Fall) nur 0,2IE/h Basal hat und dann über mehrere Stunden nur Luft statt Insulin kommt, weil dieser Hohlraum unbemerkt gar nicht mit Insulin, sondern mit Luft gefüllt war, dann hat das Kind nach den Stunden ein ziemliches Problem.

Meine Meldung an das Bfarm dazu inklusive Video, was das gezeigt hat, wurde genauso ignoriert wie meine Libre-Meldung.

Mit anderen Worten: Camdiab kann machen was sie wollen und Fehler in CamAPS haben, wie sie wollen. Das interessiert das Bfarm nicht die Bohne.

Zitat von wurzelsepp

Wenn das wirklich so ist

Das ist wirklich so.

Die angebliche fehlende Netzwerk-Verbindung beim Libre3-Starten ist verifizierbar falsch. Ich hatte vorher

a) beim Start meinen Konto-Namen und -Passwort angeben müssen, hier wurde über das Internet verifziert, es war also eine Netzwerkverbindung vorhanden.

b) die Pumpe verbinden müssen. Auch hier wurde eine Netzwerk-Verbindung hergestellt, um die Berechtigung der Nutzung von CamAPS mit dieser Ypsopump zu verifzieren.

und dann

c) den Libre 3 gestartet. Und auf einmal soll keine Netzwerkverbindung mehr da gewesen sein, obwohl ein sofortiger Abruf von Internet-Seiten natürlich problemlos funktioniert hat und die vorherigen Netzwerkverbindungen, die innerhalb der letzten 2 Minuten stattfanden, ja auch funktioniert hatten.

Der Companion-Fehler, der zu einem irrsinnigen Anwachsen des internen Speichers (innerhalb von Stunden in den Gigabyte-Bereich!) führt, wurde, nachdem ich Ypsomed/Camdiab logcat-Auszüge geschickt hatte, als internes Netzwerk-Handling-Problem analysiert und mir so mitgeteilt. Tatsächlich war in dem logcat-Log zu sehen, dass CamAPS im millisekunden-Takt Netzwerkstatus-Abfragen durchführte und offensichtlich falsch mit der Antwort umging, weshalb es umgehend wieder dieselbe Anfrage stellte und so in kürzester Zeit wahrscheinlich interne Logs mit Fehlermeldungen überflutete. Offensichtlich verwendet CamAPS keine rollierenden Logs, was an dieser Stelle katastrophal war, denn dadurch wuchs der interne Speicher so rasant an, dass CamAPS selbst nicht mehr damit zurecht kam und behauptete, weder Sensor noch Pumpe seien erreichbar. Dies war aber ganz klar kein Bluetooth-Problem, sondern der Tatsache geschuldet, dass CamAPS mit seinen eigenen Gigabyte nicht zurecht kam. Grundsätzlich muss das System ja auch nur mit Megabyte umgehen (14 Tage minütliche Librewerte erzeugen ca. 2MB Datenmenge!).

Und in Folge war dann das Übertragen der Diagnose-Daten (die ganz offensichtlich dann diese internen Gigabyte Log beinhaltet hätten) auch wegen angeblicher Netzwerkfehler nicht möglich. Ich hatte dazu zwischendurch das System komplett zurückgesetzt, so dass der Speicher wieder bei 0 anfing. Hier ließen sich die Diagnose-Daten problemlos übertragen. Auch noch einige Stunden später, als das System bei ca. 130MB war. Wieder ein paar Stunden später, als mittlerweile 600MB interner Speicher belegt waren (eben wegen der Millisekunden-Dauer-Netzwerk-Fehler, die in Wirklichkeit nichts mit dem Netzwerk, sondern dem nicht erreichbaren Companion zu tun hatten), da hatte dann die Übermittlung der Diagnose-Daten auch wieder angebliche Netzwerk-Probleme.

Wie gesagt: in keinem dieser Situationen gab es wirklich ein Netzwerk-Problem. Alle anderen Netzwerk-Aktivitäten sowohl über Wlan als auch über Mobildaten haben selbstverständlich einwandfrei funtioniert. Es handelt sich hier um klare Bugs in CamAPS FX.

Zitat von Bjr

Arbeitet das System wirklich nur mit TBRs (Ähnlich AMA bei AAPS)

Nebenbei war das immer eine von mehreren Dingen, die ich bei AndroidAPS immer für falsch gehalten habe und die CamAPS FX an dieser Stelle viel besser macht. Die Verwendung von temporären Basalraten war schon immer ein Fehler. Denn von einer Basalrate 0 kann man keine prozentualen Veränderungen vornehmen. Deshalb verbot AndroidAPS auch immer den Basalratenwert 0, obwohl alle Pumpen natürlich die Möglichkeit haben, auch mal eine Stunde die Basalrate 0 zu setzen, was insbesondere bei kleinen Kindern mit wenig Basalratenbedarf durchaus Sinn macht (alternierend z.B. 0,00 und 0,04 bei der Dana als Basalrate zu setzen, wenn das Kind eigentlich 0,02 pro Stunde braucht).
Hier ist CamAPS FX trotzdem steuerfähig, weil es die Basalrate einfach IMMER auf 0 setzt und die gesamte Insulinsteuerung über verzögerte Boli löst - und die sind immer unabhängig von der Basalrate, der verzögerte Bolus steht einfach nie in einem prozentualen Zusammenhang zur Basalrate, wie das die TBR tut. Noch dazu haben eben alle Pumpen Begrenzungen in der Höhe der TBR, was mit einem verzögerten Bolus gar nicht zum Tragen kommt. Da haben sich die AAPS-Entwickler (wie in einigen anderen Punkten auch) einfach nicht genug Gedanken gemacht, bzw. sind (und das gilt ganz besonders für Milos) Vorschlägen und Argumenten leider nicht einsichtig genug gegenüber. Natürlich schlägt dieses Problem bei der Verwendung von SMBs nicht mehr zu. Aber die Verwendung von verzögerten Boli, die je nach Höhe einfach eine langsamere gleichmäßigere Abgabe eines SMB darstellen, finde ich deutlich charmanter und vor allem Sicherheits-orientierter. Das macht CamAPS in meinen Augen sehr gut (auch wenn es an anderen Stellen, wie von mir ja andernorts zu lesen ist, auch einiges schlecht macht).

Es arbeitet weder mit der Basalrate (da hat Lilimaus Recht) noch mit SMB/Mikroboli.

CamAps benutzt ausschließlich verzögerte Boli, die in ihrer Art natürlich einer temporären Basalrate entsprechen, aber nicht an prozentuale TBR-Begrenzungen gebunden sind.

wurzelsepp Die angeblichen Netzwerk-Probleme sind ja aber gar nicht vorhanden! Wenn CamAPS FX glaubt, es gäbe Netzwerk-Probleme, dann sind diese Probleme intern programmiertechnisch hausgemacht. In den von mir erprobten Problemfällen (Libre 3 neu starten, Companion nicht erreichbar, Diagnosedaten bei großem selbst durch CamAPS FX verschuldeten internem Speicher) gab es in keiner Situation tatsächlich ein Netzwerk-Problem! Das war/ist alles CamAPS-intern buggy programmiert!

Zitat von califax2k

Ich finde Deine Vermutung bezüglich der Speicherung auf dem Server sehr plausibel. In der Arzt-Praxis, in der wir die Einweisung (im Beisein unserer sehr geschätzten Diabetologin) bekommen haben, gab es leider nur "dünnes" Netz - Edge. Man könnte mutmaßen, dass CamAPS anfangs versucht, eine Verbindung zum Server aufzubauen und wenn es nicht klappt, in einen Zustand gerät, von dem es sich anschließend nicht wieder "erholt" (Bug).

Dazu noch ein Nachtrag: Wir hatten die Einweisung bei mir Zuhause gemacht. 5m vom Wlan-Router entfernt mit einer absolut stabilen 100Mbit-DSL-Leitung. Da gab es zu keinem Zeitpunkt ein Netzwerk-Problem. Ich denke, hier ist eins von vielen grundlegenden Programmierproblemen von CamAPS FX. Das betrifft z.B. auch die Companion-Geschichte (auch hier ist ja eine Netzwerk-Komponente involviert), die im Falle der Nichterreichbarkeit eines Followers/Companions zu einem unglaublichen lokalen Speicherwachstum auf dem Master führt, wodurch sich die App dann selbst lahmlegt (keine Verbindung mehr zu Sensor und Pumpe) - ein absolutes NoGo für die Verwendung bei Kindern mit Eltern als Companions! Weiteres internes Programmierproblem tritt dann in Folge des Companion-Problems auf: Durch den irre angestiegenen internen Speicher ist die App dann auch nicht mehr in der Lage, die eigenen Diagnose-Daten an den Camdiab-Server zu übermitteln (das "Verbinden"-Menü in CamAPS FX). Auch dort taucht dann beim Versuch, die Diagnose-Daten zu senden, der (falsche!) Fehlerdialog auf, dass offenbar keine Netzwerk-Verbindung besteht.

Man kann also guten Gewissens sagen, dass in CamAPS FX alles, was irgendwie mit Netzwerk-Kommunikation zu tun hat, ziemlich buggy ist - unglücklicherweise auch mit Auswirkungen auf Komponenten, deren reine Funktionalität (Pumpen- und Sensor-Kontakt) gar nichts mit irgendeiner Netzwerk-Verbindung zu tun haben!

Zitat von califax2k

LibreLink haben wir nicht verwendet, macht für uns - glaube ich - aber auch keinen Sinn, da es laut Abbott Webseiten so aussieht, als ob das die "Vorgänger" App für die Freestyle Libre 3 App ist und für Libre 2 Sensoren genutzt wurde.

Ja, die Libre 3 App heißt nicht mehr LibreLink, das stimmt. Aber das Prinzip, die Sensor-Verbindungsdaten auf den LibreView-Server hochzuladen, so dass man den Sensor mit denselben Logindaten des LibreView-Kontos auf einem anderen Handy übernehmen konnte, das war mit dem Libre 2 auch schon da. Wir brauchen immer noch Libre 2 auf (mit gepatchter LibreLink, so dass die minütlichen Daten in meine App kommen), daher benutzte ich den Namen LibreLink und nicht "Freestyle Libre 3 App". Für beide gilt aber das gleiche.

Zitat von califax2k

Ein Frage bezüglich der Accounts: Sollte der von CamAPS Fx und Freestyle Libre 3 genutzte Account nicht derselbe sein? Oder reden die Apps mit verschiedenen Servern??

Nein, der Camdiab-Account hat nichts mit dem Abbott-Libreview-Account zu tun. Camdiab nutzt nur dasselbe Prinzip wie Abbott mit Libreview, dass bestimmte Schlüsseldaten des aktivierten Sensors im eigenen Server gespeichert werden, so dass bei Verwendung desselben Kontos der Sensor auch auf einem neuen Gerät (theoretisch) wieder eingebunden werden könnte. Da das Camdiab-Konto und das Libreview-Konto aber keine Beziehung zueinander haben, ist es nicht möglich, z.B. einen mit der Freestyle Libre 3 App gestarteten Sensor in CamAPS FX zu übernehmen.

Zitat von califax2k

Wieso diese App allerdings Standortzugriff benötigt, ist für mich in keiner Weise nachvollziehbar.

Das ist nicht die Schuld der App, sondern bei Google zu suchen. Bereits seit Android 7 (glaube ich) war es bei Nutzung von Bluetooth für die Erkennung naher Geräte zwingend notwendig, die Standortfreigabe zu erteilen. Da der Libre 2/3 über Bluetooth kommuniziert und auch die Pumpe über Bluetooth verbunden werden muss, ist die Standortfreigabe dank der internen Google-Android-Vorgaben zwingend notwendig.

califax2k Ich hatte dieses Problem, dass der Libre 3 wegen angeblicher Internetprobleme nicht zu starten war, auch. Und zwar direkt bei der Einweisung.

Der Herr, der mit mir die Einweisung vornahm, hatte das noch nicht erlebt. Wir hingen dann geschlagene anderthalb Stunden in der Ypsomed-Hotline. In der Zeit haben wir es immer wieder erfolglos versucht, jedesmal mit dem Fehlerdialog, dass wegen (angeblicher!) Internet-Probleme der Sensor nicht gestartet werden könne.

Als der Einweiser endlich aufgab, weil die Ypsomed-Hotline nicht erreichbar blieb (wie gesagt: anderthalb Stunden und immer noch keiner am Rohr) und gehen wollte, wollte er vorher noch Fotos von dem Dialog machen. Und just in dem Moment ging das Starten des Sensors dann.

Du kannst davon ausgehen, dass in CamAPS FX noch jede Menge Bugs sind. Das ist einer davon. Mit tatsächlichen Netzwerk-Problemen hat das natürlich nichts zu tun. Denn ich konnte ja auch direkt vorher mit dem CamAPS-Konto einloggen, was ja auch über das Internet ging. Und selbstverständlich waren auch während dieser angeblichen fehlenden Internet-Verbindung alle anderen Internet-Tätigkeiten (Email abrufen, Browser-Seite öffnen etc.) problemlos möglich.

Grundsätzlich ist zum Starten des Sensors natürlich gar kein Internet notwendig. Allerdings scheint CamAPS genauso wie die LibreLink-App die Sensor-Informationen auf ihrem Server zu speichern, damit man bei Neuinstallation auf demselben oder einem anderen Handy die Sensor-Verbindung übernehmen kann. Aber auch diese Funktionalität ist buggy. Aussage der Ypsomed-Supporterin: "Mal geht es, mal nicht...". Ich wollte den so problematisch gestarteten Sensor dann nach einer Woche testweise auf ein anderes Handy übernehmen. Das funktionierte nicht. Danach bekam ich ihn auf dem ersten Handy auch nicht wieder. Ich setzte also einen neuen. Mit dem habe ich am letzten Betriebstag das gleiche probiert. Mit dem ging die Übernahme auf ein anderes Handy dann. Alles in allem also eine nicht zuverlässig funktionierende Software.

Ich bin mittlerweile schwer erschüttert, dass dieses System tatsächlich als medizinische Software zugelassen ist, denn da sind doch erhebliche Fehler drin, was mein Vertrauen darin ziemlich aufgelöst hat. Das, und die unerträgliche nicht konfigurierbare Abgabegeschwindigkeit der Ypsopump, haben dazu geführt, dass meine Tochter und ich nach sehr kurzem Betrieb von CamAPS/Ypsopump (ich: 3 Wochen, Tochter: 9 Stunden) wieder auf die Dana mit DIY-Loop zurückgegangen sind.

Nebenbei wird von einigen ja immer behauptet, dass die Aktualisierungen medizinischer Geräte (z.B. Pumpen-Firmware oder auch gewünschte Verbesserungen der LibreLink-Software) so träge ist, weil dann immer eine Neuzulassung fällig ist. Das ist offensichtlich Quatsch, denn von CamAPS gibt es ja in sehr kurzen Abständen (teilweise nur Wochen!) Software-Updates, und das aufgrund der Kürze dieser Abstände ganz ohne aufwendige Tests und Zulassungen. Besser macht es das ganze mit CamAPS natürlich nicht, denn es zeigt nur, was für einen Nacharbeits-Bedarf Camdiab da hat. Umgekehrt zeigt es aber auch, dass z.B. Pumpenhersteller, die Jahre für ein Firmware-Update brauchen (oder es gar nicht machen), das durchaus könnten, aber vermutlich aus wirtschaftlichen Gründen gar nicht wollen.

Zitat von Schaf

Warum hast Du so einen engen Zielbereich?

siehe:

Zitat von Sonnenblume

wegen erneuter Schwangerschaft

Bei Schwangerschaft ist der Zielwert am besten doch 80 und der Zielbereich deutlich enger als normal.

Zitat von Schaf

Und warum steht das dann da:

Das was du zeigst, sagt Google über die Kompatibilität.

Das was ich schreibe, sagt Ypsomed über die Kompatibilität.

Und wenn es um Support für CamAPS FX geht, ist Google völlig irrelevant.

Zitat von huetterei

Aber ich habe beiden auch nie geschrieben, das mein Gerät nicht auf deren Liste steht.

Ich wurde beim Telefonkontakt explizit gefragt, welches Handy ich benutze.

Und in den mehreren Gesprächen, die ich geführt habe, war unter anderem auch eine Frage von mir, ob CamAPS die Google Services benutzt (was denkbar wäre, um die Follower/Companions zu erreichen, so wie das xDrip+ und viele andere Apps auch machen). Ich wollte nämlich CamAPS für mich auf dem Ruggear RG360 einsetzen und das hat keine Google Services. Da wurde mir klipp und klar gesagt, dass für ein Smartphone, das nicht auf der Libre3-Liste steht (weil das mein Sensor ist), keinerlei Aktivität von Ypsomed/Camdiab unternommen würde. Also auch die Frage, ob Google Services notwendig sind oder nicht, nicht beantwortet werden könne.

Nebenbei: da ich ja Logs aufgrund des gravierenden Companion-Bugs gezogen habe, ist denen zu entnehmen, dass CamAPS offensichtlich den Amazon-Web-Service nutzt. Aber auch dazu sagt Ypsomed/Camdiab nichts. Ypsomed nicht, weil denen die Expertise fehlt und sie solche Fragen eh an Camdiab weiterleiten müssen, und Camdiab nicht, weil sie nicht wollen.

Zitat von Wattwurm

Das ist eben wie mit jeder Software im Trial Mode: Kosten- und Lizenzfrei mit eingeschränkter Funktionalität und oft begrenzter Laufzeit.

Wäre das anders, würde niemand mehr eine Softwarelizenz kaufen.

Das würde ich im Fall CamAPS im Dummymodus aber nicht gelten lassen.

Im Dummy-Modus läuft eine virtuelle Pumpe und ein virtueller Sensor, gegebenenfalls auch ein echter Sensor. Also kein System, mit dem man irgendetwas in Sachen Loop wirklich anfangen kann.

Dass in diesem Betriebsmodus die Faktoren nicht gespeichert werden oder der Companion-Modus gar nicht funktioniert, ist einfach Programmier-Blödsinn.

Ich habe genau das nämlich alles noch vor Inbetriebnahme testen wollen und habe genau deshalb den Support angerufen, weil das alles für mich Fehler waren (und bleiben!). Der Support hat mir dann versichert, im echten Betrieb werden die Faktoren gespeichert (was stimmt) und der Companion-Modus funktioniert (was nicht stimmt, da sind nämlich noch üble Bugs!).

Generell gibt es für mich überhaupt keinen Grund, warum im Trial-Modus nicht alles richtig funktionieren sollte. Wohlgemerkt: Trial-Modus heißt, es hängt keine echte Pumpe im CamAPS. Mit echter Pumpe muss man eh einloggen und die Schulungs-ID eingeben, dann ist es eben sowieso kein Trial mehr. Und wenn dann nicht bezahlt ist (entweder von Ypsomed oder bei Nutzung der Dana von einem selbst), funktioniert CamAPS ja eh nicht. Insofern ist die eingeschränkte Funktionalität von CamAPS im Trial-Modus einfach nur Programmier-Dummheit oder ein Bug oder sonstwas, aber sinnvoll im Lizenz-Sinn ist es eindeutig nicht.

Zitat von huetterei

In dem Dummymodus funktionieren einige Sachen nicht.

Zum Beispiel konnte ich in dem Modus Camaps + Dexcom ohne Ypsopump mein Telefon testen, konnte aber die ganzen Faktoren für Essen und Korrektur nicht dauerhaft speichern.

Damals gab es die FSL3 Version noch nicht, deshalb weiß ich nicht wie es heute als Dummyversion ist.

Auch mit der Libre-Version die gleichen Probleme im Dummy-Modus. Da ist vieles rausgekürzt oder buggy.

Zitat von Schaf

Wenn die App auf dem Handy läuft, ist die Kompatibilität bereits gegeben, s. auch im Playstore (wird dort angezeigt).

Leider nein. Bei der Kompatibilität geht es Ypsomed/Camdiab in erster Linie um den Sensor. Ist das Smartphone nicht auf der Kompatibilitätsliste von Dexcom/Abbott (je nach benutzten Sensor) ist das Smartphone nicht kompatibel und dann wird auch kein Support geleistet.

Natürlich kann ein anderes Smartphone trotzdem funktionieren. Das Cubot Pocket 3 läuft z.B. mit CamAPS und Libre 3. Aber Support gibt es dann im Problemfall eben nicht, weil nicht auf der Liste von Abbott.

Zitat von heikeov

Bei mir stand auch in dem Schrieb von der Krankenkasse drin, dass ich die Pumpe nach Ende der Nutzung an den Hersteller zurückschicken muss.

Jetzt, da du das schreibst, meine ich mich zu erinnern, dass wir für die Medtronic tatsächlich auch sowas von der KK erhalten hatten. Sicher bin ich aber nicht mehr, ist schon 6 Jahre her.

Für die Dana und die Ypsopump gab es das aber bei uns nicht.

Zitat von heikeov

Medtronic wollte die alten Pumpen immer haben, aber auch da kann man verhandeln...

Was muss man mit denen denn da verhandeln? Wenn die ihr Geld für ihr Produkt erhalten haben, warum sollte man ihnen das Produkt dann zurückgeben? Die haben doch einen Kaufpreis dafür bekommen, keine Leihgebühr. Wenn man, so wie wir, die Medtronic nach einem Jahr nicht mehr will (wir wollten sie vom ersten Moment an nicht, waren aber von der Bult leider zur Nutzung erstmal gezwungen worden), dann sehe ich ja ein, dass der Hersteller die Pumpe zurückhaben will. Allerdings natürlich auch nur dann, wenn er der Krankenkasse einen Teil des Kaufbetrags zurückerstattet, da ja die Nutzungszeit der Pumpe unter der Garantiezeit lag. Sollte die Krankenkasse trotz kürzerer Nutzungszeit gar kein Geld zurückerhalten, hat auch Medtronic überhaupt keinen Anspruch auf Rückerhalt der Pumpe.

Zitat von justtype1diabetic

Und wenn ihr Traubenzucker nehmt, welche Marke und am Besten noch die Geschmacksrichtung damit ich mich mal durchprobieren kann.

Wir haben immer Rollen von Intact Traubenzucker. Den gibt es in zig verschiedenen Sorten, da findet man sogar welche, die richtig gut schmecken. Meine Tochter steht auf Erdbeere-Yoghurt, ich bevorzuge Pfirsich-Maracuja und Apfel.

Zitat von cheers2

Den Punkt sehe ich anders (bei allem anderen hast Du recht). Die Pumpe gehört zu keinem Zeitpunkt dir. Eigentümer ist und bleibt die KK

Ja, natürlich ist die KK der Eigentümer. Aber die KK hat überhaupt kein Interesse daran, alten ausgedienten "Schrott" (selbst wenn er noch voll funktionsfähig ist) zu erhalten. Tatsächlich würde es mich wundern, wenn überhaupt irgendeine KK medizinische Geräte oder sonstige Utensilien erhalten wollen, die haben dafür nämlich überhaupt keine Verwaltungsstellen oder Lager. Unsere zumindest will von "überschüssigem" Kram nichts wissen. Wir haben nach dem Umstieg auf Libre 3 noch viele Libre 2 (in nun 5 Jahren Libre 1 und 2 durch vielfache Reklamationen, die dann natürlich zu einem "Zeitgewinn" in Bezug auf vorhandene Sensoren führen) übrig. Da will unsere KK gar nichts von wissen, die wollen überhaupt kein Material, egal ob original verpackte Katheter-10er-Packungen nach Pumpenwechsel oder originalverpackte Sensoren oder oder oder. Die machen die Rechnungsabwicklung. Anfassbares Material ist in deren Workflows nicht vorhanden!

Es geht also sowieso NIE darum, der KK etwas zurückzugeben. Wenn, dann eben dem Hersteller, aber auch das eben nur unter der Voraussetzung, dass die KK mit ihm z.B. eine Preisminderung wegen zeitlich geringerer Nutzung vereinbart. Wenn der Hersteller den vollen Preis erhalten hat, hat er kein Recht mehr auf das Produkt.

Zitat von Hubi

Das hatte ich auch mal so verstanden; es gibt eigentlich nicht per se ein "Recht" auf eine neue Pumpe nach Ablauf der Garantiezeit, sondern nur, wenn sie danach kaputt geht oder es einen medizinischen Grund gibt, warum man irgendein anderes Modell braucht. Aber offenbar sind da ja manche Kassen deutlich kulanter unterwegs als andere.

Ja, da war unsere Kasse auch sehr locker. Wir haben die Dana RS knapp 5 Jahre gehabt und wollten halt gern auf die Ypsopump mit CamAPS FX umsteigen (was wir nun allerdings wieder rückabwickeln und zur Dana I zurückgehen). Da hat unsere KK-Sachbearbeiteren beim Blick in unsere Daten sofort gesagt, "Sie haben die Pumpen ja schon mehr als 4 Jahre, da können Sie sofort eine neue beantragen".

Grundsätzlich sehe ich es auch so, dass bei voller Funktionalität keine Notwendigkeit besteht, nach 4 Jahren einfach mal so das System zu wechseln. In unserem Fall ist das Display der einen Dana RS aber schon sehr abgedunkelt und kaum noch lesbar. Blind möchte ich die nicht bedienen, die ist also wahrscheinlich in wenigen Monaten eh nicht mehr benutzbar. Die andere hat einen kleinen Riss, der über kurz oder lang mal das Gehäuse auseinanderbrechen lässt. Da habe ich dann doch, selbst wenn die Pumpen NOCH funktionieren, schon mal lieber eine neue parat. Und wenn das nach Ende der Garantiezeit so leicht mit der KK geregelt werden kann, bin ich nicht böse darüber.

Zitat von Leila

Ich hab die Insight und Fiasp, das brennt null, obwohl die pumpe das flott abgibt.

Vom Lyumjev bin ich wegen dieser ständigen Brennerei am Katheter weg.

Ich denke, bei deinen geringen Insulinmengen musst du dir da keine sorgen machen.

Das würde mich jetzt mal interessieren. Die Insight hatte ich in meiner Geschwindigkeitsliste nicht auf dem Schirm, weil sie ja nicht mehr zu haben ist. Laut Benutzerhandbuch hat die Insight sogar 4 einstellbare Geschwindigkeiten:

Standard: 12 U/Min.

Mittel: 9 U/Min.

Langsam: 6 U/Min.

Sehr langsam: 3 U/Min

Selbst die langsamste ist aber mit 3U/min immer noch doppelt so schnell wie die Standard-Geschwindigkeiten der anderen Pumpen.

Selbst die schnellste ist aber mit 12U/min immer noch nur ca. 1/3 der Ypsopump-Geschwindigkeit.

Ich gehe davon aus, dass du, wenn du vorher kein Brennen hattest, wohl immer mit der höchsten Geschwindigkeit (12U/min) abgegeben hast. Hast du mit Lyumjev dann mal die langsameren Geschwindigkeiten ausprobiert? Ich habe mit den schnellsten 5U/min bei der Dana mit Lyumjev kein Brennen und Töchterchen mit den langsamsten 1U/min mit Lyumjev eben auch nicht. Ich würde deshalb davon ausgehen, dass du mit der Insight bei den langsamsten 3U/min mit Lyumjev eher auch kein Brennen haben würdest. Daher mein Interesse, ob du das auch mit den verschiedenen Geschwindigkeiten probiert hast.

Ich habe auch so eine Jacke, die offenbar im Auftrag des Pentagon zur Verhinderung der Kommunikation mit chinesischen Handys gefertigt wurde.

Wenn ich die anhabe, gibt es keine Kommunikation zwischen Libre und Smartphone, es sei denn, ich stecke es in die passende Seitein-Innenbrusttasche der Jacke, so dass es nur 10cm vom Sensor entfernt ist.

Außerdem hatten wir mal ein Smartphone (ich glaube, das war das Soyes S10, ein insgesamt sowieso sehr schlechtes Chinaphone), damit gab es grundsätzlich Verbindungsverlust, wenn man nach draußen ging (im Haus gab es immer Kontakt).

Am Alter des Smartphones kann man es eigentlich nicht festmachen, wir hatten z.B. Android 7-Geräte mit 1G/8G, die haben einwandfrei funktioniert, auch ein aktuelles Android 13 Gerät funktioniert problemlos mit dem Libre 3 (obwohl da ja einige von Problemen bei Android 13 berichteten).

Verbindungsverlust liegt also meiner Erfahrung nach immer am Smartphone (zeigt sich sehr häufig, dass nach Neustart des Smartphones wieder Werte kommen) oder der Umgebung, nie am Sensor.

"Sensorfehler" hingegen ist genau dann, wenn schnelle GZ-Wechsel die Werte für das Libre-System unplausibel erscheinen lassen. So eine Situation hat bei uns mit dem Libre 2 aber eigentlich immer nur 5 bis 20 Minuten gedauert, dann kamen wieder Werte (und in der Regel hatte das System Recht, es GAB dann einen abrupten Richtungswechsel). Mit dem Libre 3 haben wir noch nicht genügend Erfahrungszeit dazu gesammelt (ich brauche immer noch Libre 2 auf, obwohl die Libre 3 schon im Schrank liegen...).