98_dewpoint.pm - Vorschläge zur Weiterentwicklung

[kpwg]

Hallo miteinander,

ich kann ebenso bestätigen, das die leider noch nicht eingecheckte Version problemlos läuft. Dank guter Anleitung am Threadanfang war es in Minuten eingerichtet. Würde mich ebenso freuen, wenn das Modul offiziell wird.

Viele Grüße, Ricardo

Edit: wieso bekomme ich die absolute Feuchte immer mit 1g/m³ zu gering angezeigt? Habe gerade den Werten hinterher gerechnet...

[Olaf A]

Hallo Ricardo,

ich habe die Formel im Winter an Hand des HX-Diagrams abgeglichen und damals festgestellt, das diese Formel, die ich dort benutzt habe eine Abweichung um +1 hat. Deshalb habe ich in der einen Faktor von -1 eingefügt,
um die Abweichung zu kompensieren.

Wie hast du die Werte ermittelt?

Wenn du die Werte über diese Seite errechnet hast, dann besteht da der Unterschied.
http://www.wettermail.de/wetter/feuchte.html

Als Maßstab sollte man das HX-Diagram nehmen, da die Formeln nur Näherungen sein können.
Ein Diagramm findest du unter http://www.air2000.de/Nutzliches/Hx_Diagram/hx_diagram.html .

Schau doch mal ob die Werte über das HX-Diagram besser passen.

Gruß Olaf

P.S. Kleine Hilfe für das HX-Diagram. Nehme die Temperatur auf der linken Seite und suche den Kreuzungspunkt mit der rel.Feuchte. Nun senkrecht nach unten und du findest dort die abs.Feuchte.
Wenn du am Kreuzungspunkt senkrecht nach unten gehst bis 100% rel.Feucht, kannst du dort die Taupunktemperatur auf der linken Seite ablesen.

[stromer-12]

Ich habe bei mr jetzt ein S300TH ins Gefrierfach gelegt und komme auf eine Absolute Feuchte von -0.5.
Weniger als 0 sollte doch nicht gehen, oder?

[Olaf A]

Hallo stromer-12,

da hast du Recht. Aber wie ich es schon im diesem Tread geschrieben habe handelt es sich um eine Näherungformel.
Der Bereich in dem die Anpassung jetzt past ist im normalen Tepmeraturbereich ich glaube, das die Tiefkühltruhe nicht in diesen Bereich liegt. Schau doch selber in das HX Diagram. Anleitung oben.

[eldrik]

Hallo... ich habe alle paar Tage mal ein Problem, dass FHEM beendet...
Die letzte Zeile des jeweiligen Logs...

Kann es sein, dass kein Taupunkt für solche Readings ermittelt werden kann...

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

Hi,

ich habe exakt den gleichen Fehler, mit der Konsequenz, dass der Fhem Prozess hierdurch direkt abzustürzen scheint!

siehe auch http://forum.fhem.de/index.php/topic,26245.0.html

Greetz
Eldrik

[frankbatzen]

Hallo,

vielen Dank für das Modul und die Anpassung mit der absoluten Luftfeuchtigkeit!
Läuft bei mir seit Wochen problemlos. Ich habe zwei Homematic Temperatur/Luftfeuchtesensoren (einer außen, einer im Keller) um den geeigneten Zeitpunkt zum Lüften des Kellers zu finden. Bald soll damit ein Lüftungsgerät gesteuert werden.

Gruß
frankbatzen

[Omega]

Ich hole mal den alten Beitrag wieder hoch – finde den Titel absolut passend  .

Relativ häufig habe ich folgende Meldung(en) im Log:

Code Auswählen Erweitern


PERL WARNING: Argument "18.8 C" isn't numeric in numeric gt (>) at ./FHEM/98_dewpoint.pm line 419


Das hängt damit zusammen, dass ich mehrere ZWave-Komponenten verwende, die neben den nackten Zahlen auch die jeweilige Einheit (,,C", ,,%") im Reading haben. Ich habe auch schon den Lösungsvorschlag gefunden, bei den Devices jeweils UserReadings anzulegen – denke aber, dass das der falsche Ansatz ist. Bei einem oder 2 Devices mag das ja noch ok sein, aber bei vielen ...

Besser fände ich es, wenn in 98_dewpoint.pm beim Lesen der Readings (analog readingsNum) nur der Zahlenwert extrahiert und hiermit dann weitergerechnet wird.

Ich hoffe, der Vorschlag findet Unterstützung.

LG
Holger

[kpwg]

Genau da sehe ich den falschen Ansatz. Sauber programmierte Readings solcher Werte haben modulübergreifend identische Namen und sind dann auch entsprechend numerisch oder eben einheitlich nicht. Da der überwiegende Teil der von Modulen gelieferten Readings für Temperatur und Feuchte rein numerisch ist, muss hier bei Zwave nachgebessert werden. Alles andere bedient nur Symptome, der ursächliche Wildwuchs jedoch bleibt.

[Omega]

1.   Es ist nicht nur ZWave, die Readings mit Einheiten haben. Das hieße dann, die müssten auch alle nachbessern. Wer ist eigentlich bei FHEM die Instanz, die richtig bzw. falsch festlegt?

2.   Meiner Meinung nach ist FHEM deshalb so gut, weil es in der Lage ist, verschiedene Systeme übergreifend zu steuern. Das heißt aber doch im Umkehrschluss, dass sich Systeme nicht zwangsläufig nach der Masse richten müssen (Zitat: ,,Da der überwiegende Teil der von Modulen gelieferten Readings für Temperatur und Feuchte rein numerisch ist ...") sondern dass es eleganter ist, übergreifend verschiedene Systeme gleichermaßen zu bedienen. Davon abgesehen hat die Masse nicht immer recht. Ich kenne Menschen, die freuen sich, wenn sie auf einen Blick sehen, dass der Temperaturwert C und nicht F ist.

3.   Unabhängig von einem Glaubenskrieg (readings mit oder ohne Einheit) sollten doch Programme immer so ausgelegt sein, dass mögliche Fehler abgefangen werden. Im konkreten Fall: nur mit dem numerischen Teil des Readings weiterarbeiten.

4.   Es ist relativ normal, dass in einem solchen Projekt wie FHEM – alleine schon aufgrund einer parallelen Entwicklung – ein gewisser ,,Wildwuchs" entsteht. Da kann ich doch schlecht die eine Lösung absolut als richtig ausweisen und gleichzeitig festlegen, das die andere schlecht ist und nicht mitspielen darf, weil sie sich nicht an die Regeln hält.

[kpwg]

zu 1.: das wurde bereits festgelegt: http://www.fhemwiki.de/wiki/DevelopmentGuidelines
Zitat: "Readings enthalten grundsätzlich genau einen Wert und diesen ohne Einheit."
Da sehe ich auch keinen Diskussionsbedarf- die Lösung bei ZWave ist also falsch implementiert.
Man kann den Modulautoren (hier 98_dewpoint.pm) nicht aufbürden, sich um exotische Readings nachträglich zu kümmern.

zu 2.: das ist- mit Verlaub- kompletter Käse. Ein Modul, das sich an keine Guidelines hält, muß sich nicht wundern, nicht genutzt zu werden. FHEM ist recht "deutschsprachig", daher auch zu 97% in Grad Celsius. Die Einheit kann man doch gerne bei der Anzeige hinzufügen. Dank Readingsgroup usw. ist das kinderleicht. Genau an der Stelle würde ZWave bereits scheitern...

zu 3.: siehe 1. => das ist kein Glaubenskrieg, sondern eine sinnvolle Festlegung. Es lebt sich damit leichter 

zu 4.: konsequent wäre, das Modul nachzubessern. Das obliegt dem Modulautor. Wildwuchs schadet dem Projekt immer, da mit solchen Readings immer erst "gebastelt" werden muss, bis sie denen anderer Module entsprechen und gemeinsam durch dritte Module verarbeitet werden können. Glaube mir, das hilft der Sache nicht, wenn hier jeder seine Readings neu erfindet.

Für mich wäre somit ZWave raus. Aber darum geht es hier nicht. Meine 98_dewpoint.pm läuft nun über Jahre bestens!

[KölnSolar]

Ich kann Ricardo da nur beipflichten. Hab ne Menge Sensoren/Aktoren(siehe Signatur) und alles(?) ohne Einheit !
Grüße Markus

[rudolfkoenig]

zu 1.: das wurde bereits festgelegt: http://www.fhemwiki.de/wiki/DevelopmentGuidelines

Nur weil es in der Wiki steht, heisst es nicht festgelegt. DevelopmentGuidelines ist aelter, und war als Dskussionsgrundlage geschrieben, dabei wurde die Diskussion nicht zu Ende gefuehrt, auch wegen unterschiedliche Meinungen.

Da sehe ich auch keinen Diskussionsbedarf- die Lösung bei ZWave ist also falsch implementiert.

Sagt wer?

Dewpoint ist ein altes FHEM Modul, und greift auf die Readings noch direkt mit $dev->{READINGS}{$temp_name}{VAL} zu.
Sollte in ReadingsNum($devName, $temp_name, 20) geaendert werden.

[Omega]

Danke - das war's  .

Ich hatte gar nicht geglaubt, dass es so einfach ist (die Schreibweise "->" hatte mich zunächst doch sehr irritiert - kenne ich so nicht).
Nur an jeweils 2 Stellen musste ich $dev->{READINGS}{$temp_name}{VAL} ändern in ReadingsNum($devName, $temp_name, 20) und
$dev->{READINGS}{$hum_name}{VAL} ändern in ReadingsNum($devName, $hum_name, 20).
Jetzt sind die lästigen Warnings endlich weg.

[hotbso]

Die erste Überarbeitung ist im SVN, kommt also ab morgen per UPDATE.
Ich bin dabei, die expliziten Manipulationen des Hashs durch die jetzt vorhandenen API calls zu ersetzen.

Für Instanzen mit modus "dewpoint" ist das jetzt fertig, insbesondere unter Benutzung von "ReadingsNum".

Weiterhin gibt es jetzt das Attribut "verbose", das das Logging gemäß üblicher Konvention steuert.