Beiträge von dideldum

    Libreview und patched libre broadcast muss aktiviert werden

    Nein, muss es nicht.

    Wenn Juggluco so tut, als sei es eine Nightscout-Instanz, und xDrip+ als Quelle Nightscout mit der localhost-Verbindung eingestellt hat, dann wird überhaupt kein Broadcast von xDrip+ empfangen. Also muss auch der PatchedLibre-Broadcast nicht aktiviert sein.

    Und Libreview muss nur aktiviert sein, wenn man die Daten von Juggluco auch in Libreview haben möchte. Ist das nicht gewünscht, kann das natürlich auch aus bleiben.

    Eidechse Da ist garantiert kein Fehler. Man sieht doch den Scrollbar an der rechten Seite. Der letzte Wert von 23:00 bis 24:00 ist garantiert mit 20 definiert (10 macht da ja für die Nacht ja bei der 0-6-Definition ja gar keinen Sinn!).

    Also erst Mal genau hinschauen, bevor man (falsche!) Empfehlungen gibt!

    In meiner kurzen (3wöchigen) Zeit mit der Ypsopump habe ich 2 Reservoire jeweils 3mal benutzt, beim dritten habe ich die Nutzung der Pumpe abgebrochen, sonst hätte ich das auch 3mal genutzt. Da es Glasampullen sind, sehe ich in Bezug auf das Insulin kein Problem (Kunststoff-Reservoire würde ich nie mehr als 1mal benutzen). Und solange der Stempel sich gut bewegt, ist doch alles in Ordnung. Verstopfungsalarm hatte ich bei 3maliger Nutzung nicht.

    die Abgabegeschwindigkeit kann man (noch) nicht einstellen

    Das wird man auch künftig nicht können.

    Die Ypsopump wird keine einstellbare Geschwindigkeit bekommen.

    Im nächsten Pumpenmodell der Ypsopump soll die Geschwindigkeit herabgesetzt werden, aber weiter nicht einstellbar werden.

    Jetzige Pumpen werden keine Geschwindigkeitsaktualisierung bekommen.

    Ich habe dieses Thema intensiv mit Ypsomed durchgesprochen. Da bleibt die Ypsopump in negativer Hinsicht ein Ausnahmefall unter den Pumpen.

    Der Sensor wurde mit Ruggear RG360 aktiviert und dort wurde möglicherweise ein Juggluco Arm32 verwendet, um den Sensor zu starten.

    Juggluco wartet keine 60 Minuten, wenn ein alter Sensor verwendet wird, selbst wenn die Aktivierungszeit falsch ist. Die Libre3-App von Abbotts wartet 60 Minuten. Ich weiß nicht, ob es nach dem Warten funktioniert.

    Ja, auf dem Ruggear wurde arm32 verwendet, aber der Start erfolgte dort in Juggluco. Dort war gar keine Libre 3 App installiert. Juggluco hat beim Starten des Sensors auf dem Ruggear natürlich auch 60min gewartet. Bei der Übernahme auf das Samsung hat er ja aber gesagt, der Sensor wäre erst in 13 Jahren bereit (7Mio Minuten, was dann mit der Endzeit in 2036 auch passt). Es kamen nun allerdings irgendwann doch die Werte auf dem Samsung, das grundsätzliche Handling mit den Datumswerten des Sensors ist aber schon merkwürdig.

    Was passiert, wenn Sie nicht an Libreview senden?

    Ja, da scheint das Problem zu liegen.

    Wenn ich LibreView nicht anhake, kann ich die App wechseln und Juggluco wieder starten ohne Probleme.

    Wenn ich dann in den Einstellungen Libreview anklicke und im Dialog Kontonamen und -Passworte eingebe, kann ich die ID abrufen. Soweit auch alles ok.

    Wenn ich im Dialog jetzt NICHT "An Libreview senden" und "Libre 3 sofort" anklicke, kann ich weiter Apps wechseln und Juggluco weiter starten (allerdings ist dann natürlich in den Einstellungen Libreview weiter nicht angehakt).

    Wenn ich in den Einstellungen jetzt erneut Libreview anhake, sind die Konto-Informationen und auch die ID weiter da. Jetzt hake ich nur "An Libreview senden" an und speichere die Einstellungen. Wieder kann ich Apps wechseln und Juggluco starten.

    Jetzt hake ich auch noch "Libre 3 sofort" an. Ich kann noch die Einstellungen speichern. Aber wenn ich jetzt Juggluco verlasse (mit der Android-Dreieckstaste), dann kommt es bereits hier zum SEGV und auch bei jedem versuchten Neustart. Es hängt also am "Libre 3 sofort".

    Haben Sie den Sensor mit einer arm32-Version gestartet? Die absurde Startzeit ist kein Problem. Wenn Sie den Sensor erfolgreich scannen können, sollte es möglich sein, Glukosewerte vom Sensor zu empfangen.

    Haben Sie versucht, die Libre 3-App von Abbott auf Ihrem neuen Telefon zu verwenden? Hat es 60 Minuten gewartet?

    Auf dem Samsung ist die arm64-Version installiert. Die Libre3 App war dort vor ca. 3 Wochen installiert, mittlerweile aber wieder deinstalliert. Außer Juggluco war also keine Libre-verbindende App auf dem Samsung.
    Mittlerweile kommen aber tatsächlich Werte vom übernommenen Sensor auf dem Samsung A22 herein. Ich kann nicht genau sagen, ab wann das passierte, weil ich es dann erstmal liegen gelassen hatte. Der Sensor war aber vor 3 Tagen gestartet, es hätte also eigentlich keine 60min Wartezeit geben sollen beim Übernehmen, oder?

    Hallo, jka,


    ein neues Problem:


    Ich habe auch ein Ruggear RG360, auf dem Juggluco läuft. Hier hatte ich einen aktiven Libre 3, den ich nun auf mein Samsung A22 übernehmen wollte, damit ich meiner Tochter das RG360 mit einem funktionierenden Juggluco geben kann.


    Das Übernehmen hat aber nicht funktioniert. Obwohl ich auf beiden (RG360 und Samsung) meine gleiche Libreview ID habe, hat Juggluco auf dem Samsung zwar gesagt, dass der Sensor übernommen wird, hat aber ein völlig absurdes Sensor-End-Datum (26.11.2036) und behauptet, der Sensor wäre bereit in 7084958 Minuten.

    Hallo, jka


    Ich bekomme auf meinem Cubot Pocket 3 (Android 12) ein SEGV (logcat: Zeile 50 in libc) mit Juggluco 4.17.4.


    Ich habe es mit beiden APKs probiert, beide lassen sich einwandfrei installieren, beide starten und lassen sich erstmal problemlos konfigurieren. Sobald ich dann aber zu einer anderen App gewechselt habe und wieder Juggluco aufmachen wollte, stürzte es einfach ab.


    Das Logcat dazu hänge ich an (bei mehrfachen Versuchen, es neu zu starten).


    Im Einstellungen-Bildschirm beim ersten Start konnte ich alles konfigurieren, auch die Libreview-ID wurde abgerufen, die Einstellungen hatte ich gespeichert. Aber jeder folgende Versuch, Juggluco zu starten, scheitert. Ich habe es mehrmals mit einer Neuinstallation und Neukonfiguration versucht, aber das Resultat ist immer gleich.


    Auf einem Gigaset GS4 ebenfalls SEGV.

    Mit Kulanz hat hier eine Sensor-Reklamation gar nichts zu tun.

    Nach der Aktivierung des Sensors kannst du das Lesegerät auch ausschalten. Da lernt sich nichts in der Stunde Aufwärmzeit kennen.

    Deine relevanten Kommunikationsinformationen werden beim NFC-Start ausgetauscht. Und das war's dann auch schon. Wie kommtmannur darauf, dass das Lesegerät oder das Starthandy während der Aufwärmzeit beim Sensor sein müsste? Das ist einfach Unsinn.

    Sagt das Lesegerät etwas von defektem Sensor, dann wird der ersetzt.

    Hubi Link umsetzen geht garantiert schneller als das von dir beschriebene Procedere. Und außerdem will ich ja letztendlich die neuere Version zum Laufen bekommen. Das heißt, ich muss die neuere Version verfügbar haben und dort im Verzeichnis arbeiten können. Dabei will ich aber gleichzeitig die alte Version haben, um sie entweder sogar in der Zeit laufen zu lassen oder zumindest schnell wieder zurückzuschalten, ohne meine Arbeit im aktuellen Verzeichnis zu verlieren. Das geht natürlich mit git, aber sehr viel umständlicher und zeitraubender als mit dem schnell geänderten Link.

    Wozu die Links dideldum ? Man kann mit git checkout [Commit-ID] ja jederzeit zurück auf eine alte Version.

    Und ja, das npm-Update ist von Zeit zu Zeit nötig.

    Link umsetzen geht einfach ganz schnell und schon laufen meine beiden Instanzen wieder. Hatte schon mehrmals das Problem, dass Nightscout Updates sich nicht mit Libraries, der Mongo-Version oder irgendwelchen von npm install installierten Paket-Versionen vertrugen. Dann habe ich den Link erstmal schnell wieder zurückgebogen und hatte Zeit für die Problem-Analyse.

    . Es handelt sich hierbei also nicht um einen Fehler!!

    Naja, also DER Aussage kann ich ja nun gar nicht folgen. Wenn ein Sensor absichtlich so programmiert ist, dass er seine Batterie schneller leer saugt, als das mit seinem vorgesehenen Leben vereinbar ist, dann IST das ein Fehler. Der Sensor muss seine 14 Tage durchhalten, egal was für ihn in Sachen Handy-Erreichbarkeit los ist. Und wenn das Handy 13 Tage 58 Stunden nicht in seiner Nähe ist, dann muss er in der letzten Stunde noch in der Lage sein, seine Werte zu übertragen. Alles andere IST ein Fehler!

    Ich habe ja immer gern ein Fallback und mache bei Nightscout immer ein neues Verzeichnis, das ich dann verlinke. Wenn was nicht funktioniert, biege ich den Link wieder auf's alte Verzeichnis. Das sieht im Moment so bei mir aus:

    Code
    lrwxrwxrwx 1 ubuntu ubuntu 26 Dez 9 16:20 cgm-remote-monitor -> cgm-remote-monitor.14.2.6/
    drwxrwxr-x 17 ubuntu ubuntu 4096 Dez 9 16:20 cgm-remote-monitor.14.2.5
    drwxrwxr-x 17 ubuntu ubuntu 4096 Dez 9 16:42 cgm-remote-monitor.14.2.6
    -rwxrwxr-- 1 ubuntu ubuntu 2069 Dez 9 17:11 ns_alina.sh
    -rwxrwxr-- 1 ubuntu ubuntu 2093 Dez 9 17:11 ns_ulf.sh

    Mit anderen Worten: ich mache immer ein "git clone" im neuen Versions-Verzeichnis und setze dann den cgm-remote-monitor Link auf das neue Verzeichnis. Meine beiden Start-Skripte, die die Umgebung entsprechend setzen (ns_alina.sh und ns_ulf.sh) benutzen nur den Link. Wenn der Link wieder auf's alte Verzeichnis zurückgesetzt wird, läuft es also wie vorher im Problemfall.


    Nach dem git clone war dann noch das npm install im neuen Versions-Verzeichnis notwendig (das müsste man nach einem update aber selbst im alten Verzeichnis ja wohl auch machen, oder?). Muss aber zugeben, ich mache es so selten, dass ich mich nicht mehr an alle Einzelheiten erinnere.

    Hat irgendjemand vor der YpsoPump die Dana mit Insetkatheter und kann bestätigen, dass bei den Schläuchen nur die Verbindung zur Pumpe anders ist?


    Oder anders gefragt wäre es möglich, dass ich erstmal meine Dana Inset Katheter mit der YpsoPump verwende, wenn ich ein paar YpsoPump Inset-Schläuche auftreiben könnte?


    Hintergrund ich soll auf meine neue YpsoPump umsteigen, Pumpe ist auch vorhanden, aber die benötigten Katheter sind nicht lieferbar.

    Ja, das kann ich bestätigen. Wir haben es zwar umgekehrt gemacht (Die Dana RS wieder an den gesetzten Ypsomed-Inset-Katheter angeschlossen), aber die Inset II der Dana und die Inset der Ypsomed haben am Kanülenstück den identischen Clip-Anschluss und sind auch identisch. Nur das Schlauchstück zur Pumpe hat ein unterschiedliches Ende.

    dideldum : Sach mal, Du hast doch die DanaRS, oder?

    Ja, wir haben 2mal die Dana RS, wollten aber auf CamAPS mit Ypsopump wechseln und haben das System natürlich auch mit Ypsopump getestet (die gehen jetzt aber wieder zurück und wir wechseln auf die Dana I zurück, da die beiden RS mittlerweile das Risiko haben, kaputt zu gehen (Riss in der einen, sehr dunkles Display in der anderen)).


    Ich kann jetzt halt nur noch CamAPS (die Ypsopump-Version aus dem Google Playstore, nicht die Dana-Version!) mit virtueller Pumpe und virtuellem Sensor testen. Aber auch da kann man den Auto-Mode anschalten. Und da funktioniert im Auto-Mode einwandfrei das von mir beschriebene Szenario, das ich vorher im echten Betrieb mit der Ypsopump und Libre 3 eben auch getestet hatte:
    1. Gib einen Essensbolus mit dem Besteck ab.

    2. Geh danach wieder in das Besteck-Fenster zur Essensbolusabgabe und tippe auf den BZ. Gib im Dialog einen hohen BZ ein (z.B. 400mg/dl). Bestätige mit OK. Nun wird beim Blutzuckerwert eine Korrekturmenge Insulin angezeigt, unter dieser Menge in Klammern wird aber entweder dieser Wert mit Minus davor (falls die Korrekturmenge kleiner ist als der zuvor abgegebene Bolus) oder eben maximal der zuvor abgegebene Bolus angezeigt, so dass möglicherweise eine kleine Korrekturmenge effektiv übrig bliebt.


    Was ich damit zeigen will, ist, dass CamAPS selbst die "aktive Insulinmenge" völlig falsch bewertet, denn der vorherige Bolus hat aufgrund seines Zusammenhangs zu den Kohlenhydraten nichts mit einer effektiven aktiven Insulinmenge zu tun, die allein jetzt für eine Senkung des BZ verantwortlich wäre.


    Ausgangspunkt war für mich derPost #12 von Lilimaus, in dem das aktive Insulin zur Beurteilung der Hypobehandlung herangezogen wird. Alles was ich in Folge auf die absolut richtigen Kommentare von helmama, dass es in CamAPS nämlich keine gültige Angabe des IOB gibt, geschrieben habe, diente nur der Beweisführung, dass das in CamAPS angezeigte und verwendete aktive Insulin ausschließlich das Bolusinsulin ist und die Verwendung dieser Angabe nicht nur in CamAPS völlig falsch ist, sondern auch für die Beurteilung einer Hypo-Behandlung völlig unbrauchbar ist.


    Leider wurde und wird dies von etlichen Personen hier nicht verstanden.


    Zusammenfassend möchte ich hier nur noch einmal schreiben:


    Um das aktive Insulin beurteilen zu können, muss man Korrekturinsulin (resultierend aus temporärer Basalrate oder verzögerten Boli oder SMBs in Bezug auf die ideale Basalrate), Essensinsulin und Kohlenhydrate im Zusammenhang sehen. Erst dann kann man das aus diesen drei Komponenten zusammengesetzte aktive Insulin wirklich zur Beurteilung einer Hypobehandlung heranziehen. Nur mit der Angabe in CamAPS geht das definitv nicht!


    In AndroidAPS gibt es dafür mehrere Häkchen im Bolusrechner. Diese umfassen den aktuellen BZ, die BZ-Bewegung, das aktive Bolus-Insulin, die aktiven Kohlenhydrate und das vom Basal abweichende gegebene Korrektur-Insulin (das auch negativ sein kann, wenn eine Weile das Basal aus war).


    Für eine sinnvolle Beurteilung, ob weiteres Korrekturinsulin nötig wäre, oder eben (und darum geht es hier ja eigentlich) Kohlenhydrate zuzuführen wären, sind alle Häkchen im Bolusrechner zu aktivieren. Dann zeigt einem AAPS im Bolusrechner z.B. an, ob 3gKH nachzuführen wären oder vielleicht 0,5IE zu bolen wären. DAS ist für die Hypobehandlung eine vollständige und sinnvolle Information. Die ist in CamAPS aber eben nicht zu haben.


    (Nebenbemerkung: natürlich kann man im AAPS-Bolusrechner diese Häkchen auch anpassen. Das macht in gewissen Situationen sogar durchaus Sinn, es würde aber jetzt zu weit führen, hierzu weitere Erläuterungen zu geben. Leuten wie Leila kann ich da aber nur empfehlen, die AAPS-Dokumentation nochmal sehr sorgfältig zu lesen, denn offensichtlich hat sie Benutzung und Auswirkung dieser Häkchen nicht verstanden.)


    Da aber offensichtlich meine Schilderungen für etliche Benutzer von CamAPS und sogar von AAPS nicht begreiflich sind, möchte ich an dieser Diskussion jetzt aber auch nicht weiter teilnehmen. Es ist jeder schließlich selbst für seinen Diabetes verantwortlich und wer glaubt, dass für ihn mit der Situation alles gut ist, der möge das einfach so weiter machen. Und damit schließe ich diesen Thread für mich endgültig ab.