Beiträge von dideldum

    insgesamt erhalte ich also von einem Sensor tatsächlich 14 Tage, 12 Stunden und 15min per Bluetooth Werte

    Da muss ich mich selbst gerade mal korrigieren. WERTE erhalte ich tatsächlich nur 14 Tage, ELF Stunden und 15min, weil ja seit ca. April 2020 die Libre-2-Sensoren nicht mehr offiziell 14 Tage NACH Ablauf der Startzeit, sondern 14 Tage AB STARTZEITPUNKT funktionieren, da hat Abbott die Laufzeit der Sensoren ja dem Dexcom-Verhalten angeglichen. Vorher war das anders, die Libre2-Sensoren vor ca. April 2020 hatten ja eine echte 14Tage-Werte-Zeit nach Ablauf der Startzeit.

    An der Stelle, wo jetzt die Start- und Endzeit des neuen Sensors in LibreLink vermerkt wird, vermerke ich als Endzeit einfach eine 12 Stunden spätere. So erhalte ich auch 14 Tage und 12 Stunden die Bluetooth-Werte über die gepatchte LibreLink (und tatsächlich dank eines weiteren Hinweises desselben netten Menschen, nicht erst 60min nach dem Start, sondern bereits 45min nach dem Start, insgesamt erhalte ich also von einem Sensor tatsächlich 14 Tage, 12 Stunden und 15min per Bluetooth Werte).

    Hast du mal (mit einem normalen Setup) ausprobiert, was passiert wenn man den Sensor per NFC scannt? Das müsste ja dann eigentlich auch funktionieren.

    Habe ich. Das Scannen hat offenbar nochmal an anderer Stelle seine 14-Tage-Begrenzung eingetragen. Tatsächlich sagt LibreLink nach Ablauf dieser 14 Tage + 0 Stunden, dass der Sensor nicht mehr gescannt werden kann, weil er abgelaufen ist. Die Bluetooth-Werte trudeln aber dank der Patch-Erweiterung noch 12 Stunden weiter ein.

    Da wir mit den Miniphones sowieso nicht scannen können, war es mir aber nicht wichtig, auch noch die Scan-Stelle zu finden, wo man noch verändern müsste, um auch während der Nachlaufzeit scannen zu können.


    Zum anderen Punkt gibt's eine PN.

    wie bekommst du es (ohne Zeitumstellung) auf dem Handy hin, dass diese auch nach Ablauf der 14 Tage die Werte noch akzeptiert?

    Ich habe den Patch bei mir erweitert. Das musste ich sowieso tun, weil der Patch die Werte nur an xDrip+ weiterleitet, ich die minütlichen Werte aber in meiner eigenen App haben wollte.

    Dank einem netten Hinweis eines anderen technisch Bewanderten konnte ich die Stelle in LibreLink identifizieren, in der die Endzeit des Sensors eingetragen wird und an dieser Stelle einfach 12 Stunden angehängt.

    Tatsächlich ist die Begrenzung auf 14 Tage nämlich in der LibreLink-Software festgelegt und nicht durch den Sensor bedingt. An der Stelle, wo jetzt die Start- und Endzeit des neuen Sensors in LibreLink vermerkt wird, vermerke ich als Endzeit einfach eine 12 Stunden spätere. So erhalte ich auch 14 Tage und 12 Stunden die Bluetooth-Werte über die gepatchte LibreLink (und tatsächlich dank eines weiteren Hinweises desselben netten Menschen, nicht erst 60min nach dem Start, sondern bereits 45min nach dem Start, insgesamt erhalte ich also von einem Sensor tatsächlich 14 Tage, 12 Stunden und 15min per Bluetooth Werte). Nach 14 Tagen und 12 Stunden ist dann aber tatsächlich endgültig Schluss, dann hört der Sensor selbst auf, Werte zu senden und ist nun wirklich "deaktiviert".


    Ich weiß, mit DiaBox könnte man ihn sogar neu zu starten, was ich aber noch nicht probiert habe, weil der DiaBox-Entwickler ja nicht OpenSource-Software macht (sondern im Gegenteil seine Software mit einem sogenannten "Obfuscator" für andere möglichst unlesbar macht) und auf meine Gesprächsversuche bezüglich der Daten aus seiner App nicht eingeht. Ich bleibe daher bei der gepatchten LibreLink, die ja sogar deutlich mehr Informationen rausgibt, als xDrip+ verwendet. Z.B. die gescannten Daten und auch Informationen über Bluetooth-Verbindungsverlust. Man kann dem Benutzer also über die gepatchte LibreLink viel mehr mitteilen, als das derzeit in xDrip+ leider getan wird (deshalb verwende ich die Informationen auch lieber direkt bei mir und verzichte auf xDrip+).

    Fakt ist doch, dass es von Abbott so vorgesehen ist, dass der alte Sensor deaktiviert wird, sobald ein neuer gestartet wird.

    Genau das ist eben nicht so.


    Jeder Libre 2 Sensor überträgt (wenn er denn fehlerfrei läuft) bis zum Ende seiner 14 Tage plus 12 Stunden Werte per Bluetooth. Er wird nie deaktiviert. Wenn mit demselben Startergerät ein neuer Sensor mit LibreLink gestartet wird, wird in LibreLink die neue Sensor-Kennung eingetragen und das als aktive Verbindung betrachtet. Der alte Sensor wird dabei aber gar nicht kontaktiert, also auch nicht deaktiviert.


    Wir benutzen für den Empfang der Libre2-Werte per Bluetooth Minismartphones OHNE NFC, die können den Libre also gar nicht starten. Dafür benutze ich ein anderes Smartphone MIT NFC, das aber so gefakt ist, dass es aussieht, als wäre es das Miniphone ohne NFC. Und da sieht man schön, dass trotz Aktivierung mit demselben Gerät (denn das Smartphone MIT NFC sieht für die Libre-Sensoren genauso aus wie das Miniphone OHNE NFC) der alte Sensor munter weiter Werte sendet.


    Denn unsere Überlappung funktioniert eben genau so: der alte Sensor sendet 14 Tage plus 12 Stunden Werte an das Miniphone. Irgendwann während der zusätzlichen 12 Stunden starte ich den neuen Sensor mit dem Fake-Smartphone. Jetzt senden beide Sensoren (alt und neu) an dasselbe Smartphone. Das Fake-Smartphone, mit dem ich den neuen gestartet habe, empfängt von ihm die Werte. Das Miniphone kennt den neuen noch nicht und empfängt weiter die Werte vom alten Sensor. Erst wenn ich die Datenbank von LibreLink des Fake-Handys mit den Informationen des neuen Sensors auf das Miniphone überspiele (und das tue ich erst, wenn die Startzeit des neuen Sensors vorüber ist), ist auch das Miniphone zum neuen Sensor verbunden (und hat erst jetzt keine Verbindung zum alten Sensor mehr). Trotzdem sendet der alte Sensor auch jetzt noch Werte per Bluetooth, nur dass jetzt kein Smartphone die Werte mehr annimmt. Dennoch ist dieser alte Sensor nicht deaktiviert, sondern hört eben erst nach 14 Tagen 12 Stunden auf, Werte in die Luft zu schicken.

    Hier wurde jetzt zwemal gesagt, der alte Sensor würde deaktiviert.


    Das ist falsch.


    Der alte Sensor läuft einfach weiter, wird nur von dem Startgerät des neuen Sensors nicht mehr als aktiver Sensor erkannt.


    Wir benutzen die Libre immer überlappend, d.h. ein neuer Sensor wird gestartet, während der alte noch läuft. Das Starten eines neuen Sensors auch mit demselben Startergerät hat überhaupt keinen Einfluss auf den alten Sensor. Der sendet stumpf bis zum Ablauf seiner 14 Tage plus 12 Stunden weiter minütlich die Bluetooth-Werte. Das Startergerät des neuen Sensors empfängt die nur nicht mehr.

    Benutzt du xdrip?


    Dort sieht man sehr gut wie stark die Rohdaten eigentlich schwanken und wie der jeweilige Algorithmus das ganze glättet. Daher gehe ich nicht mehr nach dem punktuell angezeigten Librewert sondern schaue mir den Vergleich an.

    Ich bin immer wieder sehr unglücklich, wenn die völlig falsche Darstellung der Libre2-Werte in xDrip+ als Beispiel herangezogen wird.

    July95 : xDrip+ zeigt die Libre2-Werte nicht richtig in chronologischer Reihenfolge an, sondern überlagert sie in 5min-Blöcken. Dadurch sehen sie sprunghaft und wolkig aus, was sie in Wahrheit gar nicht sind. Leider muss ich immer wieder sagen: die völlig fehlweisende Darstellung in xDrip+ als Begründung für die schlechte Glättung in xDrip+ als Begründung heranzuziehen, zeugt eben leider gerade nicht von profundem Wissen!

    Die Libre2-Werte bilden sehr gut auch z.B. die von Kappa geschilderten kleinen Schwankungen ab. Insbesondere sind immer wieder kleine "Hupfer" zu sehen, wo bei stabilem BZ-Verlauf innerhalb von ca. 10-15min die minütlichen Werte um 10-20mg/dl hoch- und wieder runtergehen. Das findet z.B. beim Träumen statt (bei meiner Tochter sehr deutlich, da kann ich das auch gut verfolgen, wenn sie schläft, bei mir aber ganz genauso), oder auch wie Kappa schildert, allein beim Aufstehen vom Bürostuhl.

    Natürlich sind diese sehr kurzen echten Schwankungen für einen Loop eher kontraproduktiv, also könnten sie durchaus sinnvollerweise weggefiltert werden. Leider führt der sehr schlechte Glättungsalgorithmus in xDrip+ dazu, dass dadurch auch BZ-Abfälle, bei denen man eher schleunigst reagieren sollte, mit 10-15min Verzögerung erst sichtbar werden, dafür dann aber auch noch als steil abfallend angezeigt werden, wenn man längst wieder flach wird.

    In meiner App zeige ich die minütlichen Libre-Werte richtig an, und wenn man das sieht, kann man die xDrip+-Darstellung wirklich nicht mehr ernst nehmen!

    der TK und Diaexpert ist es völlig egal, was man im Rahmen der Pauschalversorgung für Katheter bestellt

    Das kann ich mir beim besten Willen nicht vorstellen.


    Die machen mit der KK einen Pauschalvertrag, d.h., sie sind natürlich bestrebt, dass sie möglichst geringe Kosten bei der Auslieferung der Katheter und anderem Zubehör im Rahmen dieses Pauschalvertrags haben.


    Die Dana-Stahl-Katheter kosten (wenn man nicht auf Rezept bestellt) um die 73€ das 10er-Pack, die Teflon-Katheter liegen bei ca. 120€ für 10 Stück. Die Accu-Check FlexLink kosten gleich über 150€ das 10er-Pack.

    Glaubst du da wirklich, dem Versandhändler ist es egal, ob du die für 73€ oder die für 155€ nimmst, wenn er immer nur denselben Betrag von der KK bekommt?

    Meine Anforderungen an das Loop-System gehen etwas über die Möglichkeiten von AAPS hinaus (komplette Fernsteuerbarkeit vom Follower aus, ohne diesen unseligen SMS-Mist), und das wurde von Milos immer abgelehnt und ist tatsächlich im bestehenden (in einigen Teilen nicht besonders gut programmierten) AAPS-Code auch nicht so leicht zu machen.

    Deshalb habe ich mir mein eigenes Loop-System geschrieben, in dem ich auch direkt aus LibreLink (ohne xDrip+) die minütlichen Libre2-Werte empfange und verwende. Es ist noch nicht ganz fertig und muss auch noch ausführlicher getestet werden. Wahrscheinlich wird es irgendwann im Q1 2021 auf github öffentlich.


    Die Sperre in AAPS ist recht einfach zu entfernen, da muss nur eine einzige Code-Zeile geändert werden. Das kann ich dir über PM gern beschreiben.

    nur noch die zum SMB fehlen, bringen in der Konstellation ja leider aber nichts weil die Freestyle libre Daten wohl zu verrauscht sind.

    Das wird zwar immer und immer wieder von allen möglichen Leuten behauptet, es ist aber vollkommener Quatsch.


    Ich habe bei mir und meiner Tochter jetzt seit zweieinhalb Monaten die minütlichen Libre2-Werte in einem selbstgeschriebenen System und kann sicher sagen: die Werte des Libre 2 sind nicht verrauscht, unterliegen keinen ungewöhnlichen Schwankungen (es gibt grundsätzlich ein Wärmebedingtes Unter- und dann Überschwingen beim Duschen, das trat beim Dexcom G6 bei uns aber völlig identisch auf!) und sind sowohl bei Tochter als auch mir sehr präzise.

    Auch schon zu Zeiten, als ich die Werte noch 5-minütlich aus LibreLink über xDrip+ bekommen habe, hatte ich in AAPS die Sperre der SMBs für den Libre 2 herausgenommen. Jetzt mit der minütlichen Verwendung der Werte und der viel genaueren Übersicht über die Verläufe der Sensordaten kann ich erst recht keine der immer wieder geäußerten Bedenken über den Libre 2 teilen!

    Theoretisch ginge auch eine DIY-Verschlusskappe mit Rechtsgewinde.

    Wovon SOOIL dringend abrät, weil es da schon Motordefekte gab deswegen. In Schweden war es für kurze Zeit sogar mal ein Standard-Medizinprodukt von SOOIL, wurde dann aber aus den genannten Gründen aus dem Programm genommen!

    Es gibt keine logische Erklärung, wie die ander Drehrichtung des Schlauchanschlusses einen Motorschaden verursachen könnte. Das ist mal wieder eine dieser Aussagen, die unablässig wiederholt werden, aber auf ihren begründeten Inhalt nie überprüft werden.

    Ich habe sowohl in der Community als auch bei IME-DC nie auch nur ansatzweise eine plausible Erklärung für diese meiner Ansicht nach völlig unsinnige Behauptung bekommen.

    Dann bist du die einzige auf der Welt.

    Den Libre 1 hat es nie mit Alarmen gegeben, es sei denn, man hat einen Third-Party-Transmiiter mit xDrip+ oder Spike benutzt.

    Der Libre 1 hatte nur NFC und MUSSTE gescannt werden, um Werte zu erhalten. Alarme konnten erst über die Bluetooth Verbindung erzeugt werden und die hatte erst der Libre 2.

    Geh nochmal in dich, niemand wird dir glauben, dass du mit dem Libre 1 Alarme hattest.

    Ganz aktuell habe ich die Ankündigung einer modernen Full-Android-Smartwatch MIT NFC gesehen: die Lemfo Lem14 (bei Banggood für ca. 170€ ausgeschrieben, aber noch nicht verfügbar).

    Mit dieser Smartwatch kann man dann (hoffentlich, denn die NFC-Qualität des Unihertz Atom war für den Libre2 ja völlig unbrauchbar, und das könnte für die Lem14 natürlich auch passieren) die gepatchte LibreLink endlich auf einer Smartwatch benutzen UND den Libre auch wirklich mit dieser Smartwatch starten.

    Damit würde auch die von mir vorher geschilderte Möglichkeit über DiaBox/Bubble mit Full-Android-Smartwatch wieder obsolet werden, man kann mit der Lem14 dann einfach mit der gepatchten LibreLink ohne weitere Hardware den Libre2 betreiben.

    Ich werde sie auf jeden Fall bestellen, sobald sie verfügbar wird.

    ... begeistert von der Dana (R).

    Ich bin gerade mal neugierig.

    Ich hatte im Februar 2018 auch noch die Dana R bekommen (die RS gab es ja erst ab ~Juni 2018). Aber irgendwann (war das im Sommer/Herbst 2019?) schrieb IME-DC mich an, dass keine BZ-Teststreifen mehr für die Fernbedienung der Dana R mehr hergestellt werden und die Dana R mit ihrer Fernbedienung/Messgerät daher nicht mehr ihre eigentliche volle Funktionalität hat. Daher würde man mir anbieten, die Dana R in eine RS umzutauschen.

    Ich fand das sehr witzig, hat die RS ja schließlich gar keine Fernbedienung, insofern wurde ja durch den Umstieg von R auf RS ja nicht etwa eine fehlende Funktionalität ausgeglichen, sondern im Gegenteil noch mehr weggenommen.

    Da ich die Fernbedienung der R aber nie benutzt hatte (sondern sie immer vom Handy aus steuerte), habe ich die R natürlich sehr gern in die RS umtauschen lassen, allein weil ich so von 18Tagen Batterielaufzeit auf 35 Tage Batterielaufzeit gekommen bin. Zweiter (noch wichtigerer) Grund war bei mir, dass meine Tochter mittlerweile die RS hatte und ich die Möglichkeit haben wollte, im Notfall ihr meine Pumpe geben zu können und dabei nicht unbedingt das ältere R-Modell benutzen wollte, wenn ich ihr auch eine gleiche Pumpe geben konnte.

    Jetzt meine Neugier: Wieso hast du nicht auch die R gegen die (geringfügig, außer BLE ist da natürlich nicht sooo viel) modernere RS getauscht?

    Dieses NFC-Scannen ist in xDrip+ schon sehr lange und funktioniert(e) für den Libre1 auch sehr gut. Für den Libre 2 funktioniert es überhaupt nicht. Du kannst es gern versuchen, du wirst keine Werte bekommen. Es ist für den Libre 2 in xDrip+ einfach nicht implementiert, auch wenn es da sichtbar ist.


    Das Scannen des Libre 2 funktioniert derzeit nur mit LibreLink, dann bleiben die Werte in LibreLink und werden nicht rausgegeben. Oder man scannt mit der gepatchten LibreLink, dann werden die gescannten Werte auf dem Handy zwar an xDrip+ geschickt, aber xDrip+ ignoriert diese Nachricht und verarbeitet sie einfach nicht (da fehlt eben die Programmierung in xDrip+). Oder ganz neu man benutzt DiaBox, die App, die eigentlich zum Bubble Transmitter gehört. Die kann jetzt auch den Libre 2 direkt verhackstücken, auch ohne den Bubble. Ich habe sie noch nicht selbst probiert, aber sie soll wohl schon ganz gut mit dem Libre 2 (auch ohne Bubble) funktionieren. Aber auch hier nimmt xDrip+ die Werte nicht an, obwohl der Entwickler von DiaBox einen Merge-Request an xDrip+ gestellt hat und die Werte (genauso wie die gepatchte LibreLink) an xDrip+ schickt.

    Aber solange das in xDrip+ nicht reinprogrammiert wird, verpuffen alle diese existierenden Nachrichten im Leeren.

    Ich kenne das alles. Aber wenn ohne Loop nach 90min bereits wieder Zielwert erreicht ist und dann in den nächsten 3 Stunden alles stabil läuft, dann nehme ich auch bei der von AAPS verwendeten Wirkkurve keine 5 Stunden Wirkzeit, dann reichen auf jeden Fall 3 Stunden. Und da habe ich keinesfalls an den Faktoren oder der Basalrate was falsch. Denn wenn die Basalrate im BR-Test richtig läuft, dann stimmt sie nun mal. Und wenn mit einem bestimmten Faktor der Zielwert wieder erreicht wird und es dann stabil läuft, dann stimmt auch der Faktor. Und wenn bei Lyumjev nach 90min bei mir nichts mehr passiert und es dann 3 Stunden stabil läuft, dann ist das so. Mit den immer wieder propagierten 5 bis teilweise 7 Stunden funktioniert es mit Lyumjev bei mir definitiv nicht., da würde der Loop ganz offensichtlich noch von viel zu viel aktivem Insulin ausgehen.
    Noch aber werde ich den Loop eh nicht wieder anschalten, ich werde das in den nächsten Wochen alles mit Standard-Pumpentherapie begutachten.

    Ich muss da nochmal verständnishalber nachfragen: Funktioniert mit xDrip auch das nachträgliche Scannen, um den Verlauf der letzten paar Stunden zu sehen, wenn man mal ohne Handy unterwegs war?


    nein, xDrip scannt nicht, die Werte laufen per BT ein. Ist keine Verbindung da, gibt's keine Werte, auch nicht nachträglich

    Das liegt aber leider nur an xDrip+, in dem hier ein bisschen Programmierung fehlt.


    Die gepatchte LibreLink liefert nämlich außer den minütlichen Glukosewerten noch einiges mehr, auch die gescannten Werte mit der 8-Stunden-Historie. Nur nimmt xDrip+ die nicht an. Wenn genügend Leute ein Issue bei xdrip+ erstellen (bzw. unterstützen, muss ja nicht jeder ein neues issue erstellen), wird es vielleicht ja mal eingebaut.

    "DiaBox" bringt auch eine ganze Menge an Schnittstellenmit. U.a. zu LibreView, xDrip+, Nightscout, Android Aps.

    Theoretisch ja, praktisch nein.

    Der DiaBox-Entwickler hat zwar Merge Requests an xDrip+ und AndroidAPS gestellt, so dass beide Apps leicht eine Einbindung machen könnten. Es ist bisher bei beiden jedoch noch nicht passiert und einer Äußerung nach hat es den Anschein, als ob die Einbindung in AndroidAPS auch nicht erfolgen soll (so mein Eindruck).

    DiaBox sendet also die entsprechenden Nachrichten, weder xDrip+ noch AndroidAPS nehmen diese Nachrichten jedoch derzeit an.