Beiträge von dideldum

    * Nur alle 5min einen neuen Wert (ja, ja, gabs beim Libre offiziell ja auch nur)

    Beim Libre gab es NIE (auch offiziell nicht!) 5min-Werte!

    Selbst der Libre 1 hatte bereits minütlich gemessene Werte (man erinnere sich, es gab die letzten 15 minütlichen Einzelwerte, aus denen die Tendenz berechnet wurde, die vorherigen 5 3/4 Stunden wurden dann nur mit einem Mittelwert der 15min-Werte gespeichert, also nur alle 15min ein gespeicherter Wert). Wenn man mit dem Libre 1 jede Minute gescannt hatte, hat man durchaus auch unterschiedliche Werte gescannt!

    Auch der Libre 2 hat immer minütlich frisch gemessene Werte übermittelt, genau wie das der Libre 3 jetzt macht.

    Es gab beim Libre nur 5min-Abstände, die künstlich durch die aufgesetzten Transmitter erzeugt wurden. Das hatte mit dem Libre selbst aber gar nichts zu tun!

    Also nochmal: es hat beim Libre NIE NIE NIE 5min-Abstände gegeben!

    Manuela80

    Ich hatte jetzt Jahre lang den Libre 1 und 2. Dafür musste ich damals das übliche MDK-Prozedere durchlaufen.

    Da ich nun auf die Ypsopump mit CamAPS FX umsteige, hatte ich im November den Umstieg auf den Dexcom G6 beantragt, weil der Libre 3 da noch nicht integriert war.

    Ich habe prompt von meiner KK das Schreiben bekommen, ich hätte ja schon mit dem Libre ein rtCGM (sic!) genehmigt. Für ein Umstellung müsste der MDK prüfen, ob das notwendig sei (mit den üblichen angeforderten Unterlagen von Arzt und mir).

    Es ist also keineswegs so, dass die Umstellung von einem (billigeren) auf ein anderes (teureres) "einfach so" geht. Da muss schon dargelegt werden, warum das billigere auf einmal nicht mehr reicht.

    Ich konnte meine Umstellung glücklicherweise stornieren, da jetzt in CamAPS ja auch der Libre 3 funktioniert und die Kasse den als Folge des Libre2 anstandslos weiter genehmigt.

    Wie dein Arzt und du darauf kommen, dass man nach Genehmigung eines CGM Anspruch auf beliebigen Wechsel zu einem anderen System hat, ist mir schleierhaft.

    Ein "ich hab das so gehört " reicht da sicher nicht, da müsste schon ein handfesterer Nachweis für diese gewagte Aussage her.

    das ist doch nur ne Software die eigentlich fertig ist, und nur für andere Hardware angepasst werden muss!

    Das stimmt so ja nun mal gar nicht.

    Apps auf Android und iOS sind so dermaßen unterschiedlich zu programmieren, dass das zwei eigenständige Programmentwicklungen sind, selbst wenn die eigentliche Logik die gleiche ist.

    Natürlich gibt es Ansätze mit Schichten auf beiden Plattformen zur Vereinheitlichung von Schnittstellen, das ist aber immer mit Einschränkungen verbunden und gerade bei einer Medizin-App nicht tragbar.

    Deine Darstellung gibt die tatsächliche Sachlage dehalb überhaupt nicht wieder.

    Der 2er wurde ja auch schon minütlich ausgelesen, aber letztendlich wurde nur alle 5 Minuten (wenn ich mich richtig erinnere) geliefert. Scheinbar wurde dieser dann über die vorherigen Werte geglättet. Manchmal hat man es beim L2 gesehen, dass die App z.B. 189 sagt (kurz vorher 160) und zwei Minuten später ist dieser Wert dann aber 168 und der 189er Wert ist verschwunden.

    Das ist mir beim 3er jetzt schon oft passiert. Minütlich werden die Werte angezeigt und im Nachhinein werden sie dann geglättet. Da muss ich mich erst daran gewöhnen, dass ich nicht zu voreilig mit dem korrigieren bin.

    Ich nehme an, du beschreibst hier das Verhalten in der Abbott-App?

    Grundsätzlich kann man sagen, dass der 2er genauso wie der 3er minütlich die Werte gebracht hat. In der gepatchten LibreLink-App konnte man den Wert auch minütlich rausgeben (ich weiß nicht, warum im Zusammenhang mit dem Libre 2 immer mal wieder dieses 5min-Gerücht auftaucht. Es ist schlichtweg falsch!) und da hat man natürlich überhaupt nicht das von dir beschriebene Glättungsverhalten. Ein sehr unangenehmes Glättungsverhalten hatte man erst in xDrip+. Ich habe die Libre2-Werte deshalb aus der gepatchten LibreLink App in meine eigene App geleitet und kann dir versichern, dass diese Werte einen in der Regel sehr kontinuierlichen Verlauf haben, aber eben mit sehr viel dynamischeren Schwankungen als das bei 5minütigen Werten überhaupt sichtbar ist. Man sieht schon bei den minütlichen Werten des Libre 2 eindeutig Gewebezuckerbewegungen durch Träume, Aufstehen, Aufregung (ich kann bei mir sogar stressige Telefonate in der Libre-Kurve sehen!). Das sind dann häufig kurze Beulen nach oben (über einen Zeitraum von 10-20min, mit einem Delta von ca. 20-40mg/dl von der ruhigen Grundlinie zum Maximum der Beule). Diese schnellen durch Körperreaktionen ausgelösten Gewebezuckerschwankungen werden von manchen (auch aufgrund der seit Jahren entsetzlich verkrüppelten Darstellung in xDrip+) als unruhiges und unzuverlässiges Schwanken der Libre-Werte interpretiert. Das ist aber grundfalsch, die Verläufe sind absolut stetig und ohne Ausreißer und zeigen lediglich normale situationsbedingte Gewebezucker-Schwankungen.

    All dies ist beim Libre 2 genauso wie beim Libre 3 zu sehen. Dass das in der Abbott-App im nachhinein aus der Kurve weggeglättet wird, ist halt so. Wenn man die Gewebezucker-Verläufe aber wirklich mal im Detail betrachtet (was aber eben in der Abbott-App dann unmöglich ist), dann sind die Verläufe mit ihren Schwankungen absolut sinnvoll und nachvollziehbar.

    Ja, die 3er Werte sind wohl von Haus aus viel weniger geglättet als die 2er Werte. Der Vorteil daraus ist aber auch dass der 3er früher reagiert als der 2er, ich habe Vergleiche gesehen und Abfälle und Anstiege sieht man beim 3er einfach 5 bis 10 Minuten früher und auch Schwankungen viel deutlicher. Dafür muss man aber eine Ungenauigkeit, wie du sie bereits beobachtet hast, in Kauf nehmen.

    Ich habe seit Jahren die Libre2-Werte in meiner App und zeige die Libre2-Werte aus der Abbott-App und meine (mit einer exponentiellen Glättung über die letzten 4min der Libre2-Werte) an. Wie im Absatz vorher schon beschrieben, sieht man auch beim Libre2 selbst kurze Körperreaktionen (aber eben als stetige Verläufe, keine "Ausreißer"!). Da wird beim Libre 3 garantiert nicht anders geglättet als vorher schon beim Libre 2. Möglicherweise in der Abbott App in der Graphen-Ansicht, der im Nachhinein geglättet wird, aber die einzelnen aktuellen Libre2-Werte waren garantiert nicht mehr gefiltert als das jetzt beim Libre 3 ist. Diese kurzfristigen Schwankungen haben aber auch nichts mit Ungenauigkeit zu tun! Nach Jahren der genauen Beobachtung der (wirklichen!) minütlichen Werte des Libre 2 haben diese angeblichen Sprünge oder Ausreißer, die nur von Leuten mit unzulänglicher Software so falsch interpretiert werden, in Wirklichkeit als stetige Kurvenverläufe absolut ihren nachvollziehbaren Sinn! Und die Anstiege und Abfälle sind mit dem Libre 2 bei echter Verwertung der realen minütlichen Werte des Libre 2 genauso schnell erkennbar wie beim Libre 3.


    Einen kleinen Nachtrag muss ich dazu setzen: EINEN nicht vertrauenswürdigen Verlauf des Libre 2 (und ich gehe davon aus, das ist beim Libre 3 genauso) gibt es, nämlich beim Duschen oder generell mit starken kurzen Temperatur-Veränderungen. Hier scheitert der temperatur-beeinflusste Algorithmus des Libre offenbar. Beim Duschen erhalte ich immer eine Art Sinus-Periode: von der stabilen Grundlinie schwankt es einmal kurz nach unten, überschwingt dann nach oben und fällt dann wieder auf den Grundwert, das ganze tatsächlich annähernd in Form einer Periode der Sinuskurve). Das ganze setzt immer einige Minuten nach Duschbeginn ein und dauert bei mir ca. 15min, wobei das Duschen selbst nur die ersten 3-5min sind, danach braucht der Libre-Algorithmus noch ca. 10min für das Wieder-Einpendeln. Da ich während des Duschens sowieso die Pumpe nicht trage und der Loop dementsprechend aus ist, hat das keine Auswirkung für den Loop. Ich lasse für den Loop die Pumpe zum Duschen immer für eine halbe Stunde auf "Abgekoppelt" gestellt, dadurch setzt er erst ein, wenn die Sinusperiode mindestens 10min vorbei ist. Das sind aber tatsächlich die einzigen nicht vertrauenswürdigen Libre-Werte, die mir in zwei Jahren minütlicher Libre2-Werte bei 2 Personen (also immerhin 4 Personenjahre mit dauernder Libre2-Benutzung) aufgefallen sind!

    Flyingmosse

    Du scheinst CamAPS FX mit dem Libre ja jetzt schon ein paar Tage laufen zu haben.


    Ich gehe, davon aus, dass die Libre3-Werte, wie man es vom Libre 3 eben kennt, auch wirklich minütlich im CamAPS FX angezeigt werden, also tatsächlich 60 Werte pro Stunde und nicht nur 12 wie beim Dexcom, oder?


    Reagiert dann CamAPS FX auch jede Minute gegebenenfalls mit einer Anpassung oder "lässt es sich Zeit" und steuert weiterhin nur im 5min-Rhythmus?


    Ich würde mit dem Libre 3 ja grundsätzlich eine minütliche Loop-Steuerung erwarten.

    Also im Automode war es doch bei Krankheit, Zyklus etc. den höheren/niedrigeren Insulinbedarf durch den "Persönlichen Glukosezielbereich" zu beeinflussen.

    Im Webinar https://www.camdiabtraining.co…bgabesystem-CamAPS-FX.htm, Minute 15:26, wird der Boost explizit als Hilfsmittel in der vormenstruellen Zeit genannt. Dementsprechend wäre der Ease-Off passend für eine tageweise Phase niedrigeren Insulinbedarfs (=höhere Sensitivität) anzuwenden.

    Der persönliche Glukosezielbereich ist eher z.B. bei Schwangerschaft anzupassen, wenn über einen langen Zeitraum ein deutlich anderes Glukoseziel erreicht werden soll. Ich würde den Glukosezielbereich für die zyklusbedingte Profilanpassung eher nicht benutzen (naja, ich sowieso nicht, aber bei meiner Tochter halt nicht).

    July95 In der Schulung wurde, wenn ich mich richtig entsinne, extra angesprochen, dass beim Zyklus durch Ease-Off entsprechende Hilfestellung für CamAPS FX gegeben werden kann. Du solltest also an den entsprechenden Tagen einfach Ease-Off einschalten (und dann natürlich möglicherweise nicht nur für Stunden, sondern gleich für 1, 2, 3 Tage, je nachdem, wie lange sich diese Phase bei dir hält).


    Da du in einem anderen Thread allerdings von "zyklusbedingten Resistenzen" schreibst (hier ja eigentlich von "zyklusbedingt niedrig"), musst du natürlich entsprechend in den richtigen Phasen statt Ease-Off dann eher auf "Boost" schalten (und auch da gegebenenfalls nicht nur Stunden, sondern eben die Tage, die zyklusbedingt mehr Insulin verlangen. Typischerweise ist ja vor dem Eisprung ein anderer Insulinbedarf als nach dem Eisprung.


    Äh, nein, ich habe da selbst nicht mit zu tun, aber als Vater einer nun fast 10jährigen Tochter mit ebenfalls Typ 1 beschäftigt man sich schon mal mit dem, was da auf einen zukommt.

    Der 600SeriesAndroidUploader für die Minimed 640g sagt da nun noch: Unable to resolve host "nightscoutkp.local": No address associated with hostname.

    Das sieht erstmal nach einem reinen Namensauflösungsproblem aus. Ich würde die hosts-Datei auf dem Smartphone mit dem 600SeriesAndroidUploader mit dem nightscoutkp.local-Eintrag ergänzen. Dann sollte das Problem schon mal weg sein.

    Ich würde auf dem 600SeriesAndroidUploader-Smartphone auf jeden Fall das Zertifikat in den Android-Einstellungen importieren. Ansonsten wird es für die HTTPS-Verbindung sicherlich nicht als vertrauenswürdig angesehen und der 600SeriesAndroidUploader wird die Werte dann wohl doch nicht in Nightscout schicken.

    MeisterQ

    Ich habe das jetzt bei mir mal ausprobiert.

    Das INSECURE_USE_HTTP in meinem Nightscout-Startskript habe ich weggenommen, meinen Nightscout-Port nach außen sichtbar gemacht und im Nightscout-Startskript die Umgebungsvariablen SSL_CA und SSL_CERT auf mein Chain-Zertifikat (bei dir müsste es das selbst signierte Zertifikat sein) und SSL_KEY auf den Private Key zeigen lassen (dazu muss der User, der Nightscout startet, natürlich Zugriff auf die Dateien haben). Damit funktioniert auch die SSL-Verbindung zum direkten Nightscout-Port einwandfrei.

    Ich könnte dir leider nur Apache-Konfigurations-Zeilen präsentieren. Ich weiß nicht, ob dir das was für Nginx bringt...

    Was die Meldung beim Browser bezüglich des unsicheren Zertifikats angeht: das kannst du eliminieren, indem du das Zertifikat im Browser zu den sicheren Zertifikaten importierst.

    Auf dem Smartphone mit AndroidAPS würde ich davon ausgehen, dass man das Zertifikat in den Android-Einstellungen importieren muss, damit AndroidAPS die Verbindung als sicher akzeptiert. Bei mir ist das unter "Biometrische Daten und Sicherheit:Andere Sicherheitseinstellungen:Von USB-Speicher installieren:CA-Zertifikat". Aber das ist ja auf den Smartphones sehr unterschiedlich. Mit der Suche in den Einstellungen sollte aber bestimmt etwas zu "CA-Zertifikat" zu finden sein.

    Wenn dein Self-Signed-Certificate da importiert ist, sollte es eigentlich auf dem Gerät für alle Apps als vertrauenswürdiges Zertifikat gelten.

    Nach deiner derzeitigen Konfiguration leitet er von Port 443 ja noch nicht zu Nightscout weiter, sondern soll nur die index-Datei in dem entsprechenden Verzeichnis anzeigen. Liegen denn in /var/www/nightscoutkp.local/html überhaupt eine der Dateien index.html oder index.htm oder index.nginx-debian.html? Wenn nicht, ist das 404 ja normal.

    Der SSL_ERROR... auf Port 1337 sagt eigentlich nur, dass dort keine SSL-Verbindung erstellt werden kann. Du kannst wohl in dem node.js für Nightscout auch SSL einrichten (SSL_KEY, SSL_CERT, SSL_CA). In dem Fall bräuchte man die Nginx-Brücke eigentlich gar nicht, sondern würde direkt mit ssl über den Port 1337 gehen.
    Genau kann ich es dir aber auch nicht beschreiben, weil ich tatsächlich nur von außen auf Port 443 vom Apache mit SSL gehe und das ProxyPass dann unverschlüsselt mache (INSECURE_USE_HTTP=true), was ich für unkritisch halte, weil die Nightscout-Ports bei mir von außerhalb des Pi gar nicht erreichbar sind.

    Das erste, was mir auffällt, ist, dass deine Namen in der nginx-Konfiguration (nightscoutkp.local) nicht identisch sind mit dem vorher genannten nightscout.local. Der Server_Name im Webserver muss identisch sein zum Domain-Namen des Zertifikats. Funktioniert also nicht, wenn das Zertifikat nightscout.local enthält, der Servername dann aber anders heißt.

    Auf Port 1337 dürfte es auch nicht funktionieren, weil dein nginx darauf ja gar nicht lauscht. Ich vermute, 1337 ist der Port deiner Nightscout-Instanz? Ich habe bei mir (allerdings in Apache, nicht Nginx), die entsprechende Weiterleitung von Port 443 auf den Nightscout-Port mit ProxyPass konfiguriert. Ich gehe also immer auf den normalen HTTPS-Port.

    MeisterQ

    Ich weiß nicht wirklich, ob es so geht (ich benutze LetsEncrypt mit meiner richtigen Domain), aber ich würde folgendes probieren:

    • Einen Phantasie-FQDN benutzen (sowas wie "Nightscout.MeisterQ.de"), diesen FQDN auf allen beteiligten Geräten in der localhost-Datei mit der IP deines Nightscout-Gerätes auflösen, falls das nicht über einen von dir verwendeten DNS im VPN geht.
    • Ein Self-Signed-Certificate mit diesem FQDN erstellen.
    • Das Self-Signed-Certificate bei allen beteiligten Geräten in die Liste der vertrauenswürdigen Root-Certificates importieren.
    • Das Self-Signed-Certificate zusätzlich in die Webserver-Konfiguration auf dem Nightscout-Gerät aufnehmen.

    Dann müsste es hoffentlich mit der HTTPS-Verbindung funktionieren.

    Ey Leute, jetzt lasst doch jka mal in Ruhe......

    er macht hier alles mögliche und hilft wirklich jedem: Warum soll er das veröffentlichen ??? Lässt du bei deinem Mercedes den Schlüssel nachts stecken und jeder darf fahren ???

    Steinigt mich ruhig.....aber ich finde das unverschämt !

    Das ist das übliche Verhalten, das ich von sämtlichen Community-Entwicklungen im Diabetesbereich kenne: Wer Kritik übt, wird niedergemacht. Meine Kritik ist ganz und gar nicht unverschämt, sondern berechtigt. Genauso wie meine Kritikpunkte an xDrip+ und AndroidAPS berechtigt waren. Ich will die Verdienste der entsprechenden Leute (auch jka) gar nicht schmälern. Das ist toll, was da geleistet wird. Aber dass jede Kritik als unverschämt und unberechtigt dargestellt wird, wie das GRUNDSÄTZLICH passiert, das ist schon ziemlich erbärmlich. Und wird mich nebenbei nicht davon abhalten, weiter Kritik zu äußern, wo ich das als durchaus angemessen sehe.

    Der Hauptgrund ist, dass ich befürchte, dass es nur verwendet wird, um den Hochformatmodus für Juggluco einzuschalten und ihn in eine Art Librelink umzuwandeln.

    Sie wollen also Ihre Software genauso schützen, wie Abbott das tut. Sie fügen dabei von den Nutzern dringend gewünschte Funktionalitäten hinzu, was Ihnen hoch anzurechnen ist.


    Es ändert aber nichts daran, dass Sie sich mit Ihrer Software genauso wenig öffnen wie Abbott. Bei xDrip+ oder AndroidAPS KANN jeder (der es wissensmäßig kann) etwas ändern. Deshalb gibt es z.B. den Savitzky-Golay-Filter in einem xDrip+-Fork, brunole, der diese leidige Verzögerung (die ich auch schon oft genug angeprangert habe), eliminiert durch eine deutlich bessere Filterung. Oder es gibt deshalb Änderungen in Forks von AndroidAPS, zu denen der/die Hauptentwickler von AAPS nicht bereit sind. Oder auch die Möglichkeit, den Libre in AndroidAPS uneingeschränkt mit SMBs funktionieren zu lassen (was keineswegs gefährlich ist, wie ich nach mehreren Jahren mit Libre und SMBs versichern kann).


    Diese Möglichkeiten gibt es mit den genannten OpenSource-Lösungen. Abbott und eben auch jka mit seinem identischen Software-Schutz sperren sich aber dagegen. Auch wenn jka also sehr lobenswert einen echten Mehrwert für Libre-Nutzer mit juggluco schafft, so ist seine Software im Endeffekt für die Community nicht freier nutzbar als die Abbott-Software. Niemand hat die Möglichkeit zu prüfen, was in juggluco passiert oder Erweiterungen/Veränderungen zu schaffen.

    InsulinDoper, elgrupo


    Ich weiß jetzt nicht, wie genau Juggluco die Werte an xDrip+ sendet, aber ich weiß, wie das in der gepatchten Libre2-App gemacht wurde. Da wurde bei dem versendeten Paket genau angegeben, wer (nämlich die normale xDrip+ App) das Paket erhalten soll. Auch mit der gepatchten Libre2-App war es also unmöglich, dass eine xDrip+-Variante den Wert erhalten konnte, weil diese Varianten andere IDs/Paketnamen haben. Mit gleicher ID/Paketnamen wären sie nämlich nicht parallel zur normalen xDrip+-App zu installieren. Sie sind für Android also ganz andere Programme mit anderer Identifikation. Und diese Identifikation wird als Empfänger in der gepatchten Libre2-App nicht verwendet, sondern eben nur die ID der normalen xDrip+-App.

    Ich vermute mal, dass Juggluco das genauso handhabt, und damit ist es unmöglich, dass eine xDrip+-Variante diese Werte bekommt.

    Da ich von der Libre2-App die Werte nicht in xDrip+, sondern in meiner eigenen App haben wollte, musste ich die gepatchte Libre2-App "weiter patchen" und meine App als Empfänger dort eintragen, wo eigentlich xDrip+ als Empfänger stand. Dort könnte man dann natürlich auch eine Varianten-ID eintragen, und das würde in Juggluco sicherlich genauso gehen. Wäre aber eben ein nachträgliches Patchen der Juggluco-App, wass offensichtlich auch nicht so einfach ist, weil ja auch jka seine App mit Obfuscation schwer analysierbar macht - genauso wie Abbott nebenbei. Wer also auf Abbott schimpft, weil die es einem so schwer machen, an die Libre-Werte zu kommen, der darf Juggluco bei diesem Schimpfen nicht auslassen, das wird nämlich von jka genauso gemacht. Ja, er gibt die Werte z.B. an xDrip+ weiter, aber von der Art der Software-Entwicklung ist Juggluco=Abbott. Nix mit Open Source oder Community...