Änderungsanfrage setReadingsVal() für dewpoint

[Willi]

Hallo,

ich mache gerade dewpoint kompatibel mit event-on-change-reading (gerade im Test).

Dewpoint erlaubt den Taupunkt in STATE zu schreiben (z.B. mit D:).

Bei der derzeitigen Logik von setReadingsVal wird allerdings STATE durch das Reading state überschrieben, auch wenn sich das Reading state nicht geändert hat. das bedeutet, dass dann im STATE der Taupunkt überschrieben wird. Da dewpoint kein Event bekommt (Reading state wird ja nicht geändert und daher kein Event ausgelöst), kann dewpoint den Taupunkt nicht erneut schreiben und dieser verschwindet.

Daher wäre mein Vorschlag in setReadingsVal() STATE nur zu überschreiben, wenn sich das Reading state geändert hat.

Anbei ein Vorschlag dazu als diff.

@Boris, Rudi: Könntet einer von Euch das prüfen und einchecken?

MfG Willi

--- fhem.pl (Revision 2193)

+++ fhem.pl (Arbeitskopie)

@@ -2705,11 +2705,11 @@

 setReadingsVal($$$$)

 {

   my ($hash,$rname,$val,$ts) = @_;

+  if($rname eq "state" && $hash->{READINGS}{$rname}{VAL} ne $val) {

+    $hash->{STATE} = $val;

+  }

   $hash->{READINGS}{$rname}{VAL} = $val;

   $hash->{READINGS}{$rname}{TIME} = $ts;

-  if($rname eq "state") {

-    $hash->{STATE} = $val;

-  }

 }

 

 sub

[Rudolf Koenig]

Hallo Willi,

> @Boris, Rudi: K�nntet einer von Euch das pr�fen und einchecken?

Eigentlich duerften Module wie dewpoint von diesem Attribut nicht betroffen
sein (am besten einstellbar), ich habe aber keine gute Idee, wie man das ohne
alles auf dem Kopf zu stellen realisiert -> Hab Dein Patch eingecheckt.

Gruss,
Rudi

[Willi]

Am Montag, 26. November 2012 18:06:17 UTC+1 schrieb Rudolf Koenig:

Eigentlich duerften Module wie dewpoint von diesem Attribut nicht betroffen
sein (am besten einstellbar), ich habe aber keine gute Idee, wie man das ohne
alles auf dem Kopf zu stellen realisiert

Hallo Rudi,

was meist Du mit Attribut? event-on-change-reading?

Wenn event-on-change-reading nicht gesetzt ist, läuft alles ohne Probleme, weil für jede Änderung eines Readings die entsprechende Events generiert werden. Dann bekommt dewpoint jede Änderung mit.

Ist allerdings event-on-change-reading gesetzt, werden nur noch Events für die angegebenen Reading generiert, deren Werte sich ändern. Damit bekommt dewpoint nur noch Events für die Änderungen mit. Wenn sich also nur die Temperatur ändert, gibt es kein Event für Humitity und dewpoint wird nicht angeliefert.

Daher habe ich jetzt (im Test) dies so geändert, dass dann das entsprechende Reading verwendet wird (natürlich nur wenn aktuell).

Eine Sonderbehandlung braucht man bei STATE. Bevor Du den Patch eingecheckt hast, hat das Reading state STATE überschrieben. Da STATE vorher mittels dewpoint manipuliert wurde, fehlt dann der Taupunkt, wenn STATE auch überschrieben wird, wenn sich das Reading state nicht ändert (denn dann bekommt das dewpoint ja nicht mit).

Das Reading state kann ich mittels dewpoint nicht manipulieren, weil die übrigen Module keinen Taupunkt schreiben und sich so die Werte jedesmal ändern würden. In diesem Fall würde für STATE jedesmal ein Event ausgelöst und jedesmal im Filelog geloggt, was ja so nicht gewünscht ist.

Es ist etwas blöd, dass sich dadurch das Reading state und STATE unterscheiden müssen, aber das geht bei der bisherigen Logik nicht anders.

Das ist leider der Nebeneffekt davon, dass dewpoint optional STATE manipulieren kann, damit dort der Taupunkt erscheint.

-> Hab Dein Patch eingecheckt. 

Danke. Damit läuft dann alles mit dewpoint korrekt auch bei Manipulation von STATE und gesetztem event-on-change-reading. 

Meine neue Version von dewpoint, die ich am Wochenende zum Test per PM an Chris gegeben habe und selbst teste, greift auch auf die jeweils fehlenden Werte (Temp oder Hum) durch Zugriff auf die entsprechenden Readings zu (sofern aktuell genug, was parametrisierbar ist). Damit funktioniert jetzt dewpoint mit event-on-change-reading sowie mit den Techno Sensoren TX3TH.

Ich möchte das noch ein paar Tage testen. Wenn alles wie bisher problemlos läuft, ändere ich dewpoint in einigen Tagen im SVN. Die Änderungen sind aufwärtskompatibel, so dass es keine Probleme geben sollte.

MfG Willi

[UliM]

Hi,
der Ursprung des Problems ist doch, dass dewpoint ein eigenes device ist, das seine Ausgabe aber auf den STATE von nicht-dewpoint-devices schreibt - durch Erweiterung des vom originären Modul platzierten Textes.
Es wurde im Zusammenhang mit floorplan mal diskutiert, dass man ein separates reading (noch namenlos, nennen wir's mal dispState) etablieren könnte.
Hintergrund war damals: mglw möchte ein Modul in floorplan ausführlichere Infos anzeigen als in fhemweb. Diskussion: https://groups.google.com/d/msg/fhem-developers/Q8-ecYj63rA/Urw0r2fiSbwJ

So ein Mechanismus könnte doch auch für dewpoint praktisch sein: readings->state auslesen, um dewpoint erweitern, auf readings->dispState schreiben.
Dikussionsstand seinerzeit war, dass die ausgebenden Module (v.a. FHEMWEB und FLOORPLAN) prüfen, ob readings->dispState vorliegt.  Falls ja, wird dieses in der Raum-Übersicht gezeigt, falls nein wird wie bisher defs->STATE angezeigt.

Hoffe ich erinnere mich korrekt.
Weiß nicht ob dieser Ansatz verfolgt werden soll?

Gruß, Uli

[Willi]

Am Montag, 26. November 2012 21:06:47 UTC+1 schrieb UliM:

Hi,
der Ursprung des Problems ist doch, dass dewpoint ein eigenes device ist, das seine Ausgabe aber auf den STATE von nicht-dewpoint-devices schreibt - durch Erweiterung des vom originären Modul platzierten Textes.

Das ist eine Option, die man derzeit nutzen kann, aber nicht muss.

Die normale Option ist ein eigenes Reading zu schreiben, welches dewpoint heisst. Das Überschreiben des STATE hatte ich eigentlich für mich geschrieben, weil ich es in der Übersicht praktisch finde. Anscheinend nutze nicht nur ich es.

 

Es wurde im Zusammenhang mit floorplan mal diskutiert, dass man ein separates reading (noch namenlos, nennen wir's mal dispState) etablieren könnte.
Hintergrund war damals: mglw möchte ein Modul in floorplan ausführlichere Infos anzeigen als in fhemweb. Diskussion: https://groups.google.com/d/msg/fhem-developers/Q8-ecYj63rA/Urw0r2fiSbwJ

So ein Mechanismus könnte doch auch für dewpoint praktisch sein: readings->state auslesen, um dewpoint erweitern, auf readings->dispState schreiben.
Dikussionsstand seinerzeit war, dass die ausgebenden Module (v.a. FHEMWEB und FLOORPLAN) prüfen, ob readings->dispState vorliegt.  Falls ja, wird dieses in der Raum-Übersicht gezeigt, falls nein wird wie bisher defs->STATE angezeigt.

Hoffe ich erinnere mich korrekt.
Weiß nicht ob dieser Ansatz verfolgt werden soll?

Ja, in modifizierter Firm. Schau mal in die Diskussion  unter FHEm developers "Ankündigung: neue STATE-Behandlung".

Hmm. Habe bisher nicht darüber nachgedacht, ob dies das Problem löst.

Kurz nachgedacht: Vermutlich wird es mit dewpoint nicht funktionieren. Der STATE wird durch readingsEndUpdate überschrieben (so ist der derzeitige Stand). Zu diesem Zeitpunkt ist aber durch dewpoint noch kein Reading dewpoint neu berechnet worden. dewpoint wird wie average erst durch die Events aufgerufen.

Folge wird sein, dass man nicht den aktuellen Taupunkt, sondern den vorherigen Taupunkt im STATE hat. Macht die Sache eher schlimmer als besser.

Ich sehe also nicht, dass dies das Problem mit STATE und Taupunkt im STATE löst. 

MfG Willi

[Martin Fischer]

Am Montag, 26. November 2012, 12:41:03 schrieb Willi:
> [...]

mal 'ne ganz andere überlegung dazu:

was spricht eigentlich dagegen, wenn die taupunkt berechnung _direkt_ in die
module verlegt wird, die temp / hum liefern?

abgesehen mal von dem dann redundanten code? das würde ich doch für sinnvoll
erachten..

oder um den redundanten code zu vermeiden, fangen wir mit "klassen" an, die in
einem extra modul FhemUtils/classes.pm o.ä. liegen, die _vor_ allen module
geladen werde müsste ;-)

gruss

[Rudolf Koenig]

> was spricht eigentlich dagegen, wenn die taupunkt berechnung _direkt_ in die
> module verlegt wird, die temp / hum liefern?

Es waere deutlich mehr Aufwand: man muesste jeden Modul-Autor ueberzeugen, die
Klasse zu verwenden. So ist dewpoint bzw. Willi unabhaengig, und man kann ohne
grosse Abstimmung zusaetzliche features spendieren. Je groesser fhem wird,
desto wichtiger wird das.

Nachteil: der Benutzer muss es bestellen. Allerdings weiss er dann auch, das er
es hat, und wozu.

[Willi]

Am Dienstag, 27. November 2012 21:42:19 UTC+1 schrieb Martin Fischer:

mal 'ne ganz andere überlegung dazu:

was spricht eigentlich dagegen, wenn die taupunkt berechnung _direkt_ in die
module verlegt wird, die temp / hum liefern?

Hallo Martin,

die Diskussion gab es schon, bevor ich dewpoint erstellt habe. Mein erster Ansatz war es in die Module reinzubringen. Ich hatte es zu diesem Zeitpunkt bei mir bereits in meinem Modulen (USBWX, OREGON, etc.) lokal bei mir.

Die meisten haben zu dieser Zeit die Berechnung des Taupunktes als überflüssig angesehen.

Rudi hat mir das Konzept des average vorgestellt und mich von den Vorzügen überzeugt.

Man muss nicht in jedes Modul dewpoint erneut einbauen. Neben dem Aufwand ist nicht zu vergessen, dass nicht alle Modul-Autoren dewpoint eingebaut hätten. Selbst jetzt bin ich mir nicht sicher, ob es alle einbauen würden.

So muss ich niemanden überzeugen es einzubauen und man kann zusätzliche Funktionalitäten bereitstellen wie fan und alarm.

Bis auf das Problem mit STATE gibt es bisher keine Probleme. Selbst wenn wir mal in den Zustand kommen, dass dewpoint aus Design-Gründen mit STATE nicht mehr funktionieren kann, kann man es mit zusätzlichem Reading dewpoint gut verwenden.

Grüße

Willi

[Martin Fischer]

hallo willi,

Am Dienstag, 27. November 2012, 13:25:49 schrieb Willi:
> [...]

> Man muss nicht in jedes Modul dewpoint erneut einbauen. Neben dem Aufwand
> ist nicht zu vergessen, dass nicht alle Modul-Autoren dewpoint eingebaut
> hätten. Selbst jetzt bin ich mir nicht sicher, ob es alle einbauen würden.

ich hab damit keine probleme.. es war nur ein spontaner vorschlag..

grüsse martin