Neues Charting / Plotting - GUI Redesign?

[Johannes]

Das erklärt dann mein Problem mit dem Frontend.

Neben einem Userreading kannst du das Problem auch umgehen, wenn du DbLog benutzt. Da wird der beschriebene Code nicht benötigt und damit gehts auf jeden Fall...

[willyk]

Hallo,Schau mal bitte in deinem FHEM Verzeichnis unter /www/frontend/app/ ob da die Datei filelogcharts.js existiert.
Wenn ja, was steht drin?

Habe ich angehängt.

Wenn nein, bitte anlegen und mit folgendem Inhalt füllen:

Code Auswählen Erweitern


FHEM.filelogcharts = [{}];

Dann nochmal probieren.

Viel besser. Nun kann ich Charts speichern. Die neue Datei habe ich zur Info mal angehängt.

Kleiner Schönheitsfehler: unter "Charts" habe ich nun zusätzlich einen leeren Eintrag stehen, den ich nicht bearbeiten / löschen kann (siehe hc1). Wie kriege ich das wieder weg?

[willyk]

Viel besser. Nun kann ich Charts speichern. Die neue Datei habe ich zur Info mal angehängt.

Doch nicht. 

Die Charts kann ich speichern, wenn ich das Frontend neu lade ist alles weg. Das Speichern funktioniert also, das Einlesen anscheinend nicht.

Kann ich einen Debug / Trace anschalten damit man sieht, was passiert?

Danke + Gruss
willyk

[Johannes]

Das Problem liegt darin, dass dein Browser / Betriebssystem beim Speichern in die Datei filelogcharts.js am Anfang und am Ende der Datei ein ' Zeichen einfügt.
Das gehört da nicht hin und verursacht das Problem. Ist mir bisher nicht untergekommen und zur Zeit noch schleierhaft, wo das herkommt.

Welches OS / Browser kommt genau zum Einsatz?
Schonmal einen anderen Browser ausprobiert (mit vorher gereinigter filelogcharts.js, wie oben beschrieben)?
Gruß!

[willyk]

Welches OS / Browser kommt genau zum Einsatz?

WIN X64, Chrome 37.0.2062.120, wahlweise IE 10.0.20. Der Effekt ist bei beiden Browsern gleich.

Das Problem liegt darin, dass dein Browser / Betriebssystem beim Speichern in die Datei filelogcharts.js am Anfang und am Ende der Datei ein ' Zeichen einfügt.

Die Zeichen habe ich mal testhalber mit einem Editor entfernt, das ändert aber nichts (soll heissen, es wird immer noch nicht eingelesen).
Gruss

[Bkel]

Passt nicht ganz, aber ...

ich war gezwungen, fhem komplett neu aufzusetzen. Ich benutze das Charting frontend ganz gerne und wollte es erneut installieren.
Das "update thirdparty" liefert mir aber nur ein "nothing to do". Beißt sich da was mit dem "neuen" update-Mechanismus oder sitzt das Problem vor dem Bildschirm?

Grüße
Boris

[krikan]

Probier mal (wegen neu geschriebenen update-Befehl):

Code Auswählen Erweitern

update all http://svn.code.sf.net/p/fhem/code/trunk/fhem/www/frontend/controls_frontend.txt

[Bkel]

Danke!

Es tut wieder

[RichardR.]

Hallo,
ich habe ein Problem mit dem Charting Frontend und DbLog:
nachdem ich im Frühjahr ein paar Plots angelegt hatte wollte ich jetzt nach längerer Zeit einige weitere anlegen. Leider kann ich keine Devices mehr auswählen, wenn ich DbLog verwenden möchte (FileLog geht). Es erscheint nur einige Zeit lang der Sanduhrkreis und dann ist jedoch kein Eintrag in dem Drop-Down-Menü zu finden.
Im Logfile finde ich dann Einträge:
"PERL WARNING: Use of uninitialized value $yaxis in concatenation (.) or string at ./FHEM/93_DbLog.pm line xyz"

Wo kann ich hier ansetzen?

FHEM ist aktualisiert.
Das Frontend meldet sich mit einer Version 1.0.8 vom 12.01.2014 - ist das aktuell? Ein update-Versuch wird jedenfalls mit einem "nothing do do" beantwortet.

[Johannes]

Hi,

Das Problem ist wahrscheinlich deine Datenbank, die mittlerweile zu träge geworden ist. Die Perl-Warning kannst du ignorieren, hat damit nichts zu tun.
Im Hintergrund läuft das DbLog Modul, welches die Datenbanktabelle "history" abfragt nach allen verfügbaren "Devices" (SQL in etwa "Select distinct(device) from history;").
Je nach Größe der Datenbank dauert dies lang.  Wenn länger als 30 Sekunden bricht das Frontend die Anfrage ab.
Was du tun kannst:
1.) Prüfen, ob die Indexes korrekt gesetzt wurden auf der Tabelle
2.) Die Datenbank entschlacken (alte Einträge archivieren?!))
3.) Probehalber eine neue DB / Tabelle anlegen (alte natürlich vorher sichern) und prüfen, ob das Problem verschwindet.
4.) Mir mitteilen, welche Datenbank (SQLite?) benutzt wird, wie groß die DB ist und auf welcher Hardware das ganze läuft.

Ich tippe mal Raspberry Pi und SQLite. Das wäre nämlich die langsamste Variante...

[RichardR.]

Hallo,

zu 1)
wie prüft man die Indices?
(es hat wie gesagt auch schon mal funktioniert)

zu 2)
wie kann man die DB reduzieren?
Kann man auch selektiv einzelne "devices" entfernen?
(momentan werden alle gespeichert ".*:.*")

zu 3)
ist in Arbeit...

zu 4)
sqlite3 auf Raspberry-Pi
Die DB hat knapp 600MB und ist ca. 6 Monate in Betrieb.

Generell wäre es natürlich wünschenswert, wenn man auf die Daten schon über lange Zeiträume zurückgreifen kann, ohne die DB "entschlacken" zu müssen, z.B. um Jahresvergleiche machen zu können.
Wie sollte man dafür die DB anlegen?
Bis zu welcher DB-Größe funktioniert der Zugriff in akzeptabler Zeit?

[Jakl]

Hallo RichardR, hallo Johannes,

ich habe das selbe Problem wie RichardR, habe zum Teil die einzelnen Punkte schon gelöst, aber auch noch selbst fragen.

zu 1)
wie prüft man die Indices?
(es hat wie gesagt auch schon mal funktioniert)

Die SQLite3 Konsole für die DB öffnen und per .schema die Tabellen und Indices abfragen. Sieh auch http://www.sqlite.org/faq.html#q7
Bei mir war der Index schon angelegt, obwohl ich mich nicht erinnern konnte, das selbst gemacht zu haben.

zu 2)
wie kann man die DB reduzieren?
Kann man auch selektiv einzelne "devices" entfernen?
(momentan werden alle gespeichert ".*:.*")

Dazu kann man die einzelnen Devices ausschließen. Hierfür gibt es das Attribut DbLogExclude. Man muss das Attribut erstmal zu den userattr von global hinzufügen und dann kann man jedem Device, welches man ausschließen will das Attribut DbLogExclude hinzufügen.

Code Auswählen Erweitern

attr global userattr devStateIcon devStateStyle icon sortby webCmd DbLogExclude
attr global DbLogExclude .*


Zu 3) muss ich auch Johannes eine Frage stellen, welche DB wird den in Zusammenhang von FHEM auf einem Raspi empfohlen?

Und noch was, ich habe im Forum die Empfehlung gelesen, das Attribut "attr xyz DbLogType History" würde auch Geschwindigkeit bringen.
@Johannes, kannst du das bestätigen?



Gruß,
Jakl

[Johannes]

Hallo,

wie kann man die DB reduzieren?
Kann man auch selektiv einzelne "devices" entfernen?
(momentan werden alle gespeichert ".*:.*")

Also ich habe am Anfang auch gesagt "ich nehme erstmal alles" in die DB auf.
Rückblickend kann ich sagen, dass ich
1.) Nur ca. 10% der erfassten Daten (Readings) auch Nutze zur Visualisierung und
2.) Ich tatscähclich mir nicht mehr anschaue, wie sich der Stromverbrauch minütlich geändert hat vor 12 Monaten

Es gibt 2 ganz simple Möglichkeiten, die Datenmenge in der DB enorm zu reduzieren:
1.) DbLogExclude. Damit sortiere ich konkret Readings aus (nicht devices!), die mich nicht interessieren. Hier mal ein Beispiel für meinen ESA2000

Code Auswählen Erweitern


attr ESA2000_LED_011e DbLogExclude repeat,sequence,raw,rate,lr_kwh,day_lr_kwh,month_lr_kwh,type,ticks_kwh,total_ticks,actual_ticks,total_kwh,diff_kwh,diff_sec,diff_ticks,last_sec

Die ganzen Daten interessieren mich genau genommen - garnicht. Also weg damit. Das hab ich für jedes Device gemacht das ich in die DB logge. EInmal schauen, was man wirklich braucht un den Rest excluden.

2.) Alternativ oder zusätzlich "event-on-change" verwenden. Ist eine weitere praktische Sache. Damit landen in der DB nur noch Messwerte, die sich zum vorhergehenden Messwert unterscheiden.
Ein Temperatursensor im Innenraum fabriziert dadurch (weil er nur gering schwankt) gefühlt 80% weniger Datenmüll in der DB. Was bringt es mir 200 aufeinanderfolgende Messwerte zu haben, die sich garnicht unterscheiden? Mir persönlich nichts.
Ein Codebeispiel:

Code Auswählen Erweitern


attr WZ_Wandthermostat event-on-change-reading temperature,desiredTemperature,battery


Generell wäre es natürlich wünschenswert, wenn man auf die Daten schon über lange Zeiträume zurückgreifen kann, ohne die DB "entschlacken" zu müssen, z.B. um Jahresvergleiche machen zu können.
Wie sollte man dafür die DB anlegen?
Bis zu welcher DB-Größe funktioniert der Zugriff in akzeptabler Zeit?

Das sehe ich genauso! Das Problem bei dir ist aber 1.) der Rechenschwache Raspberry und 2.) Die Datenbankgröße kombiniert mit der unperformanten SQLite DB.
Vielleicht kann ja hier mal jemand berichten, wie man die SQLite beschleunigen kann. Ich habe selber eine Weile rumprobiert aber keine Lösung gefunden.
Trotz Index auf der Device Spalte benötigt ein
"Select distinct(device) from history" auf einem Raspberry bei großer Datenbank teilweise Minuten!
Gibt es vielleicht Vorschläge für ein performanteres SQL?

[Johannes]

Zu 3) muss ich auch Johannes eine Frage stellen, welche DB wird den in Zusammenhang von FHEM auf einem Raspi empfohlen?

Ich kann mir vorstellen, dass Postgres und MySQL beide performanter wären. Mangels Raspberry und Zeit zum Loggen / testen bleibts aber eine Vermutung meinerseits.
Das wesentliche Problem der Diskussion hier ist das im vorigen Beitrag genannte SQL. Wenn man das in den Griff bekommt, also schnell, ist das Problem auch gelöst und SQLite auch ok.

Und noch was, ich habe im Forum die Empfehlung gelesen, das Attribut "attr xyz DbLogType History" würde auch Geschwindigkeit bringen.
@Johannes, kannst du das bestätigen?

Kann ich nicht, da ich das Attribut weder kenne, noch in der Commandref finde. Was soll das genau bezwecken?

[Posti123]

Hi,

wenn ich das Fronten mit update all http://svn.code.sf.net/p/fhem/code/trunk/fhem/www/frontend/controls_frontend.txt installieren möchte, bekomme ich nur ein "nothing to do". Auch ein force bringt keinen Erfolg.

Das Frontend ist definitiv noch nicht installiert.

Schon mal jemand das Problem gehabt?