Habe seit 6 Stunden Signalverlust beim Libre Sensor, gibt es da noch irgendeinen Trick, die Verbindung wieder herzustellen? Hatte das Problem noch nie.
Handy? Schalt mal Bluetooth aus und an. Das stellts bei mir eigentlich immer wieder her.
Wenn das die Verbindung mal verliert, bleibt die einfach weg bis ich das mache. Doofer Bug.
Das ist ein riesiger Schritt vorwärts für die Community.
Grob gibts bei Analoginsulinen drei Wirkstoffe, die sich geringfügig unterscheiden und alle leichte Veränderungen des Humainsulins sind.
Hier kurz nur die 3 Arten und ein prominenter Produktname:
Insulin Lispro (Humalog, von Lilly)
Insulin Aspart (Novorapid, von Novo Nordisk)
Insulin Glulisin (Apidra, von Sanofi)
Bei der Argumentation ist so was wie "stell ich mir bequemer vor" halt leider Gift.
10 Nadeln ist aber z. B. ein Grund für eine Insulinpumpe, denn diese wird auch indiziert wenn man mehr als die durchschnittlich 5 Nadeln am Tag verwenden muss.
Bei mir hat der MDK das trotz einer Einstellung die eigentlich ganz okay war dann zugestimmt, weil ich eben 8 oder mehr steche um den Blutzucker gezielt unter Kontrolle zu haben.
So ein Aufwand ist eben auch eine Lebenseinschränkung und bei der Zustimmung geht es sowohl um Einschränkungen des Lebens als auch medizinische Notwendigkeit. Wenn man das argumentiert, sehen das Ärzte auch oft ein, dass die Aufhebung eben dieser Lebenseinschränkung die medizinische Notwendigkeit auslösen würde.
Zum Spaß macht man das aber absolut nicht, man erkauft sich weniger Stechen und eine feinere Kontrolle dadurch dass man diese Kontrolle aber auch wirklich gewissenhaft ausführen muss. Da können auch mehr Dinge schief gehen, und wenn das eben passiert hat man dann überhaupt kein Insulin mehr (wenn man 0 Produktion hat eben). Basalinsulin das man sich einmal am Tag spritzt bleibt ja bis zu 26 Stunden im Körper (Toujeo z. B.).
Aber wenn man sich da ernsthafte Gedanken drüber macht und erstmal viel drüber liest, kommt man da schon drauf was das für ein "Berg" ist, den man da im Kopf besteigen muss.
Ich hatte jetzt 2-mal leichte Schwierigkeiten mit Tresiba 200. Kommt nur mir das seltsam vor, wie es immer mehr Lieferengpässe gibt? Bauholz, Klopapier, Ol, Nudeln,.... , Hustensaft, Insulin. Hört das noch mal auf oder geht das jetzt immer so weiter?
Die Schöpfungsketten sind allgemein gerade hart belastet. Da muss ich mich auch ein wenig ärgern, weil im BWL immer so das Just-In-Time angepriesen wurde. Richtiges Schönwettersystem, da man die Lager klein hält (Lagerplatz ist doch so teuer!). Jetzt sehen wir den Nachteil dieses Systems: Kaum laufen die Ketten aus dem Ruder, gibt es keine Lager mehr die das auffangen und die ganze Kette bricht auseinander.
Was Medizin angeht seh ich grad schon ein paar Dinge bei mir auch in der Knappheit, z. B. das ACC das ich ständig brauche.
Was das Problem hier grade auch wieder ist, bei dem Hustensaft: Die Zutaten kommen wieder aus China. Die ganze Arzneimittelbranche hängt am Tropf von China und Indien.
Eine der Firmen die z. B. das reine Ibuprofen herstellen ist die hier: 湖北亨迪药业股份有限公司_[官网] (biocause.com)
Es gibt momenten 11 aktive Hersteller hier, Certificates Results (edqm.eu), Indien, China... und dann noch 2 mal USA (BASF produziert in Texas)
Das zieht sich halt leider momentan durch den gesamten Markt so durch. Der Lauterbach will ja versuchen, die Pharmafirmen dazu anzuregen, wieder mehr in den EU zu produzieren, also auch die Hilfs- und Grundstoffe hier zu produzieren.
So was war ich auch schon am überlegen ob ich das schreiben soll... Jetzt kamst du mir wohl zuvor 
mit GlucodataAOD hab ich jetzt aktuell ja im Quellcode ja auch was drin um einen eigenen Glucodata-Broadcast zu machen, falls man den Wert aus ner anderen Quelle holt (da ist der xdrip Companion implementiert). Da es für mich wohl mittelfristig dahin gehen wird dass ich weder Juggluco noch die Libre 3 app verwende (CamAPS-FX Mit Ypsopump, die liest den Libre selbstständig aus). Aber da gehts eher Richtung Off-Topic.
Bis jetzt benutze ich dafür G-Watch, aber ich probier das auf jeden Fall damit mal. Wahrscheinlich kann ich auch mit meinem eigenen Glucodata-Broadcast die dann füttern.
Wie schon TryHarderFish richtig verlinkt hat, denke ich, dass alex2010 sich vorrangig auf den Juggluco-Thread bezieht.
Und ganz ehrlich: da werden von deutschsprachigen Personen wie sinni800 Beiträge auf Englisch verfasst, obwohl jka den Thread auf Deutsch angefangen hat und in genügend Beiträgen gezeigt hat, dass zur Kommunikation mit ihm Englisch nun wirklich nicht nötig ist.
Warum werden da also Beiträge von lauter Leuten in Englisch verfasst, die ansonsten Beiträge in Deutsch schreiben? Das macht das Lesen und Verstehen für Nicht-Englisch-Verstehende wirklich überflüssig schwierig. Und obwohl ich des Englischen durchaus mächtig bin, nervt mich diese absolut unnötige Sprachumschaltung auch.
Ich kann sagen wieso ich das tue, weil jka bei komplizierteren Zusammenhängen sonst aus der maschinellen Übersetzung nicht versteht was ich eigentlich sagen will. Ist leider schon öfters passiert.
Selbst bei Themen die dann am Ende nicht so programmierlastig sind, ging da leider schon mehrmals Kontext verloren. Daher ist das für mich gerade schneller.
Aber ich schaue dass ich die Dinge einfach doppelt schreibe, ich möchte rüberbringen was ich sagen will, aber nicht die Leute hier die dem Englischen nicht so mächtig sind vor den Kopf stoßen
You seem to think that because Android is made a certain way, it has to be efficient. That is really stupid. Do you want to say that the Libre3 app is smaller and faster than Juggluco?
I never said such a thing, I analyzed the code on how the resources actually worked, thats all. I don't have a problem with that you don't try to do everything in the most Java and Android way possible...
I never said I think Android is efficient. My point would have been that we're looking in the territory of micro-optimizations that end up making little improvements in the grand scheme of things, but are overall reducing the readability and maintainability of our code. Finding a good middle way and not reinventing every wheel is, to me, a basic tenet of application development that isn't stuck in the 80s.
That said, I think Juggluco is in the current form SUPER efficient with resources. That is absolutely commendable and awesome. I don't want to ruin that at all.
And for the record, I think the Libre 3 original app is absolutely terrible when it comes to memory usage as it has a some sort of memory leak (not in the literal sense, it accumulates data) that will, over time, make it become larger and larger, and also slower and slower. It uses like 400 mb for me now (according to Android settings, that likely doesn't include shared memory usage)
This is in the end a medical application that many people are trying to rely on and some here have already been burned by the opaque situation that, for example, broke itself with updates and are now ending up to stop updating ever again. And it's supposed to be their own fault for using "hacked apks" (I don't think anyone did that) or having a "corner case". I think that's somewhat... irresponsible. Maybe it would be better to have a big disclaimer on the page. That this is essentially beta software that tries to reverse engineer and reimplement a closed, proprietary system and that there may be errors.
I am not trying to find fault, I am trying to make the situation better for everyone and I am willing to put some work into cooperating on that. I made an app that uses the glucodata broadcast to show it on the always-on-display, and I am leaving my pants down figuratively on this: sinni800/glucodata-aod - glucodata-aod - mgs git (metalgearsonic.de). The code is probably pretty bad (primarily the GUI code), but it was the first thing I made in Android Studio.
Regarding the translation: Since the types are hidden in the headers, there was really no way I could have knowm how many bytes are reserved for each of those, its would be a good idea to document these byte length limitations on the site, I think.
Zitatthese structures already sit in installed programs
This is honestly why GNU gettext was made, to access translation strings. This is a micro-optimization that is now locking out less fortunate languages like German because of our word length.
"Benachrichtigung" has a shorter, good word for German: "Mitteilung", which is only 11 characters including null termination.
Such a C++ struct uses a small fraction of the RAM in comparison to these Android resources.
I know this sounds logical but I would love to know how much it actually is. And I admit I have no real way to find out, I'm not all-knowing after all. I know that the string resources are all parsed and saved on the heap by android.content.res.AssetManager, which uses cpp code (made for JNI, so it does create Java objects in the end). From what I can see these don't retain the original XML structures at all, and instead save in "ResTables" that use maps with resource ids to resources, and those resource IDs are implicitly created integers in our resource namespace anyway. So from what I can tell from reading Android code they don't look "horrifying", and languages or resource files that are not used aren't parsed at all.
Last time we discussed ram you included shared memory allocations in the "ram usage" of the application, shared memory that is shared system wide, making 64 bit memory usage insanely blown up. I think there needs to be a bit of a higher standard in seeing what one "probably assumes" to be the case as the true facts and that your own code is always better than what these weird Californian Google dudes can produce.
For translations, here's a few things I found
< constexpr static std::string_view delabels[]={ "Ins schnell", "Kohlenhydra", "Dextrose", "Langes Insu", "radeln", "Walk", "Blut"};
> constexpr static std::string_view delabels[]={ "Schnellinsulin", "Kohlenhydrate", "Dextrose", "Verzögerungsinsulin", "radeln", "Walk", "Blut"};
> .monthlabel={ "Jan", "Feb", "Mär", "Apr", "Mai", "Jun", "Jul", "Aug", "Sep", "Okt", "Nov", "Dez"},
< {"Fehler bei Bibliotheksinitialisierung", "Neuinstallation durch Entfernen der Bibliothek erzwingen"},
The macros have nothing to do with the translation, but was the easiest way for me to differentiate between the WearOS and phone version.
Naturally you want to make it for the translator as easy as possible and macros don't add to that, but one such condition isn't that difficult to read.
I consider it easier than the strings.xml.
Oh gosh that's a c++20 struct initializer I was seeing there, I thought that whole thing was a macro.
I don't think it's that much easier, for one, it's an indentation mess and in another way, this seems to be always located in RAM like that, for every language?
A lot of the German translations also feel kind of random still with the current file, and the "shortinit" array isn't translated at all?
The files to be translated can be found here:
http://jkaltes.byethost16.com/Juggluco/translation
The German translation is already in http://jkaltes.byethost16.com/Juggluco/download.html and the version I have uploaded to Google Play.
Thank you,
since German is the only other language I know, I can't really add anything here anymore personally, but it will surely help someone else who can add another language.
Interesting that you used a c++ file with macros for translation like that, that's exactly what something like gettext was made for
Ich habe Juggluco durch Google Translate geschoben und einige offensichtliche Fehler wie "Os tragen" für Wearos entfernt. Hat jemand Interesse, Verbesserungsvorschläge zu machen? Oder besser Juggluco ins Arabische übersetzen; die am dritthäufigsten verwendete Sprache der Benutzer von Juggluco, nach Englisch und Deutsch.
Could you supply string XMLs or POs or anything that can be used to translate them? I don't see anything on the site.
Wenn ich die orig. App von Dexcom und xdrip nutze, bekomme ich dann Warnungen von der Dexcom App und von xdrip? Das wäre sicherlich nervig!
Wenn ich die orig. Dexcom App nutze, werden meine BZ Werte dann automatisch an Dexcom gesendet? Oder nur, wenn ich Clarity nutze?
Klar kommen die doppelt. Musst du eins dann halt abschalten.
Also so ganz unerfahren bin ich mit einer Pumpe nicht. Hatte sie ein paar Tage an mir aber hat mir nicht gefallen weil ich zB beim Aufstehen immer gepiekst wurde. Ich denke da war wohl die Nadel damals zu lang. Ist jetzt aber auch etwas her.
Update: Den Termin für Bad Mergentheim habe ich für den 22. Februar bekommen mit dem Hinweis dass es evtl verschoben werden muss falls akute Fälle dazwischen kommen. Ich hoffe der Termin bleibt so wie es ist. Ich weiß nicht ob das generell von der Klinik so mitgeteilt wird. Bin aber froh dass es nicht April oder so ist
Sind immerhin trotzdem 5 Wochen... Uff, da noch mal so lang warten würde mich trotzdem ärgern.
Vor allem wenn man sieht wies bei den Kids abgeht, da wird diagnostiziert und die hängen noch in der gleichen Woche ne Pumpe hin
Da brauchst du halt ein Linux-Betriebssystem dazu. Unter einem halbwegs modernen Laptop mit Windows 11 kann man sich so was tatsächlich relativ einfach anschaffen: WSL | Ubuntu
Man muss halt echt sich ein wenig durch die Technik fuchsen können. Die APK (Android Installationsdatei) gepatcht zu Teilen ist nämlich no bueno, den Patch muss man schon selbst erstellen. Aber eine Schritt-für-Schritt-Anleitung auf so einer Ebene anzufertigen mit der man SO was hinkriegt ist auch echt nicht einfach... Englisch sollte man zumindest können für so was
Das kommt ja aber nicht plötzlich und unvorhergesehene.
Kalkuliere ich beruflich immer ein und die Großen werden da wohl noch eher ein Auge drauf haben.
Natürlich aber die sind ja momentan schon im Aufholmodus und das Mondneujahr machts nicht einfacher, aufzuholen
Falls jemand Insulin und Kohlenhydrate von Juggluco an Libreview senden möchte, ist dies jetzt mit Juggluco 4.4.1 möglich.
Wenn es nur noch vertikal verwendbar wäre, weil ich das oft nebenbei mache und mein Handy sehr groß ist..
Zum Thema kurz, hab heut auch ein Insulinrezept rausgelassen (für Apidra) und da hat der Apotheker auch gesagt dass es für so manche Insuline wohl Engpässe gibt. Apidra gut, aber er hat mir auch mal die Liste der Produkte (damit halt alles über Pens, Fläschen und Penfills... also alle Produkte) für Humalog gezeigt und dort war die Hälfte der Ampeln rot und viele gelb, die sind normal alle grün. Rot heißt kann nicht bestellt werden in deren System
Da gabs wohl eine Verunreinigung die Teile der Produktion zunichte gemacht hat. Mein Arzt hat da wohl auch einen Brief für bekommen.
Dann kommen einige Hilfsstoffe wohl auch aus China (laut dem Apotheker) und die haben bald Mondneujahr (22. Januar). Das heißt für China dass dort erstmal die Produktion still stehen wird.
Die größte Not wird aber aktuell sein dass man halt vielleicht mal nicht sofort was bekommt, sondern später, oder einfach ein anderes Insulin nimmt.
Ganz offensichtlich ist es nur für Industrieelektroniker glaube ich.
SPS heißt SpeicherProgrammierbare Steuerung. Also quasi der Computer der die Pumpe steuert.
Kannte ich noch gar nicht den Begriff, also ist einfach nur ein Wort um Mikrocontroller zu beschreiben, aber in dem Kontext dass sie im Gegensatz zur Steuerung existiert die rein durch elektronische Gatter funktioniert, also fest verdrahtet ist?
Alles anzeigenMeins zum Thema Batterieverbrauch:
Habe vor einer Woche eine harte Fehlermeldung von meiner Pumpe gehabt (auch 034146 000679) und habe danach eine Billigbatterie eingesetzt. Das Ergebnis war, das schon nach einer Woche wieder die 20% Batteriemeldung kam. Ganz anders als die Energizer Industrie Batterien, die ich für meine Medtronic Pumpe bekommen habe. Es hat eben doch auch mit der Qualität der Batterien zu tun, wie oft man sie wechseln muss.
Zudem Fehler 34146 000679. Mir wurde auch gesagt ich soll mich melden wenn es wieder passiert. Mir wurde aber auch gesagt, das dies keine Meldung ist, falls sich die Pumpe nicht meldet (die hatte ich nämlich auch schon häufiger und dann muss man es einfach nochmal versuchen), sondern es ist eine Laufzeit-Abweichung zwischen den beiden SPSen die in der Pumpe arbeiten. In der Pumpe arbeitet nach meinem Wissen (was sich durch die Information von Ypsomed bestätigt hat) eine Fail-Safe-SPS mit 2 getrennten Rechnern. Unterscheidet sich die Laufzeit zwischen den beiden Rechnern zu stark, wird davon ausgegangen das einer der beiden Rechner einen Fehler hatte (zum Beispiel könnte ein Stöckchen in die Speichen von einem Zahnrad gekommen sein
). In diesem Fall wird die SPS aus Sicherheitsgründen gestoppt.
Dies ist insofern interessant, als es schon eine elementare Sicherheitsabweichung ist, die auch mMn nichts mit dem Handy oder der Aussenwelt zu tun hat.
ABER ganz klar: lästig, aber keine Gefahr für den Benutzer, weil eben abgeschaltet wird!
Ah, Redundanz. Sehr gute Idee eigentlich da einfach alle Prozesse doppelt ablaufen zu lassen.
Aber was bedeutet hier SPS? Das ist bestimmt was ganz offensichtliches 
