Naja, es ging in dem Fall nicht nur darum, dass der Loop allein etwas gemacht hat, die Person hat auch selbst Insulin gegeben (weil der BZ ja nicht fiel), so etwas kann halt auch normal passieren....
AndroidAPS und Closed Loop
-
-
Naja, es ging in dem Fall nicht nur darum, dass der Loop allein etwas gemacht hat, die Person hat auch selbst Insulin gegeben (weil der BZ ja nicht fiel), so etwas kann halt auch normal passieren....
Das ist mir auch schon ein paar mal passiert. Mit Humalog ganz fies, mit Lyumjev händelbar... Mit viiiiiiel aufgelöste TZ an der Seite. 😉
Man lernt eben nie aus.
Und wie war das noch, der Fehler sitzt vor dem PC /der Technik. 🥴😜
-
Warum man mit aktiven KHs und bei temporären Zielen trotzdem SMBs nutzen kann, ist mir auch nicht ganz klar. Zumindest bei temp. Zielen erschließt sich mir nicht, warum die Genauigkeit der Werte nicht so wichtig sein soll...
Die Idee dahinter ist vermutlich, dass man zu diesen (begrenzten) Zeiten eh etwas aufmerksamer ist. Die "Angst" bei den Entwicklern dürfte eine Situation sein, in der z.b. nachts eine Fehlmessung auftritt und der Loop bis ans Limit insulin pumpt.
Finde die Entscheidung der Entwickler nicht gerade toll. Rauschen lässt sich ja in den Daten erkennen. In so einem Fall könnte man die SMB Funktion zeitweise automatisiert deaktivieren...da sollte man in meinen Augen mehr Zeit reinstecken als in neue Fragen...
Es gibt nicht den oder die Entwickler, sondern ganz verschiedene Gruppierungen, die jeweils ihre eigenen Gebiete bearbeiten. Auch AAPS und xDrip werden (mit Überschneidungen) seperat entwickelt, der Libre2-Part von xDrip stammt afaik auch von anderen Leuten als der Dexcom-Part.
Ein Grund für die große Skepsis gegenüber dem Libre (2) wird sicher der beinahe tödliche Zwischenfall mit dem Libre 1 gewesen sein, der zu sehr unrühmlichen Schlagzeilen und einer Warnung der FDA geführt hat.
Auch wenn ich selbst meine Libre-Kurven glatter finde als vieles, was so vom G6 gepostet wird, so hat der Libre seit diesem Zwischenfall irgendwie das Image als "Frickelsystem" wegbekommen. Das Chaos mit den sprunghaften Werten beim MiaoMiao2 etc. als sie ganz neu rausgekommen waren, hat es auch nicht besser gemacht.
Tendenziell scheint aber schon der Wunsch der Libre-Entwickler zu sein, die SMB-always auch mittelfristig mit dem Libre zu erlauben. Daher auch der relativ zähe Glättungsalgorithmus und die stark eingeschränkte Kalibrierbarkeit.
Finde die Entscheidung der Entwickler nicht gerade toll. Rauschen lässt sich ja in den Daten erkennen. In so einem Fall könnte man die SMB Funktion zeitweise automatisiert deaktivieren...da sollte man in meinen Augen mehr Zeit reinstecken als in neue Fragen...
Genau dafür gibt es aktuell auch einen Pull-Request, den z.b. Hubi gerade austestet. Aber dieser "wartet" halt schon ein paar Monate darauf, eingebaut zu werden. Man muss eben auch bedenken, dass die ganze Software in der Freizeit von den Leuten entwickelt wird und da sicher in der aktuellen Zeit auch andere Dinge auf der Prioritätsliste stehen.
Hallo,
von diesem Zwischenfall habe ich bislang nichts gehört. Aber allem Anschein nach, lag hier auch ein Fehlverhalten des Benutzers vor. Wenn der G6 (warum auch immer) dauerhaft falsche Werte liefert, kann ich als Nutzer mir auch zu viel Insulin verabreichen.Ich weiß, dass die Programmierer hier dies alles in ihrer Freizeit machen oder zumindest zum größten Teil. Ich bin dankbar für deren Arbeit. Wenn es sich nicht gerade um Java/Kotlin handeln würde, sondern um Python, würde ich sogar meine Hilfe anbieten und unterstützen. Trotzdem fände ich es schön, wenn man den Libre 2 hier anders behandeln würde.
Grüße
-
von diesem Zwischenfall habe ich bislang nichts gehört. Aber allem Anschein nach, lag hier auch ein Fehlverhalten des Benutzers vor. Wenn der G6 (warum auch immer) dauerhaft falsche Werte liefert, kann ich als Nutzer mir auch zu viel Insulin verabreichen.
Dazu hatten sich die Entwickler von AAPS/xDrip im Looper Forum geäußert. Es war angeblich ein Kind mit Loop, dessen Eltern falsch gehandelt hatten. Die Ursache des Vorfalls lag eindeutig zwischen den Ohren. Es war aber der Grund, weshalb danach die Kalibrierung des Libre begrenzt wurde. Das Problem ist halt, dass es weltweit auch Looper gibt, die nicht genau wissen, was sie da machen.
Das Rauschen bzw. die Glättung der Werte des Libre und die damit begründete Limitierung der SMB ist aber ein anderes Thema, das auch in der Looper Community
https://de.loopercommunity.org/t/fsl-2-limitierung-smb/4538
heftig diskutiert wurde. Dort sind auch einige der Meinung, dass die Limitierung nicht mehr zeitgemäß ist. Insbesondere dideldum hat dort (und auch hier in ähnlichen Posts) eine Lanze für den Libre2 gebrochen, nachdem er auch den Dex verwendet hatte und keine Nachteile beim Libre sehen kann. Man hat aber als außenstehender Beobachter etwas den Eindruck, dass das bei den Entwicklern auf taube Ohren trifft.
Vielleicht versteht ich auch die Hintergründe und Details nicht vollständig. Soweit ich mich erinnere, soll der Dex eine bessere integrierte Plausibilitätsprüfung haben, der die Übertragung von fehlerhaften Werten ggf. abbricht, während der Libre auch unsinnige Werte weiter senden soll. Es stellt sich aber die Frage, ob das für den Libre2 auch noch gilt.
-
von diesem Zwischenfall habe ich bislang nichts gehört. Aber allem Anschein nach, lag hier auch ein Fehlverhalten des Benutzers vor. Wenn der G6 (warum auch immer) dauerhaft falsche Werte liefert, kann ich als Nutzer mir auch zu viel Insulin verabreichen.
Dazu hatten sich die Entwickler von AAPS/xDrip im Looper Forum geäußert. Es war angeblich ein Kind mit Loop, dessen Eltern falsch gehandelt hatten. Die Ursache des Vorfalls lag eindeutig zwischen den Ohren. Es war aber der Grund, weshalb danach die Kalibrierung des Libre begrenzt wurde. Das Problem ist halt, dass es weltweit auch Looper gibt, die nicht genau wissen, was sie da machen.
Das Rauschen bzw. die Glättung der Werte des Libre und die damit begründete Limitierung der SMB ist aber ein anderes Thema, das auch in der Looper Community
https://de.loopercommunity.org/t/fsl-2-limitierung-smb/4538
heftig diskutiert wurde. Dort sind auch einige der Meinung, dass die Limitierung nicht mehr zeitgemäß ist. Insbesondere dideldum hat dort (und auch hier in ähnlichen Posts) eine Lanze für den Libre2 gebrochen, nachdem er auch den Dex verwendet hatte und keine Nachteile beim Libre sehen kann. Man hat aber als außenstehender Beobachter etwas den Eindruck, dass das bei den Entwicklern auf taube Ohren trifft.
Vielleicht versteht ich auch die Hintergründe und Details nicht vollständig. Soweit ich mich erinnere, soll der Dex eine bessere integrierte Plausibilitätsprüfung haben, der die Übertragung von fehlerhaften Werten ggf. abbricht, während der Libre auch unsinnige Werte weiter senden soll. Es stellt sich aber die Frage, ob das für den Libre2 auch noch gilt.
Nachdem was ich gelesen habe, war es eindeutig ein Anwenderfehler. Man hätte da rechtzeitig mal blutig messen müssen. Über den Dex habe ich jetzt gelesen, dass der erkennen soll, wenn der Sensorfaden abgeknickt ist und dann liefert er keine Werte mehr. Das hat der L2 soweit ich weiß nicht. Gegenüber dem L1 hat er sich aber auch schon mal dahingehend verbessert, dass man nachts nicht durchgehend eine rote Linie hat, weil man auf dem Sensor liegt. Gibt natürlich noch andere Verbesserungen.
-
-
Solange der niedrigste mg/dl-Wert, den ein Libre "messen" und übertragen kann, 39 ist, ist eine Kalibrierung um mehr als 20-25 auch wenig sinnvoll. Mein persönlicher sehr subjektiver Hypo-Bereich beginnt unterhalb von 65 mg/dl, bei einer typischen Kalibrierung (ohne die wohl auch dideldum nicht auskommt) im Bereich von 15-20(-30) ist da nicht mehr wirklich viel Luft.
Was nicht heißen soll, dass der Libre im Normalbereich keine Hilfe ist, im Gegenteil - man darf es nur halt nicht so weit kommen lassen, dass die Kurve (kalibriert oder nicht) zur horizontalen Gerade entartet. Dafür ist xDrip mit mehreren konfigurierbaren Alarmen sehr hilfreich. (Es sagt mir auch rechtzeitig, wenn ich wieder einmal auf dem Sensor liege oder der Sensor zu viel kalte Luft bekommt.) Ob das DiaBox auch leisten kann, würde ich gern ohne zu probieren herausfinden... Gibt es irgendwo aussagekräftige Dokumentation? Auf der bubblan.org-Seite finde ich dazu nur "stubs" vom letzten September ohne Text
Vielleicht bringt der Libre 3 ja nicht nur weniger Volumen, sondern auch einen größeren Messbereich mit...
-
Vielleicht bringt der Libre 3 ja nicht nur weniger Volumen, sondern auch einen größeren Messbereich mit...
Wenn ich es richtig verstanden habe, kann der Libre 2 (in den Rohwerten) auch tiefer messen. Nur da wir von der patchedApp die verarbeiteten Werte nutzen ist damit eben bei 39 schluss.
Wenn man diese weglässt und den Libre 2 direkt per Bluetooth mit xDrip+OOP2 verbindet, dann soll auch ein größerer Kalibrierungsbereich möglich (und funktionabel) sein.
-
Gendra Dann weiß ich nicht, woher ich die wirklich rohen Daten nehmen soll.
In der "currentReadings" Tabelle der Datenbank, direkt von der App gezogen, sind die niedrigsten Werte gleich 39 - und das über 14 Messungen hinweg.
Auch in "historicalReadings" ging es zweimal bis auf 39 herunter.
Niedriger finde ich in meinen gesamten Aufzeichnungen der letzten neun Monate nicht.
Soweit ich das bisher verstanden hatte, geht der Wertebereich bei 40 los, 39 steht für LOW. Und ich würde erwarten, dass die currentReadings-Minutenwerte keine Filterung durchlaufen haben.
-
Hallo,
an diejenigen, die ihre App anpassen, um zu jeder Zeit SMBs zu nutzen, könnt ihr mal bitte sagen, was ihr da genau ändert? Falls ihr das nicht im Forum posten wollte, könnt ihr mir auch eine Nachricht schicken. Ich hab an mehreren Stellen ein True gesetzt, aber beim OpenAPS SMB tab steht für enableSMB_always und enableSMB_after_carbs immer noch ein False.Danke.
-
Falls das noch nicht durchgesickert ist, gibt es ein neues Neues APS 2.8.2...
Funktioniert bei mir im Moment so gar nicht. über 4 Stunden habe ich rumexperimentiert.
Viele Angaben aus dem Wiki sind bei mir gar nicht mehr vorhanden. Das habe ich beim letzten mal aber noch "irgendwie" lösen können...nun nicht mehr.
Normal ist das bei mir immer "stochern im Nebel - mit Erfolg"
Ich glaub ich warte erstmal auf 2.8.2.1.......
-
-
Falls das noch nicht durchgesickert ist, gibt es ein neues Neues APS 2.8.2...
Funktioniert bei mir im Moment so gar nicht. über 4 Stunden habe ich rumexperimentiert.
Viele Angaben aus dem Wiki sind bei mir gar nicht mehr vorhanden. Das habe ich beim letzten mal aber noch "irgendwie" lösen können...nun nicht mehr.
Normal ist das bei mir immer "stochern im Nebel - mit Erfolg"
Ich glaub ich warte erstmal auf 2.8.2.1.......
Hallo.
Welche Angaben meinst du denn? Ich hab einfach einen neuen Pull gemacht.
Grüße
-
Welche Angaben meinst du denn? Ich hab einfach einen neuen Pull gemacht.
Da komme ich erst gar nicht hin...
Letztes mal habe ich schon in VCS den Git - Pull gesucht (der da mal war in studio 4.0.1) und bin dann über Umwege hingekommen - diesmal funktionieren nicht mal die Umwege... jeden falls bei mir.
Es hat sich auch gleich ein neues Update gezogen Studio 4.1.2... glaub ich.. bin grad nicht mehr dabei.
Und ab da ging gar nichts mehr.
Ich guck mal Morgen mit 4.1.1 ob es da läuft.
-
Bei mir ist auch alles Neue da. Hast Du auf dem Smartphone die Version geprüft?
AAPS oben links die 3 Punkte
Über anklicken
AndroidAPS 2.8.2
-
Nach Update von Studio neues Projekt from Versioncontrol und dann das übliche
-
Android Studio 4.1.2 läuft bei mir
-
-
Bei mir ist auch alles Neue da. Hast Du auf dem Smartphone die Version geprüft?
AAPS oben links die 3 Punkte
Über anklicken
AndroidAPS 2.8.2
? Ich erstelle mir die APK am PC.
Da ist nix mit 3 Punkte... da komme ich erst gar nicht hin..*sing, träller, flöt*
Nach Update von Studio neues Projekt from Versioncontrol und dann das übliche
Jepp - wie immer geht aber aus unerfindlichen Gründen nicht... es buggt irgend wo bei mir.
Ich geh da die Tage noch mal dran.
.... v o n A n f a n g an... und dann hoffe ich das es fluppt.
Sonst meld ich mich nochmal...
Aber erstmal lieben Dank...
-
mit AS 4.1.1 funktioniert zumindest das clonen schon mal - und das Erstellen der APK auch (läuft aktuell zumindest)