2-Kanal Aktor (HM-LC-Sw2PBU-FM) interne Kanäle nutzen

[Pfriemler]

Gegen die Dauerschleife ist ein wenig Hirnschmalz und ein paar mehr Abfragen nötig ...

[Otto123]

Hi,

Meinst du sowas?

Code Auswählen Erweitern

defmod nty_Aktor1 notify Aktor[2,3]:on|off set Aktor1:FILTER=STATE!=$EVENT $EVENT

Wenn Aktor 2 oder Aktor 3 geschaltet werden, schaltet Aktor 1 immer mit

Gruß Otto

[Pfriemler]

So ähnlich. Wir hatten das schon mal... find's nicht.

Versuch (nach Ottos Idee):

Code Auswählen Erweitern

define toggleBathroomLights notify br_Light_Sw_[01|02]:on|off set br_Light_Sw_0.*:FILTER=STATE!=$EVENT $EVENT


edit: funktioniert so nicht, siehe ein paar Beiträge weiter unten.

Vorausgesetzt, es gibt nicht mehr als zwei "br_Light_Sw_0x" (mit x=1 oder 2)

Klartext: Wenn einer der beiden Schalter auf on oder off geschaltet wird, dann setze alle Geräte, die mit "br_Light_Sw_0" beginnen und deren Status NICHT dem des Schaltzustandes entsprechen, auf den Schaltzustand.

[sherwood]

Das funktioniert, allerdings nur über Webcommands. An der Schaltern selbst klappt das nicht. Nur wenn self02 (br_Light_Sw_02) gedrückt wird, geht br_Light_Sw_01 mit an. Alles andere wird ignoriert. Noch komischer, nach ca. 1 Min. schaltet sich alles wieder aus.

Mit der Regex [01|02] oder [01,02] kommt fhem auch nicht klar, sprich notify reagiert nicht.

Ich habe das so angepasst:

Code Auswählen Erweitern

define toggleBathroomLights notify br_Light_Sw_0.*:on|off set br_Light_Sw_0.*:FILTER=STATE!=$EVENT $EVENT


Was ich nicht ganz verstehe ist der Code:

Code Auswählen Erweitern

FILTER=STATE!=$EVENT $EVENT
Was passiert hier genau?

[Pfriemler]

Die Anpassung ist ok und sollte auch klappen. Das mit Minute verstehe ich nicht. Hm.
FILTER= definiert einen Filter, den die ausgewählten (...*) Geräte erfüllen müssrn
STATE!= bedeutet deren Status ungleich ist zu ...
$EVENT ist das auslösende Event.
Gesetzt, das Event ist "on", also einer der beiden Schalter wurde (irgendwie) eingeschaltet. Das löst das notify aus, welches nun alle Schalter, die in das Regex passen und nicht auf "on" stehen, auf on setzt. So ähnlich schrieb ich das ja schon.
Jetzt wäre spannend zu erfahren wo der Denkfehler liegt.
Am Kanal 2 ist nich zufällig eine automatische Abschaltung nach einer Minute definiert?

[Otto123]

In Ergänzung noch zum nachlesen von devspec

Für die Stunden rings ums Fest. 

Schöne Feiertage
Otto

[sherwood]

Nein, ein Timer ist nicht definiert.
Mein Perl Code funktioniert ja auch ohne das die Lampen wieder ausgehen. Es scheint eher an den FHEM Befehlen zu liegen.

[Pfriemler]

hm ... mir kommen da gerade ein paar Ideen, ich glaube ich muss da erst was ausprobieren...
edit: ich denke, mit den Regex kann das so nicht stimmen. Also die Langfassung.
mit Dummys funktioniert das schonmal:

Code Auswählen Erweitern

defmod toggleBathroomLights notify br_Light_Sw_0.*:on|br_Light_Sw_0.*:off set br_Light_Sw_0.*:FILTER=STATE!=$EVENT $EVENT
parktisch ohne Verzögerung.

Jetzt grabble ich nochmal einen Aktor heraus und checke das...
edit2: funktioniert hier auch an einem HM-LC-Sw2-FM. Beim Schalten über Webinterface knapp 1 Sekunde, beim Schalter am Gerät 3-4 Sekunden Verzögerung.
Aber stabil, beidseits, völlig egal wo geschalter wird - der geschalteten Kanal folgt der andere brav nach. So wie das soll.

edit3: Und wenn man die richtigen Klammern verwendet, klappt es mit den Alternativen sowohl im Trigger als auch im set:

Code Auswählen Erweitern

defmod toggleBathroomLights notify br_Light_Sw_0(1|2):(on|off) set br_Light_Sw_0(1|2):FILTER=STATE!=$EVENT $EVENT

Diese Variante hat den Vorteil, dass man hier die zu überwachenden und die (evtl.) zu schaltenden Aktoren wirklich sauber einzeln deklarieren kann.

[sherwood]

Das sieht gut aus.

Funktioniert auch direkt am Schalter.
Ich würde sagen das ist ein Eintrag im Wiki wert.

Vielen Dank


P.S.
Mit einem set des Attributs "R-statusInfoMinDly" auf "0.5" für beide Aktoren, ist auch die Verzögerung etwas kürzer. Bei mir zwischen 1-2 Sek. am Gerät.

[Pfriemler]

Mit einem set des Attributs "R-statusInfoMinDly" auf "0.5" für beide Aktoren, ist auch die Verzögerung etwas kürzer. Bei mir zwischen 1-2 Sek. am Gerät.

Richtig, denn das beschleunigt die Rückmeldung des lokal betätigten Aktors um 1,5 Sekunden (default ist 2s).
R-statusInfoRandom kann man auch noch verkürzen, dann wird die Verzögerung zudem etwas stabiler.

edit: Ich habe im Beitrag zwei darüber noch die "Kurzfassung" mit korrekten Alternativen (Variante1|Variante2) eingepflegt, die ebenfalls hervorragend funktioniert.
Man muss nur die richtigen Klammern nehmen ...