AT mit IF Bedingung wertet die Bedingung nicht aus

stratege-0815 · 20 Juni 2020, 22:36:58

Hallo zusammen,
ich habe ein ganz einfaches AT für den Rollladen meiner Wohnzimmertüre, ich möchte es mit dem homatic drei Wege Sensor kombinieren. Der sensor gibt die Werte : open, close, tilted aus. Nun soll der Rolladen nicht runter fahren wenn "open" gesetzt ist oder nur wenn "closed" oder "tilted".

*22:32 { if ( "Wohnzimmertueregriff" ne "open" ) { fhem("set Rolladen_Wohnzimmertuere down") }}

Der Rolladen fährt stur um 22:32 runter, was mache ich falsch?
Gruß
Jan

MadMax-FHEM · 20 Juni 2020, 22:40:57

Woher soll denn das if wissen WAS in Wohnzimmertueregriff steht!?

Entweder Value("Wohnzimmertueregriff") wenn es in STATE steht oder besser ReadingsVal("Wohnzimmertueregriff","ReadingName","Ersatzwert") und dann vergleichen...

Wenn es im state stehen sollte z.B.:

Code Auswählen


*22:32 { if ( ReadingsVal("Wohnzimmertueregriff","state","") ne "open" ) { fhem("set Rolladen_Wohnzimmertuere down") }}

Gruß, Joachim

betateilchen · 21 Juni 2020, 00:44:26

Randbemerkung:

Wenn "Wohnzimmertürgriff" ein Türgriffsensor sein sollte, der Homematic "spricht", sollte man in diesem Konstrukt auf keinen Fall state auf ungleich irgendwas prüfen, weil in state (HM-spezifisch) durchaus noch andere Inhalte vorhanden sein können, bei denen der Rolladen nicht reagieren soll. Ansonsten kann es passieren, dass zum Beispiel bei einem um 22:32 zufällig existierenden MISSING_ACK der Rolladen zugeht.

MadMax-FHEM · 21 Juni 2020, 00:59:51

Würde ich nicht mal (nur) auf Homematic beschränken...
ZWave verhält sich ähnlich...

Ist vermutlich generell ne gute Idee auf das zu prüfen was man haben will (wenn's mehr als einzwas ist: es gibt ja ||

)...
...bzw. auch "Gegenprüfen" (also elsif) statt nur: else...

Kommen manchmal auch "unerwartete" Aktionen um der Ecke...

Gruß, Joachim

stratege-0815 · 24 Juni 2020, 12:37:14

Danke für euer Input, ja es macht natürlich Sinn direkt die beiden Werte mit ODER abzufragen.

Leider komme ich hier immer noch nicht weiter, beide von Joachim vorgeschlagenen Schreibweisen habe ich ausprobiert. Es passiert dann aber einfach gar nichts, d.h. der Rolladen fährt nie zu. Egal wie die Griffstellung ist.

Momentan sieht das AT jetzt so aus:

Code Auswählen

*22:32 { if ( Value("Wohnzimmertueregriff") eq "closed" ) { fhem("set Rolladen_Wohnzimmertuere down") }}

auch die Variante:

Code Auswählen

*22:32 { if ( ReadingsVal("Wohnzimmertueregriff","state","") eq "closed" ) { fhem("set Rolladen_Wohnzimmertuere down") }}

bewirkte nichts. Dabei habe ich noch nicht einmal die ODER Erweiterung für die zweite Bedingung eingebaut.

Grundsätzlich funktioniert aber das Auslesen des STATE Wertes aus den Griffsensor, dies habe ich mit einem kleinen notify getestet - "wenn Griff offen schalte Licht ein"

Gerade fehlt mir irgendwie der Ansatz wo das Problem liegt.

MadMax-FHEM · 24 Juni 2020, 12:45:13

Und:

Code Auswählen


set Rolladen_Wohnzimmertuere down

In das FhemWeb-cmd eingegeben fährt den Rollladen auch runter!?

UND: um 22:32 war auch das Reading state von Wohnzimmertueregriff auf closed!?

Ändere doch mal die Uhrzeit und poste ein zeitlich dazu passendes list des Wohnzimmertueregriff...

EDIT:

Zitat von: stratege-0815 am 24 Juni 2020, 12:37:14
Grundsätzlich funktioniert aber das Auslesen des STATE Wertes aus den Griffsensor, dies habe ich mit einem kleinen notify getestet - "wenn Griff offen schalte Licht ein"

poste doch mal ein list von dem notify das geht...

Gruß, Joachim

stratege-0815 · 25 Juni 2020, 11:33:15

Hallo Joachim,
nur ein kurzes Zwischenfeedback,

ja

Code Auswählen

set Rolladen_Wohnzimmertuere down

fährt den Rolladen runter.

Ja, um 22:32 war das Reading state von Wohnzimmertueregriff auf closed. Ich habe auch mit der Zeit variiert und nachmittags Tests gemacht.
Ich werde da noch einmal wiederholen und die list hier posten.

Wird vermutlich noch etwas dauern, aber spätestens am Wochende passieren.
(zur Zeit habe ich corona-Homeoffcei und zwei Tage telefondienst)

Das Test notify hatte ich zwar schon wieder gelöscht, aber das ist ja schnell wiederhergestellt und ein list generiert.

Könnte es sein das mein "varieren mit der Zeit" irgendwie das Problem verursacht hat? Ich hatte die Zeit dann so eingestellt dass innerhalb der nächsten 5 Minuten mein Testfall eintrat. Braucht das AT längeren Vorlauf?

Danke schon mal,
Gruß
Jan

MadMax-FHEM · 25 Juni 2020, 11:45:31

Nein, at wirk sofort...

Du brauchst auch nicht mit der Zeit "spielen", mich hätte eben nur das at und ein zeitlich passendes list von Wohnzimmertueregriff interessiert

Du kannst ein at auch "jederzeit" auslösen: set atName execNow (oder so ähnlich)

EDIT: und wenn das:

Code Auswählen

set Rolladen_Wohnzimmertuere down geht, dann sollte das:

Code Auswählen

{ fhem("set Rolladen_Wohnzimmertuere down") } auch gehen...

Du kannst auch Logausgaben einbauen, so in etwa:

Code Auswählen


define atTest at *22:32 { my $State = ReadingsVal("Wohnzimmertueregriff","state","n.a.");; if ( $State eq "closed" ) { fhem("set Rolladen_Wohnzimmertuere down") } Log3(undef,1,"atTest State: $State")}

Mache ich eigentlich IMMER!
Weil nur zu glauben/denken wie etwas ist/sein müsste MUSS halt NICHT so sein

Und normalerweise packe ich "längere Konstrukte" in eine Sub...
-> https://wiki.fhem.de/wiki/99_myUtils_anlegen
Gut hier ist es nicht wirklich "lang" aber habe ich mir angewöhnt: Konfiguration und Programmierung (wo es [sinnvoll] geht) zu trennen...

(drum tue ich mich auch mit DOIF so "schwer", weil da ist irgendwie [für mich] alles in einem "vermischt"

)

Gruß, Joachim

stratege-0815 · 26 Juni 2020, 22:43:07

Hier nochmal eine kleine Zwischeninformation, ich hatte bisher nur den CUL und den Dreiwegesensor eingerichtet. Die beiden direkt gepairt.

Funktioniert auch bisher gut - bis auf den seltsamen Effekt mit dem AT.
Im FHEM log habe ich jetzt irre viele Funkdatagramme gefunden die der CUL empfängt aber nichts mit anfangen kann. Ich hatte bisher keine VCCU eingerichtet. Das hole ich jetzt nach um das FHEM log sauberer zu bekommen. Vielleicht hat das ja auch einen positiven Effekt auf meine AT Thematik. Muss dann morgen das pairing mal auflösen und mit der VCCU neu machen. Mal sehen ob sich das auch in dieser Thematik hier auswirkt.

MadMax-FHEM · 26 Juni 2020, 22:56:14

Zitat
Muss dann morgen das pairing mal auflösen und mit der VCCU neu machen.

Warum NEU machen!?

Da musst du (normalerweise) überhaupt NICHTS neu machen!

(aber: wie du meinst/willst

)

EDIT: hast du die Sachen mit Logging mal ausprobiert!? Poste doch mal was dann (mit dem Logging) im fhem Log zu sehen ist beim AT (wie geschrieben: es geht auch execNow)...

EDIT: hast du hminfo definiert!? Das zeigt dir an, ob etwas bzgl. Homematic (CUL_HM) "eigenartig"/"fehlerhaft" ist... (und noch einiges mehr) https://wiki.fhem.de/wiki/HomeMatic_HMInfo

Gruß, Joachim

stratege-0815 · 28 Juni 2020, 23:38:26

So, endlich funktioniert es.

Über das set execNow habe ich herausgefunden dass selbst ein einfachster Befehl nicht funktioniert. Keine Ahnung wo in diesem AT der Wurm drin war. Irgendwo ein Leerzeichen oder so. Ich habe das AT komplett gelöscht und wieder angelegt und dann nach und nach wieder aufgebaut. Jetzt funktioniert es mit diesem Code

Code Auswählen

*22:32:00 { if (( ReadingsVal("Wohnzimmertueregriff","state","") eq "closed" ) || ( ReadingsVal("Wohnzimmertueregriff","state","") eq "tilted" )) { fhem("set Rolladen_Wohnzimmertuere down") }}

Danke allen Input Gebern