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?
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?
was ergibt:
1+2+3x6=?
du würdest "offensichtlich" 36 behaupten. ;)
ne, ich behaupte 21 weil Punkt vor Strich 8)
Aber wenn Satzzeichen Leben retten können, wo hab ich denn die Klammer falsch gesetzt?
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
besten Dank - morgen früh werde ich berichten...Danke schonmal!
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 && ...)
if ($wday =~ /[1-5]/)
Danke für den Link und die Tipps, für morgen früh teste ich nun:
define Jalousie_02_rauf at *06:28:00 { if (!($we)) && Value ("JALOUSIE_AUTO") eq "on" { fhem("set Jalousie_02 on");; } }
Werde dann berichten :-)
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>
Zitatsyntax 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.
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.
ZitatDas 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.
Zitat von: rudolfkoenig am 03 September 2020, 09:21:32
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.
ZitatZ. 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.
Zitat von: rudolfkoenig am 03 September 2020, 10:30:23
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.
Zitatja, dann könnte man darüber nachdenken, solche Einstellungen als Default ins nächste Release aufzunehmen.
Bin nicht sicher, ob ich das richtig verstehe: perlSyntaxCheck ist die Voreinstellung seit FHEM 5.8
Zitat von: rudolfkoenig am 03 September 2020, 11:01:50
Bin nicht sicher, ob ich das richtig verstehe: perlSyntaxCheck ist die Voreinstellung seit FHEM 5.8
Dann muss er sie deaktiviert haben oder die CFG-Datei editiert haben ;)
Oder den Plan fuer den naechsten Tag kundgetan haben.
tatsächlich habe ich über edit files die config Datei editiert - mache ich aber öfter, bereits seit einiger Zeit, zumeist erfolgreich und immer mit der gebotenen Vorsicht :-)
Er hat Yehova gesagt! ;)
Jeder nur einen Stein! ::)