Multi Insulin Daten-/Klassenstruktur im Treatment ist suboptimal

[gruoner]

Ich wollte gerade meinen MultiInsulin Branch (https://github.com/gruoner/nightscout-reporter/tree/Feature-MultipleInsulin) auf deine neuen Datenstrukturen im jsonData.dart Treatment abstützen und hab festgestellt, dass so eine Datenstruktur zu schwach ist, um auf ihr Statistiken kalkulieren zu können.

Ich hab nun zwei Möglichkeiten a. ich werde auf sehr lange Zeit einen zweiten Zweig für den Multi Insulin Teil pflegen müssen und das wird langfristig zu einem Split des NSR führen - ich habe weder die Zeit noch die Lust längere Zeit einen eigenen Branch des NSR immer wieder auf die aktuellen Commits nachzuführen oder b. wir passen die Daten-/Klassenstruktur im jsonData.dart analog commit https://github.com/gruoner/nightscout-reporter/commit/3b345cfd750a15f87b4c357b25ba45696e04f1f2 an - was aber eine Anpassung an allen deinen bisherigen Multi Insulin Changes nach sich ziehen dürfte, dafür aber einen echten Fork des NSR verhindert

Kannst du die Datenstrukturen überhaupt noch anpassen oder bist du mit dem Multi Insulin Feature schon zu weit fortgeschritten, als das man jetzt noch so grundlegende Änderungen an den Daten-/Klassenstrukturen umsetzen könnte?

Das gleiche Problem dürfte uns beim Multi Carb Feature wieder treffen - das steckt gerade bei mir in der Pipeline und wird in den nächsten Monaten in einen PR im xdrip münden. Am Ende wird es ähnliche Datenstrukturen aufweisen wie Multi Insulin, nur um eine Dimension komplexer.....

[zreptil]

Hi Gruoner,

ich merge nichts in das Repository rein. Der Code hier bleibt absolut unter meiner Kontrolle. Wenn Du mir Deine angepasste json.dart schickst, kann ich schauen, ob und wie sich das verwenden lässt. Ich arbeite ständig an Nightscout Reporter weiter. Die nächste Version enthält einige einschneidende Änderungen in der Speicherung und dem Laden der Einstellungen.

Ich habe mich in letzter Zeit nicht gross um Multi Insulin gekümmert. Ich habe vor einiger Zeit was reingebaut, das diese Insuline aus den xDrip Strukturen rausliest. Allerdings ist xDrip auch nur ein Teilaspekt der Daten von Nightscout. Wer kein xDrip verwendet, wird diese Daten auch nicht zur Verfügung haben. Und auch dann muss Nightscout Reporter funktionieren. Solche speziellen Anforderungen muss ich speziell reinbauen und zwar so, dass der ganze Rest auch ohne das noch funktioniert. Deswegen bleibt der Originalcode auf alle Fälle bei mir und wird auch mit nichts anderem gemerged.

Aber ich erweitere die Strukturen selbst immer wieder und behebe aucn immer wieder Fehler, die bei Benutzern auftreten und bei mir nicht, weil ich andere Daten habe, andere Geräte und andere Uploader verwende.

Wenn Du mir also die Datenstrukturänderungen zukommen lässt, dann schaue ich, wie sich das sinnvoll einbauen lässt, sobald ich dazu komme. Zur Zeit bin ich dabei die nächste Version zusammen zu stellen. Das wird da mit hoher Wahrscheinlichkeit dann noch nicht drin sein. Aber ich bin natürlich immer an Weiterentwicklungen interessiert.

[gruoner]

Hi

am Ende gehts um diese Klasse und die Verwendung in den Treatments anstelle der List of InsulinInjectionData: class InsulinInjectionList { Map<String, double> injections = Map();

InsulinInjectionList get copy => InsulinInjectionList() ..injections = new Map.from(injections);

fromJsonString(String json) { injections= Map(); List decoded = JsonCodec().decode(json); double sum = 0; for (dynamic inj in decoded) { double u = JsonData.toDouble(inj["units"]); sum += u; injections.update(JsonData.toText(inj["insulin"]), (double v) => v + u, ifAbsent: () => u); } injections.update("sum", (double v) => v + sum, ifAbsent: () => sum); }

InsulinInjectionList add2List(InsulinInjectionList l) { InsulinInjectionList ret = this.copy; for (String insulin in l.injections.keys) { double sum = l.injections[insulin]; ret.injections.update(insulin, (double v) => v + sum, ifAbsent: () => sum); } return ret; } }

Es ist eine eigenständige Liste, auf der ich die Statistiken zu den InsulinInjektionen kalkulieren kann.... Aktuell habe ich den ganzen Multi Insulin Teil nur für die Reports implementiert, die ich für die quartalsweisen Arztgespräche brauche. Aber es hat hier noch eine Menge Bedarf an weiteren Changes; insb. wenn andere Therapieformen als FIT (Basal / Bolus) zur Anwendung kommen - da steckt noch eine Menge Arbeit drin. Und wenn "irgendwann" die Changes zu den Multi Carbs (mehrere Typen von Kohlenhydraten analog zu mehreren Typen von Insulinen) kommen, wird das ganze Reporting richtig aufwändig und komplex - dann braucht es Struktur und die muss gut durchdacht und vorbereitet sein......

Btw. auch mit Merges "behältst du die Kontrolle über deinen Code" - du erlaubst nur anderen Entwicklern deine Arbeit weiterzuentwickeln. Auf der anderen Seite musst du dich dann (in gewissen Grenzen) auch mit ihnen abstimmen und "gemeinsam" die Richtung der Weiterentwicklung festlegen. Auch wirst du dich mit deren Ideen "rumschlagen" müssen; aber defakto ist das die Basis einer jeden Community Software wie Nightscout und xDrip...... Aktuell hat NSR nur wenig Entwickler neben Dir (ich kenne aktuell nur einen neben mir), aber mit den zunehmend umfassenderen Messtechniken und -technologien und der aktuell extrem guten Platzierung des NSR im Nightscout-Ökosystem (es hat defakto kein anderes Reporting-Modul im Nightscout-Ökosystem mit diesem Featureumfang und in dieser potentiellen Weiterentwicklungsbreite), wird das Reporting und die Auswertung dieser Datenmengen zunehmend herausfordernder und komplexer. Irgendwann kann das einer alleine nicht mehr stemmen - schau dir da nur Linus Torwalds und seinen Linux Kernel an

[zreptil]

Die Herrschafft über Nightscout Reporter bleibt in dem Repository hier auf alle Fälle ein Ein-Mann-Zirkus :) Es it auch ein Open-Source Projekt und kein Community-Projekt. Ich habe schon öfter an verschiedenen Projekten mitgearbeitet, die dann letztendlich alle immer wieder die gleichen Probleme hatte: Unverständnis der Programmierer, was das grundsätzliche Konzept des Gesamtprojekts ist, Bedrängnis, schnell etwas fertig zu machen, "das kann man ja später schöner machen" und pfundweise Provisorien, ohne die die Software dann später nicht mehr lauffähig war.

Das lasse ich bei Nightscout Reporter nicht geschehen. Ich verdiene damit auch kein Geld und das wird auch nie eine Geldmaschine werden. Aber ich stelle jedem, der es haben will, den Sourcecode komplett zur Verfügung und wer immer sich berufen fühlt, das zu erweitern, zu verändern oder schöner, besser, schneller, grösser zu machen, hat meinen Segen. Aber in dieses Repository hier lasse ich niemand anderen schreiben. Der Overhead, der dadurch entsteht, zieht den Spass aus der Programmierung. Und ich war schon immer Programmierer und bleibe das auch. Kein Manager, kein Dompteur und schon gar kein Chef von irgendwas.

Ich bin weit davon entfernt Linus Torvalds zu sein, aber Nightscout Reporter ist auch wie gesagt kein Community Projekt. Ich schlage mich gerne mit den Ideen anderer herum. Aber ich verwende die so, wie ich es für richtig und brauchbar halte. Nightscout Reporter ist über die Zeit weit über das hinaus gewachsen, was ich eigentlich machen wollte. Es gab und gibt nach wie vor hervorragende Ideen von allen möglichen Benutzern. Und was immer mir sinnvoll erscheint baue ich zu meinen Bedingungen rein. Hin und wieder habe sogar ich Ideen. Auch die kommen da rein.

Auch das, was Du jetzt als Deine aktuelle Lebensaufgabe siehst, werde ich im Laufe der Zeit reinbauen. Aber zur Zeit nehme ich das nur zur Kenntnis. Ich habe für die nächste Version schon zu viele Änderungen durchgezogen, um das jetzt auch noch drauf zu setzen. Das kommt dann in einer der nächsten Versionen mit rein, sobald ich die Folgen durchdacht und die Probleme beseitigt habe, die sich dadurch ergeben.

Ich habe auch absolut kein Problem damit, den Code umzubauen und auch wegzuschmeissen, wenn er nicht mehr passt. Eines der neuen Features habe ich gestern teilweise gelöscht und den Rest komplett umgekrempelt, nachdem ich wochenlang dran rumgebastelt hatte und es eigentlich ganz gut fand. Aber es hat nicht richtig reingepasst. Also keine Sorge, dass es mir zu viel werden könnte, wenn ich was umbauen muss. So ein Code lebt und ist nicht statisch für alle Zeiten festgeschrieben. Das ist nichts auf der Welt.

Nightscout Reporter selbst hat tatsächlich nur einen Entwickler, nämlich mich. Wer sich sonst noch Branches und sonstiges rauszieht und anpasst, spielt für mich keine Rolle. Wenn es etwas gibt, was den Nutzen von Nightscout Reporter erhöht, werde ich das reinbauen. Und zwar ohne jegliche Rücksicht auf eventuelle Branches oder sonstige umliegenden Ortschaften. Das sind Baustellen, die nicht meine sind und auch nicht werden.

[zreptil]

Hallo Torsten,

nachdem ich nun die Version 2.0.0 hochgeladen habe, kann ich mich mal um die Multiinsuline kümmern. Was ich dazu bräuchte, wäre Zugriff auf eine Nightscout Instanz, auf der diese auch wirklich eingetragen werden. Genauso die Multi-Carbs. Ich bin gestern im Zuge einer anderen Fehlerbehebung im Code über die Multicarbs gestolpert und habe in den Daten von dem, der den Fehler gemeldet hat, gesehen, dass sie dort als String angelegt werden. Warum werden sie nicht direkt als Array angelegt?

Wenn ich das richtig verstanden habe, dann gibt es diese Erfassungsmöglichkeit nur in xDrip, oder? Hast Du da Pläne, das generell in Nightscout aufnehmen zu lassen? Dann würden sich andere Softwareentwickler leichter tun, diesen Fall zu berücksichtigen. Sonst bleibt das immer ein Sonderfall und das wäre schade. Denn da es den Bedarf für so eine Therapie zu geben scheint, sollte das auch datentechnisch dann in Dokumentationen auch in Nightscout selbst auftauchen. Genauso wie die Multi-Carbs.

Das alles lässt sich problemlos in Nightscout Reporter einbauen. Da Du nicht ganz verstehst, warum ich das so handhabe und keine Merges mache, hier ein kurzer Einblick in meine Arbeitsweise:

Ich mag Programmierung sehr gerne. Das ist das, was ich mir in jungen Jahren zum Hobby ausgesucht habe und was mich bis heute fasziniert. Ich habe auch meinen Job darauf aufgebaut und will auch nichts anderes machen. Alles, was drumherum so benötigt wird (Einarbeitung in neue Programmiersprachen, Tools, die man zur Entwicklung braucht und organisatorischer Overhead) mache ich von Zeit zu Zeit auch gerne, aber das ist nur ein kleiner Teil meines Spasses, den ich da raus ziehe.

Und das forken, branchen und mergen von GitHub und anderen Systemen betrachte ich nach wie vor mit einiger Skepsis. Zum einen, weil ich nie wirklich sicher bin, was da genau im Hintergrund alles passiert, zum anderen, weil es in allen Projekten, in denen ich mit so etwas bisher zu tun hatte irgendwann derbe Probleme hatte, wenn verschiedene Entwickler verschiedene Zweige wieder zusammenführen wollen. Deswegen gibt es bei Nightscout Reporter nur einen Stamm. Keinen Zweig, keine Verästelung, keine Notwendigkeit unterschiedliche Codestände wieder zusammenführen zu müssen. Und deswegen ist das kein Community Projekt. Es ist einfach nur mein Projekt und jeder, der will, kann sich das holen und damit machen, was er will. Aber ich werde mich nicht um den Overhead kümmern, der durch Forks, Branches und auseinanderlaufenden Codeständen entsteht.

Ich bin gerne bereit, mir Code anzuschauen und einzubauen, der mir sinnvoll erscheint, aber das werde ich auf keinen Fall im Repository tun, ohne ihn ausprobiert zu haben. Das geht vermutlich allen Programmierern so, weshalb es eben diese Branches und Forks gibt, um immer eine lauffähige Version zur Verfügung zu haben und auf einem Branch oder Fork dann das auszuprobieren, was andere rein gemerged haben. Ich gehe den für mich einfacheren Weg. Es gibt keine Branches und Forks und ich teste alles alles, was ich reinbaue bei mir, bevor ich es in Guthub hochlade. Deswegen merge ich nichts von ausserhalb rein.

Und deswegen wird sich eine Zusammenarbeit immer nur im Informationsaustauch ergeben. Ich brauche Testdaten, um den Code, der vorhanden ist, auch an richtigen Daten ausprobieren zu können. Die kann ich mir nicht selbst zusammenbauen, weil solche Tests sinnlos sind. Ich weiss, was ich reingebaut habe und baue dann natürlich die Testdaten entsprechend auf. Da sind Livedaten von echten Nutzern tausendmal besser. Deswegen wäre es wirklich hilfreich, wenn Du mir da einen oder mehrere Links zu Daten zuschicken könntest, wo ich sehe, was da wirklich geliefert wird. Ich habe jede Menge Links, wo ich sehe, was nicht geliefert wird, was genauso wichtig ist. Denn Nightscout Reporter muss auch dann funktionieren, wenn Datensätze nicht, teilweise oder falsch befüllt sind.

Es wäre wirklich sinnvoll, wenn Du die Ideen bei Nightscout selbst in die Datenstruktur bringen würdest. Dann könnten auch Apps wie AAPS irgendwann eine Möglichkeit der Erfassung einbauen. Ich verwende zum Beispiel xDrip lediglich zum Auslesen des Sensors. Wenn AAPS das könnte, würde ich xDrip gar nicht verwenden. Alles, was ich im Loop erfasse, mache ich in AAPS. Deswegen wird es bei mir diese Datenstrukturen nie geben, solange die nicht zum normalen Funktionsumfang von Nightscout gehören, sondern nur bei xDrip erfasst werden. Das ist zwar, wie es aussieht, so ziemlich der Standard für alle Android-Looper, aber Apple-Fans sind dann schon mal komplett raus, so wie ich das sehe.

LG Andi

Am Do., 16. Juli 2020 um 00:02 Uhr schrieb gruoner <notifications@github.com

:

Closed #43 https://github.com/zreptil/nightscout-reporter/issues/43.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/zreptil/nightscout-reporter/issues/43#event-3550527739, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQI2JNDRWK7OFNIQCQEURDR3YRNJANCNFSM4OYTATPA .

[gruoner]

Hi Andi wie du bist über MultiCarbs "gestolpert"? Ich hab den MultiCarbs noch gar nicht publiziert..... Arbeitet da noch jemand anderes dran? Im CarePortal vom Nightscout Server ist jedenfalls noch nix zu sehen..... Aktuell ist die einzige Erfassungsmöglichkeit für Multi Insulin im xDrip und sobald ich einen Weg gefunden habe die Profile zu synchronisieren, plane ich auch einen Feature Request im NS-Server selber. Aber das wird sicher ein grösserer Akt. xDrip hat noch eine Menge weiterer Datenstrukturen, die der NS-Server so gar nicht kennt und die man (auf irgendeine Geiss-Art) wieder raus bekommt und in Reports andruckt. Ich wage mal zu behaupten, das ist einer der Gründe wieso sich der NS so flexibel entwickeln konnte. Aber so lange Multi Insulin (und zukünftig Multi Carbs) nicht im offiziellen Datenformat / API aufgenommen ist, werden diese Informationen immer Spezialität bestimmter Deployments sein und viele Anwender werden mit diesen Features überhaupt nix anzufangen wissen (nämlich mal alle in Pumpentherapie und im "Standard-FIT" Muster) - denen sollte man das ganze eigentlich nicht einmal zeigen geschweige denn ihre Deployments dadurch unzuverlässiger machen (man denke nur mal an einen Looper, der aufgrund geänderter Datenstrukturen eine amoklaufende Pumpe kriegt oder eine falsch kalkulierte Basal-Rate bei der FIT). Darum müsste man irgendwie einen Switch für solche "Spezialitäten" (am besten für jede Spezialität einen eigenen) haben - im xDrip haben wir den eingebaut, aber es läuft immer noch viel vom Spezialcode Multi Insulin auch wenn man das Feature ausschaltet.....

Wegen der "Unwägbarkeiten" des ganzen Branching & Merging hab ich dir ja auch ein Patch-File geschickt - da ist besser erkennbar was sich ändert; aber im Grunde genommen ist der PullRequest auch nix anderes als ein Patch-File, dass bei Autorisation (also dem Merge) angewendet wird und den Code-Text genau nach Patch-Anweisung mutiert. Aber wie auch immer es dir lieber ist.

ich hab keine Instanz auf der du die Multi Insulin Sachen testen könntest - mein Nightscout ist intern und von aussen nicht erreichbar und ich hab nicht mal eine Ahnung wer überhaupt schon Multi Insulin auf seiner Instanz einsetzt.....

Aber umso länger ich drüber nachdenke, desto mehr erkenne ich, dass Multi Insulin (und zukünftig auch Multi Carbs) im "Mainstream Nightscout Reporter" nix verloren hat solang es nicht auch im "Mainstream Nightscout" drin ist. Ich werde also den NSR forken und in eigenständigen AddOn's weiterentwickeln; in unregelmässigen Abständen werde ich dann einfach den Mainstream NSR in die eigenständigen Module reinmergen oder es halt irgendwann einfach lassen, wenn's zu aufwändig wird......

liebe Grüsse Torsten

[zreptil]

Hallo Torsten,

ich habe einen Benutzer, dem aufgefallen ist, dass die Kohlenhydrate und das Insulin nicht mehr angezeigt werden. Nach Analyse seiner Daten habe ich gesehen, dass es an der internen Erkennung von doppelten Datensätzen lag, die ich etwas zu restriktiv reingebaut hatte. Dabei habe ich aber auch gesehen, dass er seine Behandlungen mit xDrip erfasst. Und da hatte er diese Einträge drin:

"insulinInjections":"[]"

Das war immer eine leere Liste, aber der Eintrag war in seinen Daten. Also gibt es durchaus Benutzer, die eine xDrip Version verwenden, die zumindest Multi-Insulin reinschreiben, auch wenn sie anscheinend nicht verwendet werden. Allerdings sind es eben Multi-Insuline, nicht Multi-Carbs, wie mir gerade auffällt. Sorry, war ein falscher Ausdruck.

In den Daten gibt es viele Regionen, die nur von spezialisierten Uploadern verwendet werden. Ich baue Nightscout Reporter so, dass er eine möglichst grosse Menge der Informationen verarbeitet. Natürlich ist es für sehr spezialisierte Daten, die nur einem internen Kreis zur Verfügung stehen dann wesentlich sinnvoller, wenn das dann von denen verarbeitet wird, die diese Datenstrukturen aufbauen, pflegen und auch Zugriff auf diese Daten haben. Sobald mir ein Benutzer Daten zur Verfügung stellt, bei denen ich über etwas stolpere, was noch nicht vorgekommen ist, nehme ich das auch in Nightscout Reporter auf.

Der eigene Fork ist für Dein Vorhaben dann vermutlich wirklich die beste Lösung für Dich.

LG Andi

Am Do., 16. Juli 2020 um 21:28 Uhr schrieb gruoner <notifications@github.com

:

Hi Andi wie du bist über MultiCarbs "gestolpert"? Ich hab den MultiCarbs noch gar nicht publiziert..... Arbeitet da noch jemand anderes dran? Im CarePortal vom Nightscout Server ist jedenfalls noch nix zu sehen..... Aktuell ist die einzige Erfassungsmöglichkeit für Multi Insulin im xDrip und sobald ich einen Weg gefunden habe die Profile zu synchronisieren, plane ich auch einen Feature Request im NS-Server selber. Aber das wird sicher ein grösserer Akt. xDrip hat noch eine Menge weiterer Datenstrukturen, die der NS-Server so gar nicht kennt und die man (auf irgendeine Geiss-Art) wieder raus bekommt und in Reports andruckt. Ich wage mal zu behaupten, das ist einer der Gründe wieso sich der NS so flexibel entwickeln konnte. Aber so lange Multi Insulin (und zukünftig Multi Carbs) nicht im offiziellen Datenformat / API aufgenommen ist, werden diese Informationen immer Spezialität bestimmter Deployments sein und viele Anwender werden mit diesen Features überhaupt nix anzufangen wissen (nämlich mal alle in Pumpentherapie und im "Standard-FIT" Muster) - denen sollte man das ganze eigentlich nicht einmal zeigen geschweige denn ihre Deployments dadurch unzuverlässiger machen (man denke nur mal an einen Looper, der aufgrund geänderter Datenstrukturen eine amoklaufende Pumpe kriegt oder eine falsch kalkulierte Basal-Rate bei der FIT). Darum müsste man irgendwie einen Switch für solche "Spezialitäten" (am besten für jede Spezialität einen eigenen) haben - im xDrip haben wir den eingebaut, aber es läuft immer noch viel vom Spezialcode Multi Insulin auch wenn man das Feature ausschaltet.....

Wegen der "Unwägbarkeiten" des ganzen Branching & Merging hab ich dir ja auch ein Patch-File geschickt - da ist besser erkennbar was sich ändert; aber im Grunde genommen ist der PullRequest auch nix anderes als ein Patch-File, dass bei Autorisation (also dem Merge) angewendet wird und den Code-Text genau nach Patch-Anweisung mutiert. Aber wie auch immer es dir lieber ist.

ich hab keine Instanz auf der du die Multi Insulin Sachen testen könntest

• mein Nightscout ist intern und von aussen nicht erreichbar und ich hab nicht mal eine Ahnung wer überhaupt schon Multi Insulin auf seiner Instanz einsetzt.....

Aber umso länger ich drüber nachdenke, desto mehr erkenne ich, dass Multi Insulin (und zukünftig auch Multi Carbs) im "Mainstream Nightscout Reporter" nix verloren hat solang es nicht auch im "Mainstream Nightscout" drin ist. Ich werde also den NSR forken und in eigenständigen AddOn's weiterentwickeln; in unregelmässigen Abständen werde ich dann einfach den Mainstream NSR in die eigenständigen Module reinmergen oder es halt irgendwann einfach lassen, wenn's zu aufwändig wird......

liebe Grüsse Torsten

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/zreptil/nightscout-reporter/issues/43#issuecomment-659621625, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQI2JJSGMS53QV6HZJAE4DR35IEHANCNFSM4OYTATPA .

[gruoner]

Hi Andi

eine leere InsulinInjection dürfte es nur bei Kohlenhydrat-Registratur geben (also nur BE's eingetragen aber kein Insulin gegeben) - dann müsste aber auch der "insulin" Wert Null sein.... "Stolperst" du über unbekannte Attribute in Treatments oder Entries? Sprich, bringen neue Attribute an diesen Objekten den NSR-Parser aus dem Tritt?

Das Problem mit den fehlenden Darstellungen der Injektionen, Sensorwechsel oder Insulinkartuschenwechsel hab ich gestern auch gesehen, hatte es aber initial mal auf meinen Patch geschoben. Ich gehe mal davon aus, dass die Commits von gestern das Problem beheben...?

Der Fork ist seit gestern vollzogen - mal sehen wo er uns hinbringt.....

liebe Grüsse Torsten

[zreptil]

Hallo Torsten,

nur ich stolpere über solche Attribute ^^ Nightscout Reporter ignoriert unbekannte Attribute einfach. Wenn sich die Art eines Attributs ändert, das bringt ihn dann möglicherweise schon aus dem Tritt. Aber es wird recht viel abgefangen, was schieflaufen könnte. Aber wenn ich neue Attribute sehe, schaue ich mir an, wozu die da sind und erweitere die Datenklassen von Nightscout Reporter so, dass er mit und ohne die Attribute funktioniert. Allerdings bremst so eine Überprüfung natürlich die Anwendung aus, weshalb es gut ist, wenn die Attribute "offiziell" sind, also von jedem Nightscout Uploader reingeschrieben werden. Ganz kriminell wird es, wenn verschiedene Uploader das gleiche Attribut unterschiedlich befüllen. Das ist mir bisher noch nicht untergekommen, aber das kann natürlich durchaus mal passieren, wenn da an verschiedenen privaten Stellen im Datenmodell rumgebastelt wird. Daher kam auch mein Vorschlag, das zentral zu machen. Dann ist es in Nightscout direkt drin, kann auch optional sein und jeder Uploader Hersteller kann sehen, was er da wie befüllen muss.

Die fehlende Darstellung lag daran, dass xDrip weder einen sinnvollen eventType noch eine NSClientID in die Datensätze schreibt, wie das AAPS und andere Uploader tun. Ich hatte die Erkennung doppelter Datensätze an die NSClientID gehängt, was dann alle zusammengefasst hat, die null waren (also bei xDrip alle). Das habe ich aber wieder geändert und sollte jetzt keine Probleme mehr machen.

LG Andi

Am Fr., 17. Juli 2020 um 10:11 Uhr schrieb gruoner <notifications@github.com

:

Hi Andi

eine leere InsulinInjection dürfte es nur bei Kohlenhydrat-Registratur geben (also nur BE's eingetragen aber kein Insulin gegeben) - dann müsste aber auch der "insulin" Wert Null sein.... "Stolperst" du über unbekannte Attribute in Treatments oder Entries? Sprich, bringen neue Attribute an diesen Objekten den NSR-Parser aus dem Tritt?

Das Problem mit den fehlenden Darstellungen der Injektionen, Sensorwechsel oder Insulinkartuschenwechsel hab ich gestern auch gesehen, hatte es aber initial mal auf meinen Patch geschoben. Ich gehe mal davon aus, dass die Commits von gestern das Problem beheben...?

Der Fork ist seit gestern vollzogen - mal sehen wo er uns hinbringt.....

liebe Grüsse Torsten

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/zreptil/nightscout-reporter/issues/43#issuecomment-659948479, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQI2JIVZ4WIJIIKUVDTCA3R4ABTDANCNFSM4OYTATPA .

[gruoner]

Ich hab gerade in den xDrip Code gesehen und dort wird für die Treatments ein eventType "" oder "Sensor Start" geschrieben - alles ein bissel wenig. Welche EventTypes kennt Nightscout eigentlich? u.U. braucht es einen Patch im xDrip.....

[zreptil]

Ich glaube, da gibt es keine wirkliche Liste. Mir ist zumindest noch keine begegnet. Ich verwende in Nightscout Reporter ein paar eventTypes, um bestimmte Datensätze zu erkennen. Allerdings verlasse ich mich da einfach blind drauf, dass die vom Uploader auch den entsprechenden Wert drin stehen haben, den ich meinen und den Daten anderer entnommen habe. Bisher gab es noch keine Meldungen, dass da was falsch oder nicht erkannt wurde. Aber ein leerer eventType ist schon etwas mager. Irgendwas sinnvolles sollte drin stehen, denke ich.

Am Fr., 17. Juli 2020 um 13:21 Uhr schrieb gruoner <notifications@github.com

:

Ich hab gerade in den xDrip Code gesehen und dort wird für die Treatments ein eventType "" oder "Sensor Start" geschrieben - alles ein bissel wenig. Welche EventTypes kennt Nightscout eigentlich? u.U. braucht es einen Patch im xDrip.....

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/zreptil/nightscout-reporter/issues/43#issuecomment-660052358, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQI2JIFDDT4TURVTJ62WV3R4AX3VANCNFSM4OYTATPA .