Dewpoint lässt fhem abstürzen

[eldrik]

Hi,

Ich hab das Problem, dass mir das dewpoint Modul fhem abstürzen lässt, folgendes steht zuletzt in dem Terminal fenster in dem ich fhem gestartet habe!

Code Auswählen Erweitern

Can't take log of -0.880451 at ./FHEM/98_dewpoint.pm line 413.

Ich gehe davon aus, dass in der Konstellation wenn ein Device, für das ein Dewpoint errechnet werden soll (bei mir 1Wire Temperatur und Luftfeuchtesensoren), nicht zur Verfügung steht (fhem2fhem Verbindung für readingsproxy etc. disconnected) der oben aufgeführte Event eintritt und Fhem in meinem Fall hart beendet wird.

Meine Dewpoint Definition:

Code Auswählen Erweitern

Internals:
   CMD_TYPE   dewpoint
   DEF        dewpoint .*
   DEV_REGEXP .*
   HUM_NAME   humidity
   NAME       dew_state
   NEW_NAME   dewpoint
   NR         407
   NTFY_ORDER 10-dew_state
   STATE      active
   TEMP_NAME  temperature
   TYPE       dewpoint
Attributes:
   disable    0

Über Unterstützung Würde ich mich freuen!

Greetz
Eldrik

[Thorsten Pferdekaemper]

Hi,

Code Auswählen Erweitern


       }
        my $e1 = $e / 610.78;
        my $f = log( $e1 ) / $A;      <<<< hier passiert's
        my $f1 = 1 - $f;
        if ($f1 == 0) {

Da versucht das Teil wohl aus einer negativen Zahl einen Logarithmus zu berechnen. Das geht halt nicht. Ich hätte zwar erwartet, dass Perl da trotzdem irgendwie weitermacht, aber anscheinend nicht.
Das Komische dabei ist, dass das wohl nur passiert, wenn humidity < 0. Wie kommt das denn?
Gruß,
   Thorsten

[eldrik]

Hi,

bei mir ist das der Fall, sollte sich ein entfernter per OWServer angeschlossener 1Wire Busmaster verabschiedet haben und die gemessenen HIH-5030 Spannungswerte, welche ich per clonedummy via fhem2fhem in meiner Hauptinstanz abbilde nicht aktualisiert werden dann liefert die Berechnung http://www.fhemwiki.de/wiki/1-Wire_Feuchtemessung von humidity Werte, die zu dem aufgezeigten Problem führen.

In der Zwischenzeit hab ich die Berechnungen für dewpoint und absfeuchte in meine 99_myUtils.pm ausgelagert, würde aber auch in absehbarer Zeit gerne wieder dem Modul mein Vertrauen schenken wollen.

Greetz
Eldrik

[betateilchen]

dann liefert die Berechnung von humidity Werte, die zu dem aufgezeigten Problem führen.

Dafür kann doch das dewpoint Modul nix, wenn ein vorgelagertes Modul falsche Meßwerte liefert, mit denen dewpoint weiterrechnet? Das muss doch in der humidity-Berechnung selbst korrigiert werden und nicht im dewpoint.

[hexenmeister]

Das muss doch in der humidity-Berechnung selbst korrigiert werden und nicht im dewpoint.

Grundsätzlich gebe ich Dir recht, allerdings wäre es IMHO schön, wenn auch Dewpoint-Modul eine Absicherung gegen Absturz einbaut. Der Gesamtabsturz ist doch etwas sehr schwerwiegend.

[eldrik]

Dafür kann doch das dewpoint Modul nix, wenn ein vorgelagertes Modul falsche Meßwerte liefert, mit denen dewpoint weiterrechnet? Das muss doch in der humidity-Berechnung selbst korrigiert werden und nicht im dewpoint.

das ist natürlich der richtige Ansatz, jetzt wo ich weiß an welchem Glied in der Kette es gelegen hat, werde ich ungültige Werte wohl auf kurz oder lang (das von mir beschriebene Szenario ist mittlerweile eleminiert)  in meiner sub abfangen, nichtdestotrotz wäre es bestimmt auch von anderer Seite wünschenswert wenn auch das Modul dahingenend robust wäre. 

Das Problem scheint ja bisher nicht nur ausschließlich mich betroffen zu haben:
http://forum.fhem.de/index.php/topic,21458.msg150577.html#msg150577

@Thorsten Pferdekaemper danke für des Rätsels Lösung,


Greetz
Eldrik

[betateilchen]

ja, ihr habt ja recht, dass dewpoint das abfangen sollte.

Aber manchmal kann man als Entwickler gar nicht so blöd denken, wie es bei den Anwendern dann kommt. Ich hätte mit Sicherheit auch nie angenommen, irgendwann mit negativen Feuchtigkeitswerten umgehen zu müssen, wenn dewpoint mein Modul wäre

[eldrik]

ja, ihr habt ja recht, dass dewpoint das abfangen sollte.

Aber manchmal kann man als Entwickler gar nicht so blöd denken, wie es bei den Anwendern dann kommt. Ich hätte mit Sicherheit auch nie angenommen, irgendwann mit negativen Feuchtigkeitswerten umgehen zu müssen, wenn dewpoint mein Modul wäre

stimmt schon  aber es muss ja auch nicht immer der "harmlose" Anwender sein, der so ein Problem unbeabsichtigt provoziert.

Greetz
Eldrik

[hexenmeister]

Aber manchmal kann man als Entwickler gar nicht so blöd denken, wie es bei den Anwendern dann kommt. Ich hätte mit Sicherheit auch nie angenommen, irgendwann mit negativen Feuchtigkeitswerten umgehen zu müssen, wenn dewpoint mein Modul wäre

sehe ich ein, wäre auch nie drauf gekommen. Es ist halt leider der Nachteil der aktuellen Architektur, dass dabei der ganze Server abschmiert...

[betateilchen]

pragmatischer Lösungsvorschlag:

Code Auswählen Erweitern


Index: 98_dewpoint.pm
===================================================================
--- 98_dewpoint.pm (Revision 6718)
+++ 98_dewpoint.pm (Arbeitskopie)
@@ -399,6 +399,11 @@
{
         my ($temperature, $humidity) = @_;

+ if($humidity < 0) {
+ Log 1, "Error dewpoint(): humidity invalid: $humidity";
+ return -273.15;
+ }
+
         my $dp;

         my $A = 17.2694;


[Thorsten Pferdekaemper]

Hi,
das sieht IMHO gut aus. Hast Du auch mal über das Coding von da bis zum log() geschaut, ob das Argument vom log() noch aus irgendwelchen anderen Gründen negativ werden kann? Ich glaube nicht, aber ich kann was übersehen haben.
Gruß,
   Thorsten

[betateilchen]

Da eigentlich nur mit temperatur und humidity gerechnet wird, und die temperature ja durchaus negativ werden kann, prüfe ich nur am Anfang der Wertermittlung, ob die humidity negativ ist und fange dann erst gar nicht an zu rechnen. Da diese Funktion von mehreren Stellen im Modul genutzt wird, hab ich die Prüfung genau an dieser Stelle eingebaut und nicht bei jedem Aufruf selbst.

Jetzt müssen wir nur hoffen, dass der Modulverantwortlich den Patch für gut befindet

[Joachim]

Moin @ all,

das mit dem fhem-Absturz bei relFeuchte < 0 war mir entgangen, und da ich das Modul von Willi geerbt habe, muß da was geändert werden.
Der patch von Betateilchen sieht gut aus, von daher werde ich den so einbauen, und auch gleich die absFeuchte mit reinnehmen, auch wenn ich mit der Berechnung noch nicht zufrieden bin (ändern kann man immer noch).
Ich hoffe, ich schaffe das heute noch.

gruß Joachim

[Joachim]

@ betateilchen,

aus welchem Grund hast du

Code Auswählen Erweitern

+ return -273.15;
gewählt?

@ all:
Mein Vorschlag wäre so wie im Bild.

Gruß Joachim

[betateilchen]

Damit man

a) einen Wert hat, der sofort im Log und im Plot auffällt
b) einen genau definierten Wert für den Fehlerfall hat, auf den man bei Bedarf auch triggern kann