Neues Charting / Plotting - GUI Redesign?

[Johannes]

Hallo,

Das von mir beschriebene Verhalten beim Parsen bezieht sich auf Filelogs, ja.
Der angemerkte Punkt ist dabei aber nicht mehr gültig, Filelog wird jetzt auch mit unendlich vielen Lerrzeichen als Trenner unterstützt.
Eigentlich sollten damit alle Filelog Varianten unterstützt sein.

Zu deinem Problem:
Es klingt als wenn du etwas machen möchtest, das mit dem Frontend erstmal garnichts zu tun hat, nämlich die Logwerte reduzieren / beschränken.
Das sind Konfigurationen mit dblog und fhem.cfg, da müsstest du dir an anderer Stelle Hilfe holen.
Das Frontend liest aus der Datenbank die Messwerte, die dort geloggt sind. Normalerweise sorgt dblog dafür, dass pro Messwert ein einzelner Eintrag besteht, und somit muss man sich bei dblog keine Gedanken darum machen, wie man loggt. Im schlimmsten Fall hat man einfach nur zu viel Auswahl, aber das stört das Frontend ja nicht, da man dort gezielt seine gewünschten Messwerte einfach auswählen kann.

Falls ich was falsch verstanden habe, bitte einfach nochmal konkreter fragen

[tpm88]

Hallo Johannes,

danke für die Erklärung.

Das von mir beschriebene Verhalten beim Parsen bezieht sich auf Filelogs, ja.

Ok. Klar.

... Normalerweise sorgt dblog dafür, dass pro Messwert ein einzelner Eintrag besteht, und somit muss man sich bei dblog keine Gedanken darum machen, wie man loggt. ...

Code Auswählen Erweitern

2014-04-03_12:49:46 wz_Thermostat_ClimRT_tr T: 20.9 desired: 17.0 valve: 0

Hmm - dblog legt aber dieses kombinierte state Reading als einzelnen Eintrag in der Datenbank ab - im Frontend kann ich dieses Reading dann als "T" für die y-Achse auswählen, kann daraus dann aber nicht ein Chart mit drei Datenreihen mit gemessener Temperatur (T), erwünschter Temp. (desired) und Ventilöffnung (valve) erstellen. Ich komme sozusagen nicht an die beiden hinteren Werte ran.

Mein Szenario ist ein wenig komplex:
- der FHEM Hauptserver ist auf einer "schwachbrüstigen" FritzBox ohne Dblog. Dort logge ich in Filelogs und die wollte ich ausdünnen aus Performance-Gründen
- eine zweite FHEM-Instanz läuft auf meinem NAS (QNAP) und bekommt alle Events von der Hauptinstanz per FHEM2FHEM und legt die Readings per Dblog in einer sqlite Datenbank ab. Das Frontend greift auf diese DB zu.

FHEM liefert für den RT-DN die obigen Readings als drei separate Zeilen und zusätzlich redundant "kombiniert" im state Reading. Bisher habe ich die Charts über die Einzelwerte generiert - hat prima funktioniert. Um die Filelogs auszudünnen, war meine Überlegung eben jetzt die Zeilen mit den Einzelwerten im Filelog wegzulassen. Damit kommen sie aber auch nicht mehr per FHEM2FHEM in die Datenbank.

Ich hoffe, meine Motivation ist jetzt etwas klarer formuliert.

Gruss
Tobias

[Joachim]

cloneDummy
userReading

[tpm88]

Hallo Joachim,

danke für den Tip. Bevor ich jetzt mit dem Implementieren loslaufe...

cloneDummy
userReading

... bitte ich um ein kurzes "ACK", ob ich das richtig interpretiere für mein Szenario:

- an FHEM A ist der RT-DN als echtes Device "wz_Thermostat" angeschlossen, dessen Filelogs sind wie oben beschrieben "ausgedünnt"
- FHEM B bekommt per FHEM2FHEM nur noch o.g. Kombi-Reading state mit den drei Einzelwerten T, desired und valve in einer Zeile und loggt es in der DB
- auf FHEM B definiere ich ein cloneDummy device "clone_wz_Thermostat", welches auch nur das Kombi-Reading "empfängt"
- für den cloneDummy definiere ich drei  UserReadings für die Einzelwerte temperature, desired und valve und parse sie aus dem Kombi-Reading
- die UserReadings werden wiederum in der DB geloggt
- damit kann ich die Einzelwerte über das Chart / Frontend plotten

Oder eher so - Variante B ??

- der cloneDummy mit den userReadings (wie oben) wird auch auf FHEM A definiert
- FHEM B erhält per FHEM2FHEM die userReadings vom cloneDummy device und loggt sie in der DB
- Charts im Frontend wieder über die userReadings des cloneDummy

Die erste Variante gefällt mir besser. Dann habe ich die zusätzliche Last und die zusätzlichen Clone Devices nur auf dem reinen FHEM Logging Server B.
Würden überhaupt beide Varianten funktionieren??

Gruss
Tobias

[Joachim]

Die erste grundlegende Frage ist, warum loggst Du überhaupt auf FHEM A und zusätzlich nocheinmal auf FHEM B?
Die nächste Frage ist, warum dünnst Du erst aus, um danach wieder zu trennen?

Wenn Du unbedingt auf FHEM A nur ein Kombireading für das Filelog haben willst, dann kannst Du doch trotzdem die Einzelreadings über FHEM2FHEM an FHEM B weitergeben, es sei denn Du hast sie über event-on-change ausgeblendet.

Dann sparst Du Dir die ganzen Verrenkungen.
Ansonsten Variante a, Variante b ist Unfug, weil s.o.

Hatte am Anfang nicht gelesen, dass du in FHEM A schon ausdünnst, sonst hätte ich Dir cloneDummy und userReading nicht enpfohlen.


Gruß Joachim

[tpm88]

Hallo Joachim,

Die erste grundlegende Frage ist, warum loggst Du überhaupt auf FHEM A und zusätzlich nocheinmal auf FHEM B?

FHEM A auf der FritzBox ist das adHoc System mit den Devices, zum Schalten und Walten, hier kann ich schnell und einfach per grep/tail/cat etc in ein Filelog schauen, SVG Plots für den täglichen Bedarf werden aus den Filelogs generiert (auch aus Kombireadings). Aber - viele grosse Filelogs kosten beachtlich Performance, Filelogs werden irgendwann archiviert oder gelöscht, etc etc

FHEM B mit Dblog ist zur Langzeit (Monate, Jahre) Archivierung gedacht. Das Charting Frontend ist dann für Auswertungen wie Temperaturkurven oder Heizkurven über einen Monats- oder Jahreszeitraum gedacht.

Die nächste Frage ist, warum dünnst Du erst aus, um danach wieder zu trennen?

- Ausdünnen der Filelogs wegen Performance auf FHEM A
- Trennen in Einzelreadings nur WEIL das Charting Frontend eben keine Plots für  Kombi-Readings aus der DB unterstützt  (nur mit Filelogs - siehe oben)

Wenn Du unbedingt auf FHEM A nur ein Kombireading für das Filelog haben willst, dann kannst Du doch trotzdem die Einzelreadings über FHEM2FHEM an FHEM B weitergeben, es sei denn Du hast sie über event-on-change ausgeblendet.

Hm - wie soll das gehen? Habe ich da etwas übersehen? FHEM2FHEM überträgt doch genau die Events/Readings an FHEM B, die FHEM A auch ins Filelog schreibt. Dünne ich das Filelog mittels event-on-change oder event-on-update selektiv aus, sieht doch auch FHEM2FHEM die Events/Einzelreadings nicht mehr.

Nochmal ein Beispiel  - das HM Thermostat liefert periodisch folgende Events:

Code Auswählen Erweitern

2014-04-04_10:43:16 dg_Thermostat_Clima measured-temp: 19.3
2014-04-04_10:43:16 dg_Thermostat_Clima desired-temp: 17.0
2014-04-04_10:43:16 dg_Thermostat_Clima ValvePosition: 0
2014-04-04_10:43:16 dg_Thermostat_Clima T: 19.3 desired: 17.0 valve: 0


Macht vier Zeilen pro Update - 3 Zeilen mit je einem Einzelreading, 1 Zeile (state) mit dem Kombireading.
Im Filelog spare ich 75% Platz, wenn ich die Einzelreadings komplett unterdrücke (event-on-change/event-on-update nur für state). Auf FHEM B für das Auswerten aus dem DBlog bräuchte ich aber auch die 3 Events/Zeilen mit den Einzelreadings.

Dann sparst Du Dir die ganzen Verrenkungen.
Ansonsten Variante a, Variante b ist Unfug, weil s.o.

Wenn es eine einfachere Lösung (ohne Änderung der ganzen Rahmensituation mit FHEM A / B) gibt, gerne. Die Variante A mit cloneDummy und userReading ist zumindest EINE Lösung, da ich nicht davon ausgehe, dass Johannes die Readings aus der Datenbank noch weiter parsen möchte.

Ein Filter fürs  FileLog (analog DBlog oder FHEM2FHEM) zum filtern der Events/Readings, die ins Filelog geschrieben werden, würde auch helfen.

Gruss, Tobias

[Joachim]

Hm - wie soll das gehen? Habe ich da etwas übersehen? FHEM2FHEM überträgt doch genau die Events/Readings an FHEM B, die FHEM A auch ins Filelog schreibt. Dünne ich das Filelog mittels event-on-change oder event-on-update selektiv aus, sieht doch auch FHEM2FHEM die Events/Einzelreadings nicht mehr.

Ja, Du hast etwas übersehen.
Der Inhalt des Filelogs muss nicht identisch mit dem sein, was an Events generiert wird.
Bei mir ist es z.B. so, dass die FB alle 1-Wire Sensoren verwaltet, die für mich relevanten Events an den Pi mit FHEM2FHEM weitergegeben werden, dort mit cloneDummy angezeigt werden, bzw. direkt in DBLog laufen. Die FB loggt garnichts.
Du musst also nur dafür sorgen, dass nur die Readings, die Du haben möchtest, imFilelog geloggt werden.
Dafür musst Du Deine Filelogdefinition entsprechend anpassen, und trotzdem die Events die Du auf FHEM B haben möchtest, weiterhin als Reading laufen lassen.
Als Beispiel von mir:

Code Auswählen Erweitern

define FileLog_Bad FileLog ./log/Badezimmer-%Y-%m.log (HK_Regler_Badezimmer:.*(desiredTemperature|valveposition)):|(Temp_Sensor_Badezimmer:.*C).*

Alle Events von HK_Regler_Badezimmer und vom Temp_Sensor_Badezimmer mit dem der Bezeichnung desiredTemperature|valveposition und C werden in das Filelog geschrieben.
In der Definition meines HK Reglers

Code Auswählen Erweitern

define HK_Regler_Badezimmer MAX HeatingThermostat 03bfa8
attr HK_Regler_Badezimmer event-on-change-reading valveposition,battery,desiredTemperature,temperature
werden aber zusätzliche Events durchgelassen, die dann natürlich auch FHEM2FHEM zur vefügung stehen.

Gruß Joachim

[tpm88]

Ja, Du hast etwas übersehen.
Der Inhalt des Filelogs muss nicht identisch mit dem sein, was an Events generiert wird.

Du hast natürlich Recht. Ein einfaches RTFM hätte auch genügt - dabei hab ich gestern abend nochmal in die CommandRef zu Filelog geschaut.

Code Auswählen Erweitern

define <name> FileLog <filename> <regexp>

Die regexp ist natürlich auch genau der "Filter", den ich mir in meinem letzten Post gewünscht habe.

Ich habe bisher meine FileLogs eigentlich immer nur per autocreate / createlog definiert - dann loggen sie per default natürlich ALLE Events.

Oh Mann, jetzt komm ich mir ein bisserl doof vor.

In jedem Fall - wieder was/viel gelernt. Und das Beste - ich habe jetzt auch ein viel besseres Verständins von cloneDummy...

Danke & Gruss
Tobias

[Joachim]

Du hast natürlich Recht. Ein einfaches RTFM hätte auch genügt

Wollte mal höflich sein.

Gruß Joachim

[Christian.]

Hallo zusammen,

ich teste das Charting Frontend auf einer Fritz!Box 7390. Erstmal ein großes Lob an Johannes - eine großartige Idee, das sind im Vergleich zur herkömmlichen Darstellung Riesenschritte in Sachen Flexibilität und Bedienbarkeit!

Ich möchte hier einen Feature-Request loswerden. Ich habe Log-Files, die von mehreren Geräten gemeinsam beschrieben werden. Die zweite Spalte gibt immer den Gerätenamen an. Beispiel:

Code Auswählen Erweitern

2014-04-14_06:55:19 counter_eg power: 59.15 W
2014-04-14_06:55:38 counter_haustechnik power: 16.88 W
2014-04-14_06:56:20 counter_eg power: 58.82 W
2014-04-14_06:56:32 counter_heizung power: 30.01 W
2014-04-14_06:57:21 counter_eg power: 58.98 W
2014-04-14_06:57:58 counter_og power: 11.00 W
2014-04-14_06:58:22 counter_kueche power: 6.38 W
2014-04-14_06:58:22 counter_eg power: 59.48 W
2014-04-14_06:58:33 counter_heizung power: 29.88 W

Das Frontend ignoriert die zweite Spalte (z.B. counter_eg), die Geräte werden folglich nicht unterschieden. Soweit ich das diesem Thread entnehmen konnte, ist das auch so zu erwarten, weil das Frontend darauf nicht ausgelegt ist. Über eine entsprechende Erweiterung würde ich mich sehr freuen. Sollte ich nur übersehen haben, dass man dem Chart das Gerät irgendwie angeben kann, bitte ich um einen Hinweis.

In jedem Fall vielen Dank für die ganze Arbeit, ein großartiges Projekt.

Schöne Grüße
Christian

[Johannes]

Hallo,

Danke fürs Lob!
Das auslesen von mehreren verschiedenen Geräten aus einem Logfile ist noch nicht implementiert, aber da der Aufwand nicht groß ist und der Nutzen auf der Hand liegt werde ich es in das nächste Release mit aufnehmen.

Grüße!

[Johannes]

Update:

Ich möchte hier einen Feature-Request loswerden. Ich habe Log-Files, die von mehreren Geräten gemeinsam beschrieben werden. Die zweite Spalte gibt immer den Gerätenamen an.

Ist eingebaut. Bitte testen, ob es wie gewünscht funktioniert.

Sprich es sollten jetzt verschiedene Geräte aus einem Logfile mit verschiedenen Readings unterstützt werden.
Grüße!

[Christian.]

Funktioniert wie gewünscht - vielen Dank!

[maxritti]

Hallo,

bislang habe ich mit dem Standard Plots von FHEM gearbeitet.
Und zwar habe ich mir für meine Tür-/Fensterkontakte ein Chart gebaut um den Überblick zu erhalten.
Dabei habe ich unterschiedliche maximale Werte für open genommen, damit man überhaupt noch etwas sieht.
So sieht das dann aus.

Kann man so etwas auch in dem Frontend machen?
Mittels der userconfig.js habe ich den maximalen Wert schon mal auf 1 gesetzt, aber umrechnen in abhängigkeit vom Device habe ich noch nicht gefunden.

Oder hat jemand einen anderen Ansatz?
Eventuell direkt die Werte anders ins Log schreiben?

[Johannes]

Hallo,

Mittels der userconfig.js habe ich den maximalen Wert schon mal auf 1 gesetzt, aber umrechnen in abhängigkeit vom Device habe ich noch nicht gefunden.

Die userconfig arbeitet global, es gibt keine Unterscheidungen für Geräte.

Oder hat jemand einen anderen Ansatz?
Eventuell direkt die Werte anders ins Log schreiben?

Genau das ist der Weg. Das Frontend ist zum Anzeigen der Daten da, nicht zum manipulieren.
Was du suchst sollte dem "userReading" entsprechen.

Grüße!