Beiträge von dideldum

Mit Kulanz hat hier eine Sensor-Reklamation gar nichts zu tun.

Nach der Aktivierung des Sensors kannst du das Lesegerät auch ausschalten. Da lernt sich nichts in der Stunde Aufwärmzeit kennen.

Deine relevanten Kommunikationsinformationen werden beim NFC-Start ausgetauscht. Und das war's dann auch schon. Wie kommtmannur darauf, dass das Lesegerät oder das Starthandy während der Aufwärmzeit beim Sensor sein müsste? Das ist einfach Unsinn.

Sagt das Lesegerät etwas von defektem Sensor, dann wird der ersetzt.

Hubi Link umsetzen geht garantiert schneller als das von dir beschriebene Procedere. Und außerdem will ich ja letztendlich die neuere Version zum Laufen bekommen. Das heißt, ich muss die neuere Version verfügbar haben und dort im Verzeichnis arbeiten können. Dabei will ich aber gleichzeitig die alte Version haben, um sie entweder sogar in der Zeit laufen zu lassen oder zumindest schnell wieder zurückzuschalten, ohne meine Arbeit im aktuellen Verzeichnis zu verlieren. Das geht natürlich mit git, aber sehr viel umständlicher und zeitraubender als mit dem schnell geänderten Link.

Zitat von Schubi

Wozu die Links dideldum ? Man kann mit git checkout [Commit-ID] ja jederzeit zurück auf eine alte Version.

Und ja, das npm-Update ist von Zeit zu Zeit nötig.

Link umsetzen geht einfach ganz schnell und schon laufen meine beiden Instanzen wieder. Hatte schon mehrmals das Problem, dass Nightscout Updates sich nicht mit Libraries, der Mongo-Version oder irgendwelchen von npm install installierten Paket-Versionen vertrugen. Dann habe ich den Link erstmal schnell wieder zurückgebogen und hatte Zeit für die Problem-Analyse.

Zitat von Alsimera

. Es handelt sich hierbei also nicht um einen Fehler!!

Naja, also DER Aussage kann ich ja nun gar nicht folgen. Wenn ein Sensor absichtlich so programmiert ist, dass er seine Batterie schneller leer saugt, als das mit seinem vorgesehenen Leben vereinbar ist, dann IST das ein Fehler. Der Sensor muss seine 14 Tage durchhalten, egal was für ihn in Sachen Handy-Erreichbarkeit los ist. Und wenn das Handy 13 Tage 58 Stunden nicht in seiner Nähe ist, dann muss er in der letzten Stunde noch in der Lage sein, seine Werte zu übertragen. Alles andere IST ein Fehler!

Ich habe ja immer gern ein Fallback und mache bei Nightscout immer ein neues Verzeichnis, das ich dann verlinke. Wenn was nicht funktioniert, biege ich den Link wieder auf's alte Verzeichnis. Das sieht im Moment so bei mir aus:

lrwxrwxrwx  1 ubuntu ubuntu   26 Dez  9 16:20 cgm-remote-monitor -> cgm-remote-monitor.14.2.6/
drwxrwxr-x 17 ubuntu ubuntu 4096 Dez  9 16:20 cgm-remote-monitor.14.2.5
drwxrwxr-x 17 ubuntu ubuntu 4096 Dez  9 16:42 cgm-remote-monitor.14.2.6
-rwxrwxr--  1 ubuntu ubuntu 2069 Dez  9 17:11 ns_alina.sh
-rwxrwxr--  1 ubuntu ubuntu 2093 Dez  9 17:11 ns_ulf.sh

Mit anderen Worten: ich mache immer ein "git clone" im neuen Versions-Verzeichnis und setze dann den cgm-remote-monitor Link auf das neue Verzeichnis. Meine beiden Start-Skripte, die die Umgebung entsprechend setzen (ns_alina.sh und ns_ulf.sh) benutzen nur den Link. Wenn der Link wieder auf's alte Verzeichnis zurückgesetzt wird, läuft es also wie vorher im Problemfall.

Nach dem git clone war dann noch das npm install im neuen Versions-Verzeichnis notwendig (das müsste man nach einem update aber selbst im alten Verzeichnis ja wohl auch machen, oder?). Muss aber zugeben, ich mache es so selten, dass ich mich nicht mehr an alle Einzelheiten erinnere.

Die Kuh ist doch letztes Jahr schon durch's Dorf getrieben worden: Glucose Monitor per SmartWatch

Leute, euer Optimismus in allen Ehren, aber das eine chinesische 50$-Uhr nicht wirklich den Blutzucker messen kann, das müsste doch allen klar sein...

Zitat von July95

Hat irgendjemand vor der YpsoPump die Dana mit Insetkatheter und kann bestätigen, dass bei den Schläuchen nur die Verbindung zur Pumpe anders ist?

Oder anders gefragt wäre es möglich, dass ich erstmal meine Dana Inset Katheter mit der YpsoPump verwende, wenn ich ein paar YpsoPump Inset-Schläuche auftreiben könnte?

Hintergrund ich soll auf meine neue YpsoPump umsteigen, Pumpe ist auch vorhanden, aber die benötigten Katheter sind nicht lieferbar.

Ja, das kann ich bestätigen. Wir haben es zwar umgekehrt gemacht (Die Dana RS wieder an den gesetzten Ypsomed-Inset-Katheter angeschlossen), aber die Inset II der Dana und die Inset der Ypsomed haben am Kanülenstück den identischen Clip-Anschluss und sind auch identisch. Nur das Schlauchstück zur Pumpe hat ein unterschiedliches Ende.

Zitat von huetterei

dideldum : Sach mal, Du hast doch die DanaRS, oder?

Ja, wir haben 2mal die Dana RS, wollten aber auf CamAPS mit Ypsopump wechseln und haben das System natürlich auch mit Ypsopump getestet (die gehen jetzt aber wieder zurück und wir wechseln auf die Dana I zurück, da die beiden RS mittlerweile das Risiko haben, kaputt zu gehen (Riss in der einen, sehr dunkles Display in der anderen)).

Ich kann jetzt halt nur noch CamAPS (die Ypsopump-Version aus dem Google Playstore, nicht die Dana-Version!) mit virtueller Pumpe und virtuellem Sensor testen. Aber auch da kann man den Auto-Mode anschalten. Und da funktioniert im Auto-Mode einwandfrei das von mir beschriebene Szenario, das ich vorher im echten Betrieb mit der Ypsopump und Libre 3 eben auch getestet hatte:
1. Gib einen Essensbolus mit dem Besteck ab.

2. Geh danach wieder in das Besteck-Fenster zur Essensbolusabgabe und tippe auf den BZ. Gib im Dialog einen hohen BZ ein (z.B. 400mg/dl). Bestätige mit OK. Nun wird beim Blutzuckerwert eine Korrekturmenge Insulin angezeigt, unter dieser Menge in Klammern wird aber entweder dieser Wert mit Minus davor (falls die Korrekturmenge kleiner ist als der zuvor abgegebene Bolus) oder eben maximal der zuvor abgegebene Bolus angezeigt, so dass möglicherweise eine kleine Korrekturmenge effektiv übrig bliebt.

Was ich damit zeigen will, ist, dass CamAPS selbst die "aktive Insulinmenge" völlig falsch bewertet, denn der vorherige Bolus hat aufgrund seines Zusammenhangs zu den Kohlenhydraten nichts mit einer effektiven aktiven Insulinmenge zu tun, die allein jetzt für eine Senkung des BZ verantwortlich wäre.

Ausgangspunkt war für mich derPost #12 von Lilimaus, in dem das aktive Insulin zur Beurteilung der Hypobehandlung herangezogen wird. Alles was ich in Folge auf die absolut richtigen Kommentare von helmama, dass es in CamAPS nämlich keine gültige Angabe des IOB gibt, geschrieben habe, diente nur der Beweisführung, dass das in CamAPS angezeigte und verwendete aktive Insulin ausschließlich das Bolusinsulin ist und die Verwendung dieser Angabe nicht nur in CamAPS völlig falsch ist, sondern auch für die Beurteilung einer Hypo-Behandlung völlig unbrauchbar ist.

Leider wurde und wird dies von etlichen Personen hier nicht verstanden.

Zusammenfassend möchte ich hier nur noch einmal schreiben:

Um das aktive Insulin beurteilen zu können, muss man Korrekturinsulin (resultierend aus temporärer Basalrate oder verzögerten Boli oder SMBs in Bezug auf die ideale Basalrate), Essensinsulin und Kohlenhydrate im Zusammenhang sehen. Erst dann kann man das aus diesen drei Komponenten zusammengesetzte aktive Insulin wirklich zur Beurteilung einer Hypobehandlung heranziehen. Nur mit der Angabe in CamAPS geht das definitv nicht!

In AndroidAPS gibt es dafür mehrere Häkchen im Bolusrechner. Diese umfassen den aktuellen BZ, die BZ-Bewegung, das aktive Bolus-Insulin, die aktiven Kohlenhydrate und das vom Basal abweichende gegebene Korrektur-Insulin (das auch negativ sein kann, wenn eine Weile das Basal aus war).

Für eine sinnvolle Beurteilung, ob weiteres Korrekturinsulin nötig wäre, oder eben (und darum geht es hier ja eigentlich) Kohlenhydrate zuzuführen wären, sind alle Häkchen im Bolusrechner zu aktivieren. Dann zeigt einem AAPS im Bolusrechner z.B. an, ob 3gKH nachzuführen wären oder vielleicht 0,5IE zu bolen wären. DAS ist für die Hypobehandlung eine vollständige und sinnvolle Information. Die ist in CamAPS aber eben nicht zu haben.

(Nebenbemerkung: natürlich kann man im AAPS-Bolusrechner diese Häkchen auch anpassen. Das macht in gewissen Situationen sogar durchaus Sinn, es würde aber jetzt zu weit führen, hierzu weitere Erläuterungen zu geben. Leuten wie Leila kann ich da aber nur empfehlen, die AAPS-Dokumentation nochmal sehr sorgfältig zu lesen, denn offensichtlich hat sie Benutzung und Auswirkung dieser Häkchen nicht verstanden.)

Da aber offensichtlich meine Schilderungen für etliche Benutzer von CamAPS und sogar von AAPS nicht begreiflich sind, möchte ich an dieser Diskussion jetzt aber auch nicht weiter teilnehmen. Es ist jeder schließlich selbst für seinen Diabetes verantwortlich und wer glaubt, dass für ihn mit der Situation alles gut ist, der möge das einfach so weiter machen. Und damit schließe ich diesen Thread für mich endgültig ab.

Zitat von Leila

Exactly das gleiche Verhalten macht AAPS bei mir?

Nein, das tut es definitiv nicht.

Zitat von Frogchen

Weiterer Nachtrag:

Das, was ich an Änderung habe, wenn ich den BZ quasi bestätige im Besteck-Menü, das ist die Anpassung an meinen Glukose-Zielwert. Aber der hat nix mit dem aktiven Insulin zu tun…

Doch. Durch den hohen Blutzucker, den du da bestätigen oder eben auch ändern kannst, wird manuelles Korrektur -Insulin dazugegeben. Wenn du vorher einen Bolus abgegeben hast, zeigt er in Klammern einen negativen Wert an, der gleich dem Korrektur Bolus ist, jedoch maximal der vorher abgegebene Bolus. Bis zur vorher abgegebenen Bolushöhe lässt er also keine Korrektur zu. Und ignoriert dabei, dass dieser Bolus zu Kohlenhydraten gehört. Das ist einfach ein absolutes Fehlverhalten in der Bewertung des aktiven Insulins.

Jetzt habe ich es aber wirklich genug erklärt. Bei Nicht-Verstehen meine Beiträge bitte noch einmal lesen oder einfach ignorieren.

Zitat von Frogchen

Nachtrag: Zumal ich überhaupt nicht weiß, warum ich den BZ dort per Hand eingeben sollte.

Ich habe das beschrieben, um zu zeigen, dass CamAPS im Boluskalkulator etwas völlig Falsches tut, nämlich das aktive Bolusinsulin von vorher zu berücksichtigen, und zwar ohne Zusammenhang zu den vorherigen Kohlenhydraten. Das ist einfach grottenfalsch. Richtig wäre hier die Berücksichtigung des selbst von CamAPS abgegebenen Korrekturinsulins, das aber eben nirgendwo angezeigt wird. Was ich beschrieben habe, zeigt das Fehlverhalten von CamAPS und ist keine Handlungsanweisung!

Zitat von Frogchen

Ich habe die App gerade mit Pumpe laufen und habe es durchgespielt. Dort ändert sich nichts, solange der Automodus an ist. Der Bilus- Kalkulator ist im Auto Modus ausgeschaltet. Was anderes ist es, wenn der Automodus ausgeschaltet ist. Dann läuft der Modus Kalkulator. Wie der nun mit dem aktiven Insulin umgeht, weiß ich nicht, da bei mir der Automodus immer alles, außer ich dusche oder mache Ähnliches.

Ich habe CamAps jetzt nochmal installiert und laufe mit virtueller Pumpe und virtuellem Sensor im Auto-Modus.

Es funktioniert exakt so, wie ich beschrieben habe, auch im Auto-Modus.

Frogchen Ich kann es nicht mehr testen, weil es deinstalliert ist, Pumpe versandfertig weggepackt und im Moment wieder ein Libre2 am Arm ist.

Bin aber sicher, das im Automode wie von mir beschrieben durchgespielt zu haben.

Habe dazu übrigens den BZ im Bolusrechner entsprechend verändert, um zu sehen, ab wann er keine Menge in Klammern mehr erhöht. Und das war dann eben die gerade vorher gegebene Bolusmenge. Man muss dann halt testweise den BZ-wert deutlich höher setzen.

Zitat von Schaf

dideldum

CamAPS berücksichtigt doch bei Eingabe einer Mahlzeit den aktuellen Bz-Wert nicht, weil dieser doch durch das System selbst schon durch Insulingabe oder Stop berücksichtigt wurde.

Du kannst ihn aber dennoch im Bolusrechner mit einbeziehen, indem du auf den BZ tippst und mit OK bestätigst. Und dann siehst du die von mir geschilderte völlig falsche Verwendung des aktiven Bolusinsulins.

Zitat von Lilimaus

huetterei

Leider funktioniert bei mir die "Hypobehandlung" nicht wirklich.... ohne Insulin komme ich meist zu hoch raus.

Es gibt in CamAPS die Angabe "aktives Insulin" - ich schaue, ob da noch was läuft, esse 12 g KH.... wenn noch aktives Insulin da ist, gebe ist die 12 g als Snack ein. Wenn keins mehr läuft, gebe ich es als normale Mahlzeit ein und reduziere den Bolus um 50 %. Kommt natürlich auch auf die Menge des aktiven Inulins an.

Da liegt eine Fehlinterpretation des aktiven Insulins vor. Eben weil CamAPS nur das restliche Bolusinsulin als aktiv zeigt, ist diese Angabe für sich völlig bedeutungslos und hat nichts mit sinnvoller Hypo-Behandlung zu tun. Denn dieses aktive Insulin wurde ja typischerweise für Essen abgegeben, steht also in direktem Zusammenhang mit zu resorbierenden Kohlenhydraten. Dieser Zusammenhang fehlt in CamAPS völlig.

Wenn du 10min später (du bist immer noch niedrig, weil die Hypobehandlung ja schon ein paar Minuten dauert) wieder aufs aktive Insulin schaust, steht da immer noch fast die gleiche Zahl. Würdest du jetzt wieder 12gKH essen? Nein, weil du ja weißt, dass du gerade KH eingeworfen hast. Warum hast du das aber 10min vorher getan? Da hast du nämlich völlig vergessen, dass da auch aktive Kohlenhydrate sind, die mit dem aktiven Insulin in Zusammenhang stehen. Deshalb war deine Folgehandlung auf Basis nur des aktiven Bolus-Insulins in meinen Augen keine sinnvolle Therapie-Handlung.

Zitat von Lilimaus

und warum funktioniert es dann?

Tut es ja ganz offensichtlich nicht, wie sich in diesem Thread und auch an anderen Stellen zeigt.

huetterei Auch wenn es so aussieht, als seien wir von deiner eigentlichen Fragestellung abgedriftet mit der IOB-Diskussion, so zeigt dies doch eine erhebliche Schwäche in CamAPS bezüglich der Interpretationsmöglichkeit von aktivem Insulin und aktiven Kohlenhydraten zur Beurteilung der aktuellen Situation und Handlungsfolgerung.

Um sinnvoll agieren zu können, muss ich den Zusammenhang aus Korrekturinsulin (und das ist der Überschuss oder eben auch das Fehlen durch Abschaltung bezüglich des "Basals", den CamAPS durch Variation seiner verzögerten Boli umsetzt), Bolus-Insulin und wirkenden Kohlenhydraten kennen. Diesen Zusammenhang stellt CamAPS eben an keiner Stelle dar. Und das führt zu völligen Fehlinterpretationen der unvollständigen Angaben und dementsprechend auch zu Fehlhandlungen.

Die eindeutige Fehlangabe ist im Bolusrechner zu sehen. Wenn ich einen Bolus für Kohlenhydrate abgebe (ohne den BZ im Bolusrechner dabei zu aktivieren), dann gibt CamAPS Insulin auf Basis meines hinterlegten KH-Faktors ab. Bole ich jetzt ein zweites Mal für weiteres Essen und wähle dabei den BZ als zusätzlichen Insulin-beeinflussende Größe, dann zeigt er zwar das theoretische zusätzliche Korrekturinsulin an, zieht aber (in Klammern) diese Menge wieder ab, sofern sie kleiner oder gleich der aktiven Insulinmenge aus dem vorherigen Bolus ist. Das ist natürlich völliger Quatsch, denn das vorherige aktive Insulin gehört ja zu den vorherigen Kohlenhydraten. Richtig wäre an dieser Stelle, das Insulin abzuziehen, was CamAPS selbst schon vorher im Rahmen seiner verzögerten Bolus-Abgabe als Korrekturmenge (Überschuss zur eigentlich notwendigen Basalabgabe) zugeschossen hat. Und genau diese Menge ist nirgendwo ersichtlich und wird von CamAPS eben an dieser Stelle auch gar nicht verwendet. Und diese Menge wäre genau die Basal-IOB-Menge, von der Leila glaubt, sie wäre von AAPS-Benutzern überbewertet. Ist sie, wie sich hier zeigt, ganz und gar nicht.

Nebenbei: Ich bin gar kein AAPS-Fan. Ich habe AAPS schon lange bei uns durch eine Eigenprogrammierung ersetzt, weil ich mit vielen Dingen in AAPS nicht einverstanden bin und Milos sehr selbstherrlich agiert und Argumenten ziemlich unzugänglich ist. Aber gewisse Dinge sind in AAPS durchaus richtig umgesetzt und dazu gehört auch die vollständige Beurteilungsmöglichkeit des richtigen IOB und des Zusammenhangs zu aktiven Kohlenhydraten gerade in Bezug auf die Hypo-Behandlung. Und hier hat CamAPS ein enormes Defizit.

Zitat von Frogchen

Redest du da von AAPS oder CamApsFx?

Sowohl als auch.

Gehen wir von einem System ohne Loop mit idealer Basalrate, die den BZ konstant hält, aus, dann ist zu jedem Zeitpunkt (auch wenn die Basalrate natürlich nicht konstant ist, sondern zirkadian verläuft), das IOB=0, weil das Basal-Insulin bei idealem Verlauf gar nicht gezählt wird. Wird nun von einem Loop (egal ob durch eine temporäre Basalrate, verzögerten Bolus oder SMBs) ein Insulinüberschuss im Vergleich zur idealen Basalrate erzeugt, dann ist dieser Überschuss positives IOB. Gibt der Loop weniger als die ideale Basalrate ab, z.B. weil der BZ stark fällt, dann führt das zu negativem IOB. Zusätzlich kann dann durch Essensboli noch weiteres aktives Insulin das IOB in Richtung "positiv" verändern.

Nun zeigt CamAPS zwar die Basalrate an (von der ich hier mal optimistisch annehme, dass der Benutzer die getestet und für ideal befunden hat), führt aber keinerlei Berechnung auf Basis dieser Basalrate durch. Für CamAPS ist nur das eigene berechnete BZ-Steuerungs-Insulin relevant, was im besten Fall identisch zur idealen Basalrate wäre, aber erfahrungsgemäß nicht ist. Das ist für CamAPS aber egal. Also hat es nie positives oder negatives IOB auf Basis der Basalrate.

Dass das nicht grundsätzlich sinnvoll ist, wird einem klar, wenn man sieht, dass das "Basal" von CamAPS ja durchaus auch mal stundenlang ausgestellt werden kann. Dann entsteht an sich viel negatives IOB allein aus dem fehlenden Basal. Eine Betrachtung des gesamten IOB MUSS also eigentlich die Kombination aus Basal-IOB und Bolus-IOB berücksichtigen. Genau das geht mit CamAPS aber eben nicht.

Zitat von DerAndi

Ich glaube, da hast Du einen Denkfehler - wahrscheinlich, weil Du die Berechnung in AAPS gewohnt bist.

CamAPS macht ja keinen Basal; der ist nur in der Pumpe hinterlegt als "Backup", wenn CamAPS ausfällt. Ich denke, da sind wir uns einig.

CamAPS weiss aber doch jederzeit, wann es wieviel Bolus abgibt. Es weiss, wann es welche Abgaberate setzt. Daraus lässt sich doch jederzeit errechnen, wieviel aktives Insulin noch im Körper ist. Für die Berechnung brauchts doch keine Basalrate.

Ich schaue morgen früh nach dem Aufstehen mal nach im Infoscreen. Dann ist das Abendessen lange genug her und nach Deiner Logik müßte dann da als aktives Insulin "0" stehen. Steht da wirklich "0" und das System hat mir in den letzten 4 Stunden einen Microbolus gegeben, hast Du Recht. Steht da was anderes als "0", habe ich Recht.

Wobei es mir ums Recht haben nicht geht. Ich wüßte schon ganz gerne, wie die Menge "aktives Insulin" einzuordnen ist.

Alles anzeigen

1. Ich mache keinen Denkfehler. Meine Beschreibung des Unterschieds zwischen der Rechenweise von AndroidAPS und CamAPS FX ist ziemlich eindeutig. Wie auch an anderer Stelle in Bezug auf Bugs in CamAPS FX scheinst du die Details aber leider nicht zu verstehen.

2. Das aktive Insulin in Bezug auf die Basalrate ist nicht einfach der verzögerte Bolus, den CamAPS FX abgibt. Sondern die DIFFERENZ zum eigentlich abzugebenden Basal-Insulin. Wenn das System immer nur das Basal abgeben würde, wäre das immer IOB=0. Gibt es über eine Zeit MEHR als die Basalrate ab, wäre diese Differenz positives IOB, gibt es weniger als die Basalrate ab, wäre das negatives IOB. Deshalb "brauchts DOCH die Basalrate".

Ich möchte mich jetzt nicht wiederholen, lies am besten einfach nochmal meine vorherigen Posts dazu. Klar ist aber, dass dir offensichtlich sowohl die technischen Hintergründe als auch die detaillierten Berechnungen von Loop-Systemen und deren Unterschiede nicht klar sind. Unter diesen Umständen wäre es vielleicht sinnvoller, sich etwas zurückzuhalten.

Zitat von DerAndi

Dann wundert mich aber in der Anleitung die Beschreibung "Insulin an Bord". Das ist ja dann irreführend bzw. schlichtweg falsch.

Ja, ist es. Aber verständlich. Es liegt eben einfach daran, dass das Basal keine Bezugsgröße für CamAPS darstellt.

Für AndroidAPS ist die programmierte Basalrate eine feste Bezugsgröße. Wenn AndroidAPS also temporäres Basal setzt, kann es IOB in Relation zum Standard-Basal (was ja zu jedem Zeitpunkt ein IOB=0 darstellt) berechnen und gegebenenfalls IOB aus einem Essensbolus dazu addieren.

CamAPS zeigt das Basal in der Übersicht zwar an, es ist ja in der Dokumentation klargemacht, dass das Basal ausschließlich in der Pumpe als Backup vorhanden ist und keinerlei Einfluss auf irgendwelche Insulinberechnungen in CamAPS hat. Insofern kann CamAPS ein IOB aus dem ja gar nicht verwendeten Basal auch eben nicht bestimmen. Das ist für jemanden, der die detaillierten IOB-Angaben aus AndroidAPS gewohnt war, natürlich unbefriedigend. Denn wenn man sich die Übersicht von CamAPS anschaut und dort die gestrichelte Basalratenanzeige anschaut und dazu die tatsächlichen Insulinabgaben von CamAPS, dann kann man da natürlich schon sehen, ob CamAPS weniger oder mehr Insulin als das gedachte "ideale" Basal braucht, um einen auf Spur zu halten. Da aber CamAPS diese Basalrate nur als Info anzeigt, nicht aber für eigene Berechnungen verwendet, kann es natürlich auch nicht sinnvoll ein IOB damit generieren.

DerAndi Soweit ich mich richtig erinnere, hat helmama aber trotzdem Recht. Das in CamAPS FX angezeigte "Aktive Insulin" zeigt NUR das vom Algorithmus berechnete restliche aktive Insulin vorangegangener Essens-Boli an. Das vom Algorithmus selbst dazu gegebene (oder weggelassene) Insulin über die Steuerung durch verzögerte Boli wird in dieser Info-Zahl NICHT erfasst!

Allerdings gibt es natürlich auch eine halbwegs verständliche Begründung dafür. Zwar zeigt CamAPS FX in der Querübersicht die konfigurierte Basalrate an, aber das vom Algorithmus abgegebene Insulin über verzögerte Boli steht trotzdem in keinem Verhältnis zur Basalrate.

Während bei z.B. AndroidAPS das aktive Insulin aus der Kombination von Bolus-Insulin UND RELATIVER INSULINABGABE IN BEZUG AUF BASAL errechnet wird, gibt es diesen Bezug auf Basal bei CamAPS ja gar nicht. Daher zeigt CamAPS als "aktives Insulin" NUR das Essens-Bolus-Insulin an. helmama hat also Recht, aber es gibt immerhin einen Grund dafür.

Zitat von DerAndi

Das würde ich so nicht unterschreiben. Eine Fehlfunktion im Bluetooth-Stack von Android ist ebenfalls möglich.

Definitiv Nein.

Mit Bluetooth hatten all die geschilderten eindeutigen Bugs nichts zu tun.