LLU Client

    Mit Libre3 hatte ich gehofft, dass back-logging (verpasste Werte) nach x-Drip nun funktionieren würde. Tut es leider nicht, zumindest nicht bei mir.


    Weder mit meinem aktuellen Setting L2 Sensor + patched App, noch mit meinem gerade laufenden Test L3 + LLU client.

    In die L3 app an sich (und hoch zu LView & LLUp) werden die Werte in jedem Fall nachträglich eingetragen.


    Funktioniert das bei irgendjemanden? Mache ich (in x-Drip) etwas falsch? Das wäre ein feature, was mich schon sehr interessiert.

    Ich habe auch einen Dexcom Sensor mit x-Drip getestet, dort funktionierte das back-logging zu x-drip, ohne dass ich bewusst irgendetwas dafür machen musste.

    Zitat von qwertz0815

    Mit Libre3 hatte ich gehofft, dass back-logging (verpasste Werte) nach x-Drip nun funktionieren würde. Tut es leider nicht, zumindest nicht bei mir.


    Weder mit meinem aktuellen Setting L2 Sensor + patched App, noch mit meinem gerade laufenden Test L3 + LLU client.

    Das back-logging müsste ich im LLU Client implementieren. Ich weiß allerdings nicht was xDrip+ da benötigt. Müsste ich mich erst mal schlau machen...

    nechoj: Erst einmal vielen Dank für deinen LLU Client


    Ich bin weder xDrip-Nutzer, noch hab ich eine Smartwatch oder sonstige zusätzliche Geräte, aber die Möglichkeit, meinen aktuellen Glukosewert direkt auf dem Sperrbildschirm anzeigen zu lassen, ohne dass ich mein Smartphone in die Hand, entsperren, App öffnen und dann 10 Sekunden warten muss, bis sich die App gefangen hat und etwas anzeigt, ist für mich - Gold wert.


    Wie PythonF bereits vorgeschlagen hat, würde ich mich freuen, wenn ich mich irgendwie an der Entwicklung beteiligen könnte und der Quellcode auf Github o.ä. gehostet werden könnte. Ich könnte dabei meine Unterstützung anbieten.


    Ich bin zwar Software-, aber kein Android/Kotlin-Entwickler, dennoch kribbelt es mir schon ziemlich in den Fingern, denn etwas, das mir noch auf dem Sperrbildschirm fehlt, ist ein Indikator zur Aktualität des Messwertes, denn der Timestamp ist mMn nicht optimal: Blick auf Zeit, suche Minute, vergleiche mit aktueller Uhrzeit.


    Dadurch, dass du uns freundlicherweise den Quellcode zur Verfügung gestellt hast (scheint aber leider nicht der aktuelle zu sein), kann ich das auch für mich implementieren und nutzen. Aber davon habe dann nur ich etwas. Und vielleicht hat auch jemand anderes daran Interesse, bzw. vielleicht findet sich noch der ein oder andere Entwickler, welcher etwas zu dieser kleinen aber feinen App beitragen kann:

    - verbessern Power Consumption

    - robusteres Error Handling

    - Code Qualität

    - Kompatibilität

    - ordentliche Versionierung

    - etc.

    2 Mal editiert, zuletzt von cmtjk ()

    Gefällt mir 1
    Zitat von cmtjk

    Ich bin zwar Software-, aber kein Android/Kotlin-Entwickler, dennoch kribbelt es mir schon ziemlich in den Fingern, denn etwas, das mir noch auf dem Sperrbildschirm fehlt, ist ein Indikator zur Aktualität des Messwertes, denn der Timestamp ist mMn nicht optimal: Blick auf Zeit, suche Minute, vergleiche mit aktueller Uhrzeit.

    Bei mir sieht die Benachrichtigung auf dem Sperrbildschirm so aus:



    bzw.



    Die Aktualität des Messwerts ist also direkt sichtbar (jetzt bzw. 1 Min). Eventuell ist das eine Android-Einstellung ob das angezeigt wird oder nicht?

    nechoj

    Zitat von nechoj

    Die Aktualität des Messwerts ist also direkt sichtbar (jetzt bzw. 1 Min). Eventuell ist das eine Android-Einstellung ob das angezeigt wird oder nicht?


    Oh, ja du könntest Recht haben. Ich habe ein Honor Play mit EMUI 9 und die Einstellung nicht auf Anhieb gefunden, daher sieht es bei mir aktuell so aus:


    Aber selbst auf api-de.* umgestellt, da deine Sourcen anscheinend nicht die aktuellen sind, aber bitte nicht falsch verstehen: Das ist dein Client und ich bin schon dankbar endlich auf unkomplizierte Weise meinen Wert direkt auf dem Sperrbildschirm sehen zu können - was der offiziellen App merkwürdigerweise fehlt - und das gilt für alle LibreView/LinkUp-Nutzer. Wenn du mit Github keine Erfahrung und vielleicht auch keine Zeit oder Muse hast, ist das völlig in Ordnung.


    Scheint aber Interesse zu geben: https://github.com/NightscoutF…4#issuecomment-1172005022

    Hallo,


    die App funktioniert bis jetzt gut. Es wäre super wenn man die Werte auch in mmol anzeigen könnte wie in der Libre App.

    Ich hoffe das zu implementieren ist nicht all zu aufwendig.

    Hallo,


    ich hab den LLU Client noch einmal für mich implementiert, da mir ein paar Kleinigkeiten gefehlt haben (Trendpfeil, vergangene Zeit seit letzter Messung, Log).



    https://github.com/cmtjk/LLUClient

    (Download auf der rechten Seite)


    Hätte das gerne zu Nechojs Implementierung beigetragen jedoch ist diese nicht auf Github.


    Der LLU Client läuft bei mir auf zwei Geräten, kann aber keine Kompatibilität mit Android <9 garantieren. Falls Interesse für ältere Geräte existiert, dann einfach kurz melden.

    hi,
    ist super mit trendpfeil, nur läuft der llu client bei mir nicht, ich bekomme nur einmal einen wert, danach nicht mehr, eine idee warum das so ist?
    android 12 und motorola edge pro.

    Zitat von mic.bru

    hi,
    ist super mit trendpfeil, nur läuft der llu client bei mir nicht, ich bekomme nur einmal einen wert, danach nicht mehr, eine idee warum das so ist?
    android 12 und motorola edge pro.

    Klingt nach Akkuoptimierung. Hast du diese für die App deaktiviert, damit der Service nicht pausiert wird? Oder bekommst du auch keinen Aktualisierung, wenn die App offen ist?
    Wenn die App aktiv ist, dann sollten im Debug-Log (falls aktiviert) im entsprechenden Intervall Log-Einträge erscheinen. Siehst du diese?

    Ich hab Android 9, aber die App im Emulator mit Android 12 entwickelt.

    Einmal editiert, zuletzt von cmtjk ()

    Zitat von cmtjk

    Hallo,

    ich hab den LLU Client noch einmal für mich implementiert, da mir ein paar Kleinigkeiten gefehlt haben (Trendpfeil, vergangene Zeit seit letzter Messung, Log)

    Danke für deinen Beitrag. Für uns Anwender ist es ja begrüßenswert, wenn mehrere Programmierer an einem Projekt arbeiten und sich ggf ergänzen.


    Aber wie ist "für mich implementiert" zu verstehen? Ist das eine Weiterentwicklung der App von nechoj ? Hast du dich mit ihm abgestimmt? Basiert das auf seinem Quellcode und hattest du die letzte Version dieses Codes, um den zu ergänzen bzw zu verändern.


    Da ich nächste Woche den Libre 3 erstmals einsetze, stellt sich mir die Frage, welche App ich verwende. Für mich und wahrscheinlich viele andere Nutzer ist der wesentliche Zweck, die Sensorwerte in xDrip zu bekommen. XDrip hat übrigens eine eigene Anzeige auf dem Sperrbildschirm, darüber hinaus aber noch eine geniale Vorhersage Simulation, Widget, Anbindung vieler Uhren, bessere Statistiken ....


    Kann deine App ebenfalls die Sensorwerte in xDrip importieren? Wenn ja, was ist dort als Datenquelle einzustellen? Könntest du bitte klarstellen, was genau der Unterschied zu Nechojs Version ist. Besten Dank.

    Zitat von cmtjk

    Klingt nach Akkuoptimierung. Hast du diese für die App deaktiviert, damit der Service nicht pausiert wird? Oder bekommst du auch keinen Aktualisierung, wenn die App offen ist?
    Wenn die App aktiv ist, dann sollten im Debug-Log (falls aktiviert) im entsprechenden Intervall Log-Einträge erscheinen. Siehst du diese?

    Ich hab Android 9, aber die App im Emulator mit Android 12 entwickelt.

    Wenn die App offen ist, wird auch nichts aktualisiert,

    bekomme im Debug-Log diese Meldung:

    token still valid,
    fetching connections...

    using connectinsID:

    Einmal editiert, zuletzt von mic.bru ()

    Hallo Kappa,


    ich kann mir sehr gut vorstellen zu nechoj App meinen Teil beizutragen, jedoch ist diese leider (noch) nicht auf GitHub o.ä. verfügbar und der angehängte Source Code nicht die aktuelle Version.

    Ich fand die Idee von nechoj aber so gut und für mich extrem hilfreich - die Libre 3 App wird mit zunehmender Dauer immer träger (vgl. Play-Store Bewertungen), bei mir dauerts mittlerweile lange 10 Sekunden, bis die App irgendetwas anzeigt - das ich den LLU Client neu implementiert hab. In Java, statt Kotlin, weil ich damit absolut keine Erfahrung habe. Dennoch geht mein Dank natürlich an nechoj. Wird auch auf der Projektseite genannt.
    Dadurch habe ich für mich alles in der Hand und kann auch rumprobieren, wie ich die Notifications auf meine Smartwatch bekomme.

    Also keine Weiterentwicklung, sondern eine Reimplementierung mit zusätzlichen Features, welche ich für mich als sinnig erachtet habe.

    Mit xDrip habe ich noch nie genutzt und auf der Projektseite habe ich auch geschrieben, dass es unwahrscheinlich ist, dass mehr Features von meiner Seite implementiert werden.


    "für mich implementiert" heißt im Grunde: Darf jeder nutzen, forken, weiterentwickeln, etc., aber es ist in Zukunft offen, wie viel Zeit ich dauerhaft in die Entwicklung stecken kann/möchte.
    Daher kann ich keine Kompatibilität mit Geräten oder 100% Funktionstüchtigkeit garantieren. Solange ich Interesse daran habe, passe ich die App an, füge vermutlich noch mmol/l hinzu, und ändere die Aufrufe, falls Abbott auf die Idee kommt die LibreView-Api zu ändern. Deshalb halte ich die Features schlank.


    Das Ziel der App ist im Grunde nur den aktuellen Wert von der LibreView-Api als Notification anzuzeigen. Mehr nicht. Kein Export, kein Verlauf, keine Alarm. Nichts, was die Wartung der App aufwendiger macht.

    Nichtsdestotrotz ist die App öffentlich auf GitHub und jeder kann sie weiterentwicklen und seinen Teil beitragen, wenn er/sie ein eigenes Feature benötigt.


    Dennoch möchte ich die App niemandem vorenthalten. Wem Notifications ausreichen und bei wem die App funktioniert (sollten alle Smartphone mit Android 9+ sein): Gerne.

    Zitat von mic.bru

    Wenn die App offen ist, wird auch nichts aktualisiert,

    bekomme im Debug-Log diese Meldung:

    token still valid,
    fetching connections...

    using connectinsID:

    Hi mic.bru,


    tja, schlechte Nachrichten: die Logs sehen gut aus. Solange die so runterlaufen und kein Fehler zeigen, sondern regelmäßig den Payload loggen (die Daten, welche von den geschweiften Klammern umgeben ist, funktioniert alles).

    Außer...Android 12 oder Motorola geht irgendwie anders mit Notifications um.

    Ich hab es jetzt noch einmal im Emulator mit Android 12 ausprobiert und dort funktioniert es.

    Da ich kein physisches Gerät mit Android 12 zur Verfügung habe, kann ich es leider nicht live testen.

    Typischerweise sorgt die Akkuoptimierung dafür, dass Apps/Services im Hintergrund nicht ausgeführt werden, aber wenn du die App offen hast, wird diese auch nicht automatisch pausiert.

    Du könntest - wenn möglich - einmal probieren alles zu starten und dann dein WLAN und Mobile Daten ausmachen. Dann sollte in den Logs ein Connection Error erscheinen und auch die Notification entsprechend aktualisiert werden.

    Die Notification alamiert nur einmal (Vibration o.ä.). Danach wird sie nur noch im Hintergrund aktualisiert. Du musst also einmal oben runterswipen, um die aktualisierte Notification zu sehen.


    Dein Screenshot oben kannst du gerne wieder löschen. Da steht deine ConnectionID drin. Damit kann man vermutlich nichts anfangen, aber sind doch irgendwie persönliche Daten.


    Ja, ohne WLAN und Mobile Daten bekomme ich ein Connection Error,
    im debug-log wird das auch immer wieder aktualisiert.
    Nach wieder Einschalten von WLAN und Mobile kommt wieder nur eine Meldung.

    Dann ist das so, Gerät und/oder Android 12.

    Danke, für deine Mühe.

    Zitat von mic.bru


    Ja, ohne WLAN und Mobile Daten bekomme ich ein Connection Error,
    im debug-log wird das auch immer wieder aktualisiert.
    Nach wieder Einschalten von WLAN und Mobile kommt wieder nur eine Meldung.

    Dann ist das so, Gerät und/oder Android 12.

    Danke, für deine Mühe.

    Klar doch.

    Ich kann mir vorstellen, dass dadurch, dass die Notification dauerhaft "silent" aktualisiert wird, dass sich das auf unterschiedlichen Geräten ggf. unterschiedlich äußert.

    Bei mir vibriert das Smartphone einmal beim Starten des Services und die Notification wird oben angezeigt und wird dann nach wenigen Sekunden ausgeblendet.

    Die Notification lässt sich nicht "wegwischen", sondern bleibt dauerhaft vorhanden und von da an nur noch "silent" aktualisiert. Das Smartphone vibriert nicht und macht auch keinen Ton und die Notification erscheint auch nicht für einige Sekunden am oberen Bildschirmrand.

    Das ist das Verhalten, welches ich mir vorstelle, da es ausreicht, damit der aktuelle Wert in den Notifications und auf dem Sperrbildschirm dauerhaft angezeigt wird.


    Deine gezeigten Logs sahen auch so aus, als hätte das wie gewünscht funktioniert :/


    Theoretisch könnte man dieses Verhalten konfigurierbar machen, sodass die Notification jedes mal kurz am oberen Bildschirmrand erscheint.


    Dennoch danke für deine Rückmeldung, ich hab noch einmal eine Version nachgeschoben, welche die Connection ID in den Logs verschleiert :thumbup:https://github.com/cmtjk/LLUClient/releases/tag/v1.1.2

    cmtjk vielen Dank für die Erläuterungen. Demnach besteht ein wesentlicher Unterschied zwischen deiner App und LLUClient, nämlich die nicht vorhandene / vorhandene Verbindung zu xDrip. XDrip ist sehr weit verbreitet und bietet auch eine Kopplung mit AAPS, der Looper App. LLUClient ist auch in der Looper Community (anderes Forum) bekannt geworden, um die Libre 3 Daten zur Steuerung eines Loops verwenden zu können.


    Deshalb wird es zu großer Verwirrung führen, dass du nun deine App unter dem selben Namen aber mit anderer Funktionalität veröffentlichst. Deine App hat sicherlich Interessenten und dein Angagement ist sehr lobenswert. Aber es wäre besser, wenn du dafür einen anderen Namen verwendest oder zumindest deutlich kenntlich machst, dass damit keine Sensordaten an xDrip geliefert werden können. Ansonsten wird es zu Verwechslungen kommen.

    Zitat von Kappa

    cmtjk vielen Dank für die Erläuterungen. Demnach besteht ein wesentlicher Unterschied zwischen deiner App und LLUClient, nämlich die nicht vorhandene / vorhandene Verbindung zu xDrip. XDrip ist sehr weit verbreitet und bietet auch eine Kopplung mit AAPS, der Looper App. LLUClient ist auch in der Looper Community (anderes Forum) bekannt geworden, um die Libre 3 Daten zur Steuerung eines Loops verwenden zu können.


    Deshalb wird es zu großer Verwirrung führen, dass du nun deine App unter dem selben Namen aber mit anderer Funktionalität veröffentlichst. Deine App hat sicherlich Interessenten und dein Angagement ist sehr lobenswert. Aber es wäre besser, wenn du dafür einen anderen Namen verwendest oder zumindest deutlich kenntlich machst, dass damit keine Sensordaten an xDrip geliefert werden können. Ansonsten wird es zu Verwechslungen kommen.

    Ursprünglich hatte ich gehofft, meine Änderungen als PR in den @nechojs LLU Client einfließen zu lassen oder zumindest zur Diskussion zu stellen.

    Jedoch ist der aktuelle Code nicht öffentlich oder versioniert, dementsprechend ist ein Beitrag schwierig oder von welchem LLU Client sprechen wir hier?


    LLU heißt wohl allgemein LibreLinkUp und bei den populären Sourcecode-Hostern und Google war kein Projekt mit dem Namen zu finden, also hab ich mir nicht wirklich Gedanken darüber gemacht den Namen zu ändern. Liegt ja auch in einem eindeutigen Namespace und der Name ist sehr allgemein.


    Ich hab einen Hinweis reingemacht, dass dieser Client keine xDrip-Integration bietet. War beim durchstöbern des LLU Client Codes auf keinen Hinweis gestoßen, dass dieser so etwas kann.


    Sorry, bin erst vor knapp einer Woche auf den Zug aufgesprungen und kenne mich in der Diabetes-App-Welt noch nicht aus.

    Einmal editiert, zuletzt von cmtjk ()

    Zitat von cmtjk

    welchem LLU Client

    Was Kappa, denke ich, meint:

    DER (also nechoj 's) LLU Client, ist genau unter dem Namen "LLUClient" bekannt. Und in der Community ist bekannt, dass man mit del LLUClient die Werte zu XDrip transformieren kann und somit die Werte auf Uhren anzeigen kann oder zum Loopen verwenden. Auch wenn es keinen öffentlichen Source Code gibt, wird er LLUClient damit gleich gesetzt, mit dem Libre 3 endlich wieder mit XDrip arbeiten zu können.


    Gibt es jetzt plötzlich einen zweiten LLUClient, wird das ziemlich sicher zur Verwirrung führen, früher oder später vermutlich auch dazu, dass Du und nechoj mit Nachrichten bombardiert wird, warum denn das nicht geht.


    Wenn ich jetzt einem Freund erzähle, hey, lade dir den LLUClient runter, er googelt danach, findet deinen und dann geht das alles nicht, was ich ihm erzählt habe, wird der sich früher oder später bei dir melden und fragen, wie das denn mit der "neuen" Version geht xD