Beiträge von dideldum

Inspiriert durch meine Vorgehensweise mit einem Miniphone ohne NFC zum Empfang der Libre2-Werte, habe ich mal ausprobiert, ob es nicht auch geht, unterbrechungsfrei Werte beim Sensor-Wechsel zu bekommen, wenn man ganz normal ein Smartphone mit NFC zum Scannen und Empfangen der Werte mit gepatchter LibreLink verwendet.

Kurz: das geht.

Man braucht dazu einen PC mit dem Programm "adb" (Android Debug Bridge), das kann z.B. im Rahmen von Android Studio installiert werden, es kann aber auch allein installiert werden (-->minimal adb).

Um ADB zu benutzen, müssen auf dem Smartphone die Entwickler-Optionen angeschaltet werden. In den Entwickler-Optionen muss dann USB-Debugging angeschaltet werden.

Nachdem die Vorbereitungen getroffen sind, und der nächste Sensorwechsel ansteht, geht man folgendermaßen vor:

1. Smartphone vor dem Starten des neuen Sensors an den PC anschließen und die Daten der gepatchten LibreLink auf den PC sichern. Dazu öffnet man auf dem PC eine Eingabeaufforderung und führt folgenden Befehl aus:
   adb backup -f alter_sensor.backup com.freestylelibre.app.de
   Der Name "alter_sensor.backup" kann frei gewählt werden, sollte aber schon darauf hinweisen, dass dieses LibreLink-Backup noch mit dem alten Sensor ist.
2. Jetzt kann der neue Sensor mit der gepatchten LibreLink gestartet werden (das Smartphone kann dazu am PC angeschlossen bleiben, muss es aber nicht).
3. Nun sichert man wieder die Daten der gepatchten LibreLink, die diesmal schon den neuen Sensor enthalten (der zwar gerade erst in seiner Aufwärmzeit ist, aber das ist egal), indem man in der Eingabeaufforderung praktisch den gleichen Befehl ausführt, nur dass man einen anderen Dateinamen wählt:
   adb backup -f neuer_sensor.backup com.freestylelibre.app.de
4. Jetzt restauriert man LibreLink wieder mit den Daten des alten Sensors, indem man in der Eingabeaufforderung folgenden Befehl ausführt:
   adb restore alter_sensor.backup
   Hat man im 1. Schritt einen anderen Dateinamen gewählt, muss man den natürlich hier verwenden.
   Hier ist zu beachten, dass bei einem Restore auf allen meinen getesteten Smartphones (unterschiedliche Android-Versionen von 7 bis 11) immer die LibreLink-Berechtigung für den Standort weg ist. Da ohne die Standort-Berechtigung keine Bluetooth-Verbindung funktioniert, muss man nach dem Restore in den Android-Einstellungen für die LibreLink wieder die Standort-Berechtigung vergeben.
5. Jetzt erhält man weiter Werte vom alten Sensor, während der neue sich in der Aufwärmzeit befindet. So lässt man den alten Sensor bis zum Lebensende weiterlaufen. Sinnvollerweise ist das Sensor-Ende erst nach Ablauf der Aufwärmzeit des neuen Sensors erreicht.
6. Dann spielt man wieder das Backup mit dem neuen Sensor auf dem Smartphone ein, indem man bei angeschlossenem Smartphone in der Eingabeaufforderung ausführt:
   adb restore neuer_sensor.backup
   Hat man im 3. Schritt einen anderen Dateinamen gewählt, muss man den natürlich hier verwenden. Zum Standort gilt ebenfalls das in 4. Geschriebene.
7. Nun erhält man Werte vom neuen Sensor. Ist dessen Aufwärmzeit zu Ende, sind sofort Werte da.

Ich habe auf diese Weise immer nur Ausfälle von ca. 3min während der Restore-Zeiten (und wieder Anschalten der Standort-Berechtigung), so dass man praktisch unterbrechungsfrei die minütlichen Werte erhält.

Zusätzlich habe ich die gepatchte LibreLink noch weiter gepatcht, so dass bei mir die Aufwärmzeit nur 45min statt der üblichen 60min ist, und das Sensor-Ende erst 12 Stunden nach der eigentlich offiziellen Ende-Zeit nach 14 Tagen liegt. Mit den offiziellen Laufzeiten (14 Tage minus 60min Aufwärmzeit) müsste man jeden Sensor-Start ja immer eine Stunde vorverlegen, um die Überlappung der Aufwärmzeit mit der letzten Stunde des alten Sensors zu machen. Läuft der Sensor aber 12 Stunden länger, hat man viel Pufferzeit für die Überlappung.

Die verkürzte Aufwärmzeit von 45min ist übrigens nicht besonders sinnvoll. Manchmal, ganz selten mal, ist der Wert nach den 45min schon ziemlich gut. Meistens pendelt er sich aber tatsächlich erst zum Ende der 60min ein. Ich starte den neuen Sensor deshalb immer ein paar Stunden vor Ablauf der um 12 Stunden verlängerten Lebenszeit des alten Sensors und schalte erst auf den neuen, wenn der schon einige Stunden läuft.

Zitat von Brander-Diab

Die Masseinheit drückt das doch bei der t:slim klar aus: IE pro Gramm Kh.

Nur auf dem Display der t:slim sieht das komisch aus - bei mir gerade 1E:6.3g

Im persönlichen Profil steht da nur 1:6.3 und darunter KH. Ist eben alles gewöhnungsbedürftigen.

Damit ist die Maßeinheit auf der T-Slim aber eindeutig falsch notiert.

Die Bezugsgröße ist ja offensichtlich EINE IE. Also muss es heißen 6,3g(KH) / IE und nicht 1IE / 6,3gKH (ich ersetze bewusst den Doppelpunkt durch den Schrägstrich als Geteilt-Durch-Zeichen, um die Abgrenzung zum Doppelpunkt als Satzzeichen deutlich zu machen. Der Doppelpunkt gibt bei der Faktorangabe nunmal ein Verhältnis (also einen Teiler!) an und ist kein Satzzeichen).

Damit ist der Faktor klar, nämlich 6,3. So wie es auf der T-Slim steht, wäre der Faktor ja 1/6,3= 0,15873 IE/gKH (was auch eine richtige, aber nicht hilfreiche, Angabe wäre).

Ich finde es schon überaus merkwürdig, dass bei der T-Slim offensichtlich Zähler und Nenner der sinnvollen Faktor-Angabe vertauscht sind.

Verständlich sind nunmal Angaben von "x IE PRO 1 BE bzw. 1 KE" oder eben umgekehrt "x gKH PRO 1 IE".
Selbst bei der Umrechnung dieser unterschiedlichen Notationen tun sich ja viele schon schwer. Da dann aber auch noch Zähler und Nenner zu vertauschen, macht die Verwirrung ja ganz komplett.

Zitat von AndiHeitzer

Seit über einem wartet die 'Gemeinde' dort auf die korrekte Buchführung für Bolus/Basal, die in Exports nicht getrennt ausgewiesen wird ...

https://github.com/NightscoutFoundation/xDrip/issues/1158

... läuft ....

Auf einen meiner seit 2018 schlummernden Feature-Requests bei xDrip kam 2021 die Nachfrage von Navid, ob der Request zu meiner Zufriedenheit behandelt worden wäre. Es hat aber nie eine Programmieraktion dazu gegeben. Also natürlich nicht.

Andere Issues wurde (genauso wie bei AndroidAPS) kommentarlos oder kurz angebunden geschlossen.

Ist bei den OpenSource-Geschichten also keineswegs besser als im kommerziellen Bereich.

Funktioniert die Nightscout-Verbindung nicht mit Token?

Habe meinen Link mit Token probiert, da kommen keine Werte.

Da ich überall mit Token arbeite (meine App, Nightscout-Reporter, Webseite) würde ich das in dieser App natürlich auch wollen.

Zitat von Szaladin

Ich habe stark überlegt, Nightscout über nen Raspberry zuhause laufen zu lassen.

Ich finde das mit dem RasPi zu Hause sehr charmant. Habe den Pi 4 vor fast 2 Jahren mit Nightscout für Töchterchen und mich mit 2 Instanzen eingerichtet. So ohne Datenmengen-Beschränkung gefällt mir das doch sehr viel besser als etwa die kostenlose Heroku-Variante. Kann jetzt noch die Daten von Januar 2020 abrufen. Bei Heroku musste ich alle halbe Jahr die Datenbank wieder stutzen.

War dann eigentlich bei Martins 10.be, aber weil ich mit meiner eigenen App den Master-Follower-Mechanismus über einen MQTT-Server abbilde, den ich sowieso bei mir auf dem Pi laufen lasse, habe ich auch gleich Nightscout bei mir auf den Pi geholt. Läuft seitdem ohne Ausfälle.

Solange unsere Geräte im Wlan sind, ist mir die DSL-Verbindung sowieso egal, da wird der Pi über die lokale Namensauflösung erreicht (natürlich macht der Pi bei mir auch den DNS). Und wenn man unterwegs ist, kann zur Not auch später alles in Nightscout gepumpt werden.

Ich habe häufig Vergleichsmessungen zwischen Contour Next Link 2.4 (von der früheren Medtronic 640 meiner Tochter übrig geblieben), dem Contour Next One und dem Fora 6 gemacht. Dabei habe ich insgesamt 9 Messungen aus demselben (großen!) Blutstropfen gemacht (3 mit jedem Gerät).

Das Contour Next Link 2.4 war mit Abstand das schlechteste, die Streuung war am breitesten (teilweise Klöpse wie ~210, ~140, ~170).

Das Fora 6 war in Ordnung mit einem Streuungsabstand von ca. 30-40

Das Contour Next One war das mit dem geringsten Streuungsabstand von 15-20.

Bei Vergleichsmessungen in meiner Dia-Praxis war das Contour Next Link 2.4 immer am weitesten vom Praxis-Wert entfernt, das Fora 6 und das Contour Next One waren immer etwa gleich weit entfernt vom Praxis-Wert.

Insgesamt ist von diesen 3 Geräten das Contour Next One meiner Erfahrung nach klar das beste und das Contour Next Link klar das schlechteste.

Zitat von Schaf

Habe gesehen, das man sich die App auch selbst erstellen kann mit einem Mac und xcode.

Das fände ich sehr erstaunlich.

Dann müsste ja der Quellcode für DiaBox herunter zu laden sein, wenn man sich die selbst erstellen kann.

Ich hatte mir mal die Android-APK angeschaut und festgestellt, dass die mit einem "Obfuscator" so vernebelt ist, dass eine Code-Analyse per Reverse-Engineering extrem erschwert wird. Ich hatte auch nirgends den Quellcode gefunden.

Zumindest für Android ist der Code von DiaBox offensichtlich Closed Source (im Gegensatz zu xDrip+ oder AndroidAPS).

Deshalb wäre ich verwundert, wenn die Apple-Variante das nicht wäre.

Zitat von Rol

Nach einer Anleitung zur Code-Änderung werde ich hier lieber nicht fragen. Aber ein kleiner Hinweis wie man zumindest den entsprechenden Text im Code finden könnte wäre nett. Mit der Lupe gelingt mir das in AndroidStudio leider nicht.

Du lässt leider keine Konversationen zu, sonst könnte ich dir direkt etwas dazu schreiben. Kannst mich aber auch in einer Konversation kontaktieren.

Zitat von FelixB

dideldum Kurz was anderes, wie weit bist du denn mit deiner Eigenentwicklung. Kann man die schon testen?

Ist leider noch nicht veröffentlichungsreif

Ich habe mal kurz in die Änderungen da geschaut. Will mich da jetzt nicht zu weit aus dem Fenster hängen, weil ich wirklich nur kurz geschaut habe.

Es sieht aber danach aus, als ob Milos & Co. tatsächlich in den Code eingebaut haben, dass 2.6.2 auf Geräten mit Android höher als 7 nicht läuft.

Damit ist der Update-Zwang natürlich auch bei 2.6.2 in dem Sinne beibehalten, dass Benutzer neuerer Android-Geräte gezwungen werden sollen auch die neuere Version mit "normalem" Update-Zwang zu benutzten.

Natürlich kann man das aus dem Code auch wieder entfernen. Dazu muss man aber eben selbst im Code ändern. Ich war schon immer mit einigen Sachen in AndroidAPS höchst unzufrieden (weshalb bei mir auch mit 2.5.1 Schluss war). Der Update-Zwang gehörte von Anfang an dazu, weshalb ich den von der ersten von mir verwendeten Version an herausgenommen hatte. Auch den Zwang, 2.6.2 nur auf Android 7 zu benutzen, kann man natürlich auch wieder herausnehmen.

Zitat von bierernst

Dann hast du die 2.6.1.4 von Milos gebaut und dann?

Die 2.6.2 kann ich nicht als Repository finden.

Wird die dann zur 2.6.2.

Ich habe gerade das Repository von https://github.com/MilosKozak/AndroidAPS.git geclont. Da wurde vor 5 Tagen die Version von 2.6.1.4 auf 2.6.2 geändert. Wenn man es jetzt also holt, wird (zumindest nach der jetzt einprogrammierten Versionsnummer) die 2.6.2 gebaut.

Zitat von bierernst

Das hat sich mit AAPS 2.8++ auf die letzte Version upgedatet und nun meckern die alten AAPS Versionen..

Und das alte Studio ist futsch und will wenn es neuinstallaiert werden soll das neue löschen um auf die vorhandenen Pfade zugreifen zu können. Dabei will es aber alle neuen Teile unwiederbringlich löschen.

Ich habe bei mir die neuste Android Studio Version und habe darin testweise jetzt mal ein neues Projekt mit der Version 2.6.2 aus Milos altem Repository gemacht. Das ließ sich völlig problemlos bauen.

Ich würde an deiner Stelle beim neuesten Android Studio bleiben. Im Android Studio dann ein neues "Project from Version Control" aufrufen. Da dann den Git-Link von Milos Repository eintragen und als Zielverzeichnis (die Textbox darunter) ein neues Verzeichnis angeben (z.B. "C:\Users\Ich\StudioProjects\AndroidAPS-2.6.2-ohne-Updatezwang"). Dann wird 2.6.2 in einem anderen Verzeichnis angelegt und gebaut.

Ich vermute, du benutzt immer dasselbe "AndroidAPS"-Verzeichnis und dann überschreibst du natürlich immer alles. Aber das hat nicht das geringste mit der Android Studio Version zu tun.

Zitat von July95

Leider gibt es anscheinend die Option ja nicht mehr.

Aber nur zum Verständnis, verlängern geht doch auch nicht ohne die erneute Aufwärmphase, oder?

Mit diesen alten Transmittern (80 und 81) ging Verlängern ohne Aufwärmphase. Mit denen ab 8G musste man in der Tat einen kompletten Neustart nach dem Rausprokeln des Transmitters mit Aufwärmphase machen.

Die aufladbare Transmitter von Elvin, die jetzt offenbar leider nicht mehr von ihm gemacht werden, waren immer 80 oder 81 Transmitter (deshalb musste man ihm ja auch solche abgelaufenen schicken). Und damit geht Verlängern ohne Pause.

Warum willst du überhaupt Android Studio zweimal haben? Du kannst doch die unterschiedlichen AAPS versionen in verschiedenen Projekten haben. Da ich viel in AAPS geändert hatte, hatte ich dann für jede neue Version ein neues Projekt gemacht, um in Ruhe zu schauen, wie mein Änderungen nachzuführen waren. Aber alles im selben Android Studio.

Zitat von Hype

Wo bekommt man diese Transmitter?

Die kann man in England kaufen. Wenn man zwei alte Transmitter (müssen aber 80 oder 81 als Beginn der Seriennummer haben, also ziemlich alt sein!), dann bekommt man für diese 2 alten einen aufladbaren zu einem "günstigeren" Preis, wenn man keine alten hinschickt, kann man auch einen bekommen, dann allerdings teurer.

Ich hatte für uns 2 gekauft. Da der G6 bei uns aber ganz schlecht funktioniert hat und wir nach einem halben Jahr schnell wieder zum Libre 2 zurück gewechselt haben, habe ich die aufladbaren Transmitter schon längst wieder an andere abgegeben.

Infos gibt es in Facebook in der Gruppe " Rechargeable G5/G6 transmitter", die ist von dem Verkäufer.

EDIT: Oh, ich habe gerade mal in die Gruppe hineingeschaut und gesehen, dass Elvin seit August den ladbaren Transmitter aus Zeitgründen nicht mehr anbietet (das war halt wohl so eine Freizeitbeschäftigung von ihm). Das ist echt Pech.

Hol dir 2 aufladbare Transmitter (oder zumindest einen). Dann kannst du mit jedem neuen Sensor den anderen Transmitter draufsetzen und 2 Stunden vor Ablauf des alten starten. So hast du überhaupt keine Ausfallzeit. Allerdings musst du so jedes Mal 2 Stunden früher als beim letzten Mal setzen, es sei denn, du verlängerst die Sensoren.

Zitat von July95

Was kann das sein??

Wir hatten es einmal auch, dass dauernd Luft gezogen wurde. Der Wechsel der Reservoir-Kappe hat geholfen.

Zitat von sugardaddy21

IMHO ist es nicht verwerflich, aus so einem Service ein Business zu machen.

Für mich ist das aber anfixen, wenn man erst nen Service kostenlos anbietet und nachher die Leute vor vollendete Tatsachen stellt und sogar den Datenexport kostenpflichtig macht oder mit einem Abo bündelt. Und zum Handeln gerade mal 2 Wochen Zeit gibt bevor die Schranke runter klappt. Das ist nicht die feine Art. Punkt.

Du hast es immer noch nicht verstanden.

Martin macht da kein Business draus. Er zahlt da jedes Jahr Tausende Euros drauf. Das war 2017 nicht abzusehen, weil es da eben nur eine Handvoll Looper gab.

Mittlerweile ist die Menge an Nutzern für einen kostenlosen Service einfach nicht tragbar. Martin hatte zu Beginn die Möglichkeit, freie Server-Resourcen kostenlos für die paar Looper zu nutzen und hat das selbstlos zur Verfügung gestellt. Zusätzlich hat er ebenfalls kostenlos jahrelang alles supportet. Bei der heutigen Menge ist diese kostenlose Server-Bereitstellung aber gar nicht mehr möglich, mittlerweile trägt Martin da also selbst etliche Kosten. Er schenkte diesen Service den vielen Nutzern also nicht nur, er BEZAHLTE diesen Service für sie! Und solche Strohköpfe wie du kommen mit "anfixen". Ich bin von so viel Dummheit echt geplättet.

Entschuldigung an emp00 , dass ich ohne Hinweis auf Alternativen doch nochmal darauf reagieren musste. Werde ich jetzt nicht mehr tun. Und sugardaddy21 auf meine Blockierliste setzen, so etwas halte ich sonst nicht aus.

Zitat von sugardaddy21

Es aber erst als "kostenlos" hinzustellen, möglichst viele "Kunden" damit anfixt und dann die kommerzielle Schranke runterklappt, ist halt nicht die feine Art.

Wäre das von Anfang an absehbar gewesen, dass er das nur während der Entwicklungszeit kostenlos anbietet und dann kostenpflichtig vermarktet, dann wäre das transparent und frei von einem "Gschmäckle" gewesen.

Ich finde deine Kommentare hier ziemlich fehl am Platz!

Martin Schiftan hat vor mehreren Jahren (2019 oder sogar schon 2018EDIT: sogar schon 2017) angefangen, diesen Dienst kostenlos der Community zur Verfügung zu stellen. Damals gab es in Deutschland vielleicht ein paar Dutzend DIY-Looper.

Er hat das ganze nun jahrelang mit viel eigenem Aufwand kostenlos der Community zur Verfügung gestellt. Da kann keine Rede von "anfixen" oder "erst als kostenlos hinstellen" sein.

Klar gesagt: Du hast offensichtlich überhaupt keine Ahnung und solltest besser deine Klappe halten. Solche Kommentare wie deine sind der Situation ganz und gar nicht angemessen.

Mittlerweile gehe ich davon aus, dass aus den anfänglich an ein paar Händen abzählbaren Instanzen sicherlich über 1000 geworden sind (das schätze ich jetzt mal aus dem Blauen heraus, Martin kann da sicherlich eine genaue und ganz bestimmt sehr beeindruckende Zahl nenne).

Da sind die Kapazitäten für eine Gratis-Nutzung einfach irgendwann erschöpft. Da stecken eine Menge Kosten dahinter, von denen du offenbar keine Ahnung hast. Dazu die jahrelange freiwillige kostenlose Arbeit von Martin für alle.

Ich empfinde deine Kommentare als einfach dumm, schamlos und völlig unangemessen. So jemand wie du hat solche Leute wie Martin gar nicht verdient.
Schande über dich!

Ich muss gerade mal klugscheißen:

Ihr schmeißt hier "abwärtskompatibel" mit "aufwärtskompatibel" durcheinander.

Fakt ist: AndroidAPS IST ABWÄRTSKOMPATIBEL, das heißt nämlich, dass eine neuere Version mit den Bedingungen der alten Version (Datenbank-Formate, Konfigurationsdateien etc.) zurechtkommt.

Was ihr meint, ist, ob eine alte Version auch mit den Zuständen der neuen Version zurechtkommt. Das nennt man AUFWÄRTSKOMPATIBEL und das ist AndroidAPS früher auch gewesen, bis die Konfigurationsdateien verschlüsselt wurden. Seitdem sind die älteren Versionen, in denen die Konfiguration noch unverschlüsselt war, nicht mehr aufwärtskompatibel. Abwärtskompatibel ist AndroidAPS aber meines Wissens nach wie vor in allen Versionen.