Dewpoint und absFeuchte seit Update im Dezember 2017 fehlerhaft

[Gast45]

ich habe das gleiche Problem wie fhem-hm-knecht und zwar doppelte Einträge im Log

2018-01-17_09:35:06 lt_Aussen T: 5.3 H: 79.0
2018-01-17_09:35:06 lt_Aussen temperature: 5.3
2018-01-17_09:35:06 lt_Aussen T: 5.3 H: 79.0 D: 1.9
2018-01-17_09:35:06 lt_Aussen T: 5.3 H: 79.0
2018-01-17_09:35:06 lt_Aussen humidity: 79.0
2018-01-17_09:35:06 lt_Aussen T: 5.3 H: 79.0 D: 1.9

In Beitrag 11 hatte ich schon was dazu geschrieben. Vielleicht hilft das.

Im DeviceOverview fehlt der Dewpoint!
Internals: STATE: T: 5.3 H: 79.0
Readings: STATE: T: 5.3 H: 79.0

Genau das ist das Problem

Zur Zeit ersetze ich nach jedem Update die 98_dewpoint.pm  durch die alte Version vom 12.10.2014 dann funktioniert wieder alles.

Soweit zurück? Ist die vorletzte Version so lange unbearbeitet geblieben? Wo findet man die?

[hotbso]

Hallo zusammen,
da die Diskussion nicht in "Automatisierung" los ging, ist sie leider durch meine Filter gefallen und bisher an mir vorbeigegangen.

Zum Hintergrund:
Die Innereien des Moduls sind sehr alt und dort wurde (und wird noch) in den globalen Variablen von FHEM herumgeschraubt. Ich bin jetzt dabei, das ganze schrittweise auf das jetzt inzwischen existierende API umzubauen.

Das Modul hat die Spezialität, dass wenn die angegebene Temperatur den magischen Namen "T" hat, der STATE des Devices manipuliert wird. Dann wird auch kein Reading "dewpoint" angelegt. (absFeuchte aber ggf. schon);
Das geht so ziemlich an der Logik vom FHEM zu Readings und Events vorbei, ich versuche aber das Verhalten im Rahmen von Rückwärtskompitibilität zu erhalten.

Der Fehler müsste jetzt in der anhängenden Version gefixt sein, bitte mal ausprobieren, bevor ich das einchecke.

Der bessere Ansatz ist:
- das dewpoint device mit den Namen der Readings für Temperatur und Feuchte anlegen
- dann mit Attribut "stateFormat" den Taupunkt im STATE ergänzen

Gruss
Holger

[nils_]

Zur Zeit ersetze ich nach jedem Update die 98_dewpoint.pm  durch die alte Version vom 12.10.2014 dann funktioniert wieder alles.

--> https://fhem.de/commandref_DE.html#exclude_from_update

[RieWi]

Hallo hotbso,

ich habe Deine 98_dewpoint verwendet.

Im DeviceOverview ist der Dewpoint wieder da.
Internals: STATE: T: 5.0 H: 69.0 D: -0.2
Readings: STATE: T: 5.0 H: 69.0

Das Fhem Logfile mit dewpoint verbose = 5:
2018.01.18 18:01:39 4: dewpoint_notify: cmd_type=dewpoint devname=lt_Aussen dewname=dew_state, dev=lt_Aussen, dev_regex=lt_.* temp_name=T hum_name=H
2018.01.18 18:01:39 5: dewpoint_notify: s='T: 5.0 H: 69.0'
2018.01.18 18:01:39 5: dewpoint_notify: evName='T:' val=5.0'
2018.01.18 18:01:39 5: dewpoint_notify T: H:, temp=5.0 hum=69.0
2018.01.18 18:01:39 5: dewpoint_notify: s='temperature: 5.0'
2018.01.18 18:01:39 5: dewpoint_notify: evName='temperature:' val=5.0'
2018.01.18 18:01:39 5: dewpoint max_timediff=1
2018.01.18 18:01:39 5: dewpoint_notify: dewpoint=-0.2
2018.01.18 18:01:39 5: dewpoint_notify: current=T: 5.0 H: 69.0 D: -0.2
2018.01.18 18:01:40 4: dewpoint_notify: cmd_type=dewpoint devname=lt_Aussen dewname=dew_state, dev=lt_Aussen, dev_regex=lt_.* temp_name=T hum_name=H
2018.01.18 18:01:40 5: dewpoint_notify: s='T: 5.0 H: 69.0'
2018.01.18 18:01:40 5: dewpoint_notify: evName='T:' val=5.0'
2018.01.18 18:01:40 5: dewpoint_notify T: H:, temp=5.0 hum=69.0
2018.01.18 18:01:40 5: dewpoint_notify: s='humidity: 69.0'
2018.01.18 18:01:40 5: dewpoint_notify: evName='humidity:' val=69.0'
2018.01.18 18:01:40 5: dewpoint max_timediff=1
2018.01.18 18:01:40 5: dewpoint_notify: dewpoint=-0.2
2018.01.18 18:01:40 5: dewpoint_notify: current=T: 5.0 H: 69.0 D: -0.2

Hier scheint es als ob alles 2mal abgearbeitet wird?

[hotbso]

Das kann ich in meiner Testumgebung so nicht nachvollziehen.

Tritt das bei Dir immer auf und immer mit 1 Sekunde Abstand im Log ?

[Gast45]

Hey cool, dass Bewegung rein kommt. Dafür schon mal danke.
Ich bekomme es jetzt nicht ganz 100%ig beschrieben. Aber mit dem berechnen des Taupunktes aus Temperatur und Feuchtigkeit und anschließend einfügen per stateFormat hatte ein Nachteil. Meine Sensoren liefern mal Temperatur, mal Feuchtigkeit, mal beides und auch mal länger nichts. Und die empfangenen Werte erscheinen auch nicht sofort im state, sondern erst mit der nächsten Übertragung. So kam es öfters vor, dass der berechnete und in STATE per stateFormat eingefügte Taupunkt nicht zu den im STATE (veralteten) angezeigten Werten für Temperatur und Feuchtigkeit passte.
Wenn aber der Taupunkt aus T und H berechnet wird, dann passen die Werte zwangsläufig zusammen.

[hotbso]

Mit dem Attribut max_timediff kannst du steuern, wieweit der Messzeitpunkt von Temperatur und Feuchtigkeit auseinander liegen darf. Der default liegt bei nur 1 Sekunde. Wenn dein Thermometer längere Aussetzer hat, setze das Mal höher.

Gesendet von meinem Nexus 5X mit Tapatalk

[RieWi]

Hallo Holger,

ich habe den Sensor: TFA Dostmann Aussensender 433 Mhz-Frequenz 303125 im Einsatz.
Es ist bei meinem Sensor genauso wie von Gast45 beschrieben, Temperatur und Feuchtigkeit werden getrennt geliefert.
Jedesmal wenn sich ein Wert aktualisiert wird erfolgt eine Taupunktberechnung, was auch so sein soll.
Also ist alles wieder in Ordnung.

Das Attribut max_timediff wer bis jetzt noch nicht gesetzt, ich habe max_timediff auf 600 Sekunden gesetzt, weil der Abfrageintervall im "define lt_Aussen CUL_TX 125 0 600" auf die gleiche Zeit konfiguriert ist.

Den bessere Ansatz vom 18.01.17 11:48 habe ich nicht verstanden? (ist auch nicht mehr nötig - oder?)
   - das dewpoint device mit den Namen der Readings für Temperatur und Feuchte anlegen
   - dann mit Attribut "stateFormat" den Taupunkt im STATE ergänzen
Auch im -> dex_state -> Device specific help <- habe ich nichts gefunden.

Vielen Dank für die schnelle und kompetente Bearbeitung.

Gruss
Willi

[hotbso]

Der bessere Ansatz:
Angenommen die readings bei deinem Thermometer heissen (wie bei fast allen anderen auch) "temperature" und "humidity".

Dann definierst Du zB

Code Auswählen Erweitern

define my_dewpoint dewpoint dewpoint  Thermo_(In|Out)

Dann bekommst Du in Deinen Thermometern das Reading "dewpoint" angelegt.

Im Device des Thermometers kannst Du dann mit stateFormat die Anzeige des STATE zusammenbauen (siehe commandref).

Wie schon gesagt ist das besser, weil das Herumfummeln am STATE eines anderen Devices eigentlich an der Logik von FHEM vorbeigeht.

[Gast45]

Hi hotbso,

Maxtimediff hatte ich auch schon hochgesetzt. Im übrigen habe ich auch die gerade beschriebenen tfa. Maxtimediff ändert aber nichts am Problem, dass die geänderten Temperatur- und Humidity-Werte nicht sofort im State landen. Damit stehen im State eventuell zwei alte Werte, und mit z.b. nur einem aktualisieren Temperaturwert wird der Taupunkt berechnet. Der passt dann natürlich nicht zu den noch alten Werten im State.
Kann mir einer folgen? 

Wenn ich das richtig verstanden habe, dann nutzt dewpoint die Werte aus dem state, wenn Mann dewpoint mit T und H definiert. Damit waren die Werte zwangsläufig immer zueinander passend.

[Gast45]

Ich denke ich werde alles mal umbauen.
- Taupunktberechnung nur noch nach state-Änderung (event-on-change-reading state). Ich hoffe das funktioniert so?
- Taupunktberechnung individuell pro Device.
- Änderung des STATE mit stateFormat

Ich denke das wird auch für konsistente Werte im STATE sorgen, weil ich mir ziemlich sicher bin, dass state und STATE stets identisch sind?!

[hotbso]

Ich denke ich werde alles mal umbauen.
- Taupunktberechnung nur noch nach state-Änderung (event-on-change-reading state). Ich hoffe das funktioniert so?
- Taupunktberechnung individuell pro Device.
- Änderung des STATE mit stateFormat

Ich denke das wird auch für konsistente Werte im STATE sorgen, weil ich mir ziemlich sicher bin, dass state und STATE stets identisch sind?!

Das ganze ist aus Prosa schwer nachzuvollziehen.
Poste doch mal die Definitionen eines Thermometers, des dewpoints (alles  inklusive der Attribute) sowie einen Auszug aus dem Log mit verbose Level  (für dewpoint).

[Gast45]

Beschreibung meiner Idee:
Folgendes habe ich mir bei der u.g. Konfiguration gedacht:
Nur wenn sich das Reading "state" ändert, mindestens aber alle 3 Minuten soll ein Event erzeugt werden.
(eigenartigerweise liegen hier auch gerne mal fast 4 Minuten dazwischen, s.u.).
Durch das Event werden die T- und H-Werte aus dem reading "state" durch die Taupunkt-Berechnung dew_state geschickt.
Diese ergänzt dann wiederum das Internal "STATE" um den Taupunkt und die absolute Feuchtigkeit.
Ich hatte so gehofft, dass die Werte (T, H, D, A) im "STATE" jeweils zu 100% konsistent zueinander sind.
Ansonsten konnte es wie beschrieben passieren, dass Temperatur und/oder Humidity sich im zeitverlauf ändern,
aber wegen eines zu großen Zeitabstandes der Taupunkt und absolute Feuchtigkeit nicht berechnet wurden.
Dann passen aber die T- und H-Werte im Internal "STATE" nicht mehr zu den veralteten D- und A-Werten.
Damit wären diese Datensätze inkonsistent und das ist wiederum unschön, da sie ja in dieser Kombination im
Log erscheinen.



Definition des Außentemperaturfühlers:

Code Auswählen Erweitern


define SensorAussen CUL_TX 127
attr SensorAussen event-min-interval state:180
attr SensorAussen event-on-change-reading state,humidity,temperature
attr SensorAussen stateFormat T: temperature H: humidity D: dewpoint A: absFeuchte




Definition des Log-Files, damit nur eine Zeile pro Messpunkt geschrieben wird:

Code Auswählen Erweitern


define FileLog_SensorAussen FileLog ./log/SensorAussen-%Y.log SensorAussen:.*D:.*


Mit ".*D:.*" habe ich erreicht, dass es wie auch von anderen beschrieben keine doppelten
Einträge mehr im Log gab.



Definition Taupunktberechnung:

Code Auswählen Erweitern


define dew_state dewpoint dewpoint .* T H D
attr dew_state absFeuchte 1




Auszug aus dem LOG:

Code Auswählen Erweitern


2018-01-20_12:58:29 SensorAussen T: 4.2 H: 83.0 D: 1.6 A: 5.3
2018-01-20_13:02:23 SensorAussen T: 4.2 H: 83.0 D: 1.6 A: 5.3 (Zeitdifferenz größer 3 Minuten!)
2018-01-20_13:05:18 SensorAussen T: 4.3 H: 83.0 D: 1.7 A: 5.4 (D- und A-Berechnung bei Änderung im state)
2018-01-20_13:09:12 SensorAussen T: 4.3 H: 83.0 D: 1.7 A: 5.4 (Zeitdifferenz größer 3 Minuten!)
2018-01-20_13:13:06 SensorAussen T: 4.3 H: 83.0 D: 1.7 A: 5.4 (Zeitdifferenz größer 3 Minuten!)


Im Log erscheinen die Werte wie gewünscht, nur das Internal wird seit Dezember 2017 nicht mehr geändert.
Die Klammern sind natürlich nicht im Log, sondern nur Anmerkungen von mir, damit man direkt sieht, worum
es mir in der jeweiligen Zeile geht.


Zunkunft:
Zukünftig werde ich wohl die Taupunktberechnung pro Sensor einzeln programmieren,
das Reading dewpoint erzeugen lassen und das Internal "STATE" ändern mit:

Code Auswählen Erweitern


stateFormat {sprintf("T: %.1f H: %.1f D: %.1f A: %.1f",
ReadingsVal("SensorAussen","temperature",0),
ReadingsVal("SensorAussen","humidity",0),
ReadingsVal("SensorAussen","dewpoint",0),
ReadingsVal("SensorAussen","absFeuchte",0))}


Außerdem plane ich so eine Art "Dummy" zwischen dem Sensor und der übrigen Definition (Log, Plot) einzuführen.
Das Problem ist, dass sich der Fühler beim Batteriewechsel mit einer neuen ID meldet. Einfach wieder
mit rename umbenennen zu SensorAussen war glaube ich nicht möglich. Vielmehr musste man alles zum
Sensor löschen (Device, Log, Plot). Dann muss man aber nach einm Batteriewechsel wieder alles neu konfigurieren.
Und wenn man nicht aufpasst und sie nicht manuell sichert, dann ist nach dem rename die alte Log-Datei mit allen
Werten weg. Mit den "Dummy" möchte ich erreichen, dass bei einem Batteriewechsel nur noch der "Dummy" gelöscht
und das Device mit einem rename wieder zu dem "Dummy" wird. Das Log und der Plot sollen vom "Dummy" erfolgen und
sind damit unabhängig. Gerade der Batteriewechsel ist aber auch ein Grund, warum ich die Konfiguration des Device
möglichst einfach halten möchte. Je mehr hier programmiert ist, umso aufwendiger ist so ein Batteriewechsel.

Ergänzend:
Ich weiß nicht so recht, was ich genau mit verbose-Log erfassen soll. Mal abgesehen, dass das im Zweifel ewig lang wird
und vor allem auch lange dauert. Die Zeit kann ich mir heute leider nicht mehr nehmen.

[hotbso]

Wenn du den dewpoint mit T H D definierst und stateFormat verwendest, arbeitet das beides gegeneinander.

Ich denke mit

define dew_state dewpoint dewpoint .* temperature humidity dewpoint
attr dew_state absFeuchte 1
max_timediff muss so groß sein, dass du auch immer ein passendes temperature und humidity Reading hat, man braucht nun Mal beides.

Es passiert folgendes:
- temperature und/oder humidity event wird generiert
- Reading dewpoint wird *immer* berechnet
- stateFormat setzt STATE
- alles ist konsistent

Die doppelten Events sollte es nicht mehr geben.
Ich weiß nicht genau, was du mit "einzeln berechnen" meinst. Wenn die Definition und Attribute des dewpoint für mehrere devices passen, bringt das keinen Vorteil.

Gesendet von meinem Nexus 5X mit Tapatalk

[Gast45]

Wenn du den dewpoint mit T H D definierst und stateFormat verwendest, arbeitet das beides gegeneinander.

Das habe ich deshalb gemacht, weil bei der Konfiguration, wenn es zu keiner Taupunkt-Berechnung kommt, D und A komplett aus dem Internal STATE verschwinden bis wieder eine Berechnung stattfindet. Durch die Definition war es möglich immer die absolute Feuchtigkeit im STATE zu haben und für dewpoint wurde "n.V." angezeigt. Das habe ich erreicht, indem ich das reading für dewpoint manuell mit "n.V." belegt habe. Das funktionierte auch bis Dezember wunderbar. Dass das möglicherweise jetzt stört hatte ich auch vermutet und deshalb rauskonfiguriert. Geändert hat es aber nichts.

define dew_state dewpoint dewpoint .* temperature humidity dewpoint
attr dew_state absFeuchte 1
max_timediff muss so groß sein, dass du auch immer ein passendes temperature und humidity Reading hat, man braucht nun Mal beides.

Es passiert folgendes:
- temperature und/oder humidity event wird generiert
- Reading dewpoint wird *immer* berechnet
- stateFormat setzt STATE
- alles ist konsistent

Ja, das verstehe ich soweit, glaube ich. Aber das Problem bei den Sensoren ist leider, dass sie tatsächlich auch mal viele Minuten (zwar selten, aber auch gerne mal über eine halbe Stunde) keine Werte oder nur einen Werte liefern. Damit ist max_timediff problematisch sinnvoll zu setzen.

Das Problem:
Mein Eindruck ist, dass die Werte im Reading "state" die Werte von Temperatur und Humidity bekommen, bevor die aktuellen Werte in in die Readings "temperature" und "humidity" eingespielt werden. Damit stehen im "state" quasi die Vorgängerwerte. Wenn nun viel Zeit zwischen den Aktualisierungen vergeht, passen die mit "temperature" und "humidity" berechneten Taupunkte nicht mit den im "state" bzw. "STATE" veralteten Werte überein. Auch deshalb bin ich auf das reading "state" ausgewichen. So waren zwar die Werte alt und möglicherweise auch einer der T- oder H-Werte alt, aber in sich alle vier konsistent. Einen Tod muss man bei den Sensoren leider sterben


@hotsbo:
Die ganzen Erkenntnisse sind übrigens etwa ein Jahr alt. Damals habe ich mit Fhem begonnen und wollte die Arbeitsweise verstehen. Das Ganze war natürlich extrem zeitaufwändig und so ganz klar ist mir Vieles immer noch nicht.
Ich werde mal schauen, wie ich mit der jetzt gegebenen Situation letztlich umgehen werde. Wenn das automatische Ändern des Internals "STATE" der Arbeitsweise von Fhem widerspricht, hat es keinen Sinn sich darauf abzustützen. Über kurz oder lang würde es eh entfallen. Es ist auch absolut sinnvoll ein einheitliches Verhalten des gesamten Systems zu verfolgen. Sonderfälle erschweren das Verständnis immer.
Aber dennoch natürlich besten Dank für die hilfreichen Antworten.

Zusatzinfo, 20.1.18, 19:00 Uhr:
Ich habe doch noch etwas den Verlauf der Werteübermittlung verfolgt. Auch ein einzelner, verändert übermittelter Temperaturwert erscheint unmittelbar im Reading state. Demnach scheint meine Aussage nicht (mehr) korrekt zu sein, dass bei einem übermittelten Wert zuerst der Temperaturwert in den state verschoben wird und dann das Temperatur-Reading erneuert wird, womit im state stets der Vorgängerwert stünde. Ob das Verhalten vor einem Jahr noch anders war, oder ob es doch noch Situationen gibt, wo das Schreiben des Reading state vielleicht auch einfach ausbleibt, kann ich nicht sagen. 

Zusatzinfo, 20.1.18, 19:45 Uhr:
Update durchgeführt. STATE-Ergänzung funktioniert wieder wie früher. Danke an die zuständigen Programmierer.
Wenn hier in den nächsten Tagen kein Diskussionsbedarf mehr besteht, dann werde ich das Thema schließen. Ich glaube das ist meine Aufgabe, oder?