Beiträge von dideldum

Ich habe mir am Dienstag von meinem Diabetologen nun auch mal Lyumjev verschreiben lassen (bisher Humalog) und weil gestern Abend der Katheter nicht mehr richtig funktionierte, gleich das Insulin auf Lyumjev mitgewechselt.

Sicherheitshalber bin ich die Nacht nur auf 70% gelaufen, das war aber doch zu wenig. Musste heute morgen erstmal runterkorrigieren.

Das funktionierte bei wieder 100% mit meinem gewohnten Korrekturfaktor von 6:00. Brachte mich innerhalb von 90min perfekt auf 110 (mein Zielwert im Moment), wo ich bis 10:30 stabil blieb. Loop war aus, insofern bin ich überrrascht, dass bei meinem gut eingestellten normalen Basal bereits nach 90min keine Wirkung mehr zu sehen war.

Nach drei kurz hintereinander in mich reingekippten (ungebolten) Café Latte (7gKH jeder) bin ich zwischen 10:30 und 11:30 doch wieder auf 205 gewesen, musste um 11:34 also wieder korrigieren. Der gewohnte Korrekturfaktur von 11:00 hat bis 13:00 wieder fast gut gepasst (die Café Latte hatten aber trotz Korrektur noch ca. 15min eine weitere Aufwärtsbewegung verursacht), es wurde um die 135 flach, also wieder nur ca. 90min sichtbare Wirkzeit.

Um 14:30 dann Mittagessen, Hühnerfrikasse mit 50gKH Reis. Ohne SEA mit normalem Essensfaktor gebolt. Mit Humalog brauche ich mindestens 10min (besser 15min) SEA, ohne SEA wäre ich mit dem Reis deutlich über 200 marschiert. Jetzt war die Spitze gerade mal 127, um 15:45 (75min nach Bolus) auf 100 zurück und seitdem bis jetzt (16:30) pendele ich zwischen 100 und 110, also völlig stabil.

Ich bin perplex. Erstens wegen der offensichtlich wirklich viel schnelleren Wirkung als mit Humalog, aber auch wegen der bei mir auch sehr kurzen sichtbaren Wirkzeit.

Bei den Loopern heißt es ja immer, dass auch die schnellen Insuline mindestens 5 Stunden Wirkzeit haben, auch Fiasp. Einige dehnen das sogar bis 7 Stunden aus.

Ich war davon nie überzeugt, habe auch AndroidAPS bei uns so gepatcht gehabt, dass ein kürzeres DIA als 5h eingestellt werden konnte.

Ich werde mit Lyumjev jetzt erstmal mit 3h DIA laufen, wenn ich den Loop wieder anschalte. Erstmal lasse ich ihn aber noch aus und beobachte weiter zu unterschiedlichen Tages- und Nachtzeiten.

Nach nichtmal einem Tag bin ich aber völlig von der Rolle, wie anders der BZ mit Lyumjev gegenüber Humalog verläuft.

Zitat von Kappa

dideldum Kann man denn einen neuen Sensor auch mit Diabox starten oder wird das weiterhin mit Libre Link gemacht

DiaBox kann mit den NFC-Handy auch starten. Wie gesagt, das geht sogar (noch nicht, aber bald) über den Bubble. Allerdings muss LibreHack dazu noch etwas in die Firmware vom Bubble einbauen, das soll in der nächsten Version der Bubble-Firmware dann wohl drin sein.

Zitat von Kappa

Aber das wäre doch eine Lösung, an der auch der Pod-Hersteller interessiert sein müsste. Man könnte es mit einem einfachen Update machen: In den Einstellungen festlegen, dass ein U200-Insulin verwendet wird, sodass der Pod bei unveränderten Eingaben zur Dosierung nur die Hälfte abgibt. Vorausgesetzt, das Ding kann präzise genug dosieren.

Aber welche kurzwirksamen U200 Insuline gibt es denn eigentlich? Ich kenne keins.

Ich habe mir am Donnerstag Lyumjev von meinem Diabetologen verschreiben lassen. (Kurze Randnotiz: der kannte das gar nicht und suchte das auf seinem Computer erstmal.)

In der Liste der verfügbaren Verpackungsformen für Lyumjev standen auch U200-Einträge!

(Wieder kurze Randnotiz: Er wollte mir dann erzählen, dass bei Auslauf eines Patents die Hersteller gerne durch Veränderung der Konzentration (weil er eben auch als erstes die U200-Einträge wahrgenommen hatte) versuchen, gegenüber den dann aufkommenden Generika darzustellen, dass ihr Produkt eben doch anders ist. Ich musste ihm erstmal erklären, dass Lyumjev ein Fiasp-Konkurrenz-Produkt ist und nicht eine Pseudo-Neuerfindung, um sich von Generika abzugrenzen. Naja, er kommt mir ja auch jedesmal bei meinem 5.x-HbA1c mit den Hypos, durch die ich mir den erkaufe. Kopfschüttel)

Zitat von Marani

geht aber nicht mit xDrip, richtig?

Nein, das liegt aber an xDrip+, nicht an DiaBox.

DiaBox schickt die Glukose-Nachrichten raus, xDrip+ nimmt sie nur nicht an. Es gibt einen Merge-Request vom Bubble/DiaBox-Team, der ist in xDrip+ aber nicht eingearbeitet. Liegt also nur an xDrip+, nicht an DiaBox offenbar (soweit mein Kenntnis/Analyse-Stand).

Zitat von Kappa

Zitat von Sunny

Gendra

Ich hatte das gerade eben auch bei Facebook gelesen. Bin jetzt am Überlegen, ob ich ausprobiere. Mein aktueller Sensor würde sowieso morgen ablaufen...

Was bringt das im Vergleich zu xDrip?

Für mich ist das eine ganz spannende Sache!

Wir benutzen ja Miniphones ohne NFC (bald sogar nur noch Full Android Watches, ebenfalls ohne NFC) als Libre2-Empfänger und Loop-Gerät.
Starten müssen wir den Libre natürlich mit NFC, deshalb habe ich mir ein NFC-Handy so umgemodelt, dass es aussieht wie das Miniphone ohne NFC. Damit wird der Libre gestartet, die Librelink-Daten exportiert, auf dem Miniphone importiert und schwups, läuft das Miniphone mit aktiver Bluetooth-Verbindung zum Libre. Das ist allerdings etwas schwierig, weil das Ummodeln des NFC-Handys zum Fake-Miniphone nicht ohne ist.

Und da kommt DiaBox ins Spiel: Der findige "Libre Hack" hat herausgefunden, den entsprechenden Verbindungsschlüssel per NFC in den Libre zu schreiben. Das funktioniert sogar offenbar beliebig oft, das heißt, er kann mit einem Smartphone und DiaBox den Libre starten, dann hat das die Bluetooth-Verbindung. Nun kann ein anderes Handy mit DiaBox und NFC einen neuen Schlüssel in den Libre schreiben und die Verbindung übernehmen.

Das bringt mir noch nichts für die NFC-losen Miniphones, die können immer noch nicht starten oder übernehmen.

Aber es geht noch weiter: Der Bubble kann auf den Libre gesetzt werden und sich mit DiaBox auf einem Smartphone verbinden. Dieses Smartphone braucht nun kein NFC mehr, das hat ja der Bubble. DiaBox auf dem Smartphone OHNE NFC schreibt nun ÜBER DEN BUBBLE den Schlüssel in den Libre und bekommt eine DIREKTE BLUETOOTH-VERBINDUNG zum Libre, ohne ihn selbst direkt gestartet/gescannt zu haben. Der Bubble kann nun wieder vom Libre entfernt werden, weil ja die Bluetooth-Verbindung zum Smartphone besteht. Der Bubble hat also nur die Starter-Funktion meines Fake-Handys übernommen. Nur dass das für jeden funktioniert, auch ohne sich durch das Faken des Starter-Handys zu kämpfen!

Super-Sache!

Ich habe das Gerät jetzt seit 2 Wochen, bin aber noch gar nicht dazu gekommen, es zu probieren.

Habe auch nur die 10 normalen BZ-Teststreifen und (weil ich nur die extra angekreuzt hatte) zwei von den 3in1-Streifen (BZ, Hämatokrit, Hämoglobin) dabei.

Ich hatte 2 mal BZ-Tests mit dem Fora 6 Gerät, einem Contour Next One und einem Contour Next Link gemacht.

Immer zwei Messungen direkt nacheinander, alle direkt aus demselben Blutstropfen.

Das Contour Next Link ist eindeutig das schlechteste, es hat immer die größte Streubreite. Das war mir aber aus vorherigen Erfahrungen auch schon bekannt, wir hatten mal eine Situation, da haben wir 3mal hintereinander gemessen: 212, 148, 174. Da kann man nicht viel mit anfangen.

Das Contour Next One ist ganz klar Gewinner: Aufeinanderfolgende Messungen hatten gerade mal eine Streuung von unter 5mg/dl.

Das Fora 6 lag in der Mitte, die Streuung war besser als beim Link, war aber bei beiden Versuchen über 10mg/dl.

Allerdings hatte ich jetzt beim Quartalstermin mit dem Diabetologen mal eine Vergleichsmessung mit seinem Laborgerät gemacht, und da war es ganz ok, Laborgerät 145mg/dl, Fora 6 137mg/dl.

Da das sehr gute Contour Next One von meiner Tochter benutzt wird und ich bisher das schlechte Contour Next Link, wollte ich jetzt dann doch die Gelegenheit ergreifen und das Fora 6 gezielter nutzen.

Ich habe mir also gleich ein paar Teststreifenpackungen verschreiben lassen.

Nun hat mir meine KV mal ein Schreiben geschickt, dass ich mich nur von Partner-Handelsunternehmne meiner KV versorgen lassen darf. Meinen ganzen Diabetesbedarf bestelle ich immer sehr zufrieden bei Dia-Plus-Minus. Die hatten die PZN nicht im Web-System, also habe ich angerufen. Nach viel Hin und Herfragerei von ihnen an mich und intern bei denen kamen sie zum Schluss, sie könnten die Teststreifen nicht besorgen, ich sollte die vor Ort in der Apotheke kaufen.

Leider ist keine der Apotheken bei uns im Ort mit meiner KV verbandelt. Ein Anruf bei der KV klärte mich auf, dass im Ort 10km entfernt eine Apotheke gelistet sei, die Handelspartner von der KV ist.

Ein Anruf bei der Apotheke führt wieder zur Verwirrung. Erste Auskunft war (wie bei Dia-Plus-Minus auch), die Teststreifen könne man nicht besorgen. Außerdem seien die mit 30€ pro 50er Packung gelistet, das könne mit der KV Probleme geben. Ich war verwundert, kostet die 50er Packung bei smart-otc im Webshop doch nur 19,43€. Nur kann ich bei smart-otc nicht direkt bestellen, weil ich dort kein Rezept einlösen kann. Schließlich erklärte die Apotheke sich bereit, nochmal zu klären.

Nach einer halben Stunde dann der Rückruf: Man würde die Teststreifen direkt vom Hersteller bestellen, es könne aber eine Woche dauern.

Das ganze lässt sich im Moment also eher schleppend an.

Trotzdem möchte ich dem Gerät gern eine Chance geben, weil ich mit dem Contour Next Link eh nicht zufrieden bin und die Geschichte mit den vielen Messmöglichkeiten sehr gut finde. Auch die Blutmenge ist z.B. viel geringer als beim Freestyle Libre Meßgerät, mit dem man ja auch Ketone messen kann. Die dafür notwendige Blutmenge ist beim Freestyle Libre aber abartig hoch, da ist das Fora 6 tatsächlich deutlich besser.

Zitat von Kappa

wie die das machen, ist mir ein Rätsel.

Das ist eigentlich ziemlich einfach: Die Zeit in den Apps (ganz egal, ob LibreLink, xDrip+ oder AndroidAPS) und mittlerweile wohl auch im Lesegerät wird in "epoch-Zeit" gemessen, das ist die Zeit seit dem 01.01.1970 00:00 UTC in Sekunden bzw. Millisekunden (je nach System). Diese Zeit ist immer bezogen auf UTC, also völlig unabhängig von Zeitzonen oder Sommer/Winterzeit. Deshalb gibt es mit der Zeitumstellung auch eigentlich mit den Apps überhaupt kein Probleme, denn die Sekunden bezogen auf die UTC laufen einfach weiter, egal ob man von Sommerzeit auf Winterzeit umstellt oder umgekehrt oder es einfach laufen lässt. An diesen Sekunden ändert auch eine "doppelte" Stunde von 2 bis 3 Uhr gar nichts, denn die doppelte Stunde ist trotzdem bezogen auf die UTC eine Stunde später als die erste Stunde von 2 bis 3. Und im Frühjahr gibt es auch keine "fehlende" Stunde, denn die Sekunden bezogen auf UTC laufen einfach normal weiter, solange wir noch nicht in der Lage sind, einen echten "Zeitsprung" zu machen.

Lediglich die Anzeige in einem System mit lokaler Zeitzone und Sommer/Winterzeit ist eventuell doppelt, der Zeitstempel, der dahinter liegt, nicht.

Nur haben manche Systeme eben leider nicht diese Zeitzählung. Z.B. die Dana RS und ganz sicher auch alle anderen Pumpen. Und da etwa AndroidAPS auch die Inhalte der Dana RS ausliest und hier die für uns "normalen" Datums-/Zeit-Angaben mitbekommt, die einfach der "lokalen" Pumpenzeit entsprechen, gibt es in der Pumpenhistorie dann tatsächlich bei einer Zeitumstellung (die man ja eigentlich manuell an der Pumpe machen muss) eventuell doppelte Einträge dieser lokalen Pumpen-Zeit.

Zur Illustration mal ein Bild von heute Morgen mit Duschen. Man sieht einen Anstieg durch zwei ungebolte Café Latte (insgesamt 14gKH), die ich vor dem Duschen in mich reingekippt hatte. Über einen Zeitraum von ca. 15min sind die Werte des Libre vom Duschen beeinflusst: sie gehen entgegen der eigentlichen BZ-Bewegung erst falsch nach unten, um dann nach dem Duschen mit großen Schritten wieder nach oben aufzuholen.

Da ist also gar kein Hin- und Her-Gezackere, sondern einfach nur eine Temperatur-Beeinflussung der Sensor-Messwerte, die beim Dexcom unserer Erfahrung nach völlig identisch stattfand.

Die grauen Punkte sind nebenbei diejenigen, die direkt aus dem LibreLink kommen, die bunten Punkte meine Glättung (mit einem Zeitfenster von nur 4min und damit maximal 2min Verzögerung zum Sensorwert).

Es gibt gerade mal einen "Ausreißer" aus der sonst glatten (falschen) Abwärtsbewegung um 7:07, den glätte ich. Ansonsten gehen die Librewerte in einer flüssigen Bewegung weiter. Man sieht sehr schön den Unterschied zu xDrip+, das einem einen völlig falschen Eindruck der sehr guten Libre-Werte vermittelt!

Zitat von Gendra

Wenn aber, wie bei xDrip, jeder Wert ausgewertet wird, dann würde die Kurve ziemlich viele Hüpfer beeinhalten. Das sieht nicht nur unschön aus, sondern kann Loop (der sich vor allem an den Differenzen der Werte orientiert) auch zu einer Überdosierung führen. Deshalb wurde diese Glättung eingebaut.

Ohne die Glättung würde die Kurve so aussehen, wie die ockerfarbenen Punkte in meinem Bild oben.

Dazu muss ich auch noch etwas schreiben:

Die Anzeige der minütlichen "Rohwerte" vom Libre in xDrip+ ist katastrophal falsch! In xDrip+ sieht das immer sehr hüpfig und wolkig aus. Das liegt aber nur daran, dass xDrip+ die 5 einzelnen Minutenwerte nicht in richtiger Reihenfolge hintereinander darstellt, sondern überlagert.

In meiner App gebe ich die minütlichen Werte ganz normal hintereinander im Graph aus. Und siehe da: da sind gar keine Sprünge! Das verläuft alles ganz sauber und glatt. Tatsächlich ist da - wenn überhaupt - nur eine minimale Glättung erforderlich.

Die Schlussfolgerung der Notwendigkeit der Glättung in xDrip+ kommt also von der überaus grottigen und falschen Darstellung in xDrip+ selbst und hat mit der Realität der Werte vom Libre überhaupt nichts zu tun!

Zitat von Gendra

Du kannst aber mal probieren (z.B. nach dem Duschen) alle paar Minuten den Sensor zu scannen, auch da werden dann deutliche Sprünge zu sehen sein.

Die Sprünge beim/nach dem Duschen haben aber etwas mit der Hitze-Empfindlichkeit der Gewebezuckermessung zu tun. Diese Sprünge fanden in meiner halbjährigen Erfahrung mit dem Dexcom G6 genauso statt wie mit dem Libre, haben also gar nichts mit dem Libre-Algorithmus zu tun.

Tatsächlich ist die Glättung von xDrip+ - mit Verlaub gesagt - großer Mist. Die 25minütige Glättung mit linearem Durchschnitt führt zu einer völlig unnötigen Verzögerung von 10 bis 15 Minuten zum Sensorwert.

Ich leite mittlerweile die LibreLink-Werte an meine eigene App, glätte sie dort mit einem exponentiellen Mittelwert in einem Zeitfenster von nur 4 Minuten und bin dadurch nur 1-2 Minuten hinter dem Sensor-Wert. Liefert dieser einzelne Sprünge, glätte ich die so ziemlich weg. Beim Duschen gibt es aber über 15-30 Minuten Sprünge, die dann auch xDrip+ mit seiner überlangen Glättung nicht wirklich wegfiltert.

Und wozu auch? Während des Duschens kann man den eventuell vorhandenen Loop ausmachen (bei uns ist die Pumpe dann eh ab). Und wenn sich nach dem Anziehen der Sensor wieder gefangen hat, wird der Loop wieder angemacht.

Ansonsten sind die Sprünge des Libre im Bereich +-5mg/dl pro Minute, wie ich dir nach jetzt 2 Wochen Laufzeit mit Analyse der minütlichen Werte versichern kann.

Der Libre liefert ganz ausgezeichnete minütliche Werte, wo die in xDrip+ vorgenommene Glättung grundfalsch ist. Und zum Loopen sind die xDrip+-Werte dann überhaupt nicht mehr brauchbar, denn durch die 15min Verzögerung in xDrip+ und zusätzlich die Verzögerung des Gewebezuckers zum Blutzucker reagiert der Loop dann mit einer halben Stunde Verzögerung auf BZ-Änderungen. Das ist ein echt schlechtes Regelsystem!

Zitat von nest

Zitat von dideldum

Da gebe ich dir grundsätzlich Recht. Trotzdem kommst du ja um die Umstellung nicht herum, irgendwo ist dann mal eine Basalstunde doppelt (bzw. fehlt im Frühjahr). Und eine Stunde sehe ich für den physiologischen Insulinbedarf nicht als so gravierend an, schließlich sollte in der Basalkurve keine großen Sprünge, sondern weiche Übergänge sein. Insofern macht eine automatische nächtliche Umstellung um eine Stunde in meinen Augen kein Problem.

um eine Stunde geht es ja nicht, aber 4-5 oder mehr könnten da schon Probleme machen!

nest

Das wird in AndroidAPS ja auch nicht automatisch gemacht. Genau dafür bietet es den Mechanismus, das Profil um eine frei definierbare Zeit zu verschieben. Bei 6 Stunden Zeitverschiebung könnte man also jeden Tag das Profil um 2 Stunden weiterschieben, bis man am 3. Tag dann mit dem "normalen" Tag/Nacht-Profil bezogen auf die andere Zeitzone läuft. Ich mag einiges an AndroidAPS nicht, aber das ist ein sehr sinnvoller Mechanismus.

Zitat von nest

Zitat von dideldum

Nein, tut sie nicht.

Auch die Dana kennt keine Zeitzone oder Sommerzeit.

Die Umstellung wird extern von AndroidAPS gemacht.

so etwas möchte ich gar nicht - mein BZ stellt sich doch auch nicht so ganz automatisch um!

nest

Da gebe ich dir grundsätzlich Recht. Trotzdem kommst du ja um die Umstellung nicht herum, irgendwo ist dann mal eine Basalstunde doppelt (bzw. fehlt im Frühjahr). Und eine Stunde sehe ich für den physiologischen Insulinbedarf nicht als so gravierend an, schließlich sollte in der Basalkurve keine großen Sprünge, sondern weiche Übergänge sein. Insofern macht eine automatische nächtliche Umstellung um eine Stunde in meinen Augen kein Problem.

Zitat von July95

Zitat von Grisu

Zitat von Marani

Wenn ich es noch richtig im Hinterkopf habe, stellt sich die Dana automatisch um.

Nein, tut sie nicht.

Auch die Dana kennt keine Zeitzone oder Sommerzeit.

Die Umstellung wird extern von AndroidAPS gemacht.

Grundsätzlich KÖNNTE xDrip+ die Daten eines Scans durchaus verarbeiten.

Die Entwickler des Patchs, der dafür sorgt, dass die Bluetooth-Werte an xDrip+ geschickt werden, haben da nämlich noch viel mehr eingebaut:

Es werden Nachrichten geschickt, wenn der Libre-Sensor keine Verbindung mehr zum Handy hat, wenn die Verbindung wieder gefunden wird, UND auch die gescannten Daten! (und noch mehr)

Aber xDrip+ nimmt nur die Nachricht des einzelnen Bluetooth-Wertes an, alle anderen Nachrichten werden ignoriert. Das ist einfach eine fehlende Programmierung in xDrip+.

Ich habe die gepatchte LibreLink so verändert, dass sie nicht an xDrip+, sondern an meine eigene App schickt. So konnte ich mir die Scan-Nachricht anschauen.

Leider fehlt hier etwas: nämlich die einzelnen Minuten-Werte der letzten 15min. Man erhhält den aktuell gescannten Wert, sowie alle gescannten Werte der letzten 8 Stunden und die auf je 15min Abstand gemittelten Werte der letzten 8 Stunden, nicht aber die aktuellen 15 Einzelwerte der letzen Viertelstunde, die der Libre ja eigentlich auch vorhält.

Das stört mich insofern, als man ja das Handy mal 10 min irgendwo liegen lassen kann und dann durch den Scan eigentlich trotzdem diese 10min-Lücke mit den vollständigen Minutenwerten auffüllen könnte. Aber leider fehlt das im Patch dann doch.

Aber die üblichen 8-Stunden-Werte im 15min-Abstand, die könnte xDrip+ durchaus annehmen und in die Kurve integrieren. Muss halt nur reinprogrammiert werden.

Zitat von CR77

Könntest du hier vielleicht kurz die Seiten verlinken, die dich zum Erfolg gebracht haben?

Leider nicht.
Die von dir angeführten Seiten (kitekater und dhermanns) hatte ich mir auch angeschaut, bin aber beiden nicht gefolgt.
Letztendlich habe ich mir einfach alles in einzelnen Schritten installiert.
1) Ubuntu 18.04 LTS 64bit als Betriebssystem installiert. Mein Gedächtnis ist nicht mehr das beste, aber ich meine, der Grund war, dass MongoDB mit 32bit irgendwelche Einschränkungen hatte, die ich nicht haben wollte und deshalb 64bit als Grundlage wollte. Im Januar gab es das PiOS aber nocht nicht als 64bit, also nahm ich Ubuntu.

2) Apache mit APT als Webserver installiert (irgendwie habe ich immer in meinem Leben Apache genommen, deshalb war das einfach Gewohnheit). Wie es mit nginx gehen würde, weiß ich deshalb nicht.

3) Letsencrypt mit Apache-Einbindung mit APT installiert und mehrere subdomains zu meiner Domain zertifizieren lassen. Grund ist, dass ich 2 Nightscout-Instanzen laufen lasse (eine für mich, eine für meine Tochter). Von außen spreche ich die mit unterschiedlichen Subdomains an, so dass ich für den Nightscout-Link keine unterschiedlichen Ports brauche, sondern alles über den HTTPS-Port läuft, aber eben einmal an <tochter-name>.<meine-domain>.de und <papa-name>.<meine-domain>.de.
4) MongoDB mit APT installiert und zwei User (einen für mich, einen für Tochter) angelegt, die Passworte habe ich einfach genauso wie vorher bei Heroku genommen. Datenbank-Tabellen habe ich nicht angelegt, das passiert automatisch in Schritt 5.

5) die alten Nightscout-Daten aus Heroku exportiert (ich meine, das hätte ich über die Webseite gemacht, wo man irgendwo auch shell-Kommandos eingeben kann und da dann einen Export mit command-line-Kommando gemacht). Den Export dann auf dem Pi in die mongodb für den entsprechenden User importiert.

6) cgm-remote-monitor mit git in mein User-Verzeichnis ausgecheckt. (Habe ich zuzsätzlich mit APT auch node.js installiert? wahrscheinlich)

7) 2 Shell-Skripte (eines für Tochter, eines für mich) im Userverzeichnis angelegt, in denen ich sämtliche Nightscout-Umgebungsvariablen gesetzt habe (der Einfachheit halber habe ich einfach alle Heroku-Variablen inkl der Passworte für MongoDB und Api-Secret genommen. Die Ports, auf denen jede Nightscout-Instanz dann lauscht, in den zwei Skripten habe ich auf zwei irgendwo im 16000er Bereich gesetzt (also nicht 1337 genommen). Ist nicht optimal, irgendwo im Bereich, wo Ports dynamisch zugewiesen werden, Ports festzulegen, funktioniert aber, weil die Nightscout-Prozesse direkt nach dem Booten gestartet werden und diese Ports dann natürlich noch frei sind). Die Shell-Skripte habe dazu ich in der crontab des Pi-Users so eingetragen, dass sie nach einem Reboot automatisch gestartet werden (also nicht als Service auf der Maschine eingetragen), der crontab-Eintrag sieht dann so aus: "@reboot /home/ubuntu/<mein startscript name>.sh". [Nachtrag: Die shell-Skripte enthalten natürlich nicht nur die Umgebungsvariablen, sondern am Schluss auch den Start des Nightscout-Servers mit "node -title 'Vater/Tochter-Name' <pfad zu cgm-remote-monitor>/server.js"]
8.) In Apache 2 VirtualHosts definiert, die über HTTPS mit der entsprechenden Vater- bzw. Tochter-Subdomain die Verbindung annehmen und an die beiden entsprechenden Nightscout-Ports weiterleiten. In Nightscout habe ich dazu die INSECURE_USE_HTTP-Umgebungsvariable in die beiden Shell-Skripte mit hineingenommen, weil ich zwar von außen durchaus eine HTTPS-Verbindung habe, aber das mit dem X-Forwarded-Proto-Header auf die Schnelle nicht hinbekommen habe, da war es das einfachste, Nightscout auch unsichere Verbindungen zu erlauben, obwohl die Verbindung durchaus sicher ist. Damit der Apache-Server auch von außen erreichbar ist, wird in der Fritzbox auf dem HTTPS-Port ein Forwarding an den HTTPS-Port des Pi eingerichtet.

Zusätzlich habe ich den Pi in unserem Netzwerk als DNS-Server eingerichtet und unsere Fritzbox so konfiguriert, dass sie den Pi als DNS-Server auch bekannt gibt.

Im Pi habe ich dann die externen subdomains lokal aufgelöst, so dass ich im Wlan/Ethernet nicht erst an den externen Provider-DNS-Server gehe und dann die externe Fritzbox-Adresse mit ihrer Weiterleitung an den Pi verwendet wird, sondern im Wlan/Ethernet ohne Umwege der Pi angesprochen wird.

Wegen der Reboot-Einträge in der crontab habe ich dann den Pi einmal neu gestartet. Seitdem laufen die beiden Instanzen. Ich musste in allen unseren Clients nur den qualified name von xyz.herokuapp.com auf <vater/tochter>.<meine domain>.de ändern und alle clients liefen direkt auf den Pi.

Zitat von Kappa

Ich hab im Blut häufig kurzfristige Änderungen um 30-40, obwohl die Kurve in xDrip noch gerade läuft. Sieht man in xDrip erst 15-20 Minuten später.

Das hat ich bei xDrip+ schon immer genervt. Mein erster Versuch war, in xDrip+ die Zeit, die er rückwirkend zum Glätten der Daten nimmt, zu verkürzen. Das macht die Sache etwas besser, aber nicht viel.
Mittlerweile habe ich die Intents der gepatchten Librelink auf meine eigene App (ich schreibe mir gerade ein eigenes Loop-Programm, weil ich mit AndroidAPS auch nie wirklich zufrieden war).
In meiner App mache ich zwei Dinge anders: erstens benutze ich einen anderen Glättungsalgorithmus (xDrip+ rechnet mit gewichteten linearen Durchschnitt, wobei ich die Gewichtung nicht für gut halte. Ich benutze einen exponentiellen Durchschnitt). Durch den exponentiellen Durchschnitt konnte ich zweitens die Zeit, die ich für die Glättung nehme, auf nur 4 Minuten verkürzen und bekomme eine wunderbare Kurve, die einzelne Ausreißer des Libre gut glättet, bei schnellen BZ-Bewegungen aber auch innerhalb von maximal zwei Minuten folgt - in diesen Situation folgt xDrip+ immer erst ca. 15min verspätet. Zieht man die sowieso vorhandene Verzögerung des Gewebezuckers zum BZ in Betracht, ist xDrip+ mit Libre 2 zum Loopen eigentlich gar nicht brauchbar.
Noch ist meine App nicht fertig, aber die BZ-Verläufe sind auf jeden Fall schonmal um Welten präziser und brauchbarer zum Loopen als mit xDrip+, gerade bei steileren kurzfristigen BZ-Änderungen.

Zitat von mrks

... da der pi nicht wirklich geeignet ist.

Ach nein, so ist das nicht.

Ich habe es auf meinem Pi4 gut installieren können und es läuft einwandfrei.

Habe alles einzeln installiert. 64bit Ubuntu als OS, eine MongoDB Instanz, zwei Nightscout, Apache mit letsencrypt für die https-Verbindung. Export der beiden MongoDB-Datenbanken aus Heroku, Import in meine lokale Mongo. Musst mir dafür lauter Eizelanleitungen zusammensuchen, ging aber ganz gut.

Ich finde es auf dem Pi klasse.

Zitat von Brander-Diab

Schau doch mal, ob sich die BlueJay nicht auch mit libre koppeln lässt.

Ganz sicher nicht mit dem Libre 2 ohne Transmitter.

Nach wie vor muss die gepatchte LibreLink auf einem Full-Android-Gerät laufen, was die BlueJay nicht ist. Ohne LibreLink kann xDrip+ die Libre 2-Werte nicht bekommen (solange kein Transmitter eine Zwischenrolle übernimmt, dann braucht man natürlich LibreLink nicht und dann kann die Bluejay eventuell direkt vom Transmitter empfangen, da fehlt mir allerdings die Expertise).

Generell: xDrip+ mit gepatchter LibreLink geht NUR auf Android smartphones oder Full-Android-Watches (auf diesen jedoch nur mit zusätzlichem NFC-Handy zum Starten und etwas Aufwand, um die LibreLink-Libre-2-Verbindung auf der NFC-losen Full-Android-Uhr zu übernehmen).

Alle Uhren, die kein vollwertiges Android haben (Wear OS, Tizen etc), und da gehört die Bluejay dazu, gehen definitiv NICHT als direkter Empfänger mit gepatchter LibreLink, also ohne Transmitter.

Zitat von Kappa

Ist das nicht der Fall, entstehen bei Verwendung der gepatchten App Lücken in der Blutzuckerkurve, die Transmitter können verpasste Werte auch nachträglich auffüllen.

Ich habe mir mittlerweile die gepatchte LibreLink etwas genauer angeschaut und festgestellt, dass die Entwickler des Patches auch eingebaut haben, dass die gescannten Daten versendet werden.

xDrip+ hat das nur leider noch nicht implementiert. Die Scan-Daten sind also grundsätzlich für xDrip+ verfügbar, werden nur nicht verarbeitet.

Ich habe mir ein kleines Testprogramm gemacht, mit dem ich die Scan-Daten der gepatchten App angenommen habe. Da ist alles da, was man braucht. Auch mit der gepatchten LibreLink können also Lücken in xDrip+ grundsätzlich gefüllt werden!

Zitat von mrks

„Leider“ zählt das Libre2 seit Ende Juli 2019 als „echtes“ rtCGM, jedenfalls gemäß GBA.

Mit der gepatchten LibreLink ist der Libre 2 ein ganz wunderbares echtes CGM (allerdings nicht dank Abbott, sondern dank einiger sehr hilfreicher freiwilliger Entwickler!).

Bei meiner Tochter und mir läuft der Libre 2 als minütlicher Glukose-Lieferant im Loop sehr zuverlässig. Von den unseligen K6-Chargen im April/Mai abgesehen, hat auch jeder Sensor seit Januar sauber seine 14 Tage mit sehr guten Werten absolviert.

Mit dem Dexcom G6 waren wir gar nicht glücklich, nach dem Libre 1 dachte ich, für Töchterchen sei der Dexcom G6 besser. Aber weit gefehlt. Der war katastrophal. Letztendlich hat sie meine Libre 2 benutzt und ich 2 Quartalslieferungen G6 von ihr durchgestanden. Da haben gerade mal 2 Sensoren die vollen 10 Tage durchgehalten, die Werte waren am ersten Tag jenseits jeder Glaubwürdigkeit. Durchschnittlich hat jeder Sensor nur 7 Tage Werte geliefert, davon nur 6 halbwegs vertrauenswürdig. Im Vergleich zum Libre 2 war der Dexcom bei uns ein unglaublicher Reinfall.

Der Libre 2 läuft hingegen bei uns beiden wie eine 1. Selbst frisch gesetzte Sensoren sind häufig auf den Punkt, spätestens aber nach 1-2 Stunden. Da konnte der G6 bei weitem nicht mithalten.

Mir ist klar, dass das bei anderen Leuten auch anders läuft, aber grundsätzlich ist der Libre 2 ein tolles CGM mit einer Menge Vorteilen gegenüber dem Dexcom und den anderen wenigen Systemen.