Plot- Darstellungen zusammenfassen / Mittelwert über alle?

[M_I_B]

Hallo liebe Leute,

ich frage mal hier, weil ich kein passerendes Board gefunden habe; notfalls verschieben bitte.

Ich habe inzwischen insg. 5 Aussenfühler, jeweils mit Temp & Hum, welche ich mir in FHEM darstellen lasse (siehe Bild).
Aber rein optisch gefällt mir da so nicht wirklich. Natürlich könnte man alle Graphen in ein Fenster schreiben, aber das wird extrem unübersichtlich. Daher suche ich nach einer Möglichkeit, die Darstellung durch editieren der plot-Datei o.ä. soweit zu verändern, das (auf das Bild bezogen) alle weißen Flächen mit einer ganz schlanken Trennlinie untereinander stehen, so das die Überschriften und die Zeitbeschriftung lediglich ganz unten (und ggf. ganz oben noch einmal) steht, wie in der Montage angedeutet.

Ein weiterer Wunsch wäre, in einem weiteren Plot jeweils die Mittelwerte aller 5 Sensoren darzustellen. Da hab ich aber im Moment nicht den blassesten Schimmer, wie man da rangehen sollte...

[rudolfkoenig]

Als erstes wuerde ich alle Linien in einem Plot darastellen, das geht relativ einfach mit dem PlotEditor (DetailAnsicht eines Plots).
Die Linien verschieben kann man mit einer Funktion (Bei FileLog $fld[4]+100, usw.)
Blassen Strich kann man vmtl. mit logProxy bauen.
Skalenwerte kann man korrigieren, indem man die Werte manuell definiert.

Meine Meinung: viel Arbeit...

[jensb]

Ein weiterer Wunsch wäre, in einem weiteren Plot jeweils die Mittelwerte aller 5 Sensoren darzustellen.

Mittelwerte gibt es viele. Aber sowohl für Block-Mittelwert als auch gleitenden Mittelwert über einen festen Zeitraum kannst du den event-aggregator verwenden. Dopple über einen Notfiy die Readings und aktiviere für die gedoppelten Readings den event-aggregator mit der Funktion "mean" (siehe Commandref). In den gedoppelten Readings stehen dann immer die jeweiligen Mittelwerte der ursprünglichen Readings, und die kannst du dann z.B. mit in den Plot aufnehmen.

Gruß,

Jens

[M_I_B]

... erstmal Dank Euch für die Antwort!

Meine Meinung: viel Arbeit...

Ich befürchtete es schon 

Ich habe mir gerade mal einen Plot im Editor angesehen und die Funktion *100 eingebaut, wobei ich mal ins Blaue vermute, das $fld[] das Array ist, in dem die letzte Datenzeile aus dem entsprechenden FileLogf stehen. Immerhin sind die beiden Linien jetzt nicht mehr zu sehen und vermutlich nach oben hinaus geschossen; scheint zu funktionieren
Allerdings fehlt mir jetzt erstmal das Wissen, wie man mit welchen Attributen was verändert, wie z.B. die Anzeigehöhe des ganzen Plotfensters u.s.w.. Da werde ich mich notgedrungen noch mal ganz tief einlesen müssen, sonst wird das m.E. nix... Denn z.B. ...

Mittelwerte gibt es viele. Aber sowohl für Block-Mittelwert als auch gleitenden Mittelwert über einen festen Zeitraum kannst du den event-aggregator verwenden.

...sagt mir so erst einmal gar nix. Mir ist zwar aus den Bezeichnungen heraus schon in etwa klar, für was das gut ist, aber bis ich das umsetzen kann, wird wohl noch eine Weile ins Land gehen, womit wir mal wieder beim EIngangs erwähnten ...

Meine Meinung: viel Arbeit...

... wären *seufz*

[rudolfkoenig]

vermutlich nach oben hinaus geschossen

Unwahrscheinlich, die Bereieche werden automatisch ermittelt, es sei denn, man hat sie manuell festgesetzt.
Ich vermute eher, dass mit $fld[4] nicht die richtige Spalte getroffen wurde, man muss eins von der gewaehlten Spalte abziehen. Dokumentiert ist das hier: http://fhem.de/commandref.html#FileLogget
Zum Pruefen kann man "Show preprocessed input" in der Detailansicht verwenden.

[M_I_B]

... ok, hätte ich auch selber drauf kommen können, das Arrays gewöhnlich mit "0" beginnen ...
Dennoch scheine ich irgend etwas grundsätzliches falsch zu machen. Wie im Bild schaut das nun aus. Man sieht am ENde so ein paar senkrechte Linien über dem Sheet; oder meinst Du mit "...es sei denn, man hat sie manuell festgesetzt..." die Werte, die ich bei "Range as..." eingetragen habe?

[rudolfkoenig]

oder meinst Du mit "...es sei denn, man hat sie manuell festgesetzt..." die Werte, die ich bei "Range as..." eingetragen habe

Yepp.

[M_I_B]

... ahhhh ... Eine Insel mit zwei Bergen  So langsam sickert das ins Hirn; Dankeschön!

Ich habe das mal raus genommen und mal geschaut, was dann so passiert. Dabei stoße ich auf eine "Merkwürdigkeit", die ich mir nicht so wirklich erklären kann... ich meine die hässlichen Ausreißer. Ich habe mal drei Bilder angehängt, einmal wie ich's hatte, einmal ohne fixe Skalierung und einmal mit +100

[jensb]

Bild 1 und 2 sind stimmig, da durch die dynamische Skalierung alles was geht gestreckt wird. Die Spikes in Bild 2 sind deine Messwerte.

Bei Bild 3 stimmt die Temperatur zu Bild 1 und 2, aber der "%"-Verlauf nicht. Falsche Spalte? Andere Daten?

[M_I_B]

aber der "%"-Verlauf nicht. Falsche Spalte? Andere Daten?

Nö, nimmernich. Die sind identisch zu 1 & 2 und daran wurde nichts verändert. Daher verstehe ich es ja auch nicht *GroßesWeihnachtsGrübeln*

[jensb]

Noch 'nen Versuch:

schreib bei % mal bitte "$fld[5]&&($fld[5]+100.0)". Die Formel mag Logeinträge ohne Werte nicht, deshalb "$fld[5]&&" davorstellen. Außerdem funktionieren die Formeln meist nicht, wenn da Leerzeichen drin sind. Andere Merkwürdigkeiten fallen mir momentan nicht ein.

[M_I_B]

Ich probiere das morgen ... ach ne... heute (is ja schon Sonntag) mal aus, auch wenn ich die Nummer formeltechnisch nicht verstehe...

Aber ist das nicht eher Sympthom- Bekämpfung? Ist ja nicht das eigentliche Kernproblem. Ich habe mal einen Blick in die Logfiles geworfen. Typisches Beispiel:

Code Auswählen Erweitern

2015-12-19_17:53:15 AS.TH.5 T: 19.6 H: 66
2015-12-19_17:56:03 AS.TH.5 T: 19.7 H: 73
2015-12-19_17:56:59 AS.TH.5 T: 20.1
2015-12-19_17:57:55 AS.TH.5 T: 20.4
2015-12-19_17:58:51 AS.TH.5 T: 20.6
2015-12-19_17:59:47 AS.TH.5 T: 20.7 H: 67
2015-12-19_18:00:43 AS.TH.5 T: 20.6 H: 66
Gut zu erkennen ist die Lücke, aber ebenso der Ausreisser vor der Lücke; 73% zu dem Zeitpunkt ist Quatsch. Das kann ich deshalb so genau sagen, weil alle 4 Sensoren derzeit noch gemeinsam in einem Schuhkarton hier im Büro liegen, um Unterschiede bei der Messung zu erfassen.
Besser wäre es m.E., wenn man das Übel bei der Wurzel packt und die Daten vor dem Schreiben ins Logfile zum einen auf Plausibilität überprüft und bei Ausreissern wie diesen mit den Werten davor interpoliert so wie Lücken entsprechend füllt.
In PHP würde ich das hinbekommen, aber wie das hier aus FHEM resp Perl heraus ausschaut, ist aus meiner Sicht weit hinter dem Horizont, da ich natürlich nicht nachvollziehen kann, wie das intern der Reihe nach abgefrühstückt wird. Oder gibt es so was schon und ich weiß davon nur nix?

BTW: In dem Zusammenhang wäre es auch nett, wenn man für einzelne Sensoren Offsets für T und H angeben könnte, damit man verschiedene Sensoren aneinander anpassen und Fehlmesungen ausbügeln kann.

[jensb]

Da du wirklich Logs ohne Werte hast, sollte das vorgestellte $fld[5]&& schon mal helfen.

Natürlich ist das Symtombekämpfung, aber dann zeigt der Plot schon mal das an, was aufgezeichnet wurde und danach geht es an die Ursachen.

Wenn du den Sensorwerten nicht trauen kannst, spricht das eher für neue Sensoren, denn FHEM denkt sich keine Werte aus. Wenn du die Werte aber prüfen und ggf. ändern willst, dann sind wir wieder beim notify-Modul. Damit kannst du bei jeder Wertemeldung des Sensors einen Perl-Ablauf ausführen und dabei auch neue Werte schreiben oder halt nicht, wahlweise in das Sensordevice zurück unter neuem Namen oder z.B. auch gern genutz in ein Dummy-Device. Anschließend stellst du dein Logging und den Plot von den Sensorwerten auf die selbst erzeugten Readings um.

[rudolfkoenig]

BTW: In dem Zusammenhang wäre es auch nett, wenn man für einzelne Sensoren Offsets für T und H angeben könnte

Je nach Modul geht das direkt, oder indirekt ueber userReadings. Uebrigens sehe ich FHEM nicht als Wunsch-Veranstaltung: wenn etwas fehlt, oder besser gemacht werden koennte, Patch schreiben, und dem Modulautor zur Verfuegung stellen.

[M_I_B]

Wenn du den Sensorwerten nicht trauen kannst, spricht das eher für neue Sensoren, denn FHEM denkt sich keine Werte aus

Das sich FHEM Werte ausdenkt habe ich ja auch an keiner Stelle behauptet; warum unterstellst Du mir denn sowas?!? Im Übrigen sind alle 4 Sensoren nagelneu...
Das mit den Lücken im Log scheint ja nicht nur ein Problem bei mir zu sein; zumindest meine ich das so zwischen Deinen Worten herauslesen zu können. Und was die unterschiedlichen Messwerte anbelangt, wirst Du das bei allen Sensoren beobachten können, ausgenommen mal sehr hochpreisige Teile, die einzeln im Werk explizit auf Referenznormale abgeglichen werden.

... Dummy-Device. Anschließend stellst du dein Logging und den Plot von den Sensorwerten auf die selbst erzeugten Readings um. ...

Ich meinte das mit dem Abfangen und der PLausibilität zwar anders, aber ... macht nix.   Ja, irgendwie so werde ich das wohl notgedrungen lösen müssen. Ich schreibe es mir erst mal auf die ToDo für das kommende Jahr.

Uebrigens sehe ich FHEM nicht als Wunsch-Veranstaltung

Wer sagt denn das? Und Dir sollte eigentlich klar sein, das ich noch sehr weit entfernt davon bin, selbst einen Patch zu schreiben. Ich wollte lediglich mit jemandem diese Idee in meinem Kopf besprechen, auch mit der Hoffnung, das sich daraus vielleicht eine Lösung für alle entwickelt. Ich bin noch nicht so lange dabei resp. so lange in diesem Forum, um wissen zu können, das ein Kommunizieren solcher Ideen den Profis vorbehalten ist...
Also Sorry, das ich laut gedacht habe; kommt nicht wieder vor.

Also vielen Dank für die Hilfe und ein schönes Fest Euch allen...