Kannst Du dann nicht lieber ein Temporäres Ziel definieren, wenn du die schnellen KH ißt? Das geht doch auch...
Klar, man kann alles manuell lösen. Aber das ist nunmal nicht Sinn und Zweck des Loopens... 
AndroidAPS und Closed Loop
-
-
naja... nur weil man etwas einstellen muß um seine Mahlzeit abzudecken ist dier Loop ja nicht Ad Absurdum geführt...
Im Normalfall würde man sich ja auch einen TT eingeben oder ähnliches, da ist die Temporäre BZ nicht viel schlimmer.
Und da dein Loop das ja wohl so nicht hin bekommt, würde ich an deiner Stelle, lieber mit dem Temp. arbeiten, als gar nicht. Und zu hohe Werte zu riskieren....
Aber "so what"....
guter Einwand...
-
Anstatt ein Profilswitch.
... aber bei der Automation, ist das ja nicht der Fall... oder hab ich da was überlesen
-
-
Das war mir im Zusammenhang mit einer Automation nicht klar.
Urgs, aber Danke... wieder etwas schlauer geworden.
-
-
Autosense nutzen wir nicht.
SMS-Bolusgaben etc. fürs Kind nutzen wir auch nicht und will und werde ich auch nicht nutzen.
Ein Abschießen haben wir auch öfters mal und falsch geschätzte KEs oder einfach nicht gebolte Kohlenhydrate ebenfalls. Ja, müsste man dran arbeiten. Geht in der Pubertät aber nicht immer so einfach.
Es geht mir darum, dass wenn das Kind unterwegs ist und/oder eventuell doch etwas gegessen hat ohne zu bolen und ich länger mal keinen Blick / Einfluss drauf habe und es nicht nur eine kurzzeitige Spitze über 180 ist, die danach sofort wieder abfällt, dass dann der Loop etwas aggressiver arbeitet. Das muss jetzt nicht unbedingt 130% sein, das habe ich nur als Beispiel geschrieben.
TempTarget nutzen wir tatsächlich fast gar nicht (außer per Automation vor dem Frühstück in der Woche während der Schulzeit, da zu diesem Zeitpunkt relativ planbar).
Auch in dem oben beschriebenen Fall wäre ein TempTarget meiner Meinung nach nicht hilfreich, wenn es nur ein kurzzeitige Spitze von vielleicht 10 Minuten ist und danach steil wieder runter geht.
Egal ob Profilwechsel oder TempTarget oder etwas anderes, interessiert mich die Dauer, die der Blutzucker bei hohen Werten festhängt bzw. weiter steigt, um dann die Automation zu starten.
Ich weiß nicht, wo ich die Dauer eintragen kann.
Danke, wenn das jemand weiß.
-
Nun verstehe ich das Problem. Macht Sinn, das einzige was mir dazu einfällt ist, dass man die Graphenhöhe anders einstellt... tiefer an der Oberen und höher an der Unteren BZ Zahl. Alle sagen, das würde keinen Einfluss haben, seit dem ich das gemacht habe, laufen meine Werte nicht mehr soo übermäßig steil hoch und kommen etwas schneller wieder runter... und wenn man nochmal am Algorithmus versucht.. die sind ja nicht alle gleich "agressiv"
Hat das einen besonderen Grund warum du keine SMB willst, die wären ja eine super Lösung und man kann da ja die Zeit in der sie gegeben werden reglementieren... zB in 30/40/50/60 Minuten, je weniger Minuten um so geringer die Abgabe ( insgesamt ) wenn man dann noch die Höhe des erlaubten SMB niedrig stellt, darf da eigentlich nicht mehr so viel passieren... als keine starken Hypos.
Ist nur eine Idee, aber du wirst ganz bestimmt deinen Grund haben... wollte auch nicht nerven damit...
-
Wir nutzen SMBs mit Oref1, tatsächlich sogar relativ aggressiv eingestellt.
Wir nutzen keine SMS zur Bolusgabe etc. wie das manch andere bei ihren Kindern machen. Dafür ist mein Kind zu alt und schon Mitsprache berechtigt, so dass ich nicht per Fernsteuerung dazwischen funken will. Natürlich könnte man die Automation auch als ein Dazwischenfunken sehen. Das ist aber etwas anders. (Tatsächlich haben wir bei SMBs schon ein paar Diskussionen gehabt.)
Die Einstellung der Graphenhöhe sollte keinen Einfluss auf die Blutzuckerwerte haben, höchstens auf die Optik im Bildschirm.
Die Graphenhöhe haben wir auch nicht auf 180 eingestellt. Das war aber auch nur ein Beispiel.
-
Ich nutze den Bolusrechner SMB auch nicht. Haut bei mir nicht hin. Ich geb immer die KH über TT KH ein und danach über die normale Bolusabgabe ungefähr die Hälfte etwa... vom gesamt Bolus, dann gleicht der SMB relativ gut am Ende der KH aus,...
-
Nein, das meinte ich nicht.
Es gibt einen SMS-Kommunikator, mit dem Eltern per SMS die Einstellungen in AAPS aus der Ferne verändern können und z.B. Profilwechsel oder Bolusgaben vornehmen können. Dabei muss man einen Code per SMS senden usw.
Das ist eine SMS über das Handy und hat nichts mit SMBs zu tun, bzw. nur eingeschränkt, weil dann ggfs. SMS zu SMBs führen können.
Den Boluskalkulator nutzen wir schon.
Aber weiß denn jemand, ob man die Dauer in der Automation einstellen kann?
-
-
Moin Leute,
ich hab da mal ein paar offene Fragen zum Thema AAPS und die Updates.
Angefangen habe ich mit 2.3., dann kam die 2.5.1 auf die ich upgedatet habe und nun immer noch nutze...
Die Neue 2.6.1 habe ich mir erstellt, aber noch nicht in Gebrauch, bzw auf einem zweiten Smartphone zum rumtesten, aber eben noch nicht auf dem Hauptsmartphone....
Ich bekomme für das 2.5.1 nun immer die Meldung Neue Version verfügbar, zuerst für 2.6.1 und nun für 2.6.1.1.
Bei der Version heißt es, die würde die Combo besser unterstützen.
Nun gut, ich habe die Dana und würde die nicht brauchen..... ???
Oder, muß ich die nun auch erstellen, damit ich nach den 60/30 Tagen nicht zurückfalle?
Oder reicht es mit der 2.6.1?
Natürlich habe ich Sicherungen für die Logs und die Versionen, für den Fall der Fälle.
Und wenn ich mit der 2.5.1 nun zurückfallen würde, könnte ich dann nicht einfach die 2.6.1 auf das Hauptsmartphone installieren und die Logs importieren?
Oder geht diese Zwangsupdate nun auch für die 2.6.1.1?
Auch wenn ich keine Combo nutze und wohl erstmal auch nicht nutzen werde?
Kommt hier nun wieder eine Neue Frist in Lauf oder ist es eine Option?
Was passiert, wenn ich den Closed Loop in 2.5.1 nicht mehr nutzen könnte.
Kann ich dann immer noch die 2.6.1 reininstallieren und die Logs laden?
Und nein, bitte nicht mit "aber warum benutzt du die Neue nicht und erstelle dir doch einfach die 2.6.1.1" oder ähnlichem antworten.
Ich möchte einfach wissen, wie und ob es geht.
Schon mal Danke an alle die hilfreiche Antworten beisteuern.
-
Hi,
wenn die Zeit abgelaufen ist, fällst du in den OpenLoop zurück. Keine Ahnung wie das dann mit deinen Objevtives ist. Allerdings kannst du ja eine Sicherung, die kurz vor Ablauf der Zeit erstellt wurde, einspielen oder eine noch ältere.
Du musst auf jeden Fall die aktuellste verfügbare AAPS Version nehmen. Bei den neuen Versionen geht es nicht immer nur um eine besser Unterstützung, sondern auf um Bugfixes und 2.6.1 hatte einige, die 2.6.1.1 nicht mehr hat.
Gruß
-
Vielen Dank, das ist schon mal gut zu wissen.
Allerdings beantwortet mir das meine Frage nicht ganz.
Neues Beispiel.
Sagen wir, ich würde die AAPS, von nun an bis Ende des Jahres nicht mehr nutzen.
Habe mir die 2.5.1 gesichert samt der Logs -
die 2.6.1 erstellt und gesichert..
Und ich wollte nun wieder anfangen das AAPS zu benutzen.
Dann installiere ich mir die "neueste" Version ( ? 2.8. oder wie auch immer die dann heißt.) und ziehe mir die Logs vom letzten Stand 2.5.1. die ich gesichert hatte, bevor ich die AAPS nicht mehr genutzt habe.
Das würde dann funktionieren.... ???
Oder würden sich die verschiedenen Versionen beißen...
-
Die Daten der alten Version sollten erhalten bleiben, wenn die neue Version über die alte drüber installiert wird. Dafür ist es aber zwingend notwendig, dass beide mit demselben Key signiert wurden.
Ansonsten funktioniert AAPS so lange ohne zeitliche Beschränkung, wie die alte Version nichts von der neuen weiß. Neue Versionen werden in Milos' github-Repository bekanntgegeben, die genaue URL steht irgendwo in den Quellen. Wenn die App das nicht findet (z.B. weil sie nicht ins Netz kommt), dann läuft die alte Version vorerst auch nicht ab.
-
kann man der App verbieten ins Netz zu gehen oder geht das nur, wenn mein Handy nie wieder online geht? NS kriegt die Daten ja von xDrip, das sollte ja also trotzdem funktionieren, oder?
-
-
Die Beantwortung der ersten Hälfte der ersten Frage zieht im Looperforum möglicherweise eine lebenslängliche Sperre nach sich, wie das hier gehandhabt wird, überblicke ich nicht... Und eine PN werde ich deshalb auch erst einmal nicht vorschlagen.
-
Danke dir.
Das stimmt, das die alten Daten erhalten bleiben. Und klar, muss es den gleichen Key haben. Darum muss man sich ja selber die APK erstellen.
Das mit dem ins Netz kommen verstehe ich auch. Nur kann der nightscout Client dann die Daten nicht hochladen.
ist für mich auch blöd, da ich eben nur dieses eine Smartphone nutze für alles. Das zweite ist nur zur Sicherheit.
Verstehe ich das nun richtig.
Ich nutze die 2.5.1.
Erstelle mir die neueste APK und Speicher sie in der Cloud samt Sicherungen von der 2.5.1.
Dann könnte die laufende Version aus dem loop fallen und ich könnte theoretisch, Wochen später, die neueste Version installieren und die aktuellen Logs laden.... Richtig?
Nochmal danke...
-
Alles anzeigen
Danke dir.
Das stimmt, das die alten Daten erhalten bleiben. Und klar, muss es den gleichen Key haben. Darum muss man sich ja selber die APK erstellen.
Das mit dem ins Netz kommen verstehe ich auch. Nur kann der nightscout Client dann die Daten nicht hochladen.
ist für mich auch blöd, da ich eben nur dieses eine Smartphone nutze für alles. Das zweite ist nur zur Sicherheit.
Verstehe ich das nun richtig.
Ich nutze die 2.5.1.
Erstelle mir die neueste APK und Speicher sie in der Clouds samt Sicherungen von der 2.5.1.
Dann könnte die laufende Version aus dem loop fallen und ich könnte theoretisch, Wochen später, die neueste Version installieren und die aktuellen Logs laden.... Richtig?
Nochmal danke...
Richtig
-
Danke schön, dann ist ja alles schick.
-
Da AAPS OpenSource ist, ist es dir gestattet den Quellcode deinen Bedürfnissen anzupassen. Was hält dich davon ab, den Updatecheck von AAPS zu modifizieren und den TimeOut entsprechend anzupassen?
-
