Wie Taupunkt [99_Taupunkt.pm] ins Log integrieren

718 views
Skip to first unread message

mabra

unread,
Mar 4, 2012, 4:27:21 PM3/4/12
to FHEM users
Hallo !

Wenn ich mein GHEM.cfg ansehe:

define Cave CUL_WS 5
attr Cave room Cave
define FileLog.Cave FileLog /var/log/fhem/Cave-%Y.log Cave:T:.*
[<== ???]
attr FileLog.Cave logtype temp4hum6:Temp/Hum,text
[<== ???]

Wie bekomme ich die absolute Feuchte [calc_af(r,T)] ins Log??

Das CUL_WS loggt ja einfach nur, was vom Device kommt.
Kann ich die Werte VOR dem loggen modifizieren indem
ich WAS an eine Funktion übergebe?

Was mir sonst einfällt: Dummy Device anlegen und alles
per Notify machen.

Wäre nett, wenn jemand einen Tip geben könnte!

Danke und mfg
++Manfred
(mabra)


UliM

unread,
Mar 4, 2012, 4:39:49 PM3/4/12
to fhem-...@googlegroups.com

Rudolf Koenig

unread,
Mar 4, 2012, 5:36:56 PM3/4/12
to fhem-...@googlegroups.com
> W�re nett, wenn jemand einen Tip geben k�nnte!

Ich sehe mehrere Wege:

- Generisch: analog zu avarage ein af Modul schreiben. Die meiste Arbeit mit
dem meisten Nutzen, da nicht nur CUL_WS Benutzer davon profitieren. MWn.
wollte Willi auch schon mal sowas bauen.

- CUL_WS erweitern um die af Berechnung, und diese gleich in die CHANGED
reinsteckt. Damit koenne andere CUL_WS Benutzer das auch einfach verwenden.

- notify auc Cave:T:.* bauen, der aus %EVTPART2 und %EVTPART4 ein $afwert
berechnet und dann "trigger Cave af: $afwert" absetzt. Ein dummy ist nicht
notwendig.

Willi

unread,
Mar 5, 2012, 12:42:41 PM3/5/12
to fhem-...@googlegroups.com
Am Sonntag, 4. März 2012 23:36:56 UTC+1 schrieb Rudolf Koenig:
> W�re nett, wenn jemand einen Tip geben k�nnte!

Ich sehe mehrere Wege:

- Generisch: analog zu avarage ein af Modul schreiben. Die meiste Arbeit mit
  dem meisten Nutzen, da nicht nur CUL_WS Benutzer davon profitieren.  MWn.
  wollte Willi auch schon mal sowas bauen.


Stimmt, habe ich auf meiner TODO-Liste. 

Brauche ich, da ich auf meinem FHEM-Produktionsserver sonst nicht auf eine SVN-Version ohne weiteren Aufwand updaten kann, weil ich bei mir lokal die Taupunktberechnung und Ausgabe als Readings in diverse Module (13_KS300.pm, 14_CUL_WS.pm sowie 41_OREGON.pm.) lokal integriert habe. Rudi hat mich überzeugt, dass der Weg dies in die einzelnen Module zu packen nicht so gut ist. Ein Modul analog zu average ist flexibler.

Ist wegen anderer Arbeiten (RFXtrx, erste Tests mit HM, Arbeiten im realen Haus) noch auf der Strecke geblieben. Wenn niemand schneller ist ;-) (Freiwillige gerne vor), gehe ich das nächste Woche an.

Willi

unread,
Apr 12, 2012, 8:20:25 AM4/12/12
to fhem-...@googlegroups.com
Am Sonntag, 4. März 2012 23:36:56 UTC+1 schrieb Rudolf Koenig:
> W�re nett, wenn jemand einen Tip geben k�nnte!

Ich sehe mehrere Wege:

- Generisch: analog zu avarage ein af Modul schreiben. Die meiste Arbeit mit
  dem meisten Nutzen, da nicht nur CUL_WS Benutzer davon profitieren.  MWn.
  wollte Willi auch schon mal sowas bauen.

Hallo,

ab sofort gibt es ein entsprechendes neues Helper-Modul: 98_dewpoint.pm
Ist im SVN und per updatefhem installierbar. 
Eine Beschreibung wie man es nutzt, steht im aktuellen commandref.html .

Man kann es unter anderem für folgende Zwecke verwenden:

- Generieren eines neuen Readings dewpoint, bei allen Geräten, die temperature und humidity anbieten. Beispiel:
  define dew_all dewpoint dewpoint .*
oder alternativ
  define dew_all dewpoint dewpoint .* temperature humidity dewpoint

- Generieren des Taupunktes im vorhandenen STATE. Beispiel:
  define dew_state dewpoint dewpoint .* T H D
  bewirkt, dass in allen States, die mit T: beginnen und bei denen auch
  humdidity mit H: angegeben ist, der Taupunkt als D: eingefügt wird.
  So wird dann aus STATE: "T: 10 H: 62.5" neu "T: 10 H: 62.5 D: 3.2"

- Generieren eines Events "fan: on" bzw. "fan: off", wenn der Taupunkt erstmals draussen niedriger als drinnen ist (und damit auch die abolute Luftfeuchtigkeit draussen geringer and drinnen ist). Kann man beispielsweise zur Kellerlüftung verwenden. Beispiel:
  define dew_fan1 dewpoint fan Keller_Raum1 Aussen_1 0
Die Events kann man dann beispielsweise mit einem entsprechenden Notify verwenden, um einen Lüfter zu steuern.

- Generieren eines Events alarm, wenn der Temperatur an der Wand erstmals geringer ist als der Taupunkt im Raum. In diesem Fall besteht Schimmelgefahr. Beispiel:
  define dew_alarm1 dewpoint alarm roomsensor wallsensor 0

Die Syntax sollte Flexibilität für weitere Anwendungszwecke bieten.

MfG Willi 

puschel74

unread,
Apr 13, 2012, 3:40:18 AM4/13/12
to fhem-...@googlegroups.com
Hallo,

danke erstmal für das Modul.
Ich möchte in weiterer Folge nämlich später meine Ventilatoren auch nach dem Taupunkt
laufen lassen oder eben nicht.
Erstmal wird der Taupunkt bei mir nur angezeigt - die Abfrage kommt später.

Nun habe ich, wie auch beschrieben,

define dew_state dewpoint dewpoint .* T H D

nach einem beherzten Updatefhem eingetragen.

So weit so gut. In allen CUL_WS wird bei mir nun nach T und H noch D berechnet
und mitgeloggt.
Nur mein CUL_TX wehrt sich heftigst dagegen.
Ich habe dann noch ein


define dew_all dewpoint dewpoint .* temperature humidity dewpoint

dazu eingetragen aber der TX will den Taupunkt nicht rausrücken.

Im Logfile des TX steht
2012-04-13_09:26:56 Terrasse temperature: 7.0
2012-04-13_09:26:58 Terrasse humidity: 72.0
2012-04-13_09:28:58 Terrasse temperature: 7.2
2012-04-13_09:29:00 Terrasse humidity: 72.0
2012-04-13_09:29:59 Terrasse temperature: 7.3
2012-04-13_09:30:59 Terrasse humidity: 71.0

daher habe ich gehofft das ich mit dem zweiten define hier den Taupunkt reinbekomme.
Beim WS sieht das Log ja so aus

2012-04-13_09:00:25 Heizraum T: 20.7  H: 37.8 D: 5.8
2012-04-13_09:06:20 Heizraum T: 20.8  H: 37.8 D: 5.9
2012-04-13_09:09:17 Heizraum T: 20.8  H: 37.8 D: 5.9
2012-04-13_09:12:14 Heizraum T: 20.8  H: 37.8 D: 5.9
2012-04-13_09:15:12 Heizraum T: 20.8  H: 37.8 D: 5.9
2012-04-13_09:18:09 Heizraum T: 20.8  H: 37.8 D: 5.9

Wenn ich aber über fhem auf den Sensor für die Terrasse (CUL_TX) klicke zeigt mir fhem unter
STATE T xx.x H yy.y (also passend für das erste define oben oder seh ich das falsch?)
Da ich aber vermute das auch das Logfile etwas damit zu tun hat (oder lieg ich da wieder falsch?) habe ich
eben das zweite define noch eingetragen.

Das Modul wurde übrigens anstandslos von updatefhem geladen und laut WS Log-Einträge funktioniert es ja auch.

Da ich noch nichtmal das Basisreading ins Statefile eintragen kann während fhem gestoppt ist (ironie @Rudi ;-) )
scheitere ich hier natürlich kläglichst und benötige mal wieder Hilfe.

Wenn sich also bitte jemand erbarmen würde und mir hier auf die Sprünge helfen könnte.

Grüße

Willi

unread,
Apr 13, 2012, 5:09:26 AM4/13/12
to fhem-...@googlegroups.com
Am Freitag, 13. April 2012 09:40:18 UTC+2 schrieb puschel74:
dazu eingetragen aber der TX will den Taupunkt nicht rausrücken.

Im Logfile des TX steht
2012-04-13_09:26:56 Terrasse temperature: 7.0
2012-04-13_09:26:58 Terrasse humidity: 72.0
2012-04-13_09:28:58 Terrasse temperature: 7.2
2012-04-13_09:29:00 Terrasse humidity: 72.0
2012-04-13_09:29:59 Terrasse temperature: 7.3
2012-04-13_09:30:59 Terrasse humidity: 71.0

Hmm. Das ist in der Tat ein besonderes Problem, dass man derzeit mit meinem Modul nicht lösen kann. Ich berechne den Taupunkt immer dann, wenn das Gerät gleichzeitig Temperatur und Luftfeuchtigkeit sendet. Das ist bei TX nicht der Fall.

Beim TX-Sensor ist das Problem, dass er sich wie zwei Sensoren verhält und Temperatur und Luftfeuchtigkeit getrennt und zu verschiedenen Zeitpunkten schickt.
Eine Taupunktberechnung ist aber nur richtig, wenn Luftfeuchtigkeit und Temperatur zusammenpassen.

Ich überlege mir mal, welche Lösungsmöglichkeiten es hier gibt. 

Eine Lösung wäre beim Empfang des Temperaturwertes bei dem keine Luftfeuchtigkeit geliefert wird dewpoint das Reading "humidity" (bzw. das dafür angegebene Reading) liest und für Taupunkt verwendet, aber nur wenn dieser nicht zu alt ist (innerhalb von x Sekunden).

Wenn Dir etwas anderes einfällt......

MfG Willi
 

puschel74

unread,
Apr 13, 2012, 6:17:48 AM4/13/12
to fhem-...@googlegroups.com
Hallo,

ok,ich habe übersehen das teilweise bis zu 1 Minute vergehen bis der TX den Feuchtewert
übermittelt.
Das erschwert natürlich die Berechnung des Taupunktes um einiges.
Dazu fällt mir leider auch nix ein ;-)

Grüße

Willi

unread,
Apr 13, 2012, 8:42:09 AM4/13/12
to fhem-...@googlegroups.com

Am Freitag, 13. April 2012 12:17:48 UTC+2 schrieb puschel74:
Hallo,

ok,ich habe übersehen das teilweise bis zu 1 Minute vergehen bis der TX den Feuchtewert
übermittelt.
Das erschwert natürlich die Berechnung des Taupunktes um einiges.
Dazu fällt mir leider auch nix ein ;-)


Ich glaube ein paar Minuten macht kaum etwas aus. Die Sensoren sind bzgl. Luftfeuchtigkeit so und so relativ träge und auch ungenau. 
Das kannst Du mal im Bad testen..........

Gib mir mal Feeedback, wie oft Deine TX-Sensoren senden und was Du für einen sinnvolle maximalen Unterschied in Sekunden zwischen Temperatur und Luftfeuchtigkeit ansehen würdest.

puschel74

unread,
Apr 13, 2012, 9:32:33 AM4/13/12
to fhem-...@googlegroups.com
Hallo,

wie hier zu sehen

2012-04-13_14:48:44 Terrasse temperature: 11.5
2012-04-13_14:49:43 Terrasse temperature: 11.5
2012-04-13_14:49:44 Terrasse humidity: 43.0
2012-04-13_14:50:45 Terrasse humidity: 43.0
2012-04-13_14:51:42 Terrasse temperature: 11.5
2012-04-13_14:51:43 Terrasse humidity: 43.0
2012-04-13_14:52:43 Terrasse temperature: 11.6
2012-04-13_14:52:44 Terrasse humidity: 43.0
2012-04-13_14:53:43 Terrasse temperature: 11.6
2012-04-13_14:54:42 Terrasse temperature: 11.6
2012-04-13_14:54:44 Terrasse humidity: 43.0
2012-04-13_14:55:41 Terrasse temperature: 11.6
2012-04-13_14:55:43 Terrasse humidity: 43.0
2012-04-13_14:56:44 Terrasse humidity: 43.0


"vergisst" der TX wohl ab und zu auch mal eine Luftfeuchte oder eine Temperatur zu senden.
Das die Sensoren von der Genauigkeit und von der Ansprechempfindlchkeit bei diesem Preis natürlich keine
Krone gewinnen ist mir schon auch klar.
Wobei ich mal schauen muss ob ich die eventuell bei uns im Kalibrierlabor kalibrieren lassen kann - machen wir
auch für unsere Kunden.

Aber kurz und knapp.
Wie ich gesehen hab wird alle Minute zumindest ein Wert gesendet.
Allerdings konnte ich kein Muster erkennen nach dem der TX mal den einen mal den anderen Wert verschweigt.

Ergo wird eine vernünftige Taupunktberechnung für diesen Sensor daran scheitern das die zugehörigen Werte nicht
lückenlos vorhanden sind / gesendet werden.
Eine "krückenhafte" Taupunktberechnung macht für diesen Sensor aber mehr Arbeit als Sinn - behaupte ich einfach mal.
Da aber die restlichen CUL_WS wunderbar den Taupunkt mitloggen kann ich auf den TX über kurz oder lang sowieso verzichten
da ich mich dann daran wagen werde Yahoo-Wetter auf dem Tablet zur Anzeige zu bringen.
Dann fliegt die Wetterstation mit dem zugehörigen TX raus und wird durch einen WS ersetzt.
Auch daher macht es mir keinen Sinn deine Zeit mit einer eventuell nötigen Anpassung an deinem Modul zu "binden".
Diese Zeit ist bei fhem besser aufgehoben - u.a. auch weil dein Modul ja funktioniert mit den WS.

Danke nochmal für dein Feedback.

Grüße
Reply all
Reply to author
Forward
0 new messages