Vorschlag zu 98_dewpoint in Kombination mit addLog()

Begonnen von betateilchen, 31 August 2013, 00:02:12

Vorheriges Thema - Nächstes Thema

betateilchen

Im Wikieintrag zu addLog() steht unter "Bekannte Probleme":

ZitatDas Modul dewpoint fügt dem state eines device den zusatz "D: xx" hinzu. Timing-abhängig kann dies zu "verwurschtelten" Darstellungen führen. Die Verwendung von addLog in Verbindung mit dewpoint ist daher nicht empfohlen.

Dieses Problem liesse sich meines Erachtens relativ einfach mit folgendem Patch beheben:


Index: 98_dewpoint.pm
===================================================================
--- 98_dewpoint.pm (revision 3821)
+++ 98_dewpoint.pm (working copy)
@@ -295,6 +295,12 @@
  } else {
  $current = $lastval." ".$sensor.": ".$dewpoint;
  }
+
+ if ($current =~/<< addLog/){
+ $current =~ s/   << addLog//g;
+ $current =  $current."   << addLog";
+ }
+
  $dev->{STATE} = $current;
  $dev->{CHANGED}[$n++] = $current;
  }


Hierdurch wird der addLog Vermerk immer ans Ende gestellt und es wird folgende (korrekte) Ausgabe produziert:

2013-08-30_23:54:49 out_Balkon T: 19.9  H: 63.8 D: 12.8   << addLog

Vielleicht könnte der Modulverantwortliche den Vorschlag prüfen und freigeben.

Danke!
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Willi

Hallo betateilchen,

fühle mich als Modulauthor angesprochen.....

Da ich addLog() nicht verwende, habe ich bisher von diesem Problem noch nicht gehört.

Rudi hat damals NotifyOrderPrefix eingeführt, damit sichergestellt ist, dass die Änderungen am State vor allen anderen Modulen erfolgen. Dies ist auch so in 98_dewpoint.pm definiert:

98_dewpoint.pm:  $hash->{NotifyOrderPrefix} = "10-";   # Want to be called before the rest

Eigentlich sollte daher dewpoint das Event bekommen und das "D: %DEWTEMP%" einfügen, bevor dies bei Notify ankommt.

@Rudi: Verstehst Du warum das mit NotifyOrderPrefix in diesem Fall nicht funktioniert?

Was ich mich frage ist, ob addLog() überhaupt noch notwendig? Es gibt ja jetzt neu das Attribut event_min-interval, welches zusammen mit event-on-change dieses Problem des Logabrisses löst.

Siehe auch http://www.fhemwiki.de/wiki/RFXtrx#FAQ:_Wie_bringe_ich_FHEM_dazu_nicht_alle_paar_Sekunden_den_Zustand_der_Sensoren_zu_loggen.3F
So setze ich es bei mir ein.

Grüße

Willi
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

betateilchen

Hallo Willi,

Zitat von: Willi schrieb am So, 01 September 2013 17:18Es gibt ja jetzt neu das Attribut event_min-interval, welches zusammen mit event-on-change dieses Problem des Logabrisses löst.

Es sollten alle Modulentwickler einfach auch einmal über den Tellerrand ihres Anwendungsszenarios hinausschauen.

Es gibt durchaus Fälle, in denen mit den genannten Attributen keine Lösung geschaffen werden kann. Deshalb habe ich vor einigen Tagen das addLog() bei mir erstmalig eingesetzt.
Bei mir besteht die Anforderung, zu einem exakt vorgegebenen Zeitpunkt einen Logeintrag zu schreiben. Da helfen mir die event-* Attribute nicht weiter, addLog() in Kombination mit at-Definitionen aber sehr wohl (und sehr einfach).

Die vorgeschlagenen vier Zeilen zusätzliches Coding in Deinem Modul würden niemandem wehtun, aber auf einfachste Weise ein bestehendes Problem lösen, das sogar im Wiki beschrieben wird.

Viele Grüße
Udo
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Willi

ZitatEs sollten alle Modulentwickler einfach auch einmal über den Tellerrand ihres Anwendungsszenarios hinausschauen.

Was willst Du damit sagen?

Ich habe darauf hingewiesen, dass es neu das Attribut event_min-interval gibt, welches zusammen mit event-on-change bei mir dieses Problem des Logabrisses löst und gefragt, ob jetzt addLog() noch notwendig ist. Es hätte ja durchaus sein können, dass Du dieses neue Attribut noch nicht kennst.

ZitatDie vorgeschlagenen vier Zeilen zusätzliches Coding in Deinem Modul würden niemandem wehtun, aber auf einfachste Weise ein bestehendes Problem lösen, das sogar im Wiki beschrieben wird.

Wie schon geschrieben hatte Rudi extra für dewpoint NotifyOrderPrefix eingeführt, um das Problem zu lösen, dass andere Module vor dem Einfügen von "D: %DEWTEP" das Event bekommen und bearbeiten. Bevor man also etwas patcht, wofür Rudi vorher extra eine Erweiterung von fhem.pl geschrieben hat, würde ich gerne klären, was hier falsch läuft.

Wenn Dir mein Vorgehen nicht gefällt, kannst Du einfach Deine Änderung ins SVN selbst einchecken, wenn Du Dich im Falle von danach auftretenden Problemen um die Problemlösung kümmerst. Du kann auch alternativ gerne die Wartung des Moduls komplett übernehmen.

Damit hätte ich auch kein Problem.
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

rudolfkoenig

>  Es sollten alle Modulentwickler einfach auch einmal über den Tellerrand ihres Anwendungsszenarios hinausschauen.

Mit solchen Saetzen gewinnt man keine Freunde.


> Timing-abhängig kann dies zu "verwurschtelten" Darstellungen führen.

FHEM ist (noch) nicht multithreaded, insofern ist dieses Problem sicher nicht Timing abhaengig.

Normale notifys werden mit Prio 50 abgearbeitet, kommen also nach allen dewpoint Instanzen, die sich mit Prio 10 registieren, ein kurzer Test zeigt bei mir, dass das immer noch funktioniert.

Ich wuerde dieses Problem vorher klaeren wollen, bevor ich so ein Hack in meinem Modul aufnehme.
Und ich bin bereit zu Helfen, wenn mir das Problem (der "Verwurschtelung") zum Nachbauen bereitstellt.

betateilchen

ZitatMit solchen Saetzen gewinnt man keine Freunde.

Mit "das ist mir zu unspezifisch" auch nicht, vor allem dann nicht, wenn nicht zu übersehen ist, dass der Antwortende die Frage wieder einmal nicht komplett gelesen hat.

Davon abgesehen war meine obige Bemerkung in keinster Weise böse gemeint. Aber es ist hier einfach zu oft so, dass von Entwicklern Antworten kommen, die klar erkennbar nur aus dem eigenen Anwendungsumfeld stammen können. Es gibt aber sehr viele fhem-Anwender mit daraus resultierenden vielen Anwendungsszenarien. Und wenn dann jemand eine solche technische Frage stellt, sollte man auch davon ausgehen, dass diese Fragestellung nicht aus Langeweile geschieht, sondern durchaus einen tieferen Sinn haben kann.

Und dann helfen eben solche Antworten wie "braucht man addLog() überhaupt noch?" niemandem weiter und führen zu regelmäßigen Frustrationen bei Fragestellern (nicht nur bei mir)

ZitatUnd ich bin bereit zu Helfen, wenn mir das Problem (der "Verwurschtelung") zum Nachbauen bereitstellt.

Ist doch eigentlich ganz einfach: Nimm einen S300TH, definiere dazu einen dewpoint und versuche dann, mit addLog() einen Logeintrag zu schreiben.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

> Nimm einen S300TH, definiere dazu einen dewpoint und versuche dann, mit addLog() einen Logeintrag zu schreiben.

Ist mir zu unspezifisch :)
Per at oder notify oder direkt aus der Konsole? Wie ist dewpoint definiert? Wie ist FileLog definiert?
Beispiel:

define s300th_2 CUL_WS 2 -1.0 -10.1
define dp dewpoint dewpoint .*
{ Dispatch($defs{CUL}, "K1113526113", undef) }
{ addLog("s300th_2", "state") }
-> 2013-09-01 19:03:28.862 CUL_WS s300th_2 T: 20.3  H: 51.4   << addLog

Schaut ok aus.

Manche meinen ich waere ein Gedankenleser oder ich haette beliebig viel Zeit und Lust alle moeglichen Kombinationen durchzuprobieren. Ist leider nicht der Fall. Selbst wenn ich es wissen koennte wie es geht, waere es nett, wenn man mir als Copy&Paste bereitstellt, damit ich weniger Arbeit damit habe.

betateilchen

Dein Beispiel ist unspezifisch und logischerweise richtig, weil es keinen dewpoint gibt. Eigentlich hast Du aber schon alles genau so gemacht, wie es sein soll.


define s300th_2 CUL_WS 2 -1.0 -10.1
define dewall dewpoint dewpoint .*


Danach sollte der S300TH einen Dewpoint D:xx besitzen.

Und dann mach ein

addLog("s300th_2","state")

dann sollte das "  << addlog" VOR dem dewpoint stehen.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

fhem> define dewall dewpoint .*
wrong syntax: define <name> dewpoint (dewpoint|fan|alarm) devicename [options]

betateilchen

ja ja ja, ich habs ja oben schon korrigiert.


Internals:
   CMD_TYPE   dewpoint
   DEF        dewpoint .*
   DEV_REGEXP .*
   HUM_NAME   humidity
   NAME       dew_all
   NEW_NAME   dewpoint
   NR         344
   NTFY_ORDER 10-dew_all
   STATE      active
   TEMP_NAME  temperature
   TYPE       dewpoint



Internals:
   DEF        ./log/out_Balkon-%Y.log (out_Balkon.T:.*|BMP180.T:.*|Helligkeit|out_Regen_Sensor.*)
   NAME       FileLog_out_Balkon
   NR         286
   NTFY_ORDER 50-FileLog_out_Balkon
   REGEXP     (out_Balkon.T:.*|BMP180.T:.*|Helligkeit|out_Regen_Sensor.*)
   STATE      active
   TYPE       FileLog
   currentlogfile ./log/out_Balkon-2013.log
   logfile    ./log/out_Balkon-%Y.log
   Pos:
Attribut


Die Ausgabe im Log sieht übrigens so aus:

2013-09-01_19:18:19 out_Balkon T: 17.7  H: 59.1   << addLog D: 9.6

der regexp-Teil für dieses Log sieht so aus:

out_Balkon.T:.*
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Aah. Du meinst
define dewall dewpoint dewpoint .* T D H
Das Problem ist, dass addLog genauso ein Event generiert, wie ein S300TH, und dewpoint haengt (wie bestellt)  ein D: dran. Meiner Ansicht nach ist das aber nicht dewpoints Schuld, und man sollte solche Ausnahmen  nicht in dewpoint (und average, und...) einfuegen, sondern addLog muss dafuer sorgen, diese Instanzen nicht zu benachrichtigen. Mir faellt z.Zt. nur sowas ein:
fhem("attr dewall disable");
addLog("X", "Y");
fhem("deleteattr dewall disable");

was zugegebenermassen nicht sehr elegant ist.

Eine Alternative waere die Einfuehrung einer "triggerDirect TYPE=FileLog $name $event", was aber mir auch nicht gefaellt, da solche Events dann auch dem Event-Monitor/inform/usw. enthalten werden.


betateilchen

Zitat von: rudolfkoenig schrieb am So, 01 September 2013 19:34Meiner Ansicht nach ist das aber nicht dewpoints Schuld, und man sollte solche Ausnahmen  nicht in dewpoint (und average, und...) einfuegen, sondern addLog muss dafuer sorgen, diese Instanzen nicht zu benachrichtigen.

Erstens geht es nicht um eine Schuldzuweisung, sondern um eine möglichst einfache Lösungssuche.
Zweitens ist in 98_dewpoint bereits ein kariertes Maiglöckchen eingebaut, das STATE umschreibt und ich frage mich, warum die eine Sonderbehandlung möglich sein darf und die andere nicht.

Zitat von: rudolfkoenig schrieb am So, 01 September 2013 19:34Mir faellt z.Zt. nur sowas ein:
fhem("attr dewall disable");
addLog("X", "Y");
fhem("deleteattr dewall disable");

Das ist nicht nur "nicht elegant" sondern ein ziemlicher Krampf.

Eine Alternative waere die Einfuehrung einer

Man muss doch nicht alles unnötig kompliziert machen, nur weil an einer einzigen Stelle ein kleines Problem auftritt. Da gibt es in fhem weiß Gott größere Baustellen und Unzulänglichkeiten, um die man sich sehr viel vorrangiger kümmern sollte (ich sage jetzt nur eventMap, update ... und mir fallen noch ein paar andere Krampfstellen ein)

Es gibt übrigens eine noch viel pragmatischere Lösung: Man lässt in addLog() die Kennzeichung "  <<addlog" einfach weg.

Meine Lösung: Ich habe die vorgeschlagenen vier Zeilen Coding eingebaut und die bleiben auch drin.
Das funktioniert einwandfrei, tut niemandem weh und hat definitiv an keiner anderen Stelle in fhem irgendwelche Auswirkungen.
Es wird letztendlich nur das ausgegebenen STATE verändert (also nur eine Formatierung durchgeführt) und noch nichtmal irgendein Reading.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

>  warum die eine Sonderbehandlung möglich sein darf und die andere nicht

Nur weil irgendwo ein Hack drin ist, heisst es nicht, dass man jetzt nur noch mit Hacks weitermachen sollte.

betateilchen

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Willi

Dann ist ja jetzt alles klar. Das Problem tritt auf, weil ein neues Event für state generiert wird. Dann kann auch NotifyOrderPrefix nicht helfen.

Ändere doch bitte mal in 98_dewpoint.pm die Zeilen ab Zeile 292

     
                if ($lastval =~ /BAT:/) {
                        $current = $lastval;
                        $current =~ s/BAT:/$sensor: $dewpoint BAT:/g;
                } else {
                        $current = $lastval." ".$sensor.": ".$dewpoint;
                }



                if ($lastval =~ /BAT:/) {
                        $current = $lastval;
                        $current =~ s/BAT:/$sensor: $dewpoint BAT:/g;
                } elsif ($lastval =~ /<</) {
                        $current = $lastval;
                        $current =~ s/<</$sensor:$dewpoint <</g;
                } else {
                        $current = $lastval." ".$sensor.": ".$dewpoint;
                }


Danach sollte ein das "D: %DEWTEMP" vor dem << eingefügt werden. Das passt so gut in den Code, da ich dies bei BAT im state auch schon mache, damit dies so besser aussieht.

Bitte testen. Dann packe ich es nach Test ins SVN.

MfG Willi
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433