Neues Charting / Plotting - GUI Redesign?

[Johannes]

Hast du die Ausgabe vom Update noch? Klingt sehr danach, dass es nicht komplett ist.
Den aktuellsten Stand bekommt man zu 100% , wenn man den gesamten Ordner Frontend aus www löscht und dann nochmal updated.
Wenn das auch nicht hilft gib nochmal Bescheid. Ich teste jedes Update selbst bevor ich es frei gebe, aber das Update Modul hat wohl noch einige Bugs.

[nfidel]

Wer das Problem hat das das Update eventuell nicht komplett funktioniert
hat, kann nachdem der Ordner Frontend gelöscht/verschoben/umbenannt worden
ist ein "force" an das Update hängen. Somit umgeht man die Meldung "nix zu tun".

Code Auswählen Erweitern


update thirdparty http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/www/frontend frontend force


Gruß
Jens

[Johannes]

Kurzinfo:

Derzeit arbeite ich an einer Generalisierungsfunktion für die Charts.
Das hat vor allem Auswirkung auf die Performance im Browser.
Je stärker generalisiert wird, desto weniger gibt es im Browser darzustellen.
Ab einem gewissen Grad gehen natürlich zu viele Informationen verloren. Daher habe ich aktuell eine An / Ausschaltoption für die Generalisierung eingebaut.
Bei aktiver Generalisierung kann dann ein Differenzwert aus einer Dropdown Liste gewählt werden, z.B. 50%.
Bei 50% werden benachbarte Messwerte, deren Differenz zueinander (bzw. zum vorherigen Messwert) größer als 50% ist, in den Chart mit einbezogen. Differenzen darunter fallen raus.
Wer Details dazu wissen will kann gerne nachhaken ;-)

Am besten spielt man mit den Werten ein wenig rum um ein Gefühl dafür zu bekommen, was gute Werte sind.

Hier mal ein paar Vergleichsbilder:
Auf dem ersten sind ungefiltert 227 Messwerte

(siehe Anhang / see attachement)




Auf dem zweiten Bild der selbe Datensatz mit Differenzwert 50% (nur noch 75 Messwerte):

(siehe Anhang / see attachement)




Hier ein Beispiel für eine Wochenansicht mit ungefilterten 1260 Messwerten:

(siehe Anhang / see attachement)



Reduziert bei Differenzwert 80% auf nur 400 Messwerte:

(siehe Anhang / see attachement)





Wie man sehen kann, sind die Darstellungen doch recht identisch. Alle Ausreißer sind weiterhin erkennbar. Und der Browser freut sich und läuft geschmeidiger.

Vor allem lohnt sich die Generalisierung für große Messreihen, wie Wochen / Monats / Jahrescharts.

Grüße,
Johannes

[Andi]

Super Frontend, danke dafür!

Hab nur noch einen Fehler beim speichern der Charts:

Code Auswählen Erweitern


The Chart could not be saved, error Message is:

Could not setup SQL String

MySql Datenbank.

[Johannes]

Hallo Andi,

Probier doch bitte mal wie in
Link
angegeben erstmal den gesamten frontend Ordner unterhalb von www zu löschen, dann ein

Code Auswählen Erweitern

fhem update, dann ein

Code Auswählen Erweitern

update thirdparty http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/www/frontend frontend force

[Johannes]

Update:

Die oben erwähnte Generalisierung ist jetzt eingecheckt und kann per

Code Auswählen Erweitern

update thirdparty http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/www/frontend frontend

installiert werden. Standardmäßig ist die Generalisierung deaktiviert. Wird ein Chart mit Generalisierung gespeichert, wird diese auch beim Laden wieder angewandt.
Mit dem Generalisierungsfaktor kann man ein bisschen rumspielen um zu schauen, was gute Werte sind. Bei Tagescharts reichen 30% i.d.R. aus. Bei Wochencharts oder mehr kann man ruhig weiter nach oben gehen, je nachdem, wie viele Messwerte man hat.

Grüße,
Johannes

[Andi]

Hi Johannes

Danke für dein Feedback!
Habe deine Anleitung befolgt, das Problem besteht aber leider weiterhin.

1. Frontend gelöscht

Code Auswählen Erweitern

/usr/share/fhem/www/frontend

2. Fhem update (beim erneuten Updateversuch)

Code Auswählen Erweitern

fhem> update
nothing to do...

3. Force update vom Frontend.


Wo speichert er denn das Chart Preset? In der Datenbank oder in der Filestruktur?

(siehe Anhang / see attachement)

Filerechte:

Code Auswählen Erweitern

pi@raspberrypi /usr/share/fhem/www $ ls -l
total 16
drwxr-xr-x 4 fhem dialout 4096 Mar 16 16:40 frontend
drwxr-xr-x 2 fhem dialout 4096 Mar 10 23:19 gplot
drwxr-xr-x 6 fhem dialout 4096 Mar 10 23:19 images
drwxr-xr-x 2 fhem dialout 4096 Mar 10 23:19 pgm2


MySql:
Server version: 5.5.28-1 (Debian)

Tabellen:
current
frontend
history

[Johannes]

Hi,

Bitte mal mit einer richtigen Timerange speichern, also über die Kalender Zeitraum auswählen und dann speichern.
Klappts dann?

EDIT:
Das Speichern kann unter Umständen geblockt werden, wenn von FHEM zur selben Zeit in die DB geschrieben wird.
In dem Falle dieser Meldung bitte das Speichern einfach nochmal probieren, nach etwas 20 Sekunden und schauen ob es dann klappt.

[Andi]

Japp, vielen Dank!

Weiter so, freue mich über Updates :-)

EDIT: Die Timerange scheint das Problem bei mir gewesen zu sein - jetzt mit einem festen Zeitraum ging das speichern wunderbar.

[Johannes]

Ok, Problem gefunden und behoben, es gab unter gewissen Umständen ein Problem beim Speichern der dynamischen Zeit, ist aber nun behoben.

[Johannes]

Update

Ich habe auf der linken Seite das Accordion Panel eingedampft. Dort gibt es jetzt stattdessen einen sogenannten "Tree".
Dieser bildet hierarchisch die Struktur der Geräte ab. Nach dem Klick auf ein Gerät, erscheint das Detailfenster, u.a. mit Readings, in der Mitte.

Beispiel:

(siehe Anhang / see attachement)


Bei Fragen / Anmerkungen: scheut euch nicht hier zu melden :-)

Update wie üblich:

Code Auswählen Erweitern


update thirdparty http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/www/frontend frontend


[Andi]

Funktioniert super. Die Baumstruktur ist nützlich und sehr benutzerfreundlich.

[Johannes]

Danke!

Zur Info:
Ich arbeite aktuell an einer Statistikfunktion.
Damit kann ich aktuell:
  * Durschnittswerte zu einem beliebigem Reading abfragen (Average)
  * Summenwerte zu einem beliebigem Reading abfragen (SUM)
  * Maximalwerte zu einem beliebigem Reading abfragen (MAX)
  * Minimalwerte zu einem beliebigem Reading abfragen (MIN)
  * Insgesamte Anzahl zu einem beliebigem Reading abfragen (COUNT)

Das Abfrage lässt sich zudem folgendermaßen eingrenzen:
  * stündlich (1 Wert pro Stunde)
  * täglich (1 Wert pro Tag)
  * wöchentlich (1 Wert pro Woche)
  * jährlich (1 Wert pro Jahr)

Ausserdem dann noch über einen allgemeinen Zeitraum mit den kalendern, wie bisher gewohnt.


Daraus lassen sich nette Informationen ableiten:
Z.B. habe ich jetzt mal einen Überblick, wie gut bzw. häufig die Funksignale meines Sensors eigentlich bei mir eintreffen (COUNT). So erkennt man schnell "Funklöcher" oder auch verregnete Tage ;-).

Oder man kann sich eine Monatsansicht holen mit den Maxwerten des Tages, etc. pp.

Das ganze wird im DbLog Modul integriert, so dass die Abfragen auch zügig auf der Datenbank von statten gehen.

[thoweiss]

Das sieht ja schon klasse aus!

Aber Schalten geht noch nicht - oder?

Gruß,
Thorsten

[Johannes]

Hallo Thorsten,

Danke fürs Lob. Was genau meinst du mit Scahlten? Vermutlich z.B: Lampe an / aus?
Ich habe bisher keine Schaltaktoren, daher habe ich mich da noch nicht dran gemacht.
Es wäre aber sinnvoll auch in der Richtung mal was zu tun. Da mir da aber sowohl Hardware als Erfahrung fehlt, würde ich gerne eure Vorschläge hören, wie das Schalten am besten umzusetzen wäre.
Wo sollen die Schalter im Frontend auftauchen, wie sollen sie zu bedienen sein (Button, Icon, Dropdown, Slider etc. pp.)?
Ich bin für alle Vorschläge offen, un denkt dran, neue Wege einzuschlagen was die Bedienung angeht ist kein Verbrechen :-)