Hallo Ihr,
mich hat immer gestört, dass in dem Modul die Ausrechnung der absoluten Feuchte fehlt.
Ich habe mich also mit Joachim auf die suche gemacht eine Formel zu finden, die ich in das Modul einbauen kann. Diese habe ich nach einigen suchen gefunden und ne Möglichkeit gefunden die Formel per Attribut einzubinden.
Mit Willi Herzig, der das Modul geschrieben hat, habe ich abgesprochen, dass es von mehreren Personen getestet werden soll und wenn da keine Einsprüche kommen wir er diese einbinden lassen.
Also Feuer frei.
Zum Handling:
In Attribute den Punkt ,,absFeuchte" auswählen und abschicken.
Ab diesen Zeitpunkt errechnet das Modul zusätzlich die absolute Feucht und zeigt diese in den Readings mit an. Über stateFormat kann man dann diese auch in den State einbinden.
Ich habe die Formel über Wochen an Hand des HX- Diagramms kontrolliert und habe bis jetzt keinen Fehler gefunden.
Gruß Olaf
Aktuelle Version vom 06.4.14 22:12 Uhr
Als Beispiel für die fhem.cfg:
define dew_all dewpoint dewpoint .* Temperatur Feuchte dewpoint
attr dew_all absFeuchte 1
Hallo,
ich hab
- die angehängte 98_dewpoint.pm auf meinen RasPi kopiert (ins FHEM-Verzeichniss - die alte 98_deqpoint.pm habe ich in 98_dewpoint_old.pm umbenannt)
- ein reload 98_dewpoint in fhem eingegeben
- das Attribut gesetzt (siehe Screenshot1 Definition dewpoint und attr)
- bei meinem HM-Sensor nachgeschaut und kein neues Reading gefunden (sie Screenshot2)
Der dewpoint an sich wird berechnet und auch angezeigt - siehe Screenshot3
Jemand eine Idee was ich falsch mache?
Im FHEM-Logfile finden sich zumindest keine Fehlermeldungen.
Grüße
P.S.: Ja, die Werte aktualisieren sich schön nur eben das neue Reading finde ich nicht :o
Edith: Grad noch bei einem S300TH geschaut - auch kein Reading gefunden.
Moin Puschel74,
kommt im Eventmonitor was an?
Ich habe bei mir das StateFormat angepasst:
stateFormat {sprintf("T: %.1f H: %.1f D: %.1f A: %.1f",ReadingsVal("FS_Bad","temperature",0), ReadingsVal("FS_Bad","humidity",0), ReadingsVal("FS_Bad","dewpoint",0), ReadingsVal("FS_Bad","absFeuchte",0))}
Gruß Joachim
Hallo,
Zitatkommt im Eventmonitor was an?
Jep -
Zitat2014-03-15 17:20:05 CUL_WS OG_Schlafzimmer T: 20.7 H: 33.4 D: 4.0
Grüße
Mit der Angabe T H D funktioniert die Berechnung nicht.
Edit: Die absFeuchte wird nicht bei der Option zur STATE Anpassung berechnet.
Eigentlich meinte ich soetwas:
2014-03-15 17:32:42.474 OWMULTI FS_Bue_Zuluft VDD: 5.13
2014-03-15 17:32:42.474 OWMULTI FS_Bue_Zuluft Temperatur: 16.7
2014-03-15 17:32:42.474 OWMULTI FS_Bue_Zuluft Feuchte: 72.3
2014-03-15 17:32:42.474 OWMULTI FS_Bue_Zuluft dewpoint: 11.7
2014-03-15 17:32:42.474 OWMULTI FS_Bue_Zuluft absFeuchte: 9.3
ansonsten mal bitte den entsprechenden Teil aus der fhem.cfg für dewpoint und die Temperatur/Feuchtesensoren.
gruß Joachim
Hallo,
ok, sowas kann ich noch anbieten:
Zitat
2014-03-15 18:05:01 CUL_HM Garage temperature: 11.8
2014-03-15 18:05:01 CUL_HM Garage battery: ok
2014-03-15 18:05:01 CUL_HM Garage humidity: 59
2014-03-15 18:05:01 CUL_HM Garage T: 11.8 H: 59 D: 4.1
Definition von dewpoint und eines HM-Sensors siehe obiger Beitrag von mir.
Grüße
Probiere mal bitte:
define dew_all dewpoint dewpoint .* temperature humidity dewpoint
attr dew_all absFeuchte 1
und dann wieder einen Auszug aus dem Eventmonitor, habe da einen Verdacht.
Gruß Joachim
Hallo,
ok.
Mit deiner dewpoint-Definition und dem stateFormat klappt es jetzt einwandfrei mit der absoluten Feuchte.
Danke.
Grüße
Edith: Sorry, bin dir noch den EventMonitor schuldig:
Zitat2014-03-15 18:19:29 CUL_WS Heizraum T: 17.9 H: 43
2014-03-15 18:19:29 CUL_WS Heizraum temperature: 17.9
2014-03-15 18:19:29 CUL_WS Heizraum RSSI: -53.5
2014-03-15 18:19:29 CUL_WS Heizraum RAWMSG: K11790143
2014-03-15 18:19:29 CUL_WS Heizraum dewpoint: 5.2
2014-03-15 18:19:29 CUL_WS Heizraum absFeuchte: 5.6
2014-03-15 18:32:40 CUL_HM EG_Terrasse temperature: 9.6
2014-03-15 18:32:40 CUL_HM EG_Terrasse T: 9.6 H: 68
2014-03-15 18:32:40 CUL_HM EG_Terrasse dewpoint: 4.0
2014-03-15 18:32:40 CUL_HM EG_Terrasse absFeuchte: 5.2
Das andere sehe ich mir mal an.
Danke Puschel
Gruß Joachim
Hallo Puschel74,
nach dem ich heute mit Jo noch mal ne Tel. Standleitung aufgemacht habe müsste es jetzt auch mit deiner Einstellung
define dew_state dewpoint dewpoint .* T H D
attr dew_state absFeuchte 1
funktioniren.
Bitte Teste es mal und melde dich dann.
Bei Jo hat es geklappt in meinem Aufbau konnte ich es nicht Testen.
Gruß Olaf
P.S. Die Aktuelle Verson habe ich oben ein angeängt.
Hallo Olaf,
habe dein überarbeitetes Modul im Einsatz, es funktioniert bei meinem HM-WDS10-TH-O wie erwartet. Hatte dafür bisher ein ziemlich altes Modul im Einsatz, was sich jetzt erledigt hat. Danke!
Danke für die Antwort.
Hallo,
bei meinen HM-Sensoren hat das auch wunderbar funktioniert mit T H D
Nur meine WS (S300TH) haben lt. Plot nicht mitgemacht.
Die Readings wurden auch nur noch sporadisch erneuert und im EventMonitor habe ich nur "verstümmelte" Nachrichten gefunden.
Ich bin aber noch am testen - es kann auch sein das die Batterien der S300TH langsam am leer werden sind (sind schon > 2 Jahre im Gerät).
Screenshots habe ich aber gemacht und bin erstmal wieder zurück auf das gestrige Modul.
Der Plot wird wieder aktualisiert aber wie gesagt - ich tippe erstmal auf "schwächelnde" Batterien.
Sobald ich neue Batterien in den Geräte hab schau ich nochmal und melde mich wieder.
Grüße
P.S.: Ja, es betrifft nur CUL_WS (S300TH) - die HM sind aber recht neu und erst seit maximal 3-4 Monate im Einsatz und da die Readings (für mich zumindest) im Eventmonitor bis auf den TYPE identisch aussehen schiebe ich das erstmal auf meine alten S300TH resp. deren Batterien.
Hallo Puschel,
sind deine Batterien schon geliefert und lüpt es oder war der Weg zu weit? 8)
Gruß Olaf
Hallo,
Batterien sind schon längst neue verbaut 8)
Ich bin mir nur im Moment nicht sicher wo ich nach dem "Problem" suchen soll.
Wenn ich die letzte 98_dewpoint.pm verwende und dewpoint mit T H D definiere
sehe ich nur das die Temperaturwerte meiner S300TH nichtmehr geplottet werden.
Stelle ich wieder auf die vorletzte 98_dewpoint.pm um und definiere dewpoint wieder mit temperature humidity dewpoint
funktioniert auch das plotten der S300TH wieder einwandfrei.
Ich werde das heute abend nochmal auf T H D umstellen und den Plot mal länger laufen lassen und schauen was in der Datenbank an Daten ankommt.
Komischerweise sind nur die S300TH (6 Stück) davon betroffen.
Den HM-Sensoren scheint das nichts auszumachen - da läuft der Plot anstandslos weiter.
Grüsse
Ich hab zwar keine Lösung, aber ich bewundere das Problem. Auch wenn ich nach mehrmaligem Lesen dieses Threads immer noch nicht verstanden habe, was genau im Moment noch das Problem ist?
Hallo Puschel,
also 98_dewpoint.pm hat grundsätzlich zwei arbeitsweisen.
Die Definition mit ¨ temperature humidity dewpoint¨ erzeucht in den Reading Werte.
Beispiel:
defpoint 4,5
absfeuchte 5,1
temperature 150
humidity 55
Die Definition mit ¨T H D¨ schribt das STATE um und giebt die diese verändert wieder ( T: 150 H: 55 D: 4,5 A: 5,1)
Wilst du beides must du auch beides definieren.
Ich habe mich entschieden nur die Readins zu definieren und das State per Hand selber zu generiren.
Schaue doch mal, ob du einen deiner Sensoren ohne jegliche attrebute erst mal in Betribnimst.
Wenn es dann nicht geht dann währe es schön wenn du mal deine Definitionen hier postest, damit wir dein Problem nachvolziehen können.
Gruß Olaf
PS: absFeuchte sollte mann drin lassen. 8)
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.
Moin 5punk0,
Welches dewpoint-Modul hast Du?
Gruß Joachjim
Hallo Ihr,
Ich glaube es gibt keine Probleme mit dem Modul.
Ich werde also, wenn hier keiner Probleme anmeldet, Willi bitten das Modul ein zu checken.
Gruß Olaf
Just to add another report that it is working well here. A nice addition, thanks.
Hallo,
spät aber doch will ich meinen Senf auch noch dazu geben ;D
Klappt einwandfrei Olaf, solange man es richtig definiert ;)
Den obigen Plot habe ich schon umgestellt auf dewpoint und absfeuchte.
Die restlichen folgen noch.
Grüße
Hallo Puschel,
ich habe mir mal deinen Screen Shot angeschaut und musste feststellen, dass du jegliche Änderung der Messwerte mit Plottest.
Das Problem hatte ich auch und habe daher es mal mit einer Glättung versucht um das Datenaufkommen zu reduzieren.
Die Glättung geht über das userReadings in dem ich immer zwei Werte habe, die ich mit einander vergleich. Ein neuer- und ein alter- Wert.
Sprich ich mache aus ,,H" relFeuchte und auch temperature TEMP. In die Datenbank nehme ich nur die neuen Readings auf (relFeuchte und TEMP). Zur Glättung habe ich eine Verhältnis von ¼ (neu zu alt) für mich als optimal heraus gefunden.
Die Screen Shot von mir habe ich dir mal angehängt und die Einstellung für das userReading bei mir.
Gruß Olaf
P.s. Ich Danke auch Jo, der mich auf den Gedanken gebracht hat. Er teste da, mit einem Verhältnis bei 1/ 14.
attr OWX_Schlafstube_Feuchte userReadings H {(ReadingsVal("OWX_Schlafstube_Feuchte","H",0) < "100") ? (ReadingsVal("OWX_Schlafstube_Feuchte","H",0) + (ReadingsVal("OWX_Schlafstube_Feuchte","relFeuchte",0) * 4))/5: ReadingsVal("OWX_Schlafstube_Feuchte","relFeuchte",0)},relFeuchte { int ( 10 * ReadingsVal("OWX_Schlafstube_Feuchte","H",0) + 0.5 ) / 10 },TEMP { int ( 10 * ((ReadingsVal("OWX_Schlafstube_Feuchte","temperature",0) + (ReadingsVal("OWX_Schlafstube_Feuchte","TEMP",0) * 4))/5) + 0.5 ) / 10 }
Hallo Olaf,
danke für deinen Tipp und die Hilfestellung zur Umsetzung.
Zitatdass du jegliche Änderung der Messwerte mit Plottest.
Ich habe eigentlich an allen S300TH und HM-Sensoren das event-on-change-reading auf .* gesetzt.
Aber es ist richtig wie du sagst - jegliche Änderung.
Ich werde deine Lösung mal bei mir einbauen.
Ich gebe dann Bescheid - weiß nicht ob ich heute noch dazu komme.
Grüße
Moin Olaf,
kontrolliere mal Deine Formel! Du machst da einen Denkfehler.
Es wird ein neues userReading H anlegt, dabei das
alte userReading H kontrolliert, ob es unter 100 ist, und wenn das so ist, dann das Reading relFeuchte mit einer Gewichtung 4 mal userReading H zu ein mal Reading relFeuchte als neues Reading H geschrieben, sonst den Wert vom Reading relFeuchte nach H geschrieben.
Gruß Joachim
Hallo Jo,
da ist kein Fehler, ich kontrolliere "H" ob es kleiner ist als 100 wenn das so ist, dann nehme das "H" zu einem Teil und die relFeuchte zu vier Teilen und teile diese dann durch 5.
Ist "H" größer als 100 dann nehme die "alte" relFeuchte.
Im zweiten Schritt mache ich dann aus "H" die gerundete relFeuchte (weiter hinten).
Diese sollte so eigentlich klappen, wich ich es in dem Plott auch sehen kann.
Hallo Puschel,
wichtig ist bei diesem vorgehen, dass man immer einen neuen und einen alten Wert zur Verfügung hat. An sonsten klappt das nicht.
Ach ja, um deine Frage vorweg zu nehmen, warum ich dort nach schaue ob mein ¨H¨größer ist als 100, und dann eine Auswahl vornehme. Ich habe in meinem OWX Bus immer mal wieder plötzlich Messwerte größer 100 % was den Plott zerreist. Und so weit ich weiß gibt es keine Feuchte, die größer ist als 100 :-).
Gruß Olaf
Moin Olaf, moin Willi,
ist die Änderung schon offiziell?
Oder gibt es noch Probleme?
Bei mir läuft es einwandfrei.
Gruß Joachim
Hallo Joachim,
mir sind keine Problem mehr bekannt.
Ich habe nun schon einige mal Willi angeschrieben und ihn gebeten diese Verson online zu stellen,
aber bis heute habe ich keine Antwort von Ihm bekommen.
Ich weis nicht mehr was ich machen soll.
Schauen wir mal wann es so weit ist
Gruß Olaf
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...
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.
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?
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.
Zitat von: 5punk0 am 18 März 2014, 19:28:20
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 (http://forum.fhem.de/index.php/topic,26245.0.html)
Greetz
Eldrik
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
Ich hole mal den alten Beitrag wieder hoch – finde den Titel absolut passend :).
Relativ häufig habe ich folgende Meldung(en) im Log:
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
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.
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.
zu 1.: das wurde bereits festgelegt: http://www.fhemwiki.de/wiki/DevelopmentGuidelines (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 8)
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! ;D
Ich kann Ricardo da nur beipflichten. Hab ne Menge Sensoren/Aktoren(siehe Signatur) und alles(?) ohne Einheit !
Grüße Markus
Zitatzu 1.: das wurde bereits festgelegt: http://www.fhemwiki.de/wiki/DevelopmentGuidelines (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.
ZitatDa 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.
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.
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.