Denkfehler in UND & ODER Verknüfung?

[dieoma]

Nabend zusammen,

gestern Abend habe ich eine leicht geänderte Zeitschaltung für eine Jalousie eingestellt, jedoch heute morgen festgestellt das sie nicht funktioniert hat. Kann mir jemand einen Tipp geben warum fhem die Syntax nicht mag?

Code Auswählen Erweitern

define Jalousie_02_rauf at *06:28:00 { if (($wday == 1) || ($wday == 2) || ($wday == 3) || ($wday == 4) || ($wday == 5) && Value ("JALOUSIE_AUTO") eq "on" )) { fhem("set Jalousie_02 on") }}
Plan war offensichtlich das die Jalousie um 6:28 rauf (on) fährt wenn der Wochentag 1-5 ist und ein Reading aus der Tablet UI auf "on" steht - tut sie aber leider nicht Habe ich irgendeine Klammer falsch gesetzt?

[frank]

was ergibt:

1+2+3x6=?

du würdest "offensichtlich" 36 behaupten. 

[dieoma]

ne, ich behaupte 21 weil Punkt vor Strich 
Aber wenn Satzzeichen Leben retten können, wo hab ich denn die Klammer falsch gesetzt?

[frank]

genau so gilt && vor ||.

also eine klammer um alle 5 oder-elemente, damit das und-element für alle oder-elemente gilt.

(1+2+3)x6=36

[dieoma]

besten Dank - morgen früh werde ich berichten...Danke schonmal!

[KyleK]

wday 1-5 ist doch wochentags, wenn ich mich nicht irre, könnte man den ersten Teil der Bedingung dann nicht ersetzen durch !($we)?
Ein Vor- (oder Nachteil, je nachdem was du erwartest): $we wird an Feiertagen wahr wenn du eine holiday-Datei verwendest. -> https://wiki.fhem.de/wiki/Wochenende,_Feiertage_und_Schulferien

Andere Alternative: if($wday >= 1 && $wday <= 5 && ...)

[crusader]

if ($wday =~ /[1-5]/)

[dieoma]

Danke für den Link und die Tipps, für morgen früh teste ich nun:

Code Auswählen Erweitern

define Jalousie_02_rauf at *06:28:00 { if (!($we)) && Value ("JALOUSIE_AUTO") eq "on" { fhem("set Jalousie_02 on");; } }
Werde dann berichten

[rudolfkoenig]

Code Auswählen Erweitern

fhem> { if (!($we)) && Value ("JALOUSIE_AUTO") eq "on" { fhem("set Jalousie_02 on");; } }
syntax error at (eval 1607913) line 1, near ") &&"
syntax error at (eval 1607913) line 1, near "} }"

fhem> { if (!$we && Value("JALOUSIE_AUTO") eq "on") { fhem("set Jalousie_02 on") } }

fhem>


[crusader]

syntax error at (eval 1607913) line 1, near ") &&"

Früher, als man noch den Stapel Lochkarten mit dem eingestanzten Fortran-Programm abgeben musste, um dann drei Tage später einen Computerausdruck mit dem Ergebnis "Syntaxfehler inZeile ..." aus dem Postfach zu holen, haben wir uns noch mehr Mühe gegeben.

[dieoma]

Wenn der Meister selbst ruft gehorchen sogar die Jalosien aus der Ferne - danke Rudolf, hattest natürlich recht!
@Crusader: Das mit den Lochkarten stimmt, aber außer in Paderborn, München oder Göttingen findet man kaum noch welche. Das Problem zeigt mir aber auch, warum es einen "Trend" in Richtung Blocky, NodeRed etc gibt: einfache Syntaxfehler werden leichter verziehen und es verbreitert die Nutzerbasis für Einsteiger...
Besten dAnk an alle und einen sonnigen Abend.

[rudolfkoenig]

Das Problem zeigt mir aber auch, warum es einen "Trend" in Richtung Blocky, NodeRed etc gibt: einfache Syntaxfehler werden leichter verziehen und es verbreitert die Nutzerbasis für Einsteiger...

Dagegen hat sich FHEM bisher erfolgreich gewehrt.
Bin auch nicht ganz sicher, ob das mein Ziel sein sollte.

[Damian]

Dagegen hat sich FHEM bisher erfolgreich gewehrt.
Bin auch nicht ganz sicher, ob das mein Ziel sein sollte.

Auch wenn man mit programmiertem Code in einem Editor am weitesten kommt und die maximale Flexibilität bewahrt, können Hilfestellungen bei der Definition sehr Hilfreich sein. Eine einfache Farbhervorhebung wie im Codemirror oder auch gewisse Checks im Modul können schon gute Dienste leisten. Z. B. würde DOIF eine solche fehlerhafte Definition erst gar nicht zulassen und mit einer Fehlermeldung quittieren, da es einen Klammerncheck bei der Definition macht.

[rudolfkoenig]

Z. B. würde DOIF eine solche fehlerhafte Definition erst gar nicht zulassen und mit einer Fehlermeldung quittieren, da es einen Klammerncheck bei der Definition macht.

Gilt auch fuer at/notify, wenn man den Code im DEF/modify Abschnitt in der FHEMWEB Detailansicht aendert.
Die Voreinstellung "attr global perlSyntaxCheck 1" macht es moeglich.

[Damian]

Gilt auch fuer at/notify, wenn man den Code im DEF/modify Abschnitt in der FHEMWEB Detailansicht aendert.
Die Voreinstellung "attr global perlSyntaxCheck 1" macht es moeglich.

ja, dann könnte man darüber nachdenken, solche Einstellungen als Default ins nächste Release aufzunehmen.

Auch über die Voreinstellung für Codemirror, dessen Fenster jetzt besser anpassbar ist, könnte man andiskutieren - dort werden Klammerebenen ebenfalls visualisiert.