LaCrosse - Absolute Luftfeuchtigkeit als Ergänzung zu Taupunkt implementiert

[fron]

ich habe vor längerer Zeit in "meinem" 36_LaCrosse.pm-File eine Berechnung der absoluten Luftfeuchtigkeit ergänzt.

Hintergrund:
* der Taupunkt ist als Basis einer Lüftungssteuerung  wunderbar geeignet
* um den Erfolg des Lüftens zu kontrollieren ist der Taupunkt jedoch absolut unanschaulich
  * die relative Luftfeuchte als Ersatz ebenso ungeeignet, da sich der Raum beim Lüften (z.B.) abkühlt und dann bei evtl. gleicher oder sogar höherer rel. Luftfeuchte dennoch getrocknet wurde!!!
* die absolute Luftfeuchtigkeit ist dagegen "handfest" genug, um es anschaulich plotten zu können.

Messreihe: Aufheizen eines Raumes
* Temperatur steigt, relative Luftfeuchte sinkt
* absolute Luftfeuchte konstant, Dewpoint auch

T: 15.7 H: 45 A: 6 D: 3.8 T: 15.9 H: 44 A: 6 D: 3.7 T: 16.1 H: 44 A: 6 D: 3.9 T: 16.3 H: 43 A: 6 D: 3.7 T: 16.4 H: 43 A: 6 D: 3.8 T: 16.5 H: 43 A: 6 D: 3.9 T: 16.7 H: 42 A: 6 D: 3.7 T: 16.8 H: 42 A: 6 D: 3.8 T: 16.9 H: 42 A: 6 D: 3.9 T: 16 H: 44 A: 6 D: 3.8 T: 17.1 H: 41 A: 6 D: 3.8 T: 17.2 H: 41 A: 6 D: 3.8 T: 17.3 H: 41 A: 6 D: 3.9 T: 17.5 H: 40 A: 6 D: 3.8 T: 17.6 H: 40 A: 6 D: 3.9

Formel gemäß:
https://carnotcycle.wordpress.com/2012/08/04/how-to-convert-relative-humidity-to-absolute-humidity/

Es waren nur geringe Änderungen erforderlich, 1:1 analog zum "Dewpoint" implementiert, seit Sommer 2015 bei mir im Einsatz.

Attribut-Dropdown ergänzt:

Code Auswählen Erweitern

...
    ." doAbsoluteHumidity:1,0"
...

Formel ergänzt:

Code Auswählen Erweitern


sub LaCrosse_CalcAbsHumidity (@) {
  my ($temp,$hum) = @_;

  my($AHUM);

  $AHUM = 6.112 * 2.718281**((17.67*$temp)/($temp+243.5))*$hum*2.1674 / (273.15+$temp);

  return $AHUM;
}


Verarbeitung ergänzt:

Code Auswählen Erweitern

# Calculate absoluteHumidity
      my $ahum = undef;
      if( AttrVal( $rname, "doAbsoluteHumidity", 0 ) && $humidity && $humidity <= 99 && $temperature != 0xFFFF ) {
        $ahum = LaCrosse_CalcAbsHumidity($temperature,$humidity);
      }

inkl. "resolution"

Code Auswählen Erweitern

if ($ahum) {
        $ahum = int($ahum * 10 / $resolution + ($ahum < 0 ? -0.5 : 0.5)) * $resolution / 10
      }

und "bulk update"

Code Auswählen Erweitern

   if ($ahum) {
        readingsBulkUpdate($rhash, "abshumidity$channel", $ahum);
      }

sowie neuem State "A:###"
=> zwischen "H:" und "D: platziert, damit "relative und absolute Luftfeuchte" nebeneinander stehen und D/Taupunkt weiterhin rechts platziert ist.

Code Auswählen Erweitern

$state .= " A: $ahum" if( $ahum );

Zuguterletzt ne Notiz in der Doku:

Code Auswählen Erweitern

    <li>doAbsoluteHumidity<br>
      calculate absolute humidity</li>


[chris1284]

das modul dewpoint https://fhem.de/commandref.html#dewpoint implemetiert dies bereits mit attr absFeuchte.
ist die frage ob jedes modul welches temp und hum von geräten/quelllen abfragt sein eigenes "rechensüppchen" kochen muss oder doch nur das macht was es soll -> die messadaten bereitstellen.
wenn ja sollte man sich auf homogene readingnamen einigen (so das hm, lacrosse, hms, usw alle die selben nutzen)

ich fand es bei einigen sensoren per signalduino und devicemodulen schon  ätzend das diese all möglichen kram (ohne das man es abstellen kann) berechnen obwohl es dafür seit her andere module gab und die devices diese daten nicht liefern von haus aus.

[fron]

da geh' ich grundsätzlich mit - Recht hast du!!!

Zur Entschuldigung... das "absFeuchte" muss in der Zwischenzeit an das Dewpoint-Modul angeflanscht worden sein, evtl. habe ich es auch übersehen, da man als LaCrosse-Nutzer das Dewpoint-Modul nicht braucht... Und ganz sicher habe ich nicht den Suchbegriff "absFeuchte" verwendet um im Forum zu suchen...

Ich finde es bei einem Wetterstationsmodul wie dem LaCrosse allerdings vorteilhaft alle Messwerte in einer Hand zu berechnen, sehr effizient - zehn Zeilen Code, ein einziges Update des "State"-Attributes schreibt alle 4 Werte...

Am Rande... Wenn das Dewpoint-Modul neben der Berechnungfunktion auch Lüfter an und ausschalten darf [gehört eher in 99_myUtils oder so, oder!?], dann darf LaCrosse evtl. auch rechnen

[HCS]

wenn ja sollte man sich auf homogene readingnamen einigen (so das hm, lacrosse, hms, usw alle die selben nutzen)

Gibt es eine allgemeine Richtline für die Namen von readings?

ich fand es bei einigen sensoren per signalduino und devicemodulen schon  ätzend das diese all möglichen kram (ohne das man es abstellen kann) berechnen obwohl es dafür seit her andere module gab und die devices diese daten nicht liefern von haus aus.

Wobei man es im vorgeschlagenen Patch ja explizit einschalten muss, wenn man es will.

Ich finde es bei einem Wetterstationsmodul wie dem LaCrosse allerdings vorteilhaft alle Messwerte in einer Hand zu berechnen, sehr effizient ...

Ja, das ist auf alle Fälle schlanker als ein weiteres Modul, das interagieren muss.


Bin hin- und hergerissen zwischen der Einfachheit von "Attribut setzen und fertig" und "gibt es doch schon aber muss man erst mal finden und konfiguriert bekommen"
Muss man drüber schlafen 

Ideal wäre, wenn es zentrale Routinen gäbe, die Taupunkt, Absolute Feuchte usw. rechnen können, die dann die Module verwenden können.
Das größte Risiko sehe ich darin, dass verschidene Module nach verschiedenen Formeln rechnen und kein vergleichbares Ergebinis haben.

@fron: entspricht Deine Formel der Rechenmethode aus dem dewpoint modul?

[chris1284]

Gibt es eine allgemeine Richtline für die Namen von readings?

leider nein. es haben sich zwar einige bezeichnungen über die module gefestigt (battery, temprature, humidity, usw) aber eine echte richtlinie gibt es leider nicht

[Sidey]

ich fand es bei einigen sensoren per signalduino und devicemodulen schon  ätzend das diese all möglichen kram (ohne das man es abstellen kann) berechnen obwohl es dafür seit her andere module gab und die devices diese daten nicht liefern von haus aus.

Sorry passt nicht 100% zum Thema, aber welche Readings hättest Du gerne deaktiviert?

Ansonsten bin ich auch der Meinung, dass wir es beim dewpoint Modul belassen sollten, das reagiert dann auch bei allen Sensoren einheitlich.

Grüße Sidey

[fron]

@fron: entspricht Deine Formel der Rechenmethode aus dem dewpoint modul?

Nein, ich hatte die gleiche Quelle wie des Dewpointmoduls zunächst auch verwendet und in Perl umgesetzt, die Formel erscheint mir aber nicht sehr genau zu sein, der harte Sprung der zugrundeliegenden Werte - sehr unnatürlich...

Habe dann umgestellt auf die Formel, die in
https://carnotcycle.wordpress.com/2012/08/04/how-to-convert-relative-humidity-to-absolute-humidity/
hergeleitet wird.

This formula is accurate to within 0.1% over the temperature range –30°C to +35°C

Besser gehts bei geringem Rechenaufwand wohl nicht.

[chris1284]

wäre also der richtige weg nun auch noch Joachim (hab ihm eine pm gesendet)

FHEM/98_dewpoint.pm          Joachim              http://forum.fhem.de Automatisierung

ins boot zu holen damit er seine formel anpasst. sollte das nicht geschehen, ist es ja quasi ein muss die bessere formel ins lacrosse mit einzubauen

[HCS]

wäre also der richtige weg nun auch noch Joachim ins boot zu holen damit er seine formel anpasst. sollte das nicht geschehen, ist es ja quasi ein muss die bessere formel ins lacrosse mit einzubauen

Genau das dachte ich heute unter der Dusche auch.
1. absolute Feuchte nicht ins LaCrosse einbauen
2. die Formel in dewpoint verbessern (ggf. Patch vorschlagen)
3. die dewpoint Berechnung im LaCrosse modul auf die bessere Version umstellen

Anstatt 3. müsste man dewpoint eigentlich aus dem LaCrosse Modul eliminieren, das wäre konsquent, aber den geballten Zorn über die danach erforderlichen Umbauten bei tausend Anwendern will ich nicht auf mich lenken 

Ich warte mal ab, wie es mit dem dewpoint modul weiter geht.

[fron]

vielleicht wäre es sinnvoll...

...das Dewpoint-Modul aufzuspalten in zwei "purpose built" Module
a) WeatherCalc.pm => Dewpoint(), absHumidity() und alles was noch dazu kommt...
b) TaupunktbasierteLüftersteuerung.pm

ich meine... Wenn man schon dabei ist, aufzuräumen?

[HCS]

wäre also der richtige weg nun auch noch Joachim (hab ihm eine pm gesendet)ins boot zu holen

Der scheint nicht mehr sehr aktiv zu sein, war am 11. Februar 2017 zuletzt angemeldet.

[chris1284]

in der tat... brauchts wohl einen neuen maintainer oder man checked es in absprache mit rudi so ein

[HCS]

Wir warten mal noch ein weing, so eilig ist der Fall ja nicht.
Ich habe da was von drei Wochen im Hinterkopf, bis wann ein Maintainer reagieren sollte.
Falls er doch mal noch bei FHEM vorbei schaut, sollte er ja Deine PM sehen.
Falls nicht, können wir überlegen, wie wir weiter verfahren.

[HCS]

Lange genug wurde nun wohl gewartet.
Letzte Anmledung von "Joachim" immer noch 11 Februar 2017, 14:00:07
Das Modul braucht wohl einen neuen Maintainer.

@fron: Du hast ja developer-Status und verstehst was von feuchten Dingen 
wäre das nichts für Dich?

[HCS]

OK, fron war auch das letzte mal 26 April 2017 online.

Steht echt schlecht für das Thema