SVG-Plot/LogProxy: Beschriftung der Plot-Werte

Begonnen von Bastel-Frank, 14 August 2020, 08:35:55

Vorheriges Thema - Nächstes Thema

rudolfkoenig

eigentlich würde ich gerne auch ein paar generalisierte Muster-.gplot für z.B. das 3-phasige Messen oder den Thermostat mit Außentemperatur oä. einpflegen
Das finde ich deswegen amuesant, weil ich auch damit angefangen habe: einige Module erzeugen jetzt noch per autocreate SVGs mit dem passenden Template, autocreate bietet eine Schnittstelle dafuer an.

Ich empfand irgendwannmal den Aufwand, diese Templates anzupassen (auch wegen den Fragen von Generix) hoch, bzw. fuer "einfache" Benutzer unzumutbar, deswegen habe ich mit dem PlotEditor angefangen.

Vermutlich gibt es keine Loesung, was jedem Recht ist.

Beta-User

Ja, man merkt dieser Ecke von FHEM an, dass da viele vieles angefangen haben... (ich habe CUL_HM-Thermostate und fand das lange sehr gut, was autocreate da "veranstaltet"; irgendwann habe ich allerdings dann mit dem "hilfreichen" Editor die Außentemperatur (aus einer anderen Logfile ;) ) dazugebastelt und dummerweise damit einen ganzen Haufen individueller Definitionen generiert; erst beim Aufräumen dieses suboptimalen Zustands bin ich dann über plotreplace "gestolpert", was dann Anlaß für den "neuen Artikel" (SVG) war und auch für mindestens einen anderen wieder so interessant, dass der sehr aktiv dazu beigetragen hat).

Im Prinzip denke ich, dass plotreplace ein sehr mächtiges Werkzeug ist, das vieles vereinfachen _könnte_. Es fehlt allerdings irgendwie der integrierende Ansatz, und es wäre vermutlich wichtig, eine gewisse "kritische" Masse an gplot-Files zu haben, damit die User das feature überhaupt wahrnehmen und damit weiterarbeiten können. Anders gesagt: es gibt da viele Detaillösungen, aber warum braucht es fht.gplot und hm-rt.gplot (und einen Wandthermostat?) und ggf. nochmal was für EnOcean und dann noch (EnOcean) motion, motion+brightness, ... und dasselbe nochmal für ZWave, ... (?)?
"Eigentlich" sollte man z.B. für jede Variante eines Klimagerätes (und unterschiedslos für FileLog oder DBLog?) mit einem oder zwei "Master-gplot" auskommen können (mit und ohne Fenster-kontakt, z.B.), dann vergibt man (via attrTemplate?) das "eine" Attribut und "fertig ist die Laube" (und das Ergebnis ggf. nachvollziehbarer). Würde halt erfordern, dass im Modul-Code ignoriert wird, was "nicht vorhanden" ist.

Dazu ggf. noch ein paar wenige sinnstiftende logProxy-Beispiele? (Ich habe das noch nicht im Einsatz, aber irgendwann will ich ggf. meine statistics-Werte ohne komplexe Datenbankabfragen historisch vergleichen können).

(Das ist nicht die wichtigste Ecke, es war nur grade Gelegenheit, meine Gedanken etwas auszuführen).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files