Konstruktiver Vorschlag zu event-on-change

[rudolfkoenig]

                                                   

> Rudolf König hat auch mal die Patchfiles dafür bekommen, bisher sind aber im
> Wesentlichen nur die Bargraphs in den trunk übernommen worden.

MWn habe ich alle Aenderungen uebernommen, bis auf die Rundung der Zahlen auf 0.1.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Im SVG-Modul ja, aber ich glaube nicht in der FileLog

LG

pah


--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Dr. Boris Neubert]

                                             

Hallo Tobias,

Am 04.12.2012 06:38, schrieb tobias.faust:
> möchte nur mal anmerken das bei einer Auslagerung in FilePLot das
> DbLog garnichts davon hat.

geht es um Logs oder um Plots? Wir haben m.E. die Anforderungen noch
nicht ausreichend geschärft. Wenn es um Plots geht, würde ich die Logs
in Ruhe lassen und an den Plots ansetzen.

Bzgl. der Logs kenne ich die Anforderung:
- Logs klein halten, indem nur Aktivitäten auf interessanten Readings
(event-on-update/change-reading) und/oder nur Änderungen
(event-on-change-reading) gemeldet werden.

Bzgl. Graphen kenne ich die Anforderungen:
- wenn ich Zustände (t1,x1), (t2,x1), ..., (tn,x1), (tn+1,x2), ... habe,
dann will ich eine Linie von (t1,x1) über (tn,x1) nach (tn+1,x2) sehen
und nicht von (t1,x1) nach (tn+1,x2)
- der Plot soll um 00:00 Uhr (nach dem Logrotate) beginnen


Bitte ergänzen. Eine genaue Aufgabenbeschreibung ist wichtig, damit wir
zur Lösung kommen.

Grüße
Boris


--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> Wenn es um Plots geht, würde ich die Logs in Ruhe lassen und an den Plots
> ansetzen.

Je nachdem was man loesen will: beim Generieren der SVG's wird etwa 60% der
Zeit im FileLog GET verbraten, insofern waer das auch interessant. Weiterhin
generiert SVG.pm keine ueberlappenden Punkte, d.h. nur Events die mind. 2
Minuten auseinander sind werden auf dem Tagesplot gezeichnet.

Evtl. unbekannt: FileLog wertet neben $hash->{CHANGED} auch $hash->{CHANGETIME}
aus (Array im TimeNow() Format), um die Zeitpunkte fuer die einzelnen Events
aus $hash->{CHANGED} zu setzen. Wird aber nur vom 50_WS300 / 87_WS2000
verwendet.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Joachim]

                                                   

Danke an alle,
ich fasse das ganze mal fuer mich zusammen,um zu sehen, ob ich alles
richtig verstanden habe.
event-on-update/event-on-change sollte auf jeden Fall in fhem.pl blieben,
die Einstellung on-change filtert allerdings alle Events heraus, und diese
sind dann fuer alle nachgelagerten Module nicht mehr vorhanden. Das
entlastet wahrscheinlich das Hauptprogramm. as Modul dewpoint beschreitet
hier einen Sonderweg (welchen?)
Es ist Interesse vorhanden fuer die gleiche Funktion in FileLog, auch wenn
die gleiche Funktion dann doppelt waere, um Logs klein zu halten.
Fuer Plots waere es sinnvoll, diese Funktion ein drittes mal vorzuhalten,
und ausserdem noch eine Moeglichkeit, zu definierten Zeiten (Tageswechsel,
Vierteltageswechsel). Wahnsinn in Verbindung mit der Vorfilterung des Event
generierenden Moduls.

habe ich dass so richtig verstanden?

Gruss Joachim

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com