Artikelserie: Closed Loop

In dieser Serie von Artikel, möchte ich erklären, was ein Closed Loop System überhaupt ist, was man sich darunter vorstellen kann, was es braucht, was es kann, was es nicht kann und was für Variablen man ermitteln muss.

Es handelt sich hierbei um ein Do It Yourself (DIY) ClosedLoop, von daher ist jeder selbst für die Konfiguration, Einstellungen, Fehler usw. verantwortlich.

nightscout ansicht

Ich übernehme keine Haftung für falsche Handhabung! Falls du dir nicht sicher bist, frage in den jeweiligen Chats, Gruppen, Foren nach oder schau in der/das Doku/Wiki rein!

 

 

Wenn man nicht die benötigten Faktoren ermitteln möchten (wie ein Basalraten Test, mehrere…), dann bitte nicht weiter lesen und hier abbrechen!

Wenn man sich damit beschäftigen möchte und bereit ist, praktisch 3 Wochen lang jeden Tag ein Basalraten Test zu machen und weiß was ein cgm/fgm ist, wo der Unterschied zwischen dem GZ und BZ ist, dann herzlich willkommen 🙂

 

Inhaltsverzeichnis:

  1. Was ist ein Closed Loop, was versteht man darunter und was macht es?

  2. Was braucht man (Hardware/Software/Faktoren)?

  3. Wie ermittle ich die benötigten Faktoren?

  4. Installation/Nutzung von Nightscout

  5. AAPS konfigurieren

  6. APS und Safety Parameter

  7. Lernvorgang starten und verifizieren der Parameter

  8. Optimierungsmöglichkeiten (Autotune)

 

Sobald die einzelnen Punkte fertig geschrieben sind, werden diese hier dann verlinkt.

Ein Zeitplan dafür gibt es nicht. Also einfach auf Twitter, FB usw. mal schauen, ob es was neues gibt 🙂

 

Und auch alle externen Quellen:

Linkliste:

kommt bald

CarbCam – Kohlenhydrate direkt in den AAPS 3.4.x.x und iAPS Bolus-Wizard übernehmen

Kohlenhydrate aus CarbCam direkt in den AAPS 3.4.x.x/aaps4/iAPS Bolus-Wizard übernehmen

Stand: AAPS 3.4.2.2 branch. AAPS 4 (DEV), iAPS


Worum geht’s

Wer Kohlenhydrate per Foto schätzt (CarbCam) oder aus einer Lebensmittel-Datenbank zieht, muss den Wert bisher abtippen oder über Nightscout-Treatments umweglos hineinpumpen. Beides ist umständlich. Der hier beschriebene Patch fügt AAPS einen kleinen, definierten Eingang hinzu:

Eine andere App wie z.b. CarbCam sendet einen Android Intent an AAPS mit Aktion info.nightscout.androidaps.action.OPEN_BOLUS_WIZARD und einem Carbs-Wert. AAPS öffnet daraufhin denselben Bolus-Wizard wie bei manueller Eingabe, mit dem Carbs-Feld bereits ausgefüllt. Der Benutzer prüft, drückt OK, sieht den Standard-AAPS-Bestätigungsdialog und gibt den Bolus frei. Es gibt keine Möglichkeit, Insulin ohne Bestätigung abzugeben.

CarbCam (de.be10.carbcam)
    │
    │  Intent: OPEN_BOLUS_WIZARD
    │  extras: carbs=42, notes="Pizza Margherita"
    ▼
WizardLaunchActivity (exported, Caller-Whitelist)
    │
    │  prüft: callingPackage, Range 1–80
    │  leitet weiter: open_wizard_carbs, open_wizard_notes
    ▼
MainActivity (singleTask)
    │
    │  liest Extras, zeigt WizardDialog
    ▼
WizardDialog (Standard-Bolus-Wizard, vorbefüllt)
    │
    │  Benutzer bestätigt
    ▼
AAPS-Standard-Bestätigungsdialog → Bolus

Sicherheits-Design

Vier Schichten, alle aktiv:

  1. Whitelist — Nur explizit erlaubte Caller-Packages (z.B. de.be10.carbcam) können den Wizard öffnen. Andere Apps werden vom Launcher kommentarlos abgewiesen.
  2. Range-Check — Carbs außerhalb 1–80 g werden verworfen. Wer mehr braucht, hebt den Wert anschließend im Wizard manuell an.
  3. Kein automatischer Bolus — Der Patch öffnet nur den Wizard. Der Benutzer durchläuft denselben Bestätigungsflow wie bei manueller Eingabe.
  4. Source-Anzeige — Der source-Parameter erscheint im Wizard-Notes-Feld („via CarbCam“), wird aber nicht als Vertrauensbeweis gewertet.

Voraussetzungen

  • AAPS 3.4.2.2 branch, lokal oder GitHub geklont und mit Android Studio oder BrowserBuild baubar
  • Kotlin/Android Grundkenntnisse (vi reicht zum Editieren)

WICHTIG! Falls du eigene Anpassungen in AAPS gemacht hast, können die Zeilennummer anders sein.

 

Patchfiles für iaps (ungetestet), AndroidAPS 3.4.2.2 und AAPS DEV 4:

https://github.com/zehnBE/aaps3.4.2.2-carbcam-patches/blob/main/README.md

 

 

Patch — 5 Änderungen

1. Neue Datei anlegen

Datei: app/src/main/kotlin/app/aaps/activities/WizardLaunchActivity.kt

mit folgendem Inhalt:

package app.aaps.activities

import android.content.Intent
import android.os.Bundle
import app.aaps.MainActivity
import app.aaps.plugins.configuration.activities.DaggerAppCompatActivityWithResult

class WizardLaunchActivity : DaggerAppCompatActivityWithResult() {

    companion object {
        const val EXTRA_CARBS = "carbs"
        const val EXTRA_NOTES = "notes"
        const val EXTRA_SOURCE = "source"

        // Whitelist: nur CarbCam darf den Wizard externe öffnen
        private val ALLOWED_CALLERS = setOf(
            "de.be10.carbcam",
            "de.be10.carbcam.debug"
        )
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        val caller = callingPackage ?: referrer?.host
        if (caller !in ALLOWED_CALLERS) {
            finish()
            return
        }

        val carbs = intent.getIntExtra(EXTRA_CARBS, 0)
        val notes = intent.getStringExtra(EXTRA_NOTES) ?: ""

        if (carbs <= 0 || carbs > 80) {
            finish()
            return
        }

        startActivity(Intent(this, MainActivity::class.java).apply {
            addFlags(Intent.FLAG_ACTIVITY_REORDER_TO_FRONT or Intent.FLAG_ACTIVITY_SINGLE_TOP)
            putExtra("open_wizard_carbs", carbs)
            putExtra("open_wizard_notes", notes)
        })
        finish()
    }
}

 

 

2. AndroidManifest.xml ergänzen

Datei: app/src/main/AndroidManifest.xml

Innerhalb des <application>-Blocks, neben den anderen Activities:

<activity
    android:name="app.aaps.activities.WizardLaunchActivity"
    android:exported="true"
    android:excludeFromRecents="true"
    android:launchMode="singleInstance"
    android:theme="@style/AppTheme.NoActionBar">
    <intent-filter>
        <action android:name="info.nightscout.androidaps.action.OPEN_BOLUS_WIZARD" />
        <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

exported="true" ist nötig, weil eine andere App die Activity ansprechen können muss. excludeFromRecents und singleInstance sorgen dafür, dass die Launcher-Activity im Recents-Switcher nicht auftaucht und keine eigene Task-History anlegt.

 

3. Dagger-Registrierung

Datei: app/src/main/kotlin/app/aaps/di/ActivitiesModule.kt

Import ergänzen:

import app.aaps.activities.WizardLaunchActivity

Innerhalb der ActivitiesModule-Klasse eine Zeile dazu:

@ContributesAndroidInjector
abstract fun contributesWizardLaunchActivity(): WizardLaunchActivity

Ohne diesen Eintrag bekommt die Activity beim Start IllegalArgumentException: No injector factory bound for Class.

 

4. MainActivity erweitern

Datei: app/src/main/kotlin/app/aaps/MainActivity.kt

Am Ende von onCreate() einfügen:

handleExternalWizardIntent(intent)

Neue Override und private Methode in derselben Klasse ergänzen:

override fun onNewIntent(intent: Intent) {
    super.onNewIntent(intent)
    setIntent(intent)
    handleExternalWizardIntent(intent)
}

private fun handleExternalWizardIntent(intent: Intent?) {
    val carbs = intent?.getIntExtra("open_wizard_carbs", 0) ?: 0
    if (carbs <= 0) return

    val notes = intent.getStringExtra("open_wizard_notes") ?: ""

    // Extras "verbrauchen", damit sie beim nächsten Lifecycle nicht erneut feuern
    intent.removeExtra("open_wizard_carbs")
    intent.removeExtra("open_wizard_notes")

    val wizard = app.aaps.ui.dialogs.WizardDialog()
    wizard.arguments = Bundle().apply {
        putDouble("carbs_input", carbs.toDouble())
        putString("notes_input", notes)
    }
    wizard.show(supportFragmentManager, "WizardDialog")
}

Den vollqualifizierten Pfad app.aaps.ui.dialogs.WizardDialog nicht durch app.aaps.plugins.main.dialogs.WizardDialog ersetzen — der WizardDialog im aktuellen dev-Branch liegt im Modul :ui, nicht in :plugins:main.

 

5. WizardDialog argumentfähig machen (optional)

Datei: ui/src/main/kotlin/app/aaps/ui/dialogs/WizardDialog.kt

Wenn der Wizard die Carbs aus den arguments lesen soll (sonst öffnet er sich leer), in onViewCreated den Aufruf binding.carbsInput.setParams(...) ergänzen:

val initialCarbs = savedInstanceState?.getDouble("carbs_input")
    ?: arguments?.getDouble("carbs_input", 0.0)?.takeIf { it > 0.0 }
    ?: 0.0

binding.carbsInput.setParams(
    initialCarbs,
    0.0,
    maxCarbs.toDouble(),
    1.0,
    DecimalFormat("0"),
    false,
    binding.okcancel.ok,
    textWatcher
)

 

 

Alternativ per patch file:

Eine PatchFile um aaps3.4.2.2, AndroidAPS4 (dev) und Iphone iAPS für CarbCam kompatible zu machen gibt es hier:

https://github.com/zehnBE/aaps3.4.2.2-carbcam-patches/

Anzuwenden mit:

git am pfad/zur/datei\0001-xxxxxxxxxx.patch

 

Bauen

Wie sonst auch, die App AndroidAPS bauen und auf dem Handy aktualisieren.
Dann kannst du per CarbCam die ermittelten Kohlenhydrate an AAPS an den Boluzwizard senden lassen, spritzen und danach in CarbCam die Daten speichern.

Den AAPS-Package-Namen an die jeweilige Variante anpassen — Stock-info.nightscout.androidaps, .full, .pumpcontrol oder der individuelle Build mit eigener applicationId.

 

 

[UPDATE]

Im Repro sind auch die Patchfiles für iPhone Loop, iAPS (da übernimmt es auch fett, eiweiss usw.), trio….:

 

aaps3.4.2.2-carbcam-patches

To Patch aaps3.4.2.2 that it allowed external carbs directly in BolusWizard from CarbCam: https://CarbCam.app

Details: https://zehn.be/2026/06/01/carbcam-kohlenhydrate-direkt-in-den-aaps-bolus-wizard-uebernehmen

iphone iAPS Patches:

To Patch iAPS that it allowed external carbs directly in BolusWizard from CarbCam: https://github.com/zehnBE/aaps3.4.2.2-carbcam-patches/blob/main/0001-iaps-carbcam-integration.patch

iphone Loop Patches:

To Patch iphone Loop to allow carbs directly from CarbCam.app: https://github.com/zehnBE/aaps3.4.2.2-carbcam-patches/blob/main/0001-loop-carbcam-integration.patch

iphone trio Patches:

To Patch trio that it allowed eternal carbs directly into Boluswizard from CarbCam.app: https://github.com/zehnBE/aaps3.4.2.2-carbcam-patches/blob/main/0001-trio-carbcam-integration.patch

AAPS 4 (DEV) Stand 7734facd Milos Kozak m.kozak@sysop.cz on 01.06.2026 at 23:02

https://github.com/zehnBE/aaps3.4.2.2-carbcam-patches/blob/main/0001-aaps-v4-carbcam-integration.patch

 

aktuelles Diabetes Setup (Libre3, Omnipod) und Wegovy

Seit einigen Jahren bin ich nun auf dem Omnipod mit dem Libre3 unterwegs und mit dem Dash läuft es von der technischen Seite her eigentlich richtig gut (Verbindung aaps etc).

Problem damals war, dass ich nicht zu viel Insulin auf einmal abgeben durfte, sonst war die Setzstelle gefühlt bis zum Ende des Pods kaputt und wirkte sehr schlecht.

Daher gab es oft bei vielen Kohlenhydraten immer Insulin per Einwegspritze dazu.

 

Vor ca. 3 Jahren ging aber mein Gewicht deutlich nach oben und stieg immer weiter, sowie dass ich morgens aufwachte und vor Hunger fast kotzen musste. Nach der Mahlzeit hielt es keine zwei Stunden an, dann hat mein Magen wieder vor Hunger gegrummelt als ob ich zwei Tage lang nichts gegessen hätte.

Die Ernährung im Vergleich zu früher war ja schon ausgewogener und vor allem viel Gesünder (ja, deutlich, deutlich, deutlich gesünder und besser), trotzdem stieg das Gewicht und das krasse Hungergefühl immer weiter.

Daher hab ich dann mit meiner Ärztin es besprochen und den Griff zur Spritze gewagt. Krass:

Gewicht 2021 bis 2026 (ohne Klamotten und Durchschnitt)

Man sieht, wie das Gewicht gefallen ist, da einfach der Hunger weg war und man morgens ohne Übelkeit vor Hunger aufgewacht ist.

Die Spritze hab ich am Anfang noch wöchentlich genommen, aber dann gewartet bis der Hunger wieder kam. So hab ich sie nur alle 2-3 Wochen genommen. Jetzt ist der Abstand ähnlich aber mit niedrigerer Dosis.

 

Aktuell nehme ich daher nur 8 Klicks jede Woche, dass es „stabil“ im Körper ist.

 

Allerdings gibt es auch einen Nachteil, meine Muskeln sind weg. Früher war ich stark wie ein Bär und jetzt nur noch wie ein Hase 😉

Hier sieht es ja noch gut aus, aber das täuscht:

 

 

Muskelanteil in Prozent
Muskelanteil in Prozent

 

Weil die Muskelmasse selbst ist auch drastisch gesunken wie das Fett:

 

Aber nun ja, daran muss man jetzt arbeiten und deutlich mehr Muskeln wieder aufbauen, was nicht wirklich klappt, wenn einem der der Nightscout Server Dienst in Atem und ohne Schlaf wach hält.

Schlaf
wenig Energie
normale Energie

 

Nun ist aber endlich, endlich alles durch, bis auf ein paar Fehler hier und dort, die aber immer wieder Aufmerksamkeit wollen, läuft es nun extrem schnell und gut. Ich bin da schon richtig stolz drauf, auch wenn es mit viel Hilfe war und extrem anstrengende Monate waren.

 

Zurück zum Thema, Abnehmspritze

Seit das Gewicht weg ist, ist mein „schwerer“ DiabeTIS 😉 wirklich schwerer einzustellen, da das Insulin besser wirkt. Früher konnte ich x Einheiten spritzen und wusste, wenn der Loop abstellt, dann passt das zu 95%. Jetzt heißt es: der Loop ist schon seit einer Stunde aus und noch xIOB -> Zucker nehmen.

Oder so Sachen, dass er normal ist und man vor dem Spazierengehen TempTarget nach oben (sport) gesetzt hat, wusste ich, ich brauch sehr wahrscheinlich kein Zucker. Jetzt heißt es TT früh setzen und Zucker mitnehmen 🙁

Das Blöde ist auch, dass es mit der Unregelmäßigkeit der Spritze nicht einfacher macht, da vom Gefühl her immer ein paar Tage nach dem Spritzen ich wieder empfindlicher bin und dann eine Woche später wieder statt 75% eher 85% bräuchte.

Daher nun auch stabil jede Woche 8 Klicks.

 

Das war auch ein weiterer Grund die App CarbCam zu bauen, damit ich besser kcal, KH usw. sehe und diese besser tracken und in Verbindung mit Nightscout auch überprüfen ob mein Bolus Insulin korrekt war.

 

Das andere ist, dass mir der Pod seit ein paar Monaten extrem schmerzt und ich blaue Flecke und Blutergüsse danach immer habe. Und das alles nur weil das Gewicht und die Muskeln weniger sind?

Dies war nun auch ein weiterer Grund sich mal das Medtrum-System anzuschauen und 30 Tage zu testen.

 

So, für dieses bisschen Text hat es fast zwei Monate gedauert 🙂

ns.10be.de — Ein neues Kapitel nach fast zwei Jahren Arbeit

ns.10be.de – One Click Nightscout Hosting

Ich schreibe diesen Post mit einem sehr guten Gefühl. Nicht weil alles perfekt ist — das wird es nie sein — sondern weil ich auf die letzten zwei Jahre zurückblicke und sehe, was entstanden ist.

 

Wie alles begann

Wer ns.10be.de kennt, weiß: Der Dienst läuft seit November 2017. Damals war die Idee einfach: anderen ermöglichen, Nightscout zu bekommen — ohne dass jeder selbst Serveradmin sein muss und ohne dass ich dabei viel manuell arbeiten muss. Was als kleines automatisiertes Projekt startete, wurde über die Jahre zu einer ernsthaften Infrastruktur mit Hunderten von Nutzern, mehreren Clustern, MongoDB-Servern, Proxy-Servern, Backup-Systemen und einer Menge Abenden vor dem Terminal.

Irgendwann war klar: Es muss komplett neu gebaut werden. Nicht weil es nicht lief — sondern weil der Code über die Jahre immer weiter gewachsen war, neue Funktionen wurden draufgestapelt, Updates blieben aus weil schlicht keine Zeit war, und irgendwann crashte es. Der Code war nicht mehr wartbar, zu viel war zusammengestückelt was eigentlich sauber hätte aufgebaut sein müssen. Es gab keine Alternative mehr — ein kompletter Neuaufbau war der einzige Weg nach vorne.

 

Fast zwei Jahre Arbeit im Hintergrund schon davor

Was die meisten Nutzer nicht sehen: Während alles lief wie gewohnt, wurde im Hintergrund schon viel früher praktisch alles neu aufgebaut. Neue Cluster. Neues OS. Neues Docker-Setup. Ein komplett neues Queuing-System das Befehle zuverlässig über einen eigenen Message-Queue-Server abarbeitet. Neue Proxy-Server auf HAProxy/TPROXY-Basis die das alte nginx-Setup ablösen.

Das klingt trocken — ist es aber nicht, wenn man nachts um 3 Uhr vor einem frisch abgestürzten Cluster sitzt und herausfindet, dass neue AMD-Hardware unter Last anders reagiert als erwartet. Oder wenn man merkt, dass RAM-Limits trotz korrekter Konfiguration nicht übernommen werden. Oder wenn ein unkontrolliert mehrfach laufender Verteilerprozess die gesamte neue Hardware in die Knie zwingt. Nach Tagen der Fehlersuche war die Lösung: Intel-Hardware, sauber konfiguriert, mit 10–20 % RAM-Reserve und vielen Anpassungen. Seitdem läuft alles stabil.

Parallel dazu: MongoDB Replica Set und PostgreSQL Replica aufgebaut — damit kein einzelner Datenbankausfall mehr zu Problemen führt. Zwei Proxy-Server in getrennten Rechenzentren mit automatischem Failover. 47 Tage Backup-Aufbewahrung statt der alten 28 Tage.

Und dann die Geschwindigkeit. Früher dauerte ein Deploy bis zu 15 Minuten für fünf Instanzen. Heute startet eine Nightscout-Instanz in unter 3 Sekunden. Ein Redeploy zum Version aktualisieren, in unter 5 Sekunden. Das ist das Ergebnis von monatelanger Arbeit an der Infrastruktur und dank der Nightscout- und DIY-Looper-Community möglich.

 

Die neue Webseite

Die Webseite hatte bereits eine solide Basis — aber das Design war über die Jahre zusammengestückelt und an vielen Stellen nicht mehr konsistent. Das wurde jetzt von Grund auf korrigiert und deutlich verbessert. Es gibt eine Erste-Schritte-Seite mit einer echten Schritt-für-Schritt-Anleitung, eine Tour-Seite die zeigt wie das Dashboard und die Konfiguration aussehen, eine Changelog-Seite mit allem was sich seit 2017 verändert hat, und eine überarbeitete FAQ.

Aber auch im Dashboard selbst hat sich viel getan: Man kann jetzt das eigene Abo direkt in NS10BE kündigen oder die Laufzeit wechseln — ohne Umweg über Stripe oder PayPal. Follower-Tokens sind per Klick erstellbar. Viele kleine Dinge die sich über die Zeit angesammelt haben und jetzt endlich sauber umgesetzt sind.

Fünf Sprachen — Deutsch, Englisch, Französisch, Spanisch und jetzt auch Polnisch. Darkmode, Schriftgrössenauswahl, Browser-Spracherkennung. Das klingt nach Details — aber genau diese Details machen den Unterschied für jemanden der spät abends versucht, Nightscout für sein Kind einzurichten.

 

Nocturne — die moderne Nightscout-Oberfläche

Ein weiteres Thema das viel Zeit gekostet hat: Nocturne. Die neue, modern entwickelte Nightscout-Oberfläche ist technisch eine andere Welt als das klassische Nightscout-UI — und entsprechend aufwändig war es, sie auf ns.10be.de zum Laufen zu bringen und ausgiebig zu testen. Es steckt einiges an Arbeit dahinter, das Ganze so zu integrieren dass es zuverlässig funktioniert und nicht mit dem Rest der Infrastruktur kollidiert.

Erste Entwickler können Nocturne auf ns.10be.de bereits nutzen. Wer als aktiver Nightscout-Entwickler testen möchte, soll sich gerne melden — allgemeine Verfügbarkeit folgt wenn alles ausreichend getestet und stabil ist.

Was als nächstes kommt

Der Hauptserver-Umzug ist vollzogen — und auch die Extra-Server für Medtrum, Libre, Diasend/Glooko und weitere sind neu installiert. Das war der Teil der mir am meisten Sorgen gemacht hat: rund 40 Server gleichzeitig neu installieren, im laufenden Betrieb. Im Test lief alles sauber — und zum Glück hat es auch in der Realität funktioniert. Immer wieder Ausfälle gab es, da die Erkennung von fehlerhaften Logins selbst fehlerhaft war :-). Dies ist aber nun alles gefixt.

Jetzt läuft alles auf dem neuen System. Was noch kommt, werden kleinere Verbesserungen und Feinschliff sein — und natürlich alles was die Community als nächstes braucht.

Ein persönliches Wort

ns.10be.de ist ein Projekt von jemandem der selbst betroffen ist und seit 2017 daran arbeitet, dass andere sich nicht um Technik kümmern müssen. Jede Verbesserung kommt aus echtem Feedback echter Nutzer. Jeder Fehler wird von mir persönlich behoben — meistens schneller als erwartet, weil ich direkt per Discord benachrichtigt werde.

Wenn ihr Fehler findet — bitte melden. Ich hab alles mehrfach getestet, aber vier Augen sehen mehr als zwei.

Danke an alle die seit 2017 dabei sind. 🙏

→ Screenshots & Tour ansehen

 

P.S. der Text wurde mit Hilfe von KI verbessert, ansonsten wäre der Blogpost viel, viel zu technisch und 10 Seiten lang geworden 🙂

Uptime und Traffic von ns.10be.de (managed nightscout service)

Uptime von ns.10be.de

In den letzten Tagen/Wochen, lief ns.10be.de sehr stabil.

Der Service von uptimerobot, welcher alle Server, die hinter ns.10be.de stehen überwacht, ob diese laufen und auch, ob auf den einzelnen Cluster eine Monitoring-Instanz, sowie die MongoDB-Dienste schnell genug antworten, hat für die letzten 90 Tage eine Uptime von:

99.974%

errechnet. Dabei sind die Probleme mit den Medtronic-Servern auch mit drin (seit dem 15.02.21 aber erst).
Vor ein paar Tagen, war z.B. der MongoDB-Server 2 down. Dank der Automatisierung, wurde diese aber automatisch vom System dann neu gestartet.
Eine Analyse hat ergeben, das dieser das swappen angefangen hat, da nach den Anpassungen der Config, ich vergessen hatte auf diesem die MongoDB-Datenbank-Server neu zu starten und somit die Anpassung noch nicht gegriffen hat.
Ebenso sind darin auch z.B. das Up-/Downgraden von Cluster/Proxy-Server enthalten. So lange mindestens noch ein Proxy-Server verfügbar ist, sind die Nightscout-Server erreichbar.

Detailtieres Monitoring:

Was noch fehlt, ist die Ermittlung, warum zwei Cluster manchmal eine stark erhöhte Load von > 100 haben für einige Minuten.
Ich denke, da wird evtl. jemand autotune oder ein export machen oder viele komplexe Queries senden. Zum Glück, konnte ich dies bisher nur bei zwei Clustern sehen.
Die Überwachung der Server erfolgt detaillierter über Munin:
Die Analyse, führen wir mit atop durch, welches alle 5 Minuten die Daten wie Ram-Auslastung, Prozesse mit der meisten CPU- oder RAM-Nutzung, speichert. So kann man dann feststellen, ob ein Systemprozess oder Dienst von 10be dafür verantwortlich ist, oder eine/mehrere Nightscout-Instanzen.

Requests, die bei 10be eingehen

Pro Sekunden gehen bei ns.10be.de ca. 120 Requests, verteilt auf drei Proxy-Server ein.

Durchschnittlich sind auf allen Proxy-Server zusammen 700.000 Verbindungen offen, welche z.B. durch xdrip, spike, androidaps, diabox usw. gemacht werden.

Das gute bei den JiffyBox-Servern von df.eu ist, das man sie sehr schnell vergrößern/verkleinern kann. Aktuell sind beim proxy2 z.B. viel mehr Requests eingegangen, als üblich und dadurch kam dieser an seine Grenzen.

Daher wird dieser nun in einen größeren Tarif gerade gewechselt und ist in paar Minuten wieder online mit mehr Ram und CPU-Power.

Aktuell stehen hinter ns.10be.de 43 Server und es soll bald noch ein Proxy-Server im asiatischen und amerikanischen Raum dazu kommen, um von dort den Verbindungsaufbau und die Geschwindigkeit dort zu erhöhen.

Traffic von ns.10be.de

Im Monat 04/2021, hatten die Server bei Provider 1 ein Traffic von:

23.768,920 GB

Bei Provider 2 kamen im April:

53.260,035 GB

 

Zusammen also grob:

77TB

Dies konnte reduziert werden, da bei einigen Punkten, wie z.B. MySQL-Queries, welche von den Cluster-Servern (Dienste von 10be), die prüfen ob sich Daten einer Instanz geändert haben (Server erstellt, editiert oder z.B. auf redeploy geklickt wurde), komprimiert gesendet werden.

Ebenso wurde durch die Stabilität, die Anzahl der Neuverbindungen und Abbrüche reduziert, was auch etwas Traffic spart.

Und im April haben praktisch keine Umzüge stattgefunden, wo von Server 1 auf Server 2, Daten kopiert werden, was auch wieder pro Umzug einige bis hunderte MB einspart.

 

 

Lyumjev VS. Fiasp und warum ich zu Fiasp zurück bin

Ich hatte nun 11 Tage das neue Insulin Lyumjev von Lilly drin.

Nach allerdings 11 Tagen, bin ich nun wieder zu Fiasp zurück, da mein Insulin Verbrauch von ca. 50ie pro Tag auf 70ie pro Tag gestiegen ist und es beim spritzen und die ganze Zeit „dumpf“ brennt.

Beim Fiasp, hatte ich ja das erste halbe Jahr bis ganze Jahr beim spritzen auch immer einen stechenden Schmerz/Brennen, aber das war nur kurz, tat zwar mehr weh als beim Lyumjev, aber war nur kurz.

Beim Lyumjev war es nicht so schmerzhaft, aber dafür dauerhaft und die Spritzstellen waren gehärtet (so einen kleinen Finger breit). Dazu tat es beim drauf kommen deutlich weh.

Ebenso musste ich die Faktoren anpassen und verbrauchte so mehr Insulin, aber blieb viel länger hoch.

 

Hier einmal der Vergleich:

 

 

 

 

 

 

 

Was ansonsten auffällt, ist das es nachts länger „flach“ ist als beim Fiasp (kann evtl. auch an mehr fpe von der vorherigen Woche liegen?):

 

 

 

 

 

 

Also mit Fiasp bin ich an sich, niedriger, aber Nachts, ist die „gleich-bleibe“-Phase kürzer.

 

Schneller, bzw. weniger kurze Peaks nach dem Essen, hat es mit dem Lyumjev  schon:

Ebenso sieht man, das wenn z.B. 2h Basal aus ist, der BZ dann schneller/stärker ansteigt.

Wenn der höhere Verbrauch, das lange hoch bleiben und brennen nicht wäre, würde es sich für mich die Optimierung/Anpassung der BR und Faktoren lohnen.

Aber alleine wegen dem dauerhaften brennen/schmerzen, die unangenehmer als bei Fiasp (waren) sind, bin ich wieder zurück.