Beiträge von cmtjk

  • LLU Client

    Hi techn,


    yes I accept patches but since I don't have a garmin watch and therefore can't test expect to become a collaborator for support on the garmin part.

    You can also fork LinkUpConnect.

  • LLU Client

    Zitat von AndiHeitzer

    Über zwei Jahre habe ich die 'Innovation', den BZ per API abgreifen zu dürfen erfolglos an der Hotline und auch zweimal einem Techniker vorgetragen.

    Ich behaupte mal: "Abbott will das nicht!"

    Und so, wie das derzeit aussieht, holt sich die Community dann die Innovation selber ...

    Wollen nicht und gehen dagegen vor: https://github.com/github/dmca…9/11/2019-11-08-abbott.md

    Bei meiner alten Uni haben sie vor ein paar Jahren versucht die Daten für eine Typ-2 Studie aus dem FL 1 rauszudröseln und sich entsprechend um "veröffentlichbaren" Methoden bemüht. Hat nicht geklappt.

    Die Libre 2 patched App und die gecrackte Libre 3 App sind schon richtiges Gefrickel und wer weiß in welche Trickkiste man da greifen muss oder ob der Juggluco-Entwickler nur zum Spaß den "Sensor bestellen"-Menüpunkt gekapert hat :wacko:

  • LLU Client

    Zitat von WeggliNet

    Ja genau. Hier ist mmol/l Standard, daher kann ich mit mg/dl nicht viel anfangen... in Deutschland ist das ja umgekehrt 🙃


    Update: Version 1.3.1 läuft bis jetzt tadellos.

    Schön zu hören :thumbup:(Übertragung nach xDrip ist in 1.3.1 kaputt, 1.3.2 funktioniert).

  • LLU Client

    Zitat von WeggliNet

    Alles klar, hab ich gemacht. Scheint tatsächlich auch einen mmol/l Wert anzugeben, Value 6.6 stimmt.

    Vielen Dank, sehr hilfreich!


    Ab v1.3.0 wird nun auch mmol/l unterstützt: https://github.com/cmtjk/LinkUpConnect/releases


    Ich selbst verwende mg/dl, daher konnte ich es nicht "live" testen, sondern nur mit fixen Daten in der IDE. Daher bin ich für Feedback dankbar.


    Die App nimmt für die Darstellung den Wert direkt aus dem Payload. Es findet keine Umrechnung statt. Bei xDrip wird umgerechnet und dort kann man beliebig zwischen mmol/l und mg/dl wechseln: Das ist aber, glaube ich, nicht erwünscht, oder? Dein Libre ist einfach nur auf auf mmol/l eingestellt und du möchtest die Werte wie in der Libre App oder LibreView, etc. gewohnt auch in mmol/l dargestellt haben?


    Kappa wie immer vielen Dank für die Erläuterungen und Hinweise: Ich werde bei Gelegenheit einen eigenen Thread aufmachen und mich auch einmal im Looper-Forum umschauen :thumbup:

  • LLU Client

    Zitat von WeggliNet

    cmtjk


    was brauchst Du genau bzgl. mmol/l Integration ? einfach die paar Logzeilen wenn Debug aktiviert ist ? kenn mich damit null aus.

    Läuft ansonsten 1a.

    Hallo, ich bin mir leider nicht sicher, ob die Schnittstelle direkt einen Wert für mmol/l zurückgibt, oder das selbst umgerechnet werden muss.

    Ich bekomme meine Werte in mg/dl und mein Payload in den Logs sieht wie folgt aus:


    Mir würde erst einmal ein Screenshot von den Logs reichen, um festzustellen, ob dieser unterschiedlich ist.

    Auf der anderen Seite scheint die Umrechnung relativ einfach und könnte im Zweifelsfall auch implementiert werden.

  • LLU Client

    Hallo AndiHeitzer  Kappa  nechoj,


    vielen Dank für die ausführlichen Erläuterungen. Jetzt, da ich die ursprüngliche Motivation des LLU Clients kenne und verstanden habe, denke ich, dass man gut zusammenarbeiten kann.


    Ich habe mir jetzt mittlerweile auch xDrip+ genauer angeschaut: Klasse App.

    Nutze diese jetzt ebenfalls nebenbei ein bisschen, da diese einen grafischen Verlauf in der Notification anzeigt :thumbup:


    nechoj: den Intent-Broadcast habe ich gestern implementiert und ist in der 1.2.0 Version dabei: https://github.com/cmtjk/LinkU…17a3e85a21f92acdR182-R194


    Jedoch bin ich mir nicht sicher, ob noch weitere Details des LLUClients fehlen.

    Ich war mir dieses Features, wie gesagt, gar nicht bewusst und der xDrip-Broadcast ist nur ein paar Zeilen Code, die völlig untergegangen sind. Ich dachte der LLU Client bietet "nur" die Notification und ich habe mir auch zugegebenermaßen nicht alle Seiten hier durchgelesen :|


    In jedem Fall eine schlaue Lösung, um die Daten nach xDrip zu bekommen ohne irgendwelche Sicherheitsvorkehrungen "aushebeln" oder wartungsintensive Lösungen pflegen zu müssen.


    Auf xDrip-Seite scheint der LibreReceiver (https://github.com/NightscoutF…exdrip/LibreReceiver.java) auch ziemlich stabil, dennoch muss man diese als Abhängigkeit im Auge behalten. Mit wachsender Zahl and Libre 3-Sensoren wird dieser vielleicht vernachlässigt oder komplett entfernt. Weiß nicht wie das xDrip-Team das hält.

    Und da finde ich es nur von Vorteil das Projekt auf Github zu hosten. Denn etwaige Anpassungen in der Zukunft kann dann im Grunde jeder machen.


    Ich bin selbst kein App-Entwickler und daher selbst froh, wenn es Beiträge gibt.

  • LLU Client

    Franz11  nechoj  AndiHeitzer  Kappa


    Hallo zusammen,


    ich hab meine Hausaufgaben gemacht und mir angeschaut, wie der LLUClient eigentlich die Daten nach xDrip bekommt:


    - https://github.com/szpaku80/Li…irdPartyIntegration.smali

    - https://github.com/NightscoutF…ip/LibreReceiver.java#L45


    Und das ganze bei mir Implemntiert und getestet.


    Ich sehe die Namenskollision in jedem Fall ein und möchte mich noch einmal dafür entschuldigen. Das war aus der Situation heraus unüberlegt und gegenüber nechoj maximal respektlos.

    Den Namen werde ich heute noch ändern und die Verbindungen zum LLUClient entfernen.


    Dennoch möchte ich gerne dazu aufrufen, dass derartige Projekte der Community in einer zeitgemäßen Form zur Verfügung gestellt und die Mitarbeit daran ermöglicht wird.

    Der aktuelle LLUClient ist für mich keine Option, den wenn morgen sein Entwickler keine Lust mehr darauf hat oder private Gründe die Anpassung oder Weiterentwicklung verhindern, ist vermutlich nur jemand hier im Kreise des insulinclubs in der Lage, dies anzupassen, wenn sich z.B. bei xDrip oder der LibreView-API etwas etwas ändert.

    Das setzt natürlich voraus, dass der aktuelle Sourcecode zur Verfügung steht.


    Ich habe jetzt innerhalb kurzer Zeit - natürlich mit Starthilfe von nechojs Implementierung - den kompletten LLUClient reimplementiert, Trendpfeil hinzugefügt, xDrip-Übertragung, mmol/l-Unterstützung implementiert und bin gerade an der Internationalisierung dran - für Personen außerhalb DE oder EU.

    Und das könnte alles Teil des original LLUClients sein oder werden, wenn man die Mitarbeit ermöglichen würde. Denn da draußen gibt es genug fähige Entwickler, welche ihren Teil beitragen können.


    Da ich xDrip (noch) nicht nutze, werde ich die xDrip-Übertragung in der neuen Version deaktivieren, bis sich die Funktion jemand wünscht, die App umbennen und auch nicht bewerben, vor allem nicht als Konkurrent.

    Ich werde sie dennoch weiterhin öffentlich hosten und weiter "für mich" und Interessenten pflegen und weiterentwickeln.


    Ich sehe zu, dass ich alle Verbindungen zum LLUClient entferne oder aktualisiere. Das schließt die Posts hier ein. Das ich denselben Namen verwendet habe war echt großer Mist.

    Ich möchte mich da gar nicht rausreden, aber ich habe das Projekt als Hobbyprojekt wahrgenommen, da es keinerlei Präsenz auf GitHub/GitLab und nur hier im Forum hatte.


    Bis heute Nachmittag habe ich das voraussichtlich bereinigt. Bis jetzt scheint die Datenkrake Google das noch nicht aufgeschnappt zu haben. Dann sollte keine Verwirrung entstehen.

  • LLU Client

    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.

  • LLU Client

    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

  • LLU Client

    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.

  • LLU Client

    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.

  • LLU Client

    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.

  • LLU Client

    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.

  • LLU Client

    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

  • LLU Client

    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.