Wie ist ns.10be.de aufgebaut. Struktur, Skripte, Abläufe…

Also, wie sieht es denn so hinter ns.10be.de aus?

Eigentlich ist 10be nur ein Web-Frontend, welches die Bedienung von der Nightscout-Erstellung erleichtert und im Hintergrund das macht, was Heroku & co auch machen.

Die Einstellungen, welcher der User auf der Seite macht, werden in einer Datenbank gespeichert und zur Nightscout-Instanz weitergeleitet und dort in die Config eingetragen.

Nightscout selbst, händelt dann die ganzen Daten bz, treatments, profile etc und speichert dies in der MongoDB-Datenbank, welche bei 10be für den User beim erstellen vom Server gemacht wurden.

 

 

Aus User/Anwender Sicht: Ganz grob so:

 

  1. Also der Client (Browser, App etc), stellt eine Anfrage wie z.B. gib mir die Seite xxxxxxx.ns.10be.de und diese geht beim Proxy1 oder Proxy2 ein (Round Robin).
  2. Wenn es im nginx eine Config für den Hostnamen oder Port gibt, wird die Anfrage im Hintergrund an den Cluster zu der Nightscout-Instanz weitergeleitet.
  3. Nightscout selbst, holt sich die Daten aus der MongoDB, die auf dedizierten Server laufen (Ram wäre sonst auf den Clustern zu wenig und ist weniger flexible um eine einzelne Instanz auf einen anderen Cluster zu ziehen).
    1. Dann wird das Ergebnis an den Client zurück gegeben und die Webseite wird angezeigt.

 

 

Und was machen die anderen Sachen da?

  1. Da werden die Daten auf den zweiten Proxy gesynct, das falls der Hauptserver mal länger ausfällt, man diesen mit etwas Handarbeit als Ersatz nutzten kann.Das es auch ohne eingreifen geht, wäre möglich, aber habe ich noch nicht hinbekommen, da es viel Aufwand ist.
  1. und 6. Beim share-Server, liegen die Nightscout-Dateien, sowie die DB-Backups und die Autotune-Auswertung.
    Die Proxy-Server dürfen lesen auf die DB-Backups zugreifen, ansonsten pusht dieser nur die Daten/Files.Sprich dort werden die neuen Dateien/updates zuerst geladen, dann getestet und dann nach und nach auf den Cluster geladen.

 

 

Allgemeine Prüfung der Erreichbarkeit und der Instanzen

Dazu laufen alle paar Minuten Prüfungen ob servername.ns.10be.de:xxx/api/v1/status ein „OK“ zurück gibt und das innerhalb von 3 Sekunden.

Wenn dies in 15 Minuten mehr als 3 Mal fehlgeschlagen ist, wird die Instanz neu deployed.

Dazu laufen auf dem Cluster Daemons, welche prüfen, das die Instanzen laufen und auf dem Port reagieren. Läuft ein Prozess nicht oder antwortet dieser nicht, wird die Instanz neu gestartet.

 

 

Prüfung der VPS-Server

Die Server werden alle paar Minuten geprüft, ob diese erreichbar sind und wie der Status vom Server selbst in der api ist.

Wenn ein Server mehrmals nach 30 Sekunden Timeout nicht reagiert, aber gestartet ist, so wird dieser neu gestartet.

Wenn nach einer Stunde immer noch keine Antwort erfolgt, gibt es vom Slack-Bot eine Nachricht und ein reboot wird erneut probiert.

Ebenso wird eine Meldung auf Twitter und hier https://ns.10be.de/de/status.html gepostet.

Dies funktioniert meist gut, aber leider auch nicht immer korrekt, dann muss man immer mal wieder (selten), von Hand eingreifen.

 

 

 

Probleme letzer Woche

Die Hauptprobleme sind mittlerweile der nginx auf Proxy1 und Proxy2.

Die Requesttime liegt meist bei:

req_time=0.002

bis

req_time=0.295

im Normallfall (und aktuell auch wieder).

Bei dem Probleme letzter Woche, gab es aber Werte mit 5 Sekunden und höher, sowie loops, das der Proxy2 erst zum Proxy1 und von dort dann zum Cluster die Verbindung geleitet hat.

Dies kamm zum Teil von dem folgenden Fehler auf dem Proxy1:

could not allocate node in cache keys zone "STATIC"

Und durch die falsche DNS-Auflösung beim proxy2.

Den Fehler von Proxy1 konnte ich leider auch nach vielen Versuchen und Tipps nicht lösen, wodurch der Cache für statische Files, nun komplett deaktiviert ist.

 

 

Warum gibt es dann immer noch immer mal wieder Connection Timeouts?

Der Nginx-Dienst muss seit dem die 1.000 Instanzen überschritten wurde, leider mit einem restart neu gestartet werden, da ein reload nicht nur ewig lange dauert, sondern auch danach dieser die neuen Instanzen einfach nicht kennt und daher nicht eingelesen hat.

Beim einem restart werden allerdings die offenen Verbindungen beendet, was zu dem Timeout und ähnlich führen kann. Da dies aber auf dem Proxy1 und 2 mit zwei Minuten Verzögerung passiert, ist immer ein Proxy online.

Man könnte es alles in eine Config-Datei schreiben, dann würde der reload vermutlich gehen, dafür ist aber viel Arbeit zum umbauen der Skripte nötig…….

Allerdings habe ich heute eine andere Änderung gemacht, die es besser machen sollte.

 

 

 

Bitte beachte weiterhin, es ist immer noch ein Gefallen, der hier gemacht wird!

Es gibt keine Garantien oder ähnliches!

Es steckt verdammt viel Arbeit drin und ich versuche mein bestes, aber auch die Freizeit und das Wissen in allen Bereichen ist begrenzt (wächst, aber trotzdem begrenzt).

 

Von daher, kann es immer wieder zu solchen Probleme kommen und wie beim letzten Fall, wo man denkt, es ist gelöst, tritt dann aber wieder auf und wieder und wieder, kann sich die Lösung hinziehen.

Wer z.B. immer noch Probleme in aaps hat (was bei mir in der DEV nicht auftritt und auch nie aufgetreten ist), kann ich leider nur hier her verweisen:

https://github.com/MilosKozak/AndroidAPS/issues/2481#issuecomment-595903148

 

[UPDATE 27.05.2020]

Seit den letzten Anpassungen vom März, läuft alles wieder reibungslos.

Das letzte Problem Anfang/Mitte April, das timezone-Paket von npm nun eine Anpassung braucht, die in nightscout noch nicht drin ist, wurde lokal gefixt.

Abgesehen von Hardware-Probleme, die bei einem technischen Defekt auch etwas länger andauern können, gab es keine Verzögerungen, Ausfälle oder ähnliches.

 

Warum der DIY AID Loop kein Selbstläufer ist und was bei inoffiziellen cgm-Quellen wichtig ist.

Das mit am wichtigsten beim DIY AID Loop, sind die BG Werte!

Dann die Faktoren, br und natürlich die richtigen Einstellungen.

 

Es gibt ja offizielle Apps/Werte/Algorithmen (die vom Hersteller selbst) und inoffizielle wie z.B. xDrip, spike, tomato, bluecon-app usw.

Die inoffiziellen Apps nehmen die RAW-Werte und bauen meist mit einer Liniearen Kalibrierung dann die GZ-Werte daraus. Das läuft auch richtig gut bei mir. Selten sind die Abweichungen zu groß und so lange ich den Wert „runter“ ziehe, ist das in Ordnung.

Andersherum, wenn ich ein Wert hoch ziehe, hat man nach unten nicht mehr so viel Spielraum.

 

Wenn ein Sensor nur noch LO anzeigt (GZ unter 40), ist es nötig dies blutig zu verifizieren und auch mit den offiziellen Reader/Apps zu prüfen.

Ein Beispiel, wie man es nicht machen sollte:

Quelle: https://slack-files.com/TAWP5KA0L-FJV9J8U5U-478bd8cf56?nojsmode=1

Dort hätte die offizielle App/Reader garantiert gesagt „Sensor defekt“ oder „bitte in 10 Minuten noch einmal versuchen“ und nach 2-3h, hätte das Gerät dann ausgegeben, das der Sensor defekt ist.

Ebenso, ist so eine Kalibrierung von 1,x mmol auf 16mmol NICHT gut, da durch die Linieare Kalibrierung alle Werte entsprechend angepasst werden.

Sprich der Wert bei 6 wird ebenso angepasst wie der Wert bei 2 oder 20 mmol.

 

Deshalb wird empfohlen die NATIVE-Mode zu verwenden, bzw. die gepatchten offiziellen Apps, denn dort kommen die originalen Algorithmen der Hersteller zum Einsatz, welche dann auch schneller/früher sagen, das ein Sensor defekt ist.

Ebenso hätten vermutlich die meisten offiziellen Apps/Reader solch eine Kalibrierung, wie auf dem Bild, nicht zu gelassen, da diese nicht plausible ist.

Es gibt auch in den inoffiziellen Apps zum Teil ein paar plausibiltäts Prüfungen, welche man aber deaktivieren kann, da davon ausgegangen wird, das der Anwender weiß was er macht.

 

Worauf ich (und die community) hinaus will:

Ein Sensor der LO anzeigt muss man mit den offiziellen Apps/receiver gegen prüfen und nicht von 40 mgdl auf 400 mgdl kalibrieren! Der ist zu 99% defekt, wenn man nicht gerade blutig bei 60 war!

 

Weitere links/Informationen dazu (auf English):

Offizielles Statement der core Entwickler:

https://facebook.com/groups/1782449781971680?view=permalink&id=2266177020265618

 

Paar weitere offizielle und inoffizielle links dazu:

http://seemycgm.com/2019/05/20/fda-warning-against-diy-systems/

 

https://www.fda.gov/medical-devices/2019-safety-communications/fda-warns-people-diabetes-and-health-care-providers-against-use-devices-diabetes-management-not

 

Deshalb ist es auch gut die Sensor mit tape zu fixieren, das sie nicht verrutschen und kein starkes Gummiband zu nehmen, das den Sensor verschiebt.

 

 

Geschrieben vom Handy aus!

 

Kurze Einleitung/Erklärung für xDrip+ und Nightscout, sowie allgemein paar Einstellungen für xDrip

In xDrip kann man sehr, sehr viel einstellen.

In Verbindung mit Nightscout, vor allem mit https://ns.10be.de/ schreibe ich kurz paar Einstellungen auf, die man setzten/deaktivieren sollte.

Je nach Transmitter und Handy, können die Einstellungen aber abweichen!

 

Ein paar Videos dazu zum „starten“, gibts z.b. hier:

 

Wenn der Transmitter verbunden ist, kann man über „Menü“, „Sensor starten“ einen Sensor starten.

Nach jedem SensorWechsel, sollte man über „stop Sensor“ diesen auch „stoppen“, damit die Kalibrierung resettet wird, sonst kann es vor allem beim Libre falsche Werte ergeben!

 

Wichtig, bei dem Libre, muss der Sensor schon mit dem Lesegerät/Handy gestartet worden sein. Am besten erst mit dem Lesegerät aktivieren und dann mit dem Handy mit der offiziellen App scannen, dann kann man die offiziellen Geräte auch verwenden.

Beim Sensor start, einfach der Anleitung auf dem Bildschirm folgen 🙂

 

MiaoMiao

Bei den Einstellungen unter erweitere Einstellung bei „BluetoothEinstellungen„, sollte beim MiaoMiao alles außer folgend Punkte deaktiviert sein:

Schalte Bluetooth ein

Use scanning

Always discover services

Sollten diese Punkte nicht da sein, installiere bitte eine aktuellere (Nightly) Version:

https://github.com/NightscoutFoundation/xDrip/releases

 

 

Warnungen

Unter dem Menüpunkt „Warnungen“, kann man ganz viele Warnungen für unterschiedliche Zeiten und Typen einstellen.

Da muss man einfach austesten. Ich habe z.B. mittlerweile nur noch 2 Warnungen für „niedrig“ drin und nur für Hoch über 400 mit einer hohen snooze-Time, das die Alarme (abgesehen von <60) nicht alle 5 Minuten kommt.

 

Unter dem Menüpunkt Einstellungen, Vorhersageeinstellungen kann man seine ISF (Korrekturfaktor), CR (Kohlenhydrate-Faktor) eintragen und dann unter „Unterzucker-Vorhersagewerte„, den DIA vom Insulin und Ziel-Wert eingeben.

Bei den Warnungen, „Weitere Warnungen“ kann man dann „Niedrige Werte vorhersage“ aktivieren und sagen, das er z.B. wenn er abschätzen kann, das man in xx Minuten unter den eingetragenen Zielwert beiȠ“Vorhersage“ kommt, das er dann auch Alarm gibt.

Ebenso habe ich dort aktiviert, das bei „hoch“, er erst ab 300 Minuten dauerhaft hoch alle 60 Minuten sich melden soll. Da das Fiasp bei mir „normal schnell“ wirkt und ich nach 1h weiteren Stunde nach dem korrigieren keine Änderung sehe, kann ich noch mal vorsichtig korrigieren oder stärker, wenn ich später gegen essen kann.

 

Nightscout

Unter Einstellungen, Cloud-Upload, API-Rest-Upload kann man bei der Basis-URL die Nightscout URL im Format:

httpS://dein-api-passwort@dein-server.ns.10be.de:xxxx/api/v1/

eintragen.

Dann sollte man noch die Option „Download Datadeaktivieren und unter „Extra Options„,  „Upload Treatments“ deaktivieren, wenn man AAPS nutzt.

Hier ist es auch wichtig, die Checkbox bei „automatic Calibration“ zu deaktivieren!

Wenn das Häkchen bei „automatic calibration“ gesetzt ist, einmal kurz „Download data“ aktivieren, dann die Checkbox bei „automatic calibration“ raus nehmen und „Download data“ wieder deaktivieren, ansonsten bekommt man die Treatments (IE/KH) doppelt in Nightscout rein.

Wenn man NUR xDrip benutzt, kann man „Upload Treatments“ aktiviert lassen, damit die IE/KH auch hoch geladen werden.

Die Option „Alert on failures“ sollte man auch deaktivieren, ansonsten bekommt man alle 5 Minuten ein Alarm, wenn das wlan/Netz zu schlecht ist oder der Server gerade nicht erreichbar ist.

 

Automatic Calibration muss die Checkbox raus sein, wenn man Follower ist oder AndroidAPS nutzt!

 

 

 

InterApp-Settings (Broadcast)

Wenn man loopt und die Daten sollen an z.B. AndroidAPS weitergegeben werden, muss man in xDrip in den Einstellungen, Inter-App Einstellungen das Broadcasting noch aktivieren:

Damit die Werte gleich sind, sollte man „Sende den angezeigten Glukosewert“ aktivieren.

Bei identifiziere Empfänger muss (alles klein geschrieben) folgendes noch rein:

info.nightscout.androidaps

 

Wenn man dann noch „Behandlungen annehmen“ aktiviert hat und in AAPS auch das Broadcasting, dann bekommt xDrip die IE/KH/BR auch wieder zurück und kann damit die UZ-Vorhersage usw. genauer abschätzten.

 

Allerdings sollte man, wenn man AAPS benutzt, unbedingt bei xDrip „Upload Treatments“ deaktivieren, sonst hat man die Einträge doppelt in Nightscout.

 

Artikelserie: Closed Loop; 5. AndroidAPS konfigurieren

5. AndroidAPS konfigurieren

Also erst einmal müssen wir uns die App erstellen, damit wir diese überhaupt auf dem Handy installieren können.

Da gibt es mehrere Wege und auch Skripte. Ich hab einmal ein Video erstellt (nicht schimpfen, ist mein erstes dieser Art (Bildschirmaufnahme)), wo ich grob zeige, was man klicken und machen muss.

Wichtig. Je nach System und aktueller Version (dev/Master/xxx), kann es anders sein und das Video damit schon in ein paar Tagen oder Wochen nicht mehr so funktionieren.

Bitte dann selber googlen und im Wiki nach lesen oder in den jeweiligen Gruppen/Foren/Chats nachfragen.

 

Bitte verwende folgende Anleitung, da das Video zu alt und daher nicht mehr für die aktuelle Version gültig ist!

https://androidaps.readthedocs.io/en/latest/CROWDIN/de/Installing-AndroidAPS/Building-APK.html

zum Updaten, bitte folgende Anleitung nutzten:

https://androidaps.readthedocs.io/en/latest/CROWDIN/de/Installing-AndroidAPS/Update-to-new-version.html

 

 

Bei AAPS gibt es praktisch die gleichen Variablen wie bei OpenAPS,  da AAPS auf OpenAPS basiert.

Die wichtigsten haben wir ja bereits unter 2.2 kennen gelernt:

Artikelserie: Closed Loop; 2. Was braucht man (Hardware/Software/Faktoren)?

 

Ansonsten hier einmal die wichtigsten Variablen im Config-Builder durch. Die meisten zeigen dann in der blauen Menüleiste einen Tab an oder eben nicht, wenn man rechts bei dem Auge die Checkbox aktiviert/deaktiviert.

In der linken Seite kann man die Option auswählen oder aktivieren/deaktivieren.

 

Aufbau:

Erst Bild-Nummer und ob es das linke oder rechte Bild ist (evtl. packe ich die Zahlen noch direkt mit ins Bild… später…)

Dann die Bilder, dann die Beschreibung zu den Punkten.

 

1. links, 2. rechts

android aps config builderaaps config builder insulin

 

1. Profil (Basal, IC, ISF…):

Beim Config-Builder, kann man als erstes das Profil auswählen (Bild 1, links).

Hier wird aktuell empfohlen ein locales  (Lokales Profil) zu nehmen. Da gibt man dann seine BasalRate usw. direkt in AAPS ein.

Da ich meine Profile in Nightscout verwalte und anpasse, nutze ich das Nightscout-Profil. Hierbei gibt man seine BasalRate usw. in Nightscout ein.

 

2. Insulin Profil (Wirkkurve):

Beim zweiten Punk (Bild 2, rechts) kann man das Insulin Profil auswählen.

Ich verwende hier z.B. „Free-Peak Oref„, da kann man den Zeitpunkt der maximal Wirkung vom Fiasp angeben (bei mir 50 Minuten), default ist 75.

Dieses Profil bildet auch die Wirkkurve vom Fiasp besser ab, da es zwar auch 5-6 Stunden wirkt, aber nach 3 Stunden die Wirkung nur noch sehr gering, aber immer noch Insulin vorhanden ist (auch wenn es dann z.b. nur noch 0,5ie sind).

„Rapid-Acting Oref“ ist für Humalog und Novorapid (die schnellen Insuline).

„Ultra-Rapid Oref“ ist für Fiasp. Allerdings ist die Abildung da nicht ganz so gut.

Weitere Infos zu den Wirkprofilen gibts auch unter http://openaps.readthedocs.io/en/latest/docs/While You Wait For Gear/understanding-insulin-on-board-calculations.html

 

 

————————————

3. links, 4. rechts

aaps config builder bz quellenaaps config builder pumpe

 

3. BZ-Quellen (woher kommt der aktuelle Wert):

Bei den BZ-Quellen, kann man auswählen woher die Werte kommen.

Die meisten werden hier „xDrip“ nehmen, da xDrip die meisten cgms/bz-Quellen auslesen kann und entsprechende Alarme usw. hat und einfach wie aaps, einfach toll und super ist!

Ansonsten kann man die Werte auch online von Nightscout herunter laden lassen oder über Glimp oder einer gepatchten Dexcom G5 App verwenden.

 

4. Pumpe

Wenn man eine Dana-Pumpe hat, kann man hier das entsprechende Model auswählen, damit die richtigen Treiber geladen und verwendet werden.

Wer noch keine Dana R oder RS Pumpe hat, kann hier z.B. für OpenLoop die Virtuelle Pumpe oder ICT auswählen.

 

 

————————————

5. links, 6. rechts

aaps config builder sensitivitätaaps config builder aps ama ma meal assittent

5. Empfindlichkeitserkennung

Bei dieser Option kann ich gerade die Details nicht so wirklich erklären.

Aber die Option „Durchschnittliche Sensitivität“ klappt bei mir mit Fiasp sehr gut. Bei Humalog war die „Sensitivität Oref0“ besser.

 

6. APS

Die APS-Option ist in diesem Fall „Meal Assits (MA)“ und „Advanced Meal Assits (AMA)“.

Der MA reagiert nicht so stark nach der Eingabe von KH und IE (Essen) und ist meist bei sehr ungenauen Angaben besser.

Der AMA kann deutlich früher reagieren. Sprich wenn ich spritze und mein BZ geht aber schon runter, dann stellt er das Basal aus oder gibt schon mehr, wenn der BZ zu schnell nach oben geht. Da ist eine höhere Genauigkeit der KH gut. Also wenn man sich zu sehr verschätzt, muss man unter Umständen manuell eingreifen.

Da muss man auch einmal einige Zeit beide testen und sich in Nightscout/Careportal markieren, was man gegessen hat und kann dann so gut Vergleichen, welcher besser für einen passt.

 

 

 

————————————

7. links, 8. rechts

aaps config builder looopaaps config builder zielsetzungen (objectives)

 

7. Loop

Hier kann man allgemein aktivieren/deaktivieren, ob der Loop-Modus aktiv sein soll.

 

8. Beschränkungen

Diese braucht man nur am Anfang um das Lernprogramm (Objectives) durchzuführen.

Dazu ist auch Nightscout nötig. Eine kostenlose Instanz kann man sich z.b. auf https://ns.10be.de/de/ holen und dafür verwenden.

Die einzelnen Objectives/Zielsetzungen muss man dann nacheinander durch führen. Dazu fängt es z.B. an, das man erst einmal die Parameter setzt (kommt im nächsten Artikel) und dann im openloop startet um zu verstehen, wie das System überhaupt arbeitet.

 

 

————————————

9. links, 10. rechts

aaps config builder behandlungenaaps config builder der rest

9. Behandlungen

Dort werden die Eingaben, welche man gemacht hat angezeigt.

Z.B. Wenn man den Katheter vor gefüllt oder ein Bolus abgegeben hat.

 

10. Der Rest.

Hier kann man einstellen, ob z.B. der aktions-Tab (TBR setzten, Profilwechseln, Vorfüllen) angezeigt werden soll.

Das Careportal, wo man Daten eintragen kann, die dann in Nightscout hoch geladen werden. Z.B. Insulin Reservoir-Wechsel, Sport etc.

Sms-Kommukation, ob man AAPS über sms bedienen darf.

Bei Essen, wird die Food-Tabelle von Nightscout angezeigt. Wenn man dort allerdings nichts eingetragen hat, ist diese auch in aaps leer.

Die Option Wear zeigt dann im Tab die Möglichkeit an, die ganzen Daten noch mal an die Uhr zu senden, wenn diese z.B. keine aktuellen Werte anzeigt oder das Watchface nicht aktualisiert hat. Ebenso kann man vom Handy aus die das Einstellungs-Menü auf der Uhr öffnen lassen.

xDrip-Statuszeile kann man aktivieren, wenn man z.B. kein AAPS Watchface, sondern ein xDrip-Watchface verwendet. Dann kann xDrip in der weißen Statuszeile, wo auch der Batteriestand, wie alt der angezeigt Wert ist usw. auch den Status von AAPS anzeigen soll. Dabei wird einmal der aktuelle %-Satz/IE angezeigt, wenn aaps gerade mehr oder weniger Insulin gibt, sowie wie viel IOB, BR usw. aktiv sind.

Laufende Benachrichtigung sorgt dafür, das z.B. auf dem Sperrbildschirm oder oben in der Taskleiste vom Handy den aktuellen Wert und Status anzeigt.

Nightscout-Client zeigt einen Tab an, wo man die Logfile vom nightscout-Client sieht und die Queue usw. Also wenn z.B. das wlan nicht ging und man kein Netz hatte, kann man dort sehen, das „xxx hundert“ Einträge in der Queue sind. Das kann auch auf ein Problem bei Nightscout oder falsche URL/Api-Key hindeuten.

 

Die Loop-Parameter erläutere ich dann im nächsten Artikel.

 

 

Vorheriger Artikel:  4. Installation/Nutzung von Nightscout          |             Übersicht Artikelserie          |             6. AAPS und SafetyParamter (erweiterte Einstellungen)

Artikelserie: Closed Loop; 4. Installation/Nutzung von Nightscout

4. Installation/Nutzung von Nightscout

Auf die komplette Installation von Nightscout, gehe ich hier jetzt nicht näher ein.

Dafür kann man folgende Anleitungen nutzten, die man auch einmal lesen sollte:

http://www.nightscout.info/wiki/welcome

https://nightscout.gitbooks.io/user_guide/content/de/

Oder man nutzt den Dienst von https://ns.10be.de/de/ wo ich ein Dienst (shared) gebaut habe.

Das importieren von existierenden Nightscout-Server kann allerdings bei kaputten Profilen zu Problemen führen.

Ebenso ist die automatische Integration von autotune noch nicht fertig.

 

Also zurück zu Nightscout.

Eigentlich sprechen wir hier über Nightscout’s „cgm-remote-monitoring“, was ein in JavaScript geschriebener Server ist. Die Dateien werden daher per node.js ausgeführt, was die Serverseitige Ausführung von JavaScript ermöglicht.

Wenn man das erste mal auf seine Nightscout-Seite geht, wird man zu /profile weitergeleitet, wo man die ganzen Faktoren wie ISF, IC, BR-Rate usw. eingeben kann.

Wenn man sich noch nicht eingeloggt hat mit seinem API-Passwort, muss man dies erst einmal tun:

 

 

Danach kan man dann die Werte und  Einstellungen speichern.

Sobald man dann in xDrip, Glimp, LibreAlarm, OpenAPS etc. die URL und den API-Key/Token eingegeben hat und die Werte hoch geladen wurden, erscheinen diese auf der Startseite:

 

 

 

Man kann in Nightscout dann sehr viel einstellen. Was angezeigt werden soll oder ob es Alarm schlägt, wenn ein Wert zu hoch/niedrig ist.

 

 

 

Ebenso kann man für seine Werte die bei den anderen Programmen auch, sich die Perzentile-Auswertung (AGP):

 

 

 

 

 

Oder auch für die Tage insgesamt:

 

 

 

 

 

 

 

 

 

 

 

Oder auch nur allgemein die einzelnen Tage:

 

 

 

Es gibt noch mehr, das kann man aber selbst austesten 🙂

Für z.B. später mit AndroidAPS zu loopen, braucht man Nightscout, damit man das Lernprogramm absolvieren kann.

 

Dann gibt es z.B. noch das Autotune, welches versucht anhand der Nightscout-Daten und seinem Profil (muss man aktuell noch manuell erstellen), zu prüfen und zu ermitteln, ob die Faktoren und BasalRate noch korrekt ist:

Eine Erklärung dazu, wie die Werte zu interpretieren sind, ist hier erklärt (leider englisch):

https://openaps.readthedocs.io/en/2017-07-13/docs/walkthrough/phase-4/understanding-autotune.html

 

 

 

 

 

 

 

 

 

 

 

Nightscout ist echt super. Man kann auch einzelne Tokens erstellen, das man z.B. den kompletten Zugriff „verbietet“ und bestimmte Token bestimmte Berechtigungen haben (ReadOnly für  den Doc, CarePortal für z.B. die App 1 oder Admin-Token für App2).

 

 

Danach trägt man dann in xDrip, AndroidAPS, Glimp oder der entsprechenden App einfach https://api-token@deine-url.tld:port/api/v1/ ein, bzw. nur https://deine-url.tld:port/ je nach App.

 

 

Vorheriger Artikel:  3. Wie ermittel ich die benötigten Faktoren?          |             Übersicht Artikelserie          |             5. AndroidAPS konfigurieren (Config-Cuilder)