Diskussionsthread EDOMI-Releases/Updates

[MrIcemanLE]

Mittelwert, Minimum oder Maximum

Hallo Christian,

wäre es möglich noch "Summe" hinzuzufügen? Damit könnte man Laufzeiten, Regenmengen, Stromverbrauch o.ä. zusammenfassen.

Gruß
Stefan

[gaert]

Hier ein Test-Diagramm, Komprimierung in Maximalwerte ab dem vergangenen Monat (täglich, Timestamp in der Mitte des jeweiligen Tages):

Bildschirmfoto 2019-02-04 um 07.47.17.png

[gaert]

Klar, kein Problem. Ist dann allerdings etwas unlogisch bezüglich der unkomprimierten Daten... Denn diese repräsentieren ja keine Summe, dies könnte dann etwas merkwürdig im Diagramm aussehen

[Brick]

Irgendwie bin ich noch nicht sicher, ob ich das gut oder unnütz finden soll.
Den gerade dein Diagramm finde ich jetzt irgendwie "eigenartig", was kann man den mit den Informationen aus deinem Diagramm noch anfangen ?
Das ist doch jetzt so verwaschen, das man eigentlich keine Rückschlüsse auf die Werte schließen kann.

Auch zb. bei Wetterdaten. Hier auf "Täglich" zu komprimieren erscheint wir etwas wenig. Eine Temperatur eines Tages ist schon sehr vage. Stündlich, oder
3, 6 Stündlich wäre hier nützlicher. Mittelwert zb. macht hier sogar kaum Sinn.

Für Verbrauchswerte hingegen finde ich es sehr sinnvoll. Nach X Monaten interessiert es mich nicht, wann am Tag ich viel Strom verbraucht habe,
hier ist es interessant, wie viel ich an diesem Tag verbraucht habe. (Stichwort "Summe" von MrIcemanLE)

Versteh mich bitte nicht falsch, ich finde es toll, das du das einbaust (war glaub ich auch mal ein Wusch von mir)... aber wenn die Daten hinterher
nicht "nutzbar/brauchbar" sind, macht es keinen Sinn, es zu verwenden.

Also, vielleicht geht es ja noch, das du das etwas feiner Skalieren kannst.

Gruß Martin

[gaert]

Es geht hier um die Komprimierung von historischen(!) Daten - das Beispiel ist natürlich Blödsinn... Gedacht ist das Ganze also eher für große Zeiträume, z.B. den Temperaturverlauf vor 5 Jahren oder so.

Eine feinere Granulierung wäre durchaus denkbar - ich habe durchaus darüber nachgedacht Stündlich wäre aber m.E. das Ende der Fahnenstange, denn minütlich etc. macht nun wirklich wenig Sinn.

[gaert]

Hier, stündlich:

Bildschirmfoto 2019-02-04 um 08.17.50.png

[Brick]

Minütlich ist doof.. dann brauch ich gleich nicht komprimieren

aber Stündlich fände ich schon schick. dann sieht man zumindest noch den Tagesverlauf ..
Aber auch 3 oder 6 Stunden wären noch ok..

Also wenn das noch gehen würde, wärs toll

Gruß Martin

EDIT 9:23 Uhr: na des sieht doch schick aus !! Stündlich is cool..

[gaert]

MrIcemanLE : So sähe es mit "Summe" aus - relativ unbrauchbar, da die unkomprimierten Daten ja keine Summe repräsentieren. Aber ich nehme es trotzdem mal mit rein - schadet ja nicht, wenn man weiß was man tut

Bildschirmfoto 2019-02-04 um 09.49.45.png

[Winni]

Hallo zusammen,
jetzt muss ich doch noch mal was loswerden, obwohl ich mir einen entsprechenden LBS schon mal selber schreiben wollte.
Nachdem aber hier gaert selber Hand anlegt mal als Denkanstoß: Es gibt zumindest bei mir einige 0/1 Diagramme, da macht ein Mittelwert keinen Sinn, Min/Max auch eher weniger. Eine Verdichtung in Zeitscheiben ist hier meist auch unglücklich. Was wäre denn von einem Ansatz zu halten, der Werte in einem gewissen Delta-Rahmen zusammenfasst und verdichtet? Bei Temperatur z.B. würden Früh und Abends mehr Einträge entstehen, als in den eher fixen Mittags und Nachtstunden. Dabei müsste man auch auswählen können, ob der Verdichtete Werte am Anfang des Zeitraums (0/1 Aussagen) oder in der Mitte (Temperatur) eingetragen werden soll. Problem sind auch 0/1 Einträge die sehr häufig wechseln (Regen), da müsste man wieder etwas anders vorgehen, um Einträge zu sparen (Mind. 5 Min ein, damit ein im Archiv landet).
Ich habe noch nicht damit angefangen, weil es bei einer solchen Vorgehensweise wichtig wäre, bereits verdichtete Werte zu erkennen und ich noch nicht getestet habe wie bestehende Archive auf eine Ergänzung reagieren würden.
In der Zwischenzeit habe ich mir mit SBC und LBS19000347 geholfen. Bei rechten selten wechselnden Werten, wird dann aber in den Diagrammen nichts angezeigt, weil ich keinen Wert im entsprechenden Zeitraum habe (ich denke das ist immer noch so).
Eventuell würde es sogar Sinn machen, die Funktionalität in einen Standardbaustein zu packen, damit sich der interessierte User hier anhand der Vorlage auch selber was basteln kann?

Winni

[MrIcemanLE]

So sähe es mit "Summe" aus

Stimmt auch wieder. Ich war gedanklich bei der Kumulationsfunktion der Diagramme. Dort wird ja immer der Mittelwert gebildet. Dort wäre die Summe (sowie Min und Max) bei machen Messgrößen hilfreich. Aber das Thema hatten wir schon. Hier war die allgemeine Meinung eher so, dass man Daten per LBS kumuliert und in ein separates Archiv schreibt.

[gaert]

Es gibt zumindest bei mir einige 0/1 Diagramme, da macht ein Mittelwert keinen Sinn

Warum nicht? Wenn Du z.B. in einem Monat 50 mal 1 und 50 mal 0 hast kommt 0,5 bei heraus. Dies zeigt doch dann sehr schön, dass der Zustand zu 50% der Zeit 1 war.

Der Sinn der Komprimierung ist es ja gerade, Details zu verlieren um den Datenumfang zu verringern.

[Winni]

Warum nicht? Wenn Du z.B. in einem Monat 50 mal 1 und 50 mal 0 hast kommt 0,5 bei heraus. Dies zeigt doch dann sehr schön, dass der Zustand zu 50% der Zeit 1 war.

Du berechnest den Mittelwert incl. Gewichtung aufgrund der Zeit? Ich hab in einer Stunde 20 mal 0 für Trocken und 20mal 1 für Regen in den ersten 10 Minuten und dann 1 durchgehend für die restlichen 10 Minuten. Dann bekomme ich ca. 0,84 berechnet, weil es in der Stunde zu 84% geregnet hat?
Das wäre dann durchaus eine Option. Was passiert in der nächsten Stunde, in der ich evtl. nur eine 0 habe, die in der 58. Minuten auftritt, weil es das Regnen aufgehört habe.
Bitte nicht falsch verstehen, wenn es anderen weiterhilft ist es schön, wenn es dieses Feature gibt. Ich kann jedoch aktuell in nur sehr wenigen Fällen einen Vorteil erkennen. Eine einfach Mittelwertbildung funktioniert nur bei gleichmäßigen Wertintervallen. In einem Regendiagramm das im aktuellen Bereich mit 0/1 arbeitet, in der Vergangenheit aber plötzlich mit Prozentwerten fungiert ist schwierig zu lesen. Ich(!) würde dann lieber ein zweites verdichtetes Archiv aufbauen.
Meine Archive sind meistens recht groß, weil in relative kurzen Zeitintervallen viele eigentlich unnütze Daten eintreffen, da würde mir oben beschriebenes Verfahren eher weiterhelfen. Aber wie gesagt, ich werd' bei Gelegenheit mal versuchen einen LBS zu stricken, schön wäre eine PHP Grundlage wie man sowas am effektivsten angehen könnte.

[gaert]

Naja, hier geht es um "Komprimierung" und nicht um komplexere mathematische Berechnungen. Ein (zeitlich) gewichteter Mittelwert ist durchaus komplexer, ist aber für diese neue Funktion der Komprimierung nicht unbedingt erforderlich - denn hier geht's primär um das Einsparen von Ressourcen (auf Kosten der Genauigkeit und Lesbarkeit natürlich).

Wenn Du unbedingt wissen musst, wann es vor fünf Jahren wie stark geregnet hat...

[TSD]

Klasse gaert!: Wird es dann auch möglich sein die Min und Maxwerte in separate Datenarchive zu speichern? Grade beim Temperaturwert fände ich das interessant. Evtl. kann man soetwas auch über ein Funktionsfeld lösen?

[saegefisch]

Macht man das nicht am besten mit dem min/Max-LBS und von vornherein mit einem eigenen Archiv? Im selben Archiv ergibt (finde ich) nicht so viel Sinn...