Diskussionsthread EDOMI-Releases/Updates

[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.

[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

[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

[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]

Hier, stündlich:

Bildschirmfoto 2019-02-04 um 08.17.50.png

[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.

[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]

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

[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

[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]

Vorläufiger Endstand...

Die Berechnung kann tageweise/wöchentlich/monatlich/jährlich erfolgen (kalendarisch), d.h. die Daten werden z.B. wöchentlich gemittelt.

Das Mindestalter der Daten kann in Tagen/Wochen/Monaten/Jahren angegeben werden - entweder "gleitend" oder "kalendarisch".

Beispiel:
- 2 Wochen gleitend: die Daten müssen älter sein als "heute abzüglich 14 Tage"
- 2 Wochen kalendarisch: die Daten müssen älter sein als "Montag vor 2 Wochen"

Der Zeitstempel des Ergebnisses kann am Anfang/Mitte/Ende des definierten Intervalls liegen - entweder unabhängig von den tatsächlichen Daten oder im Kontext der Daten.

Beispiel (für das Intervall "Woche"):
- es gibt nur Daten von Mittwoch und Samstag: der Zeitstempel wäre jetzt z.B. Mittwoch (Anfang), da für Montag keine Daten vorliegen
- oder unabhängig von den vorliegenden Daten: dann wäre der Zeitstempel Montag, obwohl hier keine Daten vorliegen (kalendarisch quasi)

Klar soweit?

Bildschirmfoto 2019-02-03 um 21.08.25.png

[gaert]

Das Berechnungs-Intervall kann übrigens Tag/Woche/Monat/Jahr sein, zudem hat man die Wahl zwischen Mittelwert, Minimum oder Maximum. Ausserdem wird man das Ergebnis noch ein wenig formatieren können (max. Anzahl der Nachkommastellen). Komprimiert wird erst wenn mindestens 2 Werte vorliegen - nur dann macht's ja Sinn und zudem beschleunigt das den Vorgang erheblich: Das Archiv "weiß" nicht, ob bereits komprimiert wurde (es sind einfach nur gewöhnliche Daten). Nach einer Komprimierung bleibt für das Intervall aber nur 1 Wert übrig (Sinn der Sache), so dass beim nächsten Vorgang diese Werte nicht mehr angefasst werden.

[saegefisch]

Prima, das hört sich gut an. Und den 18000020 muss ja niemand mehr erfinden...

[gaert]

Die Mittelwerte werden nicht umkopiert, sondern in das vorhandene Archiv eingefügt - die entsprechenden Quelldaten werden natürlich gelöscht. Mehrstufig ist nicht vorgesehen, wir wollen's mal nicht übertreiben und den LBS-Entwicklern auch noch ein wenig Luft lassen

Das Kopieren zwischen unterschiedlichen Elementtypen ist nicht vorgesehen und i.d.R. auch nicht sinnvoll, denn Vordergrund- und Hintergrundfarben sind CSS-mäßig nicht kompatibel (mit Ausnahme von einfachen Farbwerten wie #aabbcc).

[Janncsi]

Sehr gut!!!

Könntest du es irgendwie noch einrichten, dass man sich Ordner/Elemente aus Farben (Hintergrund) in Farben (Vordergrund) kopieren kann?! Habe einen sehr großen Pool an Farben und benötige den in beiden Ordnern und muss alles doppelt anlegen....