Gegenseitige "Verriegelung" zweier Dummy- Werte ...

[M_I_B]

Hallo liebe Leute,

ich steh mal wieder auf dem Schlauch
Ich möchte Werte aus zwei Dummys dahingehend verriegeln, das Wert A zwangsweise immer um X größer ist als Wert B, wenn ich z.B. Wert B verändere und der Abstand von A zu B unter X fällt. Ganz einfach... dachte ich zumindest... Irgendwie klappt das nicht...
Sende ich per Kommandozeile "set HZ_SOLL SP 77", so wird dieser Wert angenommen und auch z.B. im DropDown geändert. Nur via DOIF klappt das nicht.

Letztlich will ich erreichen, das HZ_SOLL:SP immer mindestens X größer ist als WW_SOLL:SP
Am "schönsten" wäre es, das eine Änderung von WW_SOLL:SP nach oben HZ_SOLL:SP nach oben mitschleppt und umgekehrt eine Änderung von WW_SOLL:SP nach unten WW_SOLL:SP mitschleppt.

Versuch 1 ohne Erfolg:

Code Auswählen Erweitern

define sp_lock DOIF ({([HZ_SOLL:SP] - [WW_SOLL:SP])} < 5) (set HZ_SOLL SP {([WW_SOLL:SP]+5)})
attr sp_lock do always
Versuch 2 ohne Erfolg:

Code Auswählen Erweitern

define sp_lock DOIF ([WW_SOLL:SP] >= {([HZ_SOLL:SP]-5)}) (set HZ_SOLL SP {([WW_SOLL:SP]+5)})
attr sp_lock do always

Die Dummys, in denen im Übrigen die korrekten Werte stehen, sehen so aus:

Code Auswählen Erweitern

define HZ_SOLL dummy
attr HZ_SOLL alias SOLL Heizung
attr HZ_SOLL group SOLL- Werte
attr HZ_SOLL readingList VL RL SP
attr HZ_SOLL room KG.Heizung
attr HZ_SOLL setList VL:40,42,44,46,48,50,52,54,56,58,60,62,64,66,68,70,72,74,76,78,80 RL:40,42,44,46,48,50,52,54,56,58,60,62,64,66,68,70,72,74,76,78,80 SP:40,42,44,46,48,50,52,54,56,58,60,62,64,66,68,70,72,74,76,78,80
attr HZ_SOLL webCmd VL:RL:SP

define WW_SOLL dummy
attr WW_SOLL alias SOLL Warmwasser
attr WW_SOLL group SOLL- Werte
attr WW_SOLL readingList VL RL SP
attr WW_SOLL room KG.Heizung
attr WW_SOLL setList VL:40,42,44,46,48,50,52,54,56,58,60,62,64,66,68,70,72,74,76,78,80 RL:40,42,44,46,48,50,52,54,56,58,60,62,64,66,68,70,72,74,76,78,80 SP:40,42,44,46,48,50,52,54,56,58,60,62,64,66,68,70,72,74,76,78,80
attr WW_SOLL webCmd VL:RL:SP

[automatisierer]

also mal ehrlich, mit Commandref lesen bekommst du das auch alleine hin!

[Damian]

In der Bedingung sind die geschweiften Klammern falsch, Prioritäten werden mit runden Klammern erreicht.

[M_I_B]

@automatisierer: nicht hilfreich ^^

@Damian: Verstehe ich nicht. Ich hatte mich an "http://fhem.de/commandref_DE.html#DOIF_Berechnungen_im_Ausfuehrungsteil" gehalten. Da steht:

Code Auswählen Erweitern

Berechnungen können in geschweiften Klammern erfolgen. Aus Kompatibilitätsgründen, muss die Berechnung mit einer runden Klammer beginnen. Innerhalb der Perlberechnung können Readings, Stati oder Internals wie gewohnt in eckigen Klammern angegeben werden.

Anwendungsbeispiel: Es soll ein Vorgabewert aus zwei verschiedenen Readings ermittelt werden und an das set Kommando übergeben werden:

define di_average DOIF ([08:00]) (set TH_Modul desired {([default:temperature]+[outdoor:temperature])/2})
attr di_average do always

Ich habe mich genau an das Beispiel gehalten. Ist ja dem Meinen sehr ähnlich. Hatte es auch mal, wie von Dir vorgeschlagen, ohne die {} versucht und auch mal ohne (), aber dann tauchte die Berechnung selbst im Dummy auf und nicht das Ergebnis.
So wie ich dsa verstehe, muss eine Berechnung in die {} gepackt werden und aus Kompatibilitätsgründen die Rechnung selbst noch in (). Oder interpretiere ich das falsch? Wenn ja, an welcher Stelle?
Wie ich schon sagte: Ich stehe da im Moment voll auf'm Schlauch ...

EDIT: Ausgeschlafen und noch mal geschaut... Damian, jetzt hab ich geschnallt was Du meintest. Finde ich aber doof, das Berechnungen im Bedingungsteil und Ausführungsteil unterschiedlich ausgeführt werden müssen ...

Ok, also in die eine Richtung (manuell WW hoch) funktioniert das jetzt. Sobald ich das auch in die andere Richtung machen will (manuell HZ runter), habe ich eine Loop gebaut... uncool Ich muss also irgendwie feststellen, welcher Wert manuell verändert wurde und damit das entsprechende DOIF triggern. Also WENN WW man. hoch DANN Abstand HZ anpassen WENN kleiner 5 resp. WENN HZ man. runter DANN Abstand WW anpassen WENN kleiner 5. Die Frage ist nur, wie ich das anstellen soll/muss?
Vielleicht gibt es da ja auch schon eine andere Möglichkeit, meine Aufgabe eleganter zu lösen, die ich nur nicht kenne?

Nicht ganz so kritisch aber ein unschöner Störfaktor: Ich habe derzeit die Einstellung der Temperatur in 2° Schritten definiert. Mit einem Abstand von derzeit 5° spring der natürlich auf einen nicht existierenden Zwischenwert. Also muss ich entweder darauf achten, das der "Zwangsabstand" immer 2 oder ein Vielfaches davon ist, oder aber die Datenreihe in 1° Schritten definieren. Letzteres generiert aber eine unschöne, extrem lange Zeile. Gibt es für ...

Code Auswählen Erweitern

attr HZ_SOLL setList VL:40,42,44,46,48,50,52,54,56,58,60,62,64,66,68,70,72,74,76,78,80 RL:40,42,44,46,48,50,52,54,56,58,60,62,64,66,68,70,72,74,76,78,80 SP:40,42,44,46,48,50,52,54,56,58,60,62,64,66,68,70,72,74,76,78,80 ... nicht etwas wie z.B. ...

Code Auswählen Erweitern

attr HZ_SOLL setList VL:{40,80,1} RL:{40,80,1} SP:{40,80,1} ... wobei damit "[Startwert], [Endwert], [Schrittweite]" gemeint ist ?

[ht]

In Bezug auf

Finde ich aber doof, das Berechnungen im Bedingungsteil und Ausführungsteil unterschiedlich ausgeführt werden müssen ...,

und zu Deinen Ausführungen im anderen Thread, dass Du keine Erklärung gekriegt hast:

Ich, auch eher noch Anfänger, deute die Command Ref da so: In beiden Fällen gilt die übliche Reihenfolge für die Operatoren, und wenn Du die überschreiben willst, dann nimmst Du (). Aber: in den Klammern für die Bedingung ist von vornherein klar, dass da ein Ausdruck steht, d.h. da gelten die Perl-Regeln. Im Ausführungsteil kommt ein fhem-Befehl, und da kann man erst einmal nicht rechnen. Ich vermute, dass Damian deshalb die Berechnung syntaktisch abgetrennt hat, sozusagen der Hinweis von Dir an das Modul, hier kommt jetzt etwas, was nicht ein normaler Teil des fhem-Befehls ist. Und dafür hat er, weil sonst in fhem Perl-Teile auch mit {} gekennzeichnet werden, auch hier die {} gewählt.

@Damian: ich hoffe, das stimmt so einigermaßen;)

Ich muss also irgendwie feststellen, welcher Wert manuell verändert wurde und damit das entsprechende DOIF triggern

Genau: der Wert, der manuell geändert wird, soll triggern, der jeweils andere Wert soll nur abgefragt werden, aber eben nicht triggern. Das geht mit DOIF und ist in der Command Ref beschrieben.

Grüße,
Volker

[M_I_B]

... guten Morgen Volker,

und Dank für die erneut recht ausführliche Erklärung! Auch das habe ich (glaube ich) verstanden soweit. Was ich aber mit ...

EDIT: Ausgeschlafen und noch mal geschaut... Damian, jetzt hab ich geschnallt was Du meintest. Finde ich aber doof, das Berechnungen im Bedingungsteil und Ausführungsteil unterschiedlich ausgeführt werden müssen ...

... meinte ist, das ich ja im Bedingungsteil anders klammern muss wie im Ausführungsteil, ganz unabhängig von der darin befindlichen Rechnung. Ich bin in Anlehnung an andere Hoch-/Scriptsprachen (Basic, PHP, ...) davon ausgegangen, das  (zu klammernde) Berechnungen im Bedingungs- und Ausführungsteil identisch aufzubauen sind.

Noch mal als Beispiel:

Code Auswählen Erweitern

define bla DOIF ([A1] >= ([A2]-5)) (set blub peng {(A3]+6)})
Im Bedingungsteil muss ich die Berechnung ausschließlich in (...) packen. Das muss ich im Ausführungsteil auch, aber zusätzlich auch noch das Ganze in {...}
Ich bin halt davon ausgegangen, das Berechnungen "vorne" und "hinten" identisch zu definieren sind, also entweder auf beiden Seiten {(...)}, (...) oder auch {...}.  Auf Grund dieser meiner Annahme konnte ich also machen was ich wollte; es hat nie funktioniert. Und darauf bezog sich auch meine Frage an Damian im Anschluss an die nach Ausschlafen erlangte Erkenntnis, warum das denn unterschiedlich ist resp. sein muss; ich bin halt neugierig und möchte gerne die Gründe wissen, warum etwas mir unlogisch erscheinendes so und nicht anders sein muss...

[Damian]

In einem "lebenden" System wie FHEM, hat alles eine Historie und lässt sich durchaus erklären, wenn man die Historie kennt.

Beim DOIF ist die Bedingung etwas von mir Erschaffenes, es ist im Grunde 100 % Perl und noch etwas mehr, nämlich Dinge, die man in eckige Klammern packt. Da eine Bedingung sinnvollerweise einer if-Bedingung entspricht, gibt es dort im Normalfall keine geschweiften Klammern.

Der Ausführungsteil von DOIF ist in erster Linie 100 % FHEM und noch etwas mehr. Dieses etwas mehr muss aber kompatibel sein zu FHEM, daher habe ich {(..)} für Berechnungen, die vor der Ausführung eines FHEM-Befehls vom DOIF-Modul vorgenommen werden, definiert. Nur runde oder nur geschweifte Klammern zu verwenden ging nicht, weil diese in diversen FHEM-Befehlen benutzt werden, daher die Kombination aus {(, die es sonst nirgendwo gab.

Inzwischen wurde aber auch diese Syntax {(..)} für Berechnungen beim set, bzw. setreading-Befehl nachgebildet, sodass sie ebenfalls außerhalb von DOIF funktioniert, allerdings nur bei set bzw. setreading.

Soviel zur Vorgeschichte.

Gruß

Damian

[M_I_B]

... moin Damian,

vielen Dank für Deine ausführliche Erklärung dazu. Jetzt kann ich auch in etwa nachvollziehen, warum im Bedingungsteil anders gerechnet werden muss als im Ausführungsteil. Solch Wissen über die Zusammenhänge, welche diese "Unlogik" erklären, fehlt im Allgemeinen ... Ich denke, auf diesen Umstand sollte noch mal im WiKi und/oder ComRef nebst Beispielen hingewiesen werden ...