[gelöst] wie werden Bedingungen abgehandelt

[Damian]

Mmh, dann bin ich da, wo ich seit 10 Stunden nicht hin will 

Aber wenn du das sagst, gibt es wahrscheinlich keinen galanteren Weg

Danke!

Vielleicht gibt es den in einem DOIF. Die Frage ist nur: Wirst du ihn in einem Jahr noch mal nachvollziehen können, wenn eine Änderung oder Erweiterung ansteht?

[holle75]

... wohl war. Aber man denkt immer "das muß doch auch sexier gehen" ... und wahrscheinlich macht man sich unnötig das Leben schwer.
"Best practice" lernt man eben nur anhand von Beispielen (oder Fragen)

[Damian]

... wohl war. Aber man denkt immer "das muß doch auch sexier gehen" ... und wahrscheinlich macht man sich unnötig das Leben schwer.
"Best practice" lernt man eben nur anhand von Beispielen (oder Fragen)

Ja, ich habe DOIF (FHEM-Modul) für typische einfache Automatisierungsfälle programmiert (alle Beispiele in der Commandref sind einfach gestrickt). Es verführt dazu immer mehr Komplexität, in einem Modul abzubilden. Dafür ist der FHEM-Modus mit seiner flachen Hierarchie (if-elsif) nicht gut geeignet. Für komplexere Probleme muss man entweder mehrere Module definieren oder eben "strukturiert programmieren", dafür habe ich den DOIF-Perl-Modus entwickelt.

[holle75]

Früher oder später schaue ich mir den perl-Modus mal an ... wahrscheinlich großartig, aber wohl doch eher etwas für Menschen, die sowieso schon Perl kennen/können, denke ich. DOIF als FHEM-Modul war/ist für mich (und wahrscheinlich viele) unter anderem der Grund, mich näher mit FHEM zu beschäftigen.... und ohne DOIF würden viele Perl-Unwissende wahrscheinlich die Segel streichen, bevor die Genialität von FHEM erkannt wird.

Was wollte ich sagen? Danke für DOIF und Danke für den Support! ... auch an die anderen üblichen Verdächtigen.

[amenomade]

Wie wäre es mit:

Code Auswählen Erweitern

([11:00-14:55] and [Container_TEMPFEUCHTESENSOR:humidity] < 70 and [Container_TEMPFEUCHTESENSOR:temperature] > 5)
     (set ZirkusOben_TRIGGER_Luefter on)
DOELSEIF ( [ZirkusOben_TASTER_PIR:state] =~ "press")
     (set ZirkusOben_TRIGGER_Luefter on)
DOELSE
     (set ZirkusOben_TRIGGER_Luefter off)

wait 60:0:300 und keinem anderen attr?
Wenn die Wetterparameter nicht mehr stimmen, würde der Lüfter 5mn länger an bleiben, aber das würde de facto so eine Art Hysterese einbauen, wenn humidity oder temperature schwanken. Oder sehe ich das falsch?

[holle75]

so würde

[ZirkusOben_TASTER_PIR:state] =~ "press"  -> der Bewegungsmelder

Bedingung 1 beenden auch wenn die Zeit noch nicht abgelaufen ist.

Und Bedingung 2 würde sich bei erneuter Bewegung nicht verlängern.

Schätz ich mal so ...

[amenomade]

so würde

[ZirkusOben_TASTER_PIR:state] =~ "press"  -> der Bewegungsmelder

Bedingung 1 beenden auch wenn die Zeit noch nicht abgelaufen ist.

Warum denn? So lange eine Bedingung wahr bleibt, passiert nichts.

Und Bedingung 2 würde sich bei erneuter Bewegung nicht verlängern.

Schätz ich mal so ...

Bei erneuter Bewegung, wenn inzwischen Bedingung2 nicht mehr wahr war, wird er wieder auf Bedingung2 kommen, oder? Das einzige Nachteil ist, dass jedes Mal wiederholt "set ... on" geschickt wird

[holle75]

Warum denn? So lange eine Bedingung wahr bleibt, passiert nichts.

Das war ja mein Problem. Sobald Bedingung 2 getriggert wird, wird Bedingung 1 nicht mehr "geprüft" (wenn dort nicht das selbe device/event verbaut ist). Ich hatte es auch so gedacht verstanden zu haben, schön von links oben nach rechts unten ... und wo die Bedingung passt oder passend bleibt, wird ausgeführt oder belassen. Ist aber nicht so.

[amenomade]

Ahja stimmt. Dann lass den Bewegungsmelder in Bedingung 1 systematisch mitwirken:

Code Auswählen Erweitern

([11:00-14:55] and [Container_TEMPFEUCHTESENSOR:humidity] < 70 and [Container_TEMPFEUCHTESENSOR:temperature] > 5 and [ZirkusOben_TASTER_PIR:state] =~ ".*")
     (set ZirkusOben_TRIGGER_Luefter on)
DOELSEIF ( [ZirkusOben_TASTER_PIR:state] =~ "press")
     (set ZirkusOben_TRIGGER_Luefter on)
DOELSE
     (set ZirkusOben_TRIGGER_Luefter off)

wait 60:0:300
Bleibt die Frage für Bedingung 2: wenn keine Bewegung, geht der Bewegungsmelder auf einen anderen Status, so dass bei erneurter Bewegung die Bedingung wieder getriggert wird?

[holle75]

Mmh, gute Idee für Bedingung 1. Probier ich.

Bleibt die Frage für Bedingung 2: wenn keine Bewegung, geht der Bewegungsmelder auf einen anderen Status, so dass bei erneurter Bewegung die Bedingung wieder getriggert wird?

Der Bewegungsmelder behält seinen status bis zu erneuter Bewegung. Ohne Bewegung keine Statusänderung. Ohne resetwait müßte Bedingung 2 aber erstmal die 300 seks abarbeiten um in Bedingung 3 zu kommen und erst dann könnte erneut getriggert -> Bedingung 2 wieder eintreten. Denke ich. Öfteres An/Aus wäre halbhübsch.
Aber hier könnte man ja mit den bereits versuchten attr arbeiten. In der Theorie müßte ich in meine DEF nur das

and [ZirkusOben_TASTER_PIR:state] =~ ".*"

in Bedingung 1 einbauen.

So:

Code Auswählen Erweitern

([11:00-15:00] and [Container_TEMPFEUCHTESENSOR:humidity] < 70 and [Container_TEMPFEUCHTESENSOR:temperature] > 5) (set ZirkusOben_TRIGGER_Luefter on)
DOELSEIF ([?$SELF:state] ne "cmd_1" and ([?ZirkusOben_TRIGGER_Luefter] eq "off" or [?$SELF:cmd] eq "2.1") and [ZirkusOben_TASTER_PIR:state] =~ "press") (set ZirkusOben_TRIGGER_Luefter on) (set ZirkusOben_TRIGGER_Luefter off)
DOELSE (set ZirkusOben_TRIGGER_Luefter off)

mit:

Code Auswählen Erweitern


do         resetwait
group      System
initialize initialized
repeatsame 1:0:1
wait       60:0,300:60 (die 60 sind für den Neustart damit der Lüfter nicht vor der Initialisierung geschaltet wird - HMWIRED)

[Per]

Das einzige Nachteil ist, dass jedes Mal wiederholt "set ... on" geschickt wird

Dafür gibt es FILTER, wenn einen das wirklich stört.