CarbCam.app ist nun in vielen Sprachen verfügbar (nur noch nicht bei Apple/Ios/iphone)

Bei CarbCam hat sich vieles noch getan.

Man kann nun einstellen das z.B. Scans innerhalb von 30,60,120 Minuten nach gefragt werden soll ob es zur gleichen Mahlzeit gehört.

Damit wird „5“x Frühstück an einem Tag korrigiert 🙂

 

Viele Kleinigkeiten wurden optimiert, vor allem das Design wurde klarer und strukturierter:

CarbCam Design

 

 

Der Download von CarbCam ist für Android über:

https://play.google.com/store/apps/details?id=de.be10.carbcam

und Apple über:

https://apps.apple.com/app/10be-carbcam/id6761769250

möglich, sowie auch über die Webseite.

 

Bei Apple wartet die neue Version allerdings schon seit 9 Tagen oder so in „Waiting for Review“….

Man kann sich daher die Apple Version sonst auch noch als Testflight Version holen:

https://testflight.apple.com/join/xKH71gdv

 

Folgende Sprachen gibt es auch bei ns.10be.de und CarbCam nun:

Code Sprache
ar العربية
bg Български
cs Čeština
da Dansk
de Deutsch
el Ελληνικά
en English
es Español
fi Suomi
fr Français
he עברית
hi हिन्दी
hr Hrvatski
hu Magyar
id Bahasa Indonesia
it Italiano
ja 日本語
ko 한국어
nl Nederlands
no Norsk
pl Polski
pt Português
ro Română
ru Русский
sk Slovenčina
sl Slovenščina
sv Svenska
tr Türkçe
uk Українська
zh 中文

 

Bei Fragen oder Wünsche: bitte einfach schreiben!

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://ns.10be.de/blog/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

 

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.