[gelöst] Notify mit UND Verknüpfung

[theotherhalf]

Guten Morgen,
ich versuche schon eine Weile ein bedingtes Setzen einer Variable zu realisieren, aber komme nicht so recht weiter.
Im Grunde geht es darum den Status meiner Heizungstherme aus 3 Variablen abzuleiten:
1. Gasventil
2. Umwälzpumpe
3. Umschaltventil (Warmwasserbetrieb/Heizungsbetrieb)
Wenn Ventil "on" und Pumpe "on" sowie Umschaltventil auf "100" sind, dann bereitet die Therme warmes Wasser.
Das Ergebnis soll in ein Dummy "Vaillant_Therme_Warmwasserbetrieb"geschrieben werden.
Es gibt mehrere Möglichkeiten, wobei ich mich für ein Notify entschieden habe.
Folgenden Code habe ich testweise in Benutzung, bekomme aber als state immer nur aktiv, obwohl die Therme nichts macht.

Code Auswählen Erweitern

define test_Warmwasserbetrieb notify (Gasventil_Therme:on|Stellung_Umschaltventil:100|Umwaelzpumpe_Therme:on) { if( Value("Gasventil_Therme") eq "on" && Value("Stellung_Umschaltventil") eq "100"  && Value("Umwaelzpumpe_Therme") eq "on" )  {fhem ("set Vaillant_Therme _Warmwasserbetrieb Aktiv") ;; } else {fhem  ("set Vaillant_Therme _Warmwasserbetrieb Inaktiv");;  } }

[MadMax-FHEM]

Ich würde von der Verwendung von Value abraten!!

Value "frägt" das INTERNAL!! STATE ab!
NICHT das Reading state!

Manchmal/meist ist es dasselbe ABER: z.B. stateFormat können das ändern... Und dann liefert Value eben was "anderes"!

Dann:

set Vaillant_Therme _Warmwasserbetrieb Aktiv

Ist da nicht ein LEERZEICHEN zu viel?

Weil entweder:

set Device Value

oder

setreading Device Reading Value

Bei dir steht:

set Device NochWas Value

Ob es das ist/war und ob das alles ist: keine Ahnung

EDIT: die runden Klammern um die RegExen können weg (schaden aber nicht?). Löst denn das notify aus? Also evtl. mal eine Logausgabe einbauen (nur um sicher zu gehen): Log3(undef, 1, "Notify hat getriggert $EVENT")

Gruß, Joachim

[Beta-User]

Mal abgesehen von den berechtigten Hinweisen von MadMax-FHEM: ist denn da ein Trigger im notify für den "Inactive"-Fall...?

Weitere Hinweise:
- das "dummy-Geschubse" ist mir hochgradig suspekt, und ich vermute, da sind noch mehr (überflüssige?) dummy beteiligt, sonst ginge das mit Value() nicht...
- hier käme evtl. auch eine structure in Frage (mit entsprechendem mapping für die "100")

[Wernieman]

Ist das eigentlich direkt aus der Config oder aus FHEM kopiert? Mich wundern gerade die ;; .. also2 Stück ..

[theotherhalf]

Ah, korrekt! Da ist ein Leerzeichen zu viel. Habe ich entfernt.

Im Device muss ich  auf das Reading schauen, welches den gleichen Namen hat wie das Device selbst. Das ist dann STATE?
state ist tatsächlich anders.

[theotherhalf]

Mal abgesehen von den berechtigten Hinweisen von MadMax-FHEM: ist denn da ein Trigger im notify für den "Inactive"-Fall...?

Weitere Hinweise:
- das "dummy-Geschubse" ist mir hochgradig suspekt, und ich vermute, da sind noch mehr (überflüssige?) dummy beteiligt, sonst ginge das mit Value() nicht...
- hier käme evtl. auch eine structure in Frage (mit entsprechendem mapping für die "100")

Meine Intention war, wenn sich eine der drei Werte auf Zielwerte verändern, wird das Notify ausgelöst. Und dann im Folgenden eben abgeprüft ob alle 3 Signale entsprechend sind um den Dummy zu setzen oder eben nicht.
Es ist nur ein Dummy verwendet, da ich den Status in einem Floorplan darstellen möchte.

[theotherhalf]

Ist das eigentlich direkt aus der Config oder aus FHEM kopiert? Mich wundern gerade die ;; .. also2 Stück ..

Es ist eine Kopie dessen, was ich später über die Command Leiste eingebe.

[Beta-User]

Meine Intention war, wenn sich eine der drei Werte auf Zielwerte verändern, wird das Notify ausgelöst. Und dann im Folgenden eben abgeprüft ob alle 3 Signale entsprechend sind um den Dummy zu setzen oder eben nicht.
Es ist nur ein Dummy verwendet, da ich den Status in einem Floorplan darstellen möchte.

Dann muss halt auch ein entsprechender trigger kommen, sonst bleibt das halt uU. länger so als erwartet.

Für Darstellungsfragen in FHEMWEB/floorplan kann man readingsProxy oder readingsGroup verwenden. Im Ergebnis sollte das einfacher sein.

Ansonsten solltest du mal in der commandref nach ReadingsVal(), Value() und stateFormat suchen, dann wird das ggf. klarer, was du ggf. ändern mußt. Ansonsten können wir ohne Infos (aka: list) nicht viel weiterhelfen.

[theotherhalf]

Dann muss halt auch ein entsprechender trigger kommen, sonst bleibt das halt uU. länger so als erwartet.

Für Darstellungsfragen in FHEMWEB/floorplan kann man readingsProxy oder readingsGroup verwenden. Im Ergebnis sollte das einfacher sein.

Ansonsten solltest du mal in der commandref nach ReadingsVal(), Value() und stateFormat suchen, dann wird das ggf. klarer, was du ggf. ändern mußt. Ansonsten können wir ohne Infos (aka: list) nicht viel weiterhelfen.

Der Trigger kommt ja, da das System aktiv ist. Der Status der Heizung ändert sich ja ca. alle 60 Minuten. Aber wenn ich diesen Code eingebe, dann ist der Status sofort "Aktiv" und verbleibt da auch, auch wenn die 3 Signale nicht den Status darstellen.
Die 3 Signale habe ich auch als ReadingProxy, da hierdurch die Darstellung im Floorplan vereinfacht wurden. Du meinst wenn ich darauf verweise ist es einfacher? Es ist doch ein und dasselbe Signal?

[Beta-User]

Also: Wenn erst eines der Geräte (vereinfacht) "on" wird, setzt das notify "Aktiv". Soweit so gut. Wenn dann eines oder zwei (oder alle drei) Geräte "off" werden, passiert nichts. Erst wenn wieder ein "on"-Trigger kommt wird nochmal geprüft. Vermutlich ist das so nicht beabsichtigt? Wenn nicht, muss das notify auch auf "off"-Trigger reagieren. Genau das würde eine "structure" auch tun, übrigens...

Wenn du die drei Signale als readingsProxy angelegt hast, die nur für die Darstellung im floorplan gedacht sind, spricht das dafür, die ggf. zu löschen und das ganze in einer readingsGroup zusammenzufassen und ggf. via notify (oder uU. alternativ via userReadings) einfach ein weiteres Reading an deinem "Heizungsdevice" zu setzen. Aber nochmal:

können wir ohne Infos (aka: list) nicht viel weiterhelfen.

Beachte also bitte einfach die "Bevor du postest"-Hinweise.

[MadMax-FHEM]

Im Device muss ich  auf das Reading schauen, welches den gleichen Namen hat wie das Device selbst. Das ist dann STATE?
state ist tatsächlich anders.

STATE: INTERNAL ! Bei Änderung KEIN Event -> das kannst du "abfragen" mit Value() oder InternalVal(...) Wird beeinflusst durch stateFormat (ansonsten ist es meist gleich state)

state: Reading Bei Änderung eigentlich meist auch ein Event -> Eventhandler (notify, DOIF, FileLog, ...) gehen. Abfrage per ReadingsVal(...) oder wenn du sicher nur Ziffern willst ReadingsNum(...)

Gruß, Joachim

[theotherhalf]

Ich muss gestehen, das ich selten mit meiner Konfig in FHEM spiele, von daher ist es immer sehr holprig.
Vielleicht ist es mit DOIF etwas weniger komplex, habe mich da auch etwas eingelesen, aber obwohl es einfach scheint, komme ich leider nicht zum Ziel.

Es ist doch recht simpel: Wenn die 3 Variablen (Pumpe, Gasventil und Umschaltventil) eine bestimmte Stellung haben, dann soll ein Dummy gesetzt werden. Falls eine der Variablen nicht aktiv ist, dann soll der Dummy auf OFF gesetzt werden. Vielleicht habe ich da auch ein Brett vor dem Kopf?
Mein Ansatz ist der folgende:

Code Auswählen Erweitern

define Vaillant_Warmwasserbereitung DOIF ([Gasventil_Therme_von_Vaillant:"Gasventil_Therme on"] and [Umwaelzpumpe_Therme_von_Vaillant:"Umwaelzpumpe_Therme on"] and [Stellung_Umschaltventil_von_Vaillant:"100"]) (set Vaillant_Therme_Warmwasserbetrieb on) DOELSE (set Vaillant_Therme_Warmwasserbetrieb off)

Auch wenn alle drei Variablen die Bedingung erfüllen (sie tauchen auch im Event Monitor so auf), so wird der Dummy nicht auf "on" gesetzt.
cmd2 ist die ganze Zeit auf 2, daher scheint die Bedingung nicht erfüllt zu sein. Was übersehe ich hier? Liegt es in der Abfolge der Events begründet?
Setze ich in die Bedingung nur eine der drei Variablen ein, dann klappt es.

[Beta-User]

Bin raus. Sehe keinen Sinn in weiteren Hilfsangeboten, wenn Infos nicht geliefert werden, aber ohne Not neue Fässer aufgemacht werden.

[MadMax-FHEM]

Ich muss gestehen, das ich selten mit meiner Konfig in FHEM spiele, von daher ist es immer sehr holprig.
Vielleicht ist es mit DOIF etwas weniger komplex, habe mich da auch etwas eingelesen, aber obwohl es einfach scheint, komme ich leider nicht zum Ziel.

Es ist doch recht simpel: Wenn die 3 Variablen (Pumpe, Gasventil und Umschaltventil) eine bestimmte Stellung haben, dann soll ein Dummy gesetzt werden. Falls eine der Variablen nicht aktiv ist, dann soll der Dummy auf OFF gesetzt werden. Vielleicht habe ich da auch ein Brett vor dem Kopf?
Mein Ansatz ist der folgende:

Code Auswählen Erweitern

define Vaillant_Warmwasserbereitung DOIF ([Gasventil_Therme_von_Vaillant:"Gasventil_Therme on"] and [Umwaelzpumpe_Therme_von_Vaillant:"Umwaelzpumpe_Therme on"] and [Stellung_Umschaltventil_von_Vaillant:"100"]) (set Vaillant_Therme_Warmwasserbetrieb on) DOELSE (set Vaillant_Therme_Warmwasserbetrieb off)

Auch wenn alle drei Variablen die Bedingung erfüllen (sie tauchen auch im Event Monitor so auf), so wird der Dummy nicht auf "on" gesetzt.
cmd2 ist die ganze Zeit auf 2, daher scheint die Bedingung nicht erfüllt zu sein. Was übersehe ich hier? Liegt es in der Abfolge der Events begründet?
Setze ich in die Bedingung nur eine der drei Variablen ein, dann klappt es.

Warum plötzlich DOIF?

commandref zu DOIF gelesen?
Verglichen mit notify?

Was ist/scheint da einfacher?

Ich nutze (genau auch deswegen) kein DOIF aber ich denke die Syntax ist falsch...
...und bei DOIF gibt es auch Trigger (genau wie bei notify und anderen Eventhandlern) und die Möglichkeit "nur" abzufragen.

Selbst wenn du deine Syntax (von der ich annehme, dass sie nicht passt) korrigierst, dann sind alle "Bedingungen" triggernd und vermutlich niemals "gleichzeitig" wahr (das kommt bei DOIF dazu)...

Warum nicht einach das notify vernünftig machen und gut?

Dazu Ausschnitt aus dem Eventmonitor, wenn alles was relevant ist mal passiert ist.
Und list der beteiligten Devices -> damit man die Readings etc. sehen kann...

Mit dem Eventmonitor kann man sich auch notify/DOIF/FileLog/... anlegen lassen...
...ja nur zu einem Event aber man kann sich ja für jedes Ereignis ein notify anlegen lassen und dann mit RegEx-ODER kombinieren...
Und man darf halt (wie Beta-User schon gleich und du ja jetzt zuletzt selber angegeben hast) halt auch den Fall "und sonst" nicht "vergessen"...

Mal angenommen die trigger stimmen, dann evtl. so in der Art:

Code Auswählen Erweitern


define test_Warmwasserbetrieb notify Gasventil_Therme:.*|Stellung_Umschaltventil:.*|Umwaelzpumpe_Therme:.* { if( Value("Gasventil_Therme") eq "on" && Value("Stellung_Umschaltventil") eq "100"  && Value("Umwaelzpumpe_Therme") eq "on" )  {fhem ("set Vaillant_Therme_Warmwasserbetrieb Aktiv") ;; } else {fhem  ("set Vaillant_Therme_Warmwasserbetrieb Inaktiv");;  } }


Ob nun .* als RegEx oder ob es weiter vernünftig einzuschränken geht, dazu fehlen die Infos...

Allerdings triggert das notify nun deutlich öfter (ob zu oft musst du prüfen) und prüft ja jedes mal, ob der gewünschte Zustand vorhanden und wenn ja: Aktiv und sonst eben Inaktiv...
...so soll es doch sein?

EDIT: die Abfrage auf GENAU 100 hat halt Potential für "Probleme", wenn der Wert öfter mal schwankt -> Aktiv/Inaktiv/Aktiv/Inaktiv/Aktiv/Inaktiv... Sieht für mich eher aus als sollte da eine Hysterese rein. Aber das kannst nur du wissen...

Wichtg, generell: möglichst Events im System soweit einschränken wie möglich. Also nur so viele Events (wenn machbar) wie nötig sind, damit notify/DOIF/... und Logging funktioniert...

Stichwort: event-on-change-reading und "Verwandte"...

Da ich Perl immer (auch kleine Sachen) in eine myUtils auslagere, bin ich bei den Strichpunkten nicht sicher.
Wobei die vermutlich sogar alle weg können...

Ich hätte ja auch auf ReadingsVal/ReadingsNum umgbaut aber ohne list kenne ich ja das entscheidende Reading nicht bzw. könnte "state" annehmen aber das muss ja nicht, siehe Anmerkung stateFormat und Value()...

Wenn du bei DOIF bleiben willst: da bin ich (leider) raus.

Gruß, Joachim

[Damian]

Ich muss gestehen, das ich selten mit meiner Konfig in FHEM spiele, von daher ist es immer sehr holprig.
Vielleicht ist es mit DOIF etwas weniger komplex, habe mich da auch etwas eingelesen, aber obwohl es einfach scheint, komme ich leider nicht zum Ziel.

Es ist doch recht simpel: Wenn die 3 Variablen (Pumpe, Gasventil und Umschaltventil) eine bestimmte Stellung haben, dann soll ein Dummy gesetzt werden. Falls eine der Variablen nicht aktiv ist, dann soll der Dummy auf OFF gesetzt werden. Vielleicht habe ich da auch ein Brett vor dem Kopf?
Mein Ansatz ist der folgende:

Code Auswählen Erweitern

define Vaillant_Warmwasserbereitung DOIF ([Gasventil_Therme_von_Vaillant:"Gasventil_Therme on"] and [Umwaelzpumpe_Therme_von_Vaillant:"Umwaelzpumpe_Therme on"] and [Stellung_Umschaltventil_von_Vaillant:"100"]) (set Vaillant_Therme_Warmwasserbetrieb on) DOELSE (set Vaillant_Therme_Warmwasserbetrieb off)

Auch wenn alle drei Variablen die Bedingung erfüllen (sie tauchen auch im Event Monitor so auf), so wird der Dummy nicht auf "on" gesetzt.
cmd2 ist die ganze Zeit auf 2, daher scheint die Bedingung nicht erfüllt zu sein. Was übersehe ich hier? Liegt es in der Abfolge der Events begründet?
Setze ich in die Bedingung nur eine der drei Variablen ein, dann klappt es.

Du musst schon die Zustände (Readings) abfragen und nicht die Events:

Code Auswählen Erweitern

define Vaillant_Warmwasserbereitung DOIF ([Gasventil_Therme:state] eq "on" and [Umwaelzpumpe_Therme:state] eq "on" and [Stellung_Umschaltventil:state] eq "100") (set Vaillant_Therme_Warmwasserbetrieb on) DOELSE (set Vaillant_Therme_Warmwasserbetrieb off)