ReadingsVal arbeitet nicht wie erwartet

[ricger]

Liebe Forumsgemeinde,

bislang habe ich mich nur lesend hier aufgehalten und manchen wertvollen Tipp erhalten. Vielen Dank dafür!
Im Moment stehe ich bei einer kleinen Aufgabe vor einem Rätsel und wollte fragen, ob ihr schon ähliches beobachten konntet (oder gar eine Lösung auf Lager habt).

Szenario
Ich betreibe Homematic HM-CC-RT-DN Thermostatventile über ein CUL an FHEM.
Nun will ich aktuelle Werte über ReadingsVal auslesen und weiterverarbeiten.

Lösungsansatz
In der fhem.cfg habe ich die Zeilen

define TestDummy dummy
{ my $d = ReadingsVal("Heizung_Bad","desired-temp","Err");; fhem("set TestDummy $d");; }

angelegt, um den Wert von "desired-temp" in der Variable TestDummy abzulegen. Das Ergebnis ist allerdings, dass die Variable TestDummy auf "Err" gesetzt wird und nicht auf das Reading "desired-temp". Dies sollte laut Doku dann auftreten, wenn das Reading für das angegebene Gerät nicht definiert ist.
Bei Eingabe von {ReadingsVal("Heizung_Bad","desired-temp","Err")} in der FHEM-Eingabezeile erhalte ich das erwartete Ergebnis.

Ich poste in der Homematic-Gruppe, da das Auslesen von Readings anderer Geräte wie erwartet funktioniert und nur die Thermostate dieses Verhalten zeigen.
Gibt es bei den Thermostaten noch etwas zu beachten oder stehe ich einfach mal wieder auf dem Schlauch?

Vielen Dank für Eure Tipps!

[martinp876]

schon klar. FHEM führt beim Start erst die defines aus, dann werden die Attribute gesetzt. Zum schluss werden die Readings aus dem statefile rückgeschrieben.
Und danach beginnt das Arbeite und das setzen der Readings aufgrund von ereignissen.

Dein Dummy ist dann schon  erledigt - es wird bei der Definition gesetzt, wenn noch nicht einmal die Attribute vorhanden sind.

Wann soll es den berechnet werden? Du solltest TestDummy durch ein  Notify geschreiben lassen.

Was ist eigentlich dein Ziel. Warum der Aufwand, ein Reading in ein anderes Reading zu kopieren?

Gruss Martin

[ricger]

Danke für die schnelle Antwort! Ich hoffe, ich hab' alles kapiert. 
Das notify wollte ich schon probieren, ich dachte nur, so sei es einfacher.
Zudem fürchte ich unerwünschte Wechselwirkungen (Zirkeldefinition) wenn ich durch ein notify einen Wert einstellen lasse, der selbst wieder Grundlage für die Regelung des das notify auslösende Ereignis ist.

Sinn der Aktion ist, dass ich die gewünschten Solltemperaturen der Thermostate gerne über Dummies setzen würde. Das funktioniert auch.
Mit dem kleinen Schönheitsfehler, dass die Werte nach dem Neustart des FHEM nicht den aktuell im Thermostat eingestellten Wert haben und deswegen die Thermostate auf einen Defaultwert geregelt werden.

Im Regelbetrieb sollen sich die Thermostate also auf die Dummies einregeln.
Bei der Initialisierung sollen die Dummies hingegen den Wert der Thermostate übernehmen.

[martinp876]

Zudem fürchte ich unerwünschte Wechselwirkungen (Zirkeldefinition)

du solltest einen Dummy haben, den du mit dem notify änderst.

Sinn der Aktion ist, dass ich die gewünschten Solltemperaturen der Thermostate gerne über Dummies setzen würde

verstehe den vorteil nicht - aber jedem, was er will.

Im Regelbetrieb sollen sich die Thermostate also auf die Dummies einregeln

warum willst du dummies andern, so dass diese die RTs ändern? Hat das einen Vorteil?

Du könntest übrigens auch das Attribut "userReading" probieren. Ist eigentlich eine art nofity für alle Device-änderungen

Gruss Martin

[Martin Schmid]

Hallo ricger,
wenn Du die Werte für Dummies nur nach dem Systemstart setzen willst, mußt Du ein Notify auf global:INITIALIZED setzen:

Code Auswählen Erweitern

define <meinNotify> notify global:INITIALIZED set <Dummie.....>

Das wird dann nach jedem Systemstart aufgerufen.

Viele Grüße
Martin Schmid

[martinp876]

schon - aber da sollte man sich klar sein, was Sache ist - da stehen bestenfalls die Werte aus dem Statefile - wenn die drin stehen. Das erhebt nur einen bedingten Anspruch auf Aktualität. Eigentlich sollte man warten, bis sich das Device gemeldet hat - das ist dann der aktuellen Wert.
Mit fehlt der übergreifende Zusammenhang und das eigentliche Ziel.

[ricger]

Vielleicht denke ich zu kompliziert?

Ich versuche mein Ziel nochmal anders zu formulieren:

Ich will die Temperatur der Termostate in Abhängigkeit von verschiedenen Parametern steuern (Homestatus, manuelle Eingriffe, Zeiten etc...).

Aus den Parametern ergibt sich zunächst eine gewünschte Zieltemperatur, die ich in einem zweiten Schritt auf die Thermostate übertragen will.
Die Aufteilung in zwei Schritte soll die Übertragungssicherheit erhöhen:

• Im ersten Schritt wird der Solltemperatur-Dummy auf den gewünschten Wert gesetzt. Das funktioniert zuverlässig, da die Verarbeitung FHEM-intern bleibt.
• Im zweiten Schritt werden die Werte aus dem Solltemperatur-Dummy auf die unterschiedlichen Thermostate, bzw. Thermostatgruppen verteilt
• Jetzt kann ich prüfen, ob die Werte den "richtigen", im Solltemperatur-Dummy abgespeicherten Wert haben, und ggfs. nachsteuern.

Da der Solltemperatur-Dummy die verbindliche Instanz ist, an der sich die Steuerung der Thermostate orientiert, will ich sinnvolle Startwerte definieren.

Das notify global:INITIALIZED sollte doch genau das machen, was ich möchte: (Danke, Martin Schmid!)
define NTFY_Temp_Bad notify Heizung_Bad {my $d = ReadingsVal("Heizung_Bad","desired-temp","10");; fhem("set Heizung_Bad_Solltemperatur $d");; }


Wenn ich notify global:INITIALIZED richtig verstanden habe, dann wird das Ereignis ausgelöst, wenn die Initialisierung beendet ist und daher sinnvolle Werte ausgelesen werden können.

[Thorsten Pferdekaemper]

Hi,

Wenn ich notify global:INITIALIZED richtig verstanden habe, dann wird das Ereignis ausgelöst, wenn die Initialisierung beendet ist und daher sinnvolle Werte ausgelesen werden können.

Ich glaube, was Martin meint ist folgendes: Bei INITIALIZED ist nur das Statefile eingelesen, aber Du hast nicht unbedingt ein Reading vom Thermostat. Beispiel: Der Thermostat steht auf 20° und FHEM wird runtergefahren. Dann fummelt jemand am Rad rum und stellt die Temperatur auf 22°. Jetzt startet FHEM wieder. Bei INITIALIZED wird dann desired-temp auf 20° stehen. 22° kommen nach spätestens drei Minuten (oder so), wenn der RT das nächste mal sendet.
Das stimmt aber nur, wenn FHEM sauber runterfährt. Bei Stromausfall steht der Wert von irgendwann im Statefile. (Glaube ich zumindest.) D.h. Du kannst genauso gut irgend einen sinnvollen Wert am Anfang setzen.

Wie wär's damit: Bei der Definition ein "Still Unknown" oder so in Dein Dummy-Feld schreiben. Dazu ein notify auf desired-temp vom RT, welches zwei Dinge tut: Den Wert dahin kopieren, wo Du ihn hinhaben willst und zweitens sich selbst (das notify) löschen.

Gruß,
  Thorsten

[justme1968]

statt für jedes device einen zusätzlichen dummy zu haben ist es sehr viel übersichtlicher mit setreading jeweils ein eigenes zusätzliches reading im device selber zu erzeugen.

diese readings (so wie alle anderen auch) werden bei save und jedem sauberen neustart von fhem automatisch gespeichert und sind nach dem start wieder vorhanden.

ich vermute mal du möchtest auch eigentlich nicht die soll temperatur bei jedem start mit der desired-temp überschreiben sondern nur wenn es noch keine soll temperatur gibt

vielleicht magst du dir mal diesen thread hier (http://forum.fhem.de/index.php/topic,19126.msg128934.html#msg128934) und das letzte beispiel auf der readingsGroup seite im wiki anschauen.

das macht etwas das in die gleiche richtung geht: mit einer readingsGroup kann über zwei icons die wunsch temperatur
interaktiv in 0.5 grad schritten eingestellt werden und 3 sekunden nach der letzten änderung wird dieser wert dann als desired-temp gesetzt. dazu wird ein eigenes reading desired-new in jedem device verwendet. die initialisierung mit global:INITILIAZED und das abwarten und prüfen ob das setzen funktioniert hat will ich da auch noch einbauen.

gruss
  andre

[martinp876]

Wenn ich notify global:INITIALIZED richtig verstanden habe, dann wird das Ereignis ausgelöst, wenn die Initialisierung beendet ist und daher sinnvolle Werte ausgelesen werden können.

es wird ausgeführt wenn FHEM alles aus files gelesen hat, was zu lesen war. Wenn die desired-temp im statefile war bekommst du diese. Wenn das statefile diese nicht beinhaltet eben nicht. In jedem Fall ist es nicht der Wert aus dem Device.

Was würde ich machen:

den sollwert kannst du auch in einem Reading im RT speichern. Readings darf man definieren wie man will

Code Auswählen Erweitern

setreading <rt_Clima> desired-temp-soll <wert>
das spart den Dummy, man sieht die Werte auch gleich nebeneinander
Jetzt noch ein notify, dass soll und ist vergleicht.

Code Auswählen Erweitern

define tempCheck notify .*desired-temp {\
my $t = ReadingsVal($NAME,"desired-temp-soll","");;\
if(ReadingsVal($NAME,"desired-temp","" ne $t){\
fhem "set $NAME desired-temp $t"}}

Tipfehler bitte selbst entfernen. Ist auch nur eine Idee. Temp einstellen mit setreading ... Gibt sicher noch varianten

Gruss Martin

[frank]

hallo martin,

den sollwert kannst du auch in einem Reading im RT speichern. Readings darf man definieren wie man will

Code Auswählen Erweitern

setreading <rt_Clima> desired-temp-soll <wert>

das ist ja eine geniale methode.
doch was muss ich tun, um ein reading wieder zu entfernen?
ein "set clear readings" ist in dem modul, wo ich das reading erzeugt habe, nicht freigeschaltet!

gruss frank

[justme1968]

mit deletereading

gruss
  andre

[frank]

hallo andre,

so spät noch so schnelle reaktionen!
klappt bestens. danke!

gruss frank