bedarf für plots ausser wert über zeit?

Begonnen von justme1968, 17 November 2014, 22:59:02

Vorheriges Thema - Nächstes Thema

justme1968

hallo zusammen,

gibt es bedarf in/mit fhem auch andere dinge zu plotten als nur werte über der zeit?

also z.b. etwas aus folgendem:
- eine x-achse die etwas anderes als die zeit darstellt
- über xtics und xrange konfigurierbare x-achse
- punkte mit labeln im plot
- kurven deren segmente eventuell unterschiedlich gefärbt sein können. z.b. abhängig vom wert
- kurven mit unterbrechungen. z.b. um fehlende sensorwerte zu zeigen
- plots in polar statt kartesischen koordinaten
- ... ?

das meiste davon sind nicht unbedingt dinge die direkt über den SVG editor für den enduser sind sondern dinge die in modulen oder funktionen für das logProxy modul genutzt werden können.

z.b. so etwas wie im angehängten screenshot. (entstanden mit ein paar kleinen änderungen am SVG modul ein einer funktion die per logProxy bedient wird.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

klausw

#1
Zitat von: justme1968 am 17 November 2014, 22:59:02
gibt es bedarf in/mit fhem auch andere dinge zu plotten als nur werte über der zeit?

also z.b. etwas aus folgendem:
- eine x-achse die etwas anderes als die zeit darstellt
- über xtics und xrange konfigurierbare x-achse
- punkte mit labeln im plot
- kurven deren segmente eventuell unterschiedlich gefärbt sein können. z.b. abhängig vom wert
- kurven mit unterbrechungen. z.b. um fehlende sensorwerte zu zeigen
- plots in polar statt kartesischen koordinaten
- ... ?
Bedarf ist relativ, manche Dinge vermisse ich erst wenn ich weiss, das es sie gibt  8)

Aber mit:
- kurven deren segmente eventuell unterschiedlich gefärbt sein können. z.b. abhängig vom wert
- kurven mit unterbrechungen. z.b. um fehlende sensorwerte zu zeigen
könnte ich sofort etwas anfangen.

Dinge wir z.B. die benötigte Heizleistung in Abhängigkeit zur Aussentemperatur ließen sich mit deinem Vorschlag auch darstellen.

Ich hatte bei meinen ersten gehversuchen mit Automatisierung und Visualisierung amcharts verwendet. Das würde viele der Funktionen bereits mitbringen. Und es läuft auf clientseite (javascript). Würde also die FHEM Hardware nicht weiter belasten. Es würden sich sogar die Messwerte ohne neuladen aktualisieren lassen.  Aber k.A. wie komplex die Einbindung ist.
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

fhainz

Zitat von: klausw am 18 November 2014, 14:49:32
Bedarf ist relativ, manche Dinge vermisse ich erst wenn ich weiss, das es sie gibt  8)
So geht es mir auch! :)

Zitat von: justme1968 am 17 November 2014, 22:59:02
- kurven deren segmente eventuell unterschiedlich gefärbt sein können. z.b. abhängig vom wert
Meinst du sowas? (siehe Anhang) Die gplot definition hab ich irgendwo im Forum kopiert ist aber relativ kompliziert.

Mir würde auf die schnelle nur "Werte per MouseOver anzeigen" einfallen, das wäre super wenn das irgendwann mal gehen würde aber ich glaube das hast du nicht gemeint  ;D

Zitat von: justme1968 am 17 November 2014, 22:59:02
- kurven mit unterbrechungen. z.b. um fehlende sensorwerte zu zeigen
Mit dem kann ich auch sofort was anfangen!


Grüße



rudolfkoenig

Mouse-Over geht nicht, aber man kann jetzt schon auf die Linie klicken.
Auch wenn die Werte dann aus der Linie zurueckgerechnet werden, und damit nicht immer exakt den Tatsachen entsprechen.

justme1968

ich hatte bei den farben erst mal an die linien selber gedacht. die gefüllten flaechen oben sind nicht schwierig sondern drei mal übereinander gezeichnen. jeweils. mal sehen ob man das auch effizienter machen kann.

mouseover geht prinzipiell eigentlich auch irgendwie. ich habe nur noch nicht geschaut wie. daran hatte ich auch noch nicht gedacht.

ich wollte ja nicht das ganze SVG modul umschreiben :)
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Dr. Boris Neubert

Hallo,

mir würde es schon reichen, den Aufbau der SVG-Grafik zu beschleunigen. Meine System/EDV-Seite in FHEMWEB hat vier Graphen mit der Darstellung von insgesamt 9 Kurven in 5-Minuten-Auflösung. Das Rendern auf einem Raspi dauert so lange, dass ich unangenehme Darstellungspausen habe. Ich hatte Rudi so verstanden, dass bei einer Verlegung des Renderings mittels clientseitigen Javascript, also in den Browser, Updates ganz schnell gehen, weil der Browser den über longpoll kommunizierten neuen Datenpunkt einfach in den Chart dazuschreibt.

Von den genannten Erweiterungen würde ich nur die Unterbrechung von Linienplots bei fehlenden Daten benutzen wollen, wobei mir nicht klar ist, wie FHEM das überhaupt erkennen soll. Kniffelige Fälle sind: event-on-change-reading, eine KS300 bei der unregelmäßig ein oder zwei Sendungen ausfallen.

Viele Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

betateilchen

Mal eine saublöde Frage: Fehlende Sensorwerte kann ich doch jetzt schon erkennen, wenn ich anstatt Linien einfach Punkte plotte?

(http://up.picr.de/20164501bu.jpg)

Eigentlich sollten die grünen Punkte genau so durchgehend auftauchen wie die rote Linie, aber aus mir bisher unerfindlichen Gründen hört der Wandthermostat einfach auf, zu senden.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

justme1968

@Boris: ich hatte auch vor zu schauen wo die zeit genau verbraucht wird. beim holen der daten aus dem FilelLog, beim aufbereiten für den plot, beim eigentlichen erzeugen des plots oder beim senden an den browser. auf den ersten blick gibt es zumindest keine offensichtlichen stellen die immense beschleunigungen erhoffen lassen. um wirklich gefühlt schneller zu sein reichen ja keine 10 oder 20%. so richtig schnell fühlt es sich vermutlich erst bei 2 oder 3 mal schnellerem aufbau an. das zu erreichen ist schon ehrgeizig.

je nach deiner konkreten anwendung hilft dir vielleicht die svgs für abgeschlossene zeiträume zu cachen. hast du das schon mal probiert?

eine stelle von der ich mir etwas versprechen würde wäre das interne format von allen am plot beteiligten komponenten von FileLog/DbLog bis hin zur SVG Erzeugung vom string basierten timestamp auf einen 'echte' epoch basierten timestamp zu ändern. zur zeit wird hier für jeden datenpunkt mehrfach hin und her konvertiert. mindestens beim erzeugen, beim suchen, beim skalieren, beim berechnen der koordinaten. das wäre aber eine tiefgreifende änderung die das ganze system (vermutlich sogar inklusive events) von grund auf betrifft. das hatte ich mir zum einen nicht vorgenommen :) und zum andern lässt sich schwer abschätzen ob es wirkiich so viel bringt das sich der aufwand lohnen würde. bei optimierungsfragen liegt man mit der augenschein gern mal daneben.

das browserseitige rendern bringt glaube ich am meisten bei der interaktion mit dem plot. d.h. zoomen und scrollen. da hier dann nicht mehr neu gerendert werden muss. die daten müssen initial natürlich trotzdem erhoben und zum browser gesendet werden. eventuell sogar mehr wenn man nicht noch ein intelligentes nachschicken der gerade gebrauchten daten mit einbaut. der aufwand ist glaube ich ziemlich gross. das hinzufügen neuer punkte hilft auch nur wenn der plot gerade offen ist und nur ergänzt wird..

unterbrechungen darzustellen setzt voraus das man sie erkennt und das geht natürlich nur für sensoren die regelmässig genug senden um vorhersagbar zu sein. ich denke das verträgt sich in keinem fall mit event-on-change und bedingt bzw. bei entsprechendem schwellwert für event-min-intervall.

@betateilchen: je nach anwendungsfall sind die punkte eine gute möglichkeit aussetzer zu entdecken. ein plot aus punkten ist aber aufwändiger zu erstellen und produziert etwa 4-5 mal so viele daten die zum browser gesendet werden als die gleichen daten als linien.

das plötzliche ausbleiben von werten sehe ich bei max thermostaten übrigens auch. ich weiss nicht ob vielleicht sogar absicht dahinter steckt.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Starkstrombastler

@justme
Ich würde gerne die Heizlinie, also Vorlauftemperatur als Funktion der Außentemperatur darstellen.
IPC\Ubuntu + Fhem, 1wire, Shellies, Siemens Logo!, Z-Wave, PhilipsTV, Vu+duo2, KM200

klausw

#9
Zitat von: justme1968 am 18 November 2014, 23:34:14
das browserseitige rendern bringt glaube ich am meisten bei der interaktion mit dem plot. d.h. zoomen und scrollen. da hier dann nicht mehr neu gerendert werden muss. die daten müssen initial natürlich trotzdem erhoben und zum browser gesendet werden. eventuell sogar mehr wenn man nicht noch ein intelligentes nachschicken der gerade gebrauchten daten mit einbaut. der aufwand ist glaube ich ziemlich gross. das hinzufügen neuer punkte hilft auch nur wenn der plot gerade offen ist und nur ergänzt wird..
Beispielsweise Amcharts (javasript library) kann mit JSON Daten arbeiten. Da lassen sich relativ einfach neue Daten pushen

Zitat von: justme1968 am 18 November 2014, 23:34:14
unterbrechungen darzustellen setzt voraus das man sie erkennt und das geht natürlich nur für sensoren die regelmässig genug senden um vorhersagbar zu sein. ich denke das verträgt sich in keinem fall mit event-on-change und bedingt bzw. bei entsprechendem schwellwert für event-min-intervall.
Mit Amcharts scheint die Unterbrechung von Haus aus zu funktionieren eingebaut.
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

betateilchen

(offtopic)

Zitat von: justme1968 am 18 November 2014, 23:34:14
das plötzliche ausbleiben von werten sehe ich bei max thermostaten übrigens auch. ich weiss nicht ob vielleicht sogar absicht dahinter steckt.

Das Ausbleiben tritt nur im device der Homematic Komponente auf, im Channel selbst wird durchgängig gesendet.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Ich habe vor Jahren versucht SVG zu optimieren, und kam nicht mehr weiter, teilweise sind meine Kommentare (20%, etc.) noch sichtbar (z.Bsp. SVG_time_to_sec).


JS im Browser durfte schneller sein, da JS kompiliert wird, im Browser mehrere Prozessoren zur Verfuegung stehen, und die Prozessoren in Problemfall auch einzeln schneller sind, als die auf dem Server.
Demgegenueber steht die Lieferung der Daten, das erfolgt aber relativ primitiv, und wird per gzip (nativer code) relativ stark verdichtet.

klausw

Im Tread Neues Charting / Plotting - GUI Redesign? scheint schon einiges in diese Reichtung zu lauben. Aber wenn ich das richtig verstehe ist das ein eigenes Frontend, das sich nicht in die klassische FHEM Oberfläche enbinden lässt  :-\
Vielleicht lässt sich aber ein Teil des codes für diese Zwecke nutzen.
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

justme1968

@rudi: wie gesagt: auf der ersten blick fällt auch nichts augenscheinliches auf. alles in assembler und handoptimiert ist natürlich immer ein weg. aber ich glaube 100 euro für einen schnelleren rechner sind eventuell besser investiert.

die neuen features sollen auf jeden fall keine negativen auswirken haben wenn sie nicht genutzt werden. wenn nebenbei doch noch eine optimierung dabei heraus kommt ist das schön.

was die extend und predict möglichkeit im logProxy modul angeht lässt sich dadurch für dinge wie presence/ventilstellung/soll temepratur die log größe zum teil massiv verringern da man komplett auf event-min-intervall
und addLog verzichten kann. d.h. es gibt nur eine hand voll events und log einträge statt z.b. alle 5 oder 15 minuten.
der effekt ist also eher indirekt und klein dafür aber immer vorhanden. durch das verringerte loggen legt sich vielleicht sogar eine platte schlafen die es sonst nicht tun würde. 

@klausw: diese charing libs sind eventuell später eine alternative/option. die meisten punkte aus der liste oben und auch auf dem logProxy modul setzen aber eine ebene tiefer an. d.h. beim beschaffen der daten.

das charting frontend kenne ich. es ist aber einen ein komplett neues frontend das sehr direkt auf die db aufsetzt und zur zeit weder mit FileLog noch mit logProxy funktioniert.

mir ist es (wie immer) lieber wenn es so integriert ist das es auch mit anderen fhem komponenten/modulen funktionieren.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

justme1968

@rudi und alle die etwas dazu sagen können:

spricht etwas dagegen das transform attribut zu verwenden und die daten in ihren 'echten' koordinaten zu senden? d.h. z.b. x werten zwischen $fromsec und $tosec und den original y werten und das skalieren und shiften dann den browser machen zu lassen?

das würde einen teil der rechnerei im browser machen und es wäre möglich mehrere kurven in y richtung zu verschieben ohne das sich die y werte für min/max bestimmung ändern und es würde nebenbei das rückrechnen beim anklicken überflüssig machen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968