Dewpoint lässt fhem abstürzen

[Joachim]

Was häst du von meinem Vorschlag?
Er erfüllt Deine beiden Kriterien, und fällt in der Anzeige auf.

Gruß Joachim

[betateilchen]

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 

[Joachim]

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

[betateilchen]

Ich kann ja nix dafür, dass Du in Physik nicht aufgepaßt hast 

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.

[CQuadrat]

9999.9 ist Quatsch.

Nur 0K ergibt hier Sinn.


gesendet von unterwegs...

[Olaf A]

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

[Joachim]

@ betateilchen:

Ich 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.:

Mein 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

Dateistruktur

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

[Olaf A]

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

[Joachim]

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

[betateilchen]

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.

[Joachim]

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:

Code Auswählen Erweitern

define dew_all dewpoint dewpoint .* Temperatur Feuchte dewpoint
attr dew_all absFeuchte

gruß Joachim

[Olaf A]

Super danke.

Gruß Olaf

[betateilchen]

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

[Joachim]

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.

aber 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

Ich kann ja nix dafür, dass Du in Physik nicht aufgepaßt hast 

Ich fände es schade, wenn man bewußt den Modulverantwortlichen, oder die FHEM-Anwender in eine Falle laufen lässt.

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

So, das musste mal raus, und ist definitiv nicht böse gemeint.

Gruß Joachim

[Olaf A]

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