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!
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:
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
Hi,
}
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
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 (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
Zitat von: eldrik am 09 Oktober 2014, 07:47:32
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.
ZitatDas 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.
Zitat von: betateilchen am 09 Oktober 2014, 10:29:28
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 (http://forum.fhem.de/index.php/topic,21458.msg150577.html#msg150577)
@Thorsten Pferdekaemper danke für des Rätsels Lösung,
Greetz
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 ;)
Zitat von: betateilchen am 09 Oktober 2014, 10:46:35
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
Zitat von: betateilchen am 09 Oktober 2014, 10:46:35
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...
pragmatischer Lösungsvorschlag:
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;
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
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 :)
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
@ betateilchen,
aus welchem Grund hast du
+ return -273.15;
gewählt?
@ all:
Mein Vorschlag wäre so wie im Bild.
Gruß Joachim
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
Was häst du von meinem Vorschlag?
Er erfüllt Deine beiden Kriterien, und fällt in der Anzeige auf.
Gruß Joachim
Aber er ist (für mich) willkürlich. -273.15 ist wenigstens tatsächlich eine Temperaturangabe (der dewpoint ist das ja schließlich auch), die man irgendwoher kennt und zuordnen kann 8)
Sinn dieses willkürlichen Wertes 9999,9 ist für mich dass der Anwender sofort erkennt, dass es sich um einem ungültigen Wert handelt. Besser wäre es sicherlich, gar keinen Wert anzugeben oder xxx.x, das hat aber unkalkulierbare Folgeprobleme.
Gruß Joachim
Ich kann ja nix dafür, dass Du in Physik nicht aufgepaßt hast 8)
Jedenfalls finde ich 9999.9 einen ziemlich unglücklich gewählten Wert, aber das ist nur meine unmaßgebliche persönliche Meinung.
Mach einfach wie Du denkst, es ist ja schließlich Dein Modul.
9999.9 ist Quatsch.
Nur 0K ergibt hier Sinn.
gesendet von unterwegs...
Hallo Ihr,
hier versuchen wir einen Fehler zu heilen, der nicht zu heilen ist.
Ganz klar ist:
Das Problem liegt nicht bei Dewpoint.
Werte wie 9999.9 oder den -273,15 finde ich nicht richtig und machen es auch nicht besser.
Ein O.K. könnte bei der weiteren Verarbeitung auch zu Problemen führen.
Mein Vorschlag währe es im Log eine Fehlermeldung zu Generieren, die da lautet falscher Wehrt XXX,X
und dann Dewpoint in den Physikalisch möglichen Werten die Berechnung durchführen zu lassen.
Dieses hat den Vorteil, dass der Absturz verhindert wird und im schlimmsten Fall gerade Linien im Logfile geschrieben werden.
Mit dem Wissen, dass dann mit falschen Werten gerechnet wird. Dieses ist meiner Ansicht nach das geringste Übel.
Gruß Olaf
@ betateilchen:
ZitatIch kann ja nix dafür, dass Du in Physik nicht aufgepaßt hast
Wie kommst Du darauf, dass ich in Physik nicht aufgepasst habe?
Ich versuche einfach eine numerische Ausdrucksweise zu finden, die dem User sinnvoll mitteilt, dass hier etwas nicht stimmt. Das bedeutet, die Rückgabe muss ausserhalb des Gültigkeitsbereiches liegen. 0 Kelvin (273.15) wären noch innerhalb des Gültigkeitsbereiches (9999.9 allerdings auch).
@ Olaf A.:
ZitatMein Vorschlag wahre es im Log eine Fehlermeldung zu Generieren, die da lautet falscher Wehrt XXX,X
und dann Dewpoint in den Physikalisch möglichen Werten die Berechnung durchführen zu lassen.
Fehlermeldung ist klar, wird in Log generiert. Aber mit physikalisch möglichen Werten dann weiterrechnen ist sehr unglücklich, dem User wird dann ein falscher Wert serviert.
Mein Vorschlag, leicht angepasst in Anlehnung an http://de.wikipedia.org/wiki/Rasterdaten
ZitatDateistruktur
Einige wenige Parameter bestimmen den geometrischen Aspekt von Rasterdaten. Ein Beispiel ist das GRID-Format. Die drei bestimmenden Parameter sind die Spezifikation der Koordinaten des Ursprungs, der Rastergröße und der Anzahl der Zeilen und Spalten. Außerdem wird ein NoData-Wert definiert. Diese dienen zur Kennzeichnung der Bereiche, für die keine Werte vorliegen, die durch den rechteckigen Schnitt entstehen. Da ,,0" durchaus ein sinnvoller Messwert sein kann, sollte er nicht als NoData-Wert verwendet werden. Besser eignen sich negative Zahlen außerhalb des Gültigkeitsbereichs (-9999).[10]
Als NoData-Wert in der Anzeige: -9999.9
Gruß Joachim
Hallo Ihr,
nach einer Nacht darüber geschlafen zu haben währe ich für den Vorschlag die Berechnung ab zu brechen und einen Log zu schreiben.
Dieses sollte dann das kleinste Übel sein.
Gruß Olaf
Moin Olaf,
sehe ich mittlerweile ähnlich, und es ist im Code auch schon so vorgesehen.
Werde das heute abend nach Feierabend mal testen.
Gruß Joachim
Das ist doch genau das, was in meinem Patch passiert. Ein Logeintrag und keine Berechnung.
Es muss aber trotzdem ein Wert zurückgegeben werden, da bei einer Nichtberechnung plötzlich ein Reading bei einem anderen Device fehlt und es u.U. sehr lange dauert, bis das dem Anwender überhaupt auffällt. Deshalb macht ein "auffälliger" Rückgabewert durchaus Sinn.
Moin @ all,
der Fehler, der FHEM zum Absturz gebracht hat ist ab jetzt im SVN korrigiert, allerdings nicht so, wie vorgeschlagen.
Es gab mehrere Möglichkeiten, das Problem zu lösen:
1. unerlaubte humidity Werte in den erlaubten bereich zu verschieben (z.B. rF = -0,1 wird zu 0,1)
mMn indiskutabel, da readings nicht durch dewpoint manipuliert werden dürfen. Wenn ein vorgelagertes Modul
fehlerhafte Werte liefert, muß das Problem im vorgelagerten Modul gelöst werden.
2. der Vorschlag von betateilchen, mit dem ich zuerst auch geliebäugelt habe, siehe vorausgegangene Diskussion. Den
habe ich allerdings verworfen, da zum einen als reading nur numerische Werte zurückgegeben werden können und
ich mich nicht mit -273,15° anfreunden konnte (ist ein gültiger Temperaturwert) und mein Vorschlag von -9999.9°
keinen Anklang gefunden hat, zum anderen, da dadurch ein Plot "zerschossen" wird, und es auch wieder eine
Datenmanipulation ist, die in meinen Augen programmiertechnisch unsauber ist.
3. fehlerbehaftete Werte genauso zu behandeln, wie nicht vorhandene Werte, und garnicht erst in die Berechnung
einzusteigen. Ich glaube das ist programmiertechnisch gesehen die sauberste Variante, die sowiso schon für eine rF
von 0% vorhanden war. Der Plot wird dabei nicht "zerschossen", da keine readings manipuliert werden, es wird ein
Logeintrag ausgegeben, dass dewpoint einen unmöglichen Wert erhalten hat, und der Anwender der mit
Luffeuchtigkeiten arbeitet sollte wissen, dass nur Werte zwischen 0% und knapp über 100% möglich sind.
bei mir haben die Änderungen einen Tag ohne Probleme funktioniert, ich hoffe, es läuft bei Euch auch.
zusätzlich ist jetzt auch die Berechnung der absoluten Feucht möglich, einfach das attribut absFeuchte 1 hinzufügen:
define dew_all dewpoint dewpoint .* Temperatur Feuchte dewpoint
attr dew_all absFeuchte
gruß Joachim
Super danke.
Gruß Olaf
Du hast einen Denkfehler in Deiner Lösung, aber Du willst mir das ja vermutlich ohnehin nicht glauben.
Warten wir mal, wann der erste Anwender darüber stolpert und dann hier im Thread aufschlägt. Obwohl ich eher annehme, dass der Einfachheit halber ein neuer Thread entstehen wird...
Moin betateilchen,
Ich danke Dir für den Hinweis, dass in meiner Lösung ein Denkfehler ist.
Zielführender wäre es allerdings gewesen, wenn Du mir auch mitgeteilt hättest, wo der Denkfehler ist.
Zitataber Du willst mir das ja vermutlich ohnehin nicht glauben.
Ich weiß leider nicht, was dich zu dieser Annahme verleitet.
Ich habe schleisslich aus gutem Grund dieses Forum an meinen Gedankengängen, die zu meiner Lösung geführt haben, teilhaben lassen.
Für konstruktive Vorschäge habe ich immer ein Ohr.
Schön wäre es bei konstruktiven Vorschlägen allerdings auch, wenn man auf die Gegenargumente dann auch eingeht, siehe -273.15 und 9999.9 bzw. -9999.9 alias NoData. Und, wenn auch mit Smilie versehen, auf herabsetzende Unterstellungen verzichtet
ZitatIch kann ja nix dafür, dass Du in Physik nicht aufgepaßt hast 8)
Ich fände es schade, wenn man bewußt den Modulverantwortlichen, oder die FHEM-Anwender in eine Falle laufen lässt.
ZitatWarten wir mal, wann der erste Anwender darüber stolpert und dann hier im Thread aufschlägt. Obwohl ich eher annehme, dass der Einfachheit halber ein neuer Thread entstehen wird...
So, das musste mal raus, und ist definitiv nicht böse gemeint.
Gruß Joachim
Hallo Joachim,
Dafür,dass du immer behauptest,das du kein Perl programmieren kannst ist da doch was gutes raus gekommen.
Schauen wir doch erst mal ob die Überflieger recht behalten und da noch Verbesserungen kommen.
Erst mal ist das eine gute Erweiterung die das Modul komplettiert hat.
Gruß Olaf