Beiträge von dideldum

Zitat von dh24580

Das heist die Kospet Magic 3 oder 4 kann ich ohne Probleme nehmen.

Wahrscheinlich nicht. Bei diesen Kospet Uhren fehlt mir in der Tat die Angabe des verwendeten Betriebssystem. Und wenn da nicht explizit steht "Android X (wobei das X je nach Full Android Uhr meistens noch 7 oder 8 ist, bei einigen wenigen auch 9 oder 10), dann wäre ich eher vorsichtig. Ich hatte bei den Kospet (und anderen Herstellern wie Lemfo, Finow, Zeblaze, Microwear, und andere) immer nur nach den Full Android Uhren geschaut. Kospet scheint aber auch welche zu machen, bei denen möglicherweise ein proprietäres OS ähnlich Wear OS verwendet wird, so dass diese Uhren nur als Ergänzung zu einem Handy benutzt werden können. Da wäre ich also vorsichtig. Wenn in der Spezifikation der Uhr nur ein "Kompatibel mit Android X und iOS Y" steht, dann reicht das nicht. Bei der Optimus 2 siehst du z.B. ein "Powered by Android 10.7". Die hat wirklich ein vollwertiges Android 10 laufen. Da ist dann BYODA kein Problem. Bei diesen 40-60€ Uhren sieht das anders aus. Außerdem haben die Magic 3/4 ja noch schlechtere Akkus, die werden nicht lange durchhalten.

Also: entweder (wie schon von anderen richtig gesagt) eine Wear OS Uhr nehmen, auf der ein Watchface läuft, dass die Glukose-Werte vom Handy bekommt und anzeigt (dann ist immer das Handy der Empfänger vom Dexcom) oder eine Full Android Uhr von den oben genannten Produzenten, bei der das auch klar spezifiziert ist. Diese kann dann selbst der Empfänger vom Dexcom sein, ein Handy ist da also gar nicht nötig. Die von dir genannten preiswerteren Kospet Uhren würde ich da aber nicht einbeziehen. Die Kospet Optimus und Prime Uhren sind da eindeutig spezifiziert mit Full Android, bei den von dir genannten ist das leider nicht so.

Zitat von TuTNiX

Die hat kein Wear OS.

Kospet macht Uhren, die haben was besseres als Wear OS, nämlich Full Android. Kospet Uhren sind also vollwertige Smartphones, nur in Uhrenform.

Das bedeutet, dass die BYODA auf den Kospet Uhren selbst läuft und die Uhr selbst der Empfänger der Dexcom-Werte ist. Das ist (solange man kein Loop-Programm auf dem Handy laufen hat) für manche die deutlich bessere Alternative.

Dennoch würde ich die Tank M1 nicht nehmen, weil sie einen sehr kleinen Akku hat (nur 380mAh). Da gibt es deutlich bessere Full Android Uhren mit mittlerweile über 1000mAh, auch von Kospet. Außerdem ist bei der Tank M1 tatsächlich nicht eindeutig angegeben, welches OS darauf läuft.

Uhren wie die Kospet Optimus und Prime (bzw. Optimus 2 und Prime 2) sind als Full Android Gerät definitv als vollwertiger direkter Empfänger für den Dexcom mit der BYODA tauglich (natürlich nicht mit der originalen Dexcom App, da stehen sie nicht auf der Kompatibilitätsliste. Wie die meisten Leute kennen wohl auch die Dexcom-Leute keine Full Android Smartwatches).

Zitat von Grimmi Grimbart

Abbott "versucht" in der Situation die 12 - 15 minütige Differenz zwischen Gewebe- und Blutzuckerwert rauszurechnen.

Ich weiß. Aber der Algorithmus kann nunmal auch nicht in die Zukunft schauen. Das heißt, seine geschätzte Vorausberechnung basiert auf den 12-15min zurückliegenden BZ-Werten. Wenn die noch aufwärts zeigen, rechnet der Algorithmus gerne auch zu stark "in die Zukunft". Knickte der Blutzucker in den letzten 15min bereits wieder nach unten, dann kann der Algorithmus davon noch nichts wissen und diese Bewegung natürlich noch nicht nachvollziehen. Da er nun noch gerne in der Tat "zu stark" in die Zukunft aufwärts gerechnet hat, ist die Differenz zu dem bereits wieder fallenden BZ natürlich in so einer Situation besonders groß. Schaut man dann 15min nach der BZ-Messung, wird man in der Regel einen sehr ähnlichen Wert im Sensor sehen. Bei uns (Tochter und mir) funktioniert das auf jeden Fall einwandfrei.

Zitat von July95

219 blutig und 258 Sensor liegen gerade noch innerhalb der 15% Toleranz,

Grundsätzlich kann zwischen zwei Blutzuckermessgeräten auch 30% Abstand zwischen den Werten sein, und trotzdem liegen beide innerhalb der 15%-Toleranz. Das eine kann 15% nach unten vom "realen" BZ-Wert und das andere 15% nach oben vom "realen" BZ-Wert abweichen. Das macht bei zwei Werten von unterschiedlichen Messsystemen durchaus 30% Abweichungsmöglichkeit.

Nun gibt es diese 15%-Vorgabe aber nur für Blutzuckermessgeräte, nicht aber für Gewebezucker-Sensoren, insofern kann man diese Regel zwar für die eigene Bewertung heranziehen, nicht aber für eine Argumentation mit Abbott zwecks Reklamierung.

Zitat von klausiklaus

219 blutig vs. 272 mit Pfeil kerzengerade nach oben

Das ist ja mal grundsätzlich eine Situation, in der man den Blutzuckerwert mit dem Gewebezuckerwert gar nicht vergleichen kann. Insofern ist auch das Beschweren darüber ziemlich überflüssig.

Typischerweise kann ich bei uns auf dem Sensor bei Schwankungsbewegungen (steiler Anstieg/Abfall des BZ) ca. 12-15min nach der BZ-Messung den Sensorwert zum Vergleich heranziehen. Und dann passt der Wert auch bei starken Schwankungen sehr gut. Man muss halt die Verzögerung des Gewebezuckers zum BZ im Auge haben. Zusätzlich dann natürlich noch die durchaus existenten Abweichungen der Messgeräte (also auch 15% Abweichungsmöglichkeit des BZ-Messgeräts) einbeziehen.

Ich habe bei klausiklaus ehrlich gesagt den Eindruck, dass er die Sensorwerte nicht wirklich richtig einordnen kann.

Zur Präzision der Libre-Sensoren kann ich grundsätzlich mit Erfahrungswert n=2 (Tochter und ich) sagen, dass die sehr konsistent über die Sensoren hinweg ist.

Wir lassen dank gepatchter LibreLink die Sensoren mit den zusätzlichen 12 Stunden Nachlaufzeit über die 14 Tage laufen. Innerhalb der 12 Stunden Nachlaufzeit starten wir einen neuen Sensor, lassen aber weiter die Werte des alten Sensors bis zum endgültigen Ablauf (oder kurz vorher) weiter anzeigen und schalten dann auf den bereits ca. 8-12 Stunden vorher gestarteten neuen Sensor um. Und die minütlichen Werte des neuen Sensors laufen praktisch IMMER genau in der Fortsetzung des alten Sensors weiter, als hätte es gar keinen Sensorwechsel gegeben!

Ich finde es schon sehr merkwürdig, wie unterschiedlich die Vorgehensweise von Abbott bei verschiedenen Kunden ist.

Bei uns (Tochter und ich) gibt es bisher keinerlei Mitteilung über "Probleme" mit der weiteren Belieferung mit Libre 2 Sensoren.

Für Tochter habe ich im Februar ein neues Rezept eingereicht, da stehen im Kundenkonto unter "Rezeptbestellungen und Kostenübernahme" ganz normal geplante Termine im Quartalsrhythmus bis zur letzten im Dez 22.

Bei mir (Rezeptierung war in Nov 21) sind es noch zwei ausstehende Lieferungen, beide stehen im Kundenkonto ebenfalls ganz normal geplant für Juni und September 2022.

Ich sehe das Ganze entspannt. Ich kann mir nicht vorstellen, dass der Libre 2 überstürzt eingestellt wird.

Insbesondere kann ich mir die Panik nicht erklären, dass beim Libre 2 Patentverletzungen vorliegen, die der Libre 3 dann nicht haben soll. Wenn der Libre 2 tatsächlich deshalb vom Markt müsste, dann würde der Libre 3 meiner Ansicht nach zwangsläufig mit verschwinden. Da es danach nicht aussieht, kann ich mir das auch für den Libre 2 nicht denken.

Zitat von Angemessener Specht 67

Du bist der zweiter der das sagt, und ich kann das nicht nachstellen. Egal mit welchem Browser auf welchem System ich auf die Downloadseite gehe, ich sehe nie Werbung, und ich werde auch nicht umgeleitet sondern bekomme immer direkt die Datei (auch ohne AdBlock).

Dann bin ich der dritte. Ich bekomme da auch endlos sehr zweifelhafte Werbung, ohne dass der Download wirklich erscheint. Das ist für ein Modul, das auf einem gerooteten Handy laufen soll, natürlich nicht sehr vertrauenserweckend, zumal die Werbung seeeeehr dubios ist. Da kann man schnell davon ausgehen, dass das Modul selbst mit solchen Dingen (Glücksspiel, blaue Pillen etc) zu tun hat und besser nicht auf ein gerootetes Handy sollte.

Zitat von Kappa

Von der gepatchten App empfiehlt es sich, die zweite Version mit Verbindung zu Libre view zu verwenden. Nur mit dieser Version ist es möglich, nach einer Neuinstallation (z.B. wegen Handywechsel) die Bluetooth-Verbindung zu einem bereits gestarteten laufenden Sensor wieder herzustellen. Mit der ersten Version ohne Verbindung zu Libre view geht das nicht.

Nach mehreren Jahren der Benutzung der gepatchten LibreLink hatte ich nun das erste Mal den Fall, dass ein Libre 2 nach dem Aktivieren keine Werte per Bluetooth geschickt hat. Natürlich hat LibreLink auch nach "Alle Daten löschen"/Deinstallation und "Neu"-Aktivierung gesagt, der Sensor sei ja schon gestartet und die "Alarme" (also die minütlichen Werte) können nur mit dem Gerät empfangen werden, das den Sensor gestartet hat, also nicht diesem jetzt.

Dadurch, dass ich die Patch-Nachrichten nicht an xDrip+ senden lasse (mein Patch ist im Vergleich zum orginalen da etwas verändert), sondern an meine eigene App, konnte ich schnell feststellen, dass bei diesem Sensor in der LibreLink-App das "Streaming" der Bluetooth-Werte nicht aktiviert worden war, warum auch immer.

Ich habe im Smali-Code der LibreLink-App ein wenig gesucht und eine Stelle gefunden, an der man durch eine Änderung des Codes die Aktivierung mit Übernahme der Bluetooth-Verbindung erzwingen kann. Theoretisch gibt der Code sogar her, das über Preferences in der App zu machen, so weit bin ich da aber aus Zeitgründen dann nicht eingestiegen, sondern habe an bewusster Stelle radikal eine "Übernimm immer die Bluetooth-Verbindung des jetzt aktivierten Sensors" eingefügt.

Und es hat funktioniert!

Man kann durch Erweiterung des Patches also auch bei Handy-Wechsel mit der original gepatchten (ohne LibreView-Anbindung) LibreLink die Bluetooth-Verbindung auf das neue Handy übernehmen.

Da ich die ursprüngliche LibreLink-Patch-Anleitung bei mir einsetze, in der man alles von Hand macht (also nicht Tino Kossmans Script-Lösung!), funktioniert das ganze nicht für diejenigen, die mit Tino Kossmanns Skripten arbeiten, weil man vor dem Bauen der gepatchten APK eben von Hand eine weitere Änderung in einer smali-Datei machen muss, die von den Skripten nicht erfasst ist.

Wer aber die originale Patch-Anleitung (die in Englisch am Schluss von Tino Kossmanns Readme steht) anwendet, der kann durch eine kleine händische Änderung und dann Neubauen/Signieren/Installieren der LibreLink-APK eine Version erzeugen, mit der auch die Bluetooth-Verbindung eines laufenden Sensors übernommen werden kann.

Wer wissen möchte, wie das (eben auch ganz ohne die LibreView-Anbindung) funktioniert, kann mich gern über eine persönliche Nachricht kontaktieren.

Die Information, wieviel Insulin pro kg Körpergewicht andere brauchen, ist wirklich absolut nutzlos für die Regulierung des eigenen Insulinbedarfs (bzw. den des betreuten Kindes)!

Meine Tochter und eine Freundin (beide Typ 1) sind fast gleich alt (5 Monate auseinander) und annähernd gleich groß und schwer. Trotzdem braucht meine Tochter ungefähr doppelt so viel Basal wie die Freundin. Als beide 7 Jahre alt waren, hat die Freundin 3,5-4IE Tagesbasal gehabt, meine Tochter lag bei 7-7,5IE Tagesbasal. Bei beiden Kindern wurde der Basalbedarf durch Basalratentests bestätigt.

Man kann aus den Angaben anderer Leute also noch nicht einmal Anhaltspunkte ziehen, wie hoch der eigene Bedarf sein müsste.

Basalratentest machen. Anders geht es nicht.

Zitat von Hubi

dideldum Was macht die Eigenentwicklung in Sachen Loop?

Geht voran, bin aber noch an vielen Baustellen dran.

Zitat von TPM

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

Könnte man dann vielleicht schöner machen mit überlappenden Sensoren sobald das implementiert is.

Ja, das sieht interessant aus. Ist aber die Frage, ob das jemals implementiert wird, wenn es aufgrund des "geringen User-Impacts" zurückgestellt wird.

Zitat von Steve8x8

Um die zusätzlichen Patches zu basteln, fehlt mir die Zeit und die Einsicht in Smali, fürchte ich, oder gibt es die irgendwo im Netz?

Da musste ich jetzt aber doch nochmal nachträglich lächeln. Bist du nicht derjenige, der jede APK gleich erstmal auf Inhalte untersucht?

Nebenbei muss für meine beschriebene Methode kein neuer Patch gebastelt werden, das würde natürlich auch mit dem orginalen gehen, nur dass man dann immer nach 13 Tagen 23 Stunden bereits den neuen Sensor starten müsste und so nie zur gleichen Zeit setzen könnte. Die zusätzlichen 12 Stunden helfen halt dabei, immer im selben Setz-Rhytmus bleiben zu können.

Der eigentliche Zeitaufwand der Schritte 1 bis 7 ist übrigens keine 5min bei jedem Sensor-Wechsel. Da wird hier etwas übertrieben von einigen ein Drama draus gemacht, wo gar keins ist.

Ich wollte hier übrigens keine Diskussion starten, ob man nun mal ein oder zwei Stunden ohne Werte auskommen kann oder nicht. Darum geht es hier nicht. Das soll lediglich eine Anleitung sein, wie man die Ausfallzeit beim Sensor-Wechsel vermeiden kann (und zwar mit wirklich sehr geringem Aufwand). Wer es mag, der macht's, und wer nicht, der nicht.

Und damit ist für mich dieser Thread auch beendet.

mecki Bei uns läuft ein Loop. Da ist eine unterbrechungsfreie Werte-Versorgung von großem Vorteil. Das hat also nichts mit Hobby zu tun, sondern damit, dass unsere Diabetes-Therapie unterbrechungsfrei läuft. Ein ziemlich unqualifizierter Kommentar deinerseits. Es muss dir ja nicht gefallen, aber was lässt du denn dann so einen Quatsch vom Stapel?

Steve8x8 Natürlich würde es auch mit 2 Smartphones gehen, aber dann hat man nie alle Daten zusammen. Da bei uns nunmal der Loop läuft, wäre ein Tauschen des Smartphones mit jedem Sensor ziemlich blöd. Mit der geschilderten Methode hat man immer alle Daten zusammen im Haupt-System. Mit der von uns eigentlich benutzten Methode, ein NFC-fähiges Smartphone zum Starten zubenutzen, dann aber die Werte von einem nicht-NFC-fähigen Gerät empfangen zu lassen, muss man da natürlich tatsächlich ein zweites Start-Handy haben, aber das Hauptsystem läuft dann eben doch kontinuierlich unterbrechungsfrei vom alten auf den neuen Sensor. Für Looper, die auf die unter normalen Umständen notwendige Loop-Zwangspause bei Sensor-Wechsel verzichten wollen, ist meine geschilderte Methode aber durchaus praktikabel und überlegenswert. Ich habe das mit einem Laptop gemacht. Und USB-Kabel liegen bei uns im Haus in praktisch jedem Raum an Ladesteckern herum. Daran scheitert es also eher nicht.

bierernst Die Pumpe gehört ganz klar getauscht. Deine Dauerleiden mit den Batterien sind ja unzumutbar. Und eben auch nicht normal.

Ich steuere bei uns die 2 Dana RS (beide auch noch v1) mittlerweile mit den minütlichen Libre2-Werten an, die Pumpe wird also ca. 5mal so viel kontaktiert wie bei AndroidAPS normalerweise mit den 5minütigen Werten.

Bei 5minütiger Pumpensteuerung hält eine Batterie bei uns immer 35-38 Tage.

Bei minütlicher Steuerung hält eine Batterie 28-30 Tage.

Was bei dir mit der Pumpe passiert, ist weit jenseits dessen, was mit den Batterien passieren darf. Pumpe sofort umtauschen!

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