FHEM > Automatisierung

Vorschlag zu 98_dewpoint in Kombination mit addLog()

(1/5) > >>

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


--- Zitat ---Das 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.
--- Ende Zitat ---


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


--- Code: ---
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;
  }

--- Ende Code ---


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


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


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

Danke!

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

betateilchen:
Hallo Willi,


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


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

Willi:

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


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.


--- Zitat ---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.
--- Ende Zitat ---


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.

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.

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln