Konstruktiver Vorschlag zu event-on-change

[Joachim]

                                                   

Moin @ all,

Da wir heute den ersten Advent haben, ist es genau die richtige Zeit, sich
etwas zu Weihnachten zu wuenschen.
Mein Wunsch waere, das event-on-change/Event-o-update Handling aus der
fhem.pl zu entfernen, und der 92_FileLog.pm zuzuschlagen.
Begruendung:
1. beim jetzigen Handling ist der Plot von Sensoren/Aktoren nicht wirklich
Userfreundlich
   - wenn selten Ereignisse gemeldet werden reisst der Plot ab, z.B.
Tageswechsel, oder ist nicht aktuell, weil lange keine Daten gemeldet wurden
2. Es sind unnoetige Kunstgriffe noetig um den Tageswechsel doch sinnvoll
hinzubekommen
3. Das Log wird unnoetig aufgeblaeht, wenn der Plot brauchbar sein soll

Der Loesungsnsatz waere event-on-change/event-on-update in die
92_FileLog.pm auszulagern, da diese auch die Kontrolle ueber zu erstellende
Logs hat.
damit waere es moeglich,
a) im Log nach einem Vergleich des neuen readings bei keiner Aenderung den
alten (vorherigen) Wert aus dem Log zu loeschen und durch den neuen Wert zu
ersetzen,
    es sei denn es ist der Tageswechsel oder ein anderes definiertes
Ereigniss. Die Folge ist, dass ein Plot immer aktuell ist und auf
Kunstgriffe verzichtet werden kann.
b) Im Eventmonitor die Events immer noch auftauchen, und damit eine
Kontrolle, ob alles funktioniert einfacher ist.
c) Logs klein gehalten werden koennen bei gleichzeitig aussagekraeftigem
Inhalt. (kleinste Datenmenge 2 Eintraege am Tag)
d) der Aufbau von Plot durch die geringe Datenmenge deutlich schneller
geht. Auch Monats oder Jahresansichten waeren auf schwachbruestigen
Systemen moeglich.

Die Steuerung der zu generierenden Events sollte gleichzeitig natuerlich in
dem entsprechendem Modul verbleiben, um je nach Anforderung moeglichst
genau bei hoeherer
Systemlast Daten zu liefern, oder auf kosten der genauigkeit die Systemlast
zu reduzieren.

Ich hoffe auf eine rege Diskussion ueber das Fuer und Wieder.
Sollte mein Vorschlag im Developersbereich besser aufgehoben sein gebt
bescheid.

MfG
Joachim


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

[Guest]

Originally posted by: <email address deleted>

Hallo Joachim,

event-on-change würde ich in fhem.pl lassen. Es hat zwar Mängel, ist aber
bei vielen Einsatzzwecken gut einsetzbar.

Ein modifiziertes FileLog mit der beschriebenen Funktionalität wäre aber
schon interessant. Würde ich auch einsetzen wollen, wenn es da wäre.

Das Hauptproblem ist allerdings: Wer macht es? Hast Du Lust dies zu
implementieren?
Gemäß dem Spruch Erich Kästners: "Es gibt nichts Gutes, außer man tut es"


Bei mir ist der Leidensdruck nicht stark genug selbst Hand anzulegen. Dazu
habe ich noch viele Projekte, die dringend auf Umsetzung warten und zu
wenig Zeit diese umzusetzen. Meine 16 Gigabyte SD-Karte in meinem Raspberry
Pi/Sheevaplug ist groß genug für die nächsten Jahre (derzeit sind die Jahre
2010, 2011 und 2012 gespeichert) und Geduld etwas auf den Plot zu warten
habe ich noch.

MfG Willi

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

[Guest]

Originally posted by: <email address deleted>

Das Event-Handling sollte in fhem.pl bleiben.

In das FileLog.pm könnte aber aufgenommern werden, dass beim
Tages/Monatswechsel automatisch die zuletzt erhaltenen Daten noch ins alte
Log geschrieben sowie als erste Zeile schon ins neue Log übernommen werden.

LG

pah

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

[Joachim]

                                                   

Moin Willi, Moin Prof.,

Ist das ein Bauchgefuehl, oder gibt es Gruende, dass
event-on-change/event-on-update in fhem.pl bleiben soll?
Mal abgesehen von "wer soll es machen", und das ist der 2. Schritt sehe ich
nur Vorteile. Fuer den Plot ist die bisherige Loesung unakzeptabel, siehe
Bild.

Da ich erst ziemlich neu bei FHEM bin, kenne ich noch nicht alle
Feinheiten, aber meine vorgeschlagene Aenderung waere Modulunabhaengig,
wuerde in der normalen Oberflaeche das Risiko verringern, dass diese
Zeillich hinterherhinkt, und das Log auf die noetigen Inhalte, wann hat
eine Aenderung stattgefunden hat, beschraenken.

In OWTHERM kommt wenn ich den Code richtig verstanden habe ein ganz anderes
Handling vor.

gruss Joachim

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

[UliM]

                                                 

Am Montag, 3. Dezember 2012 08:00:10 UTC+1 schrieb Prof. Dr. Peter A.
Henning:
>
> beim Tages/Monatswechsel automatisch die zuletzt erhaltenen Daten noch ins
> alte Log geschrieben sowie als erste Zeile schon ins neue Log übernommen
> werden.
>
>
Solange das noch nicht in fhem.pl, FileLog.pm o.ä. enthalten ist, hier ein
worakround, um genau diese zusätzlichen Einträge wegzuschreiben:
http://www.fhemwiki.de/wiki/Plot-Abriss_vermeiden

Gruß, Uli

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

[Joachim]

                                                   

Hallo UliM,

Deinen Workaround habe ich erhalten und eingeaut, rennt super, gibt auch
keine Fehlermeldungen aus. Beseitigt aber nicht das grundsaetzliche Problem.
Deshalb habe ich diesen Post aufgemacht.
Hier nocheinmal ein Beispiel, dass meinen Ansatz verdeutlicht.

Aus welchen Gruenden auch immer soll ein Sensor ueberwacht werden, bei dem
sowohl eine Statusaenderung als auch ein Ausfall umgehendes Handeln
erfordert (offene Kuehlschranktuer, Haustuer/Fensterueberwachung, Wasser im
Keller, etc.)
Bei event-on-update wird das Log gnadenlos zugemuellt, obwohl sich der
Status nicht geaendert hat. Es wird aber benoetigt, um eine Aenderung
unverzueglich zu triggern.
Bei event-on-change faellt es aber nicht auf, dass dieser Sensor/die
Zuleitung/das Modul ausgefallen ist, da Statusaenderungen gewartet wird,
aber der Ausfall nicht ueberwacht werden kann.
Ich hoffe immer noch auf Gegenargumente oder nicht bedachte Probleme.

Gruss Joachim

Am Montag, 3. Dezember 2012 12:45:27 UTC+1 schrieb UliM:
>
>
>
> Am Montag, 3. Dezember 2012 08:00:10 UTC+1 schrieb Prof. Dr. Peter A.
> Henning:
>>
>> beim Tages/Monatswechsel automatisch die zuletzt erhaltenen Daten noch
>> ins alte Log geschrieben sowie als erste Zeile schon ins neue Log
>> übernommen werden.
>>
>>
> Solange das noch nicht in fhem.pl, FileLog.pm o.ä. enthalten ist, hier
> ein worakround, um genau diese zusätzlichen Einträge wegzuschreiben:
> http://www.fhemwiki.de/wiki/Plot-Abriss_vermeiden
>
> Gruß, Uli
>

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

[UliM]

                                                 

Hast Du mal getestet, ob ein watchdog trotz event-on-change anspringt -
genauer, nur dann anspringt wenn er soll?
Gruß Uli

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

[Joachim]

                                                   

Hallo UliM,
Habe noch keinen Watchdog laufen.
Das System befindet sich noch im Aufbau, und ich versuche eine Baustelle
nach der anderen abzuarbeiten.

gruss Joachim

Am Montag, 3. Dezember 2012 14:56:13 UTC+1 schrieb UliM:
>
> Hast Du mal getestet, ob ein watchdog trotz event-on-change anspringt -
> genauer, nur dann anspringt wenn er soll?
> Gruß Uli
>

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

[rudolfkoenig]

                                                   

> Hast Du mal getestet, ob ein watchdog trotz event-on-change anspringt -
> genauer, nur dann anspringt wenn er soll?

Braucht er nicht zu testen: watchdog/notify/FileLog/average/dewpoint/etc
verwenden die im info-timer und Event Monitor auch sichtbaren events.

event-on-change dreht diese events ab, das Verhalten der Module ist also
definitiv beeintraechtigt, auch wenn Willi mit dewpoint es versucht zu
kompensieren.

Btw. ich verstehe die Welt nicht: wieso will jetzt ploetzlich jeder dieses
Attribut aktivieren?

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

[Joachim]

                                                   

Am Montag, 3. Dezember 2012 15:16:10 UTC+1 schrieb Rudolf Koenig:
>
>
>
> Btw. ich verstehe die Welt nicht: wieso will jetzt ploetzlich jeder dieses
> Attribut aktivieren?
>

Hallo Rudolf,
weil es Sinn macht.
Warum soll ich Daten archivieren, die sich nicht geaendert haben?
Die Plotanzeige wird gnadenlos langsam, wenn zuviele Daten geplottet
werden, und das nicht nur auf einer langsamen FB7570, sondern auch auf
einem halbwegs aktuellen Rechner.
Deshalb diser Tread.

gruss Joachim

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

[Guest]

Originally posted by: <email address deleted>

Am Montag, 3. Dezember 2012 12:22:38 UTC+1 schrieb joachim herold:

> Moin Willi, Moin Prof.,
>
> Ist das ein Bauchgefuehl, oder gibt es Gruende, dass
> event-on-change/event-on-update in fhem.pl bleiben soll?
>

Ich findet, dass die Funktionalität event-on-change/event-on-update  für
bestimmte Einsatzzwecke sehr gut einsetzbar ist. Für die Speicherung von
Werten, die für Plots verwendet werden sollen, m. E. aber nicht.
Deshalb finde ich die Idee gut FileLog zu erweitern, aber nicht um danach
event-on-change/event-on-update aus fhem.pl zu löschen. M.E: ergänzen sich
beide Lösungen bzw. Lösungsansätze.
 
MfG Willi

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

[Dr. Boris Neubert]

                                             

-------- Original-Nachricht --------
Von: Willi
Gesendet: Mon Dec 03 20:15:04 MEZ 2012
An: fhem-users@googlegroups.com
Betreff: [FHEM] Re: Konstruktiver Vorschlag zu event-on-change

Am Montag, 3. Dezember 2012 12:22:38 UTC+1 schrieb joachim herold:

>
> Ist das ein Bauchgefuehl, oder gibt es Gruende, dass
> event-on-change/event-on-update in fhem.pl bleiben soll?
>

Ich findet, dass die Funktionalität event-on-change/event-on-update  für
bestimmte Einsatzzwecke sehr gut einsetzbar ist. Für die Speicherung von
Werten, die für Plots verwendet werden sollen, m. E. aber nicht.
Deshalb finde ich die Idee gut FileLog zu erweitern, aber nicht um danach
event-on-change/event-on-update aus fhem.pl zu löschen. M.E: ergänzen sich
beide Lösungen bzw. Lösungsansätze.
 
Du bist mir mit Deinem Vorschlag zuvorgekommen.

event-on-...-reading hat primär nichts mit Logs und Plots zu tun sondern mit Events.

Der Tatbestand, daß bei event-on-change-reading i.V.m. FileLog und Linien(!)plots nicht die korrekte Darstellung liefert sollte ebenso wie der Umgang mit dem letzten Wert im vorigen Log bei Logrotate nicht durch Änderungen am Event-Mechanismus gelöst werden.

Nachdem wir das Thema im Oktober diskutiert hatten, ist in mir die Meinung gereift,  daß eine Lösung im Filelog ansetzen könnte oder gleich in einem Plot-Device. Dabei sollten wir uns aber nicht nur auf Liniencharts und die für eine korrekte Darstellung erforderlichen Einträge im Log einengen sondern auch über Balkencharts nachdenken.

Viele Grüße
Boris


--
sent from my WePad - apologies for brevity

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

[Guest]

Originally posted by: <email address deleted>

Hi Boris,

ist jetzt evtl OT, aber wurde der linetype bars nicht schon implementiert?
Meines Wissens nach durch pah (bzw. sein Zuarbeit), bloss die Doku wurde
nicht aktualisiert?

Kann mich zwar täuschen, aber ich glaube in einer gplot Datei bewirkt bars
etwas.

VG

Am Montag, 3. Dezember 2012 21:17:51 UTC+1 schrieb Boris:
>
>
>
>
> -------- Original-Nachricht --------
> Von: Willi >
> Gesendet: Mon Dec 03 20:15:04 MEZ 2012
> An: fhem-...@googlegroups.com
> Betreff: [FHEM] Re: Konstruktiver Vorschlag zu event-on-change
>
> Am Montag, 3. Dezember 2012 12:22:38 UTC+1 schrieb joachim herold:
>
> >
> > Ist das ein Bauchgefuehl, oder gibt es Gruende, dass
> > event-on-change/event-on-update in fhem.pl bleiben soll?
> >
>
> Ich findet, dass die Funktionalität event-on-change/event-on-update  für
> bestimmte Einsatzzwecke sehr gut einsetzbar ist. Für die Speicherung von
> Werten, die für Plots verwendet werden sollen, m. E. aber nicht.
> Deshalb finde ich die Idee gut FileLog zu erweitern, aber nicht um danach
> event-on-change/event-on-update aus fhem.pl zu löschen. M.E: ergänzen
> sich
> beide Lösungen bzw. Lösungsansätze.
>  
> Du bist mir mit Deinem Vorschlag zuvorgekommen.
>
> event-on-...-reading hat primär nichts mit Logs und Plots zu tun sondern
> mit Events.
>
> Der Tatbestand, daß bei event-on-change-reading i.V.m. FileLog und
> Linien(!)plots nicht die korrekte Darstellung liefert sollte ebenso wie der
> Umgang mit dem letzten Wert im vorigen Log bei Logrotate nicht durch
> Änderungen am Event-Mechanismus gelöst werden.
>
> Nachdem wir das Thema im Oktober diskutiert hatten, ist in mir die Meinung
> gereift,  daß eine Lösung im Filelog ansetzen könnte oder gleich in einem
> Plot-Device. Dabei sollten wir uns aber nicht nur auf Liniencharts und die
> für eine korrekte Darstellung erforderlichen Einträge im Log einengen
> sondern auch über Balkencharts nachdenken.
>
> Viele Grüße
> Boris
>
>
> --
> sent from my WePad - apologies for brevity
>

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

[Tobias]

                                                   

Hi,
möchte nur mal anmerken das bei einer Auslagerung in FilePLot das DbLog
garnichts davon hat.
Weiterhin finde ich die schonmal diskutierte Idee "event-on-change aber
mindestens alle x minuten" eine gute Idee...
Man möge sich Plots vorstellen von sehr selten auftretenden Events, zb.
Tür/Fensterkontakte.

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

[Guest]

Originally posted by: <email address deleted>

Hallo Leute,

1. Bargraph geht sehr gut, habe ich als "Zuarbeit" in 98_SVG.pm geliefert.
An die Doku hat wohl keiner gedacht ...

2. Ich denke wir sind uns einig: Update-Mechanismus bleibt in fhem.pl -
Ergänzung für FileLog.pm kommt in die Pipeline.

3. Wenn das schon auf der Tagesordnung steht: Daran habe ich im
Zusammenhang mit der deutlichen Erweiterung der Plotfunktionen schon
einiges getan. Beispielsweise kann ich x/y-plots machen, bei denen die
Zeiten in einer ganz anderen Spalte stehen - verwende ich im Zusammenhang
mit den Balkendiagrammen, um die Monatsübersichten und Jahresübersichten
meiner PV-Anlage anzuzeigen. Und zwar nicht nur so animiert, wie im
Standardmodul - sondern mit zusätzlichen Achsen für die weiteren Kurven,
die auf Mausklick eingeblendet werden.  Rudolf König hat auch mal die
Patchfiles dafür bekommen, bisher sind aber im Wesentlichen nur die
Bargraphs in den trunk übernommen worden.

4. Was noch schöner wäre und im Log ebenfalls mehr Platz sparen könnte:
Angenommen, ein Gerät liefert so etwa 10 verschiedene Datenwerte (z.B. ein
8-kanaliger 1-Wire Switch). Dann habe ich mit diesem Update-Mechanismus 10
verschiedene Events, und 10 Zeilen im Log - es sei denn, ich packe alles in
den STATE. Es wäre hingegen sehr einfach möglich, die Interpretation des
Attributwertes event-on-update-reading so zu ändern, dass ich statt einer
kommaseparierten Liste auch eine solche mit Pluszeichen drin verwenden kann
- mit der Bedeutung, diese in _einem_ Event zu sammeln

Damit ergäbe beispielsweise

attr event-on-update-reading KanalA+KanalB,KanalC+KanalD

dann eben nicht 4 Events, sondern nur zwei: Einen mit den Datenwerten aus
KanalA und KanalB, und einen mit den Datenwerten aus KanalC und KanalD

LG
pah





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