Hauptmenü

Frage zu DOELSEIF

Begonnen von limats, 04 Juni 2016, 16:16:44

Vorheriges Thema - Nächstes Thema

limats

Hallo zusammen,

ich hab folgendes DOIF für meine Markisensteuerung:


define di_Markisenanforderung DOIF ([Rain] eq "rain")
    (set Markisenanforderung hoch)
DOELSEIF
([Wintergarten:temperature] < 22 or
[wunderground:solarRadiation] < 250)
    (set Markisenanforderung hoch)
DOELSE
    (set Markisenanforderung runter)


Heute hat es seit 11:00 Uhr geregnet. Um 11:30 ist die Temperatur über 22 Grad gestiegen. Da ist die Markise runter - trotz Regen.
Ich verstehe nicht ganz, wieso. Durch den Regen trifft doch eigentlich der DOIF-Zweig zu. Ich dachte, dann würde er die weiteren Zweige gar nicht mehr auswerten.

Gruß
Leo
Fhem auf BBB:
HM-CFG-USB für div. HM-Sensoren, CUL+WMBUS für EnergyCam, Nanocul für IT, Arduino Mega 2560 als 1-wire-Gateway und für div. digitale Ein-/Ausgänge, Volkszähler-USB-IR-Lesekopf mit SMLUSB, Solarsteuerung über VBUS

CoolTux

Ein list des DOIFs könnte zeigen wieso er runter gefahren ist.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

igami

Warum fasst du die ersten beiden Zweige nicht noch zusammen?
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

Icinger

Um 11 Uhr hat das reading "rain" ausgelöst....

Um 11:30 war die Temp höher, also hat logischerweise der DOELSE ausgelöst. In diesem prüfst du ja nicht wirklich, ob es immer noch regnet.

Eigentlich ganz logisch.

lg, Stefan
Verwende deine Zeit nicht mit Erklärungen. Die Menschen hören (lesen) nur, was sie hören (lesen) wollen. (c) Paulo Coelho

CoolTux

Aber es hat doch noch geregnet. Geprüft wird von rechts nach links. Und wenn Regen noch gilt dann bleibt doch der state auf cmd1. Oder übersehe ich da was?
Das DOELSE gilt doch erst wenn die anderen beiden nicht gelten.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Icinger

Es wird nur dann geprüft, ob [1] stimmt, wenn dieses Reading grade eben triggert.

Wenn [2] triggert, wird [1] nicht geprüft.
Verwende deine Zeit nicht mit Erklärungen. Die Menschen hören (lesen) nur, was sie hören (lesen) wollen. (c) Paulo Coelho

CoolTux

Ah ok. Hatte ich wohl falsch verstanden. Danke Dir
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

automatisierer

Ich würde sagen, dass ganze DOIF ist ein wenig unglücklich formuliert...

define di_Markisenanforderung DOIF
([Rain] ne "rain" and ([Wintergarten:temperature] > 22 or [wunderground:solarRadiation] > 250)) (set Markisenanforderung runter)
DOELSE
(set Markisenanforderung hoch)


limats

Hallo zusammen,

ist ja Wahnsinn, wie schnell hier Antworten kommen.
@automatisierer: Was ich euch vorenthalten hab, ist das Attribut wait, das auf 0:1200:1200 steht. Es soll also bei Regen sofort hochgefahren werden. Runterfahren bei Trockenheit und Reaktionen auf Temperatur und Sonne nur mit 20 min Verzögerung. Deshalb meine Aufteilung.
Fhem auf BBB:
HM-CFG-USB für div. HM-Sensoren, CUL+WMBUS für EnergyCam, Nanocul für IT, Arduino Mega 2560 als 1-wire-Gateway und für div. digitale Ein-/Ausgänge, Volkszähler-USB-IR-Lesekopf mit SMLUSB, Solarsteuerung über VBUS

automatisierer

wäre es nicht sinvoller das wait auf -300:1200:1200 zu setzen?

dann fährt die Markise schon 5 Minuten bevor es regnet ein...

automatisierer

keiner lacht?  ???


dann machs halt so:

define di_Markisenanforderung DOIF
([Rain] eq "rain") (set Markisenanforderung hoch)
DOELSEIF
([Rain] ne "rain" and ([Wintergarten:temperature] > 22 or [wunderground:solarRadiation] > 250)) (set Markisenanforderung runter)
DOELSE
(set Markisenanforderung hoch)


das ist dann auch wieder mit deinem wait kompatibel und fährt auch nicht runter wenns regnet...



limats

Danke. So geht's.

Wenn hier schon die Kompetenz vor Ort ist. Ein weiteres Problem mit einem anderen DOIF :


define di_Markise DOIF ([Markisenanforderung] eq "hoch")
    (set Markise pct 100)
DOELSEIF
([Markisenanforderung] eq "runter" and
[twilight:azimuth] > 110 and
[twilight:azimuth] < 190)
    (set Markise pct 50)
DOELSEIF
([Markisenanforderung] eq "runter" and
[twilight:azimuth] >= 190 and
[twilight:elevation] > 8 and
[wintergarten_schiebetuere] eq "open")
    (set Markise pct 37)
DOELSEIF
([Markisenanforderung] eq "runter" and
[twilight:azimuth] >= 190 and
[twilight:elevation] > 8 and
[wintergarten_schiebetuere] eq "closed")
    (set Markise pct 0)
DOELSE
    (set Markise pct 100)


Bis zu einem Azimuth von 110 soll die Markise nie runterfahren. Bei Azimuth zwischen 110 und 190 soll die Markise auf 50%. Bei Azimuth größer 190 soll sie ganz runter. Aber nur, wenn die Schiebetür zu ist. Bei offener Tür soll sie bei 37% stehen bleiben, damit man noch reinkommt.
Hier hab ich das Problem, dass bei Azimuth zwischen 110 und 190 das Öffnen oder Schließen der Tür die Markise hochfahren lässt.
Ich hab jetzt verstanden, dass das daran liegt, dass der erste DOELSEIF Pfad ignoriert wird, weil er durch die Tür nicht getriggert wird. Wie kriege ich hier jetzt am elegantesten ein "Tür eq egal" rein?
Wenn jemand eine elegante Möglichkeit sieht, die Problemstellung einfacher (zB. mit nur einem DOIF) zu lösen, nur her damit. Mir ist keine einfachere Lösung eingefallen, die auf das Wetter zeitverzögert, auf das Öffnen der Tür aber sofort reagiert.

Gruß
Leo

PS: das mit der negativen Wartezeit wär ne feine Sache. :-)
Fhem auf BBB:
HM-CFG-USB für div. HM-Sensoren, CUL+WMBUS für EnergyCam, Nanocul für IT, Arduino Mega 2560 als 1-wire-Gateway und für div. digitale Ein-/Ausgänge, Volkszähler-USB-IR-Lesekopf mit SMLUSB, Solarsteuerung über VBUS

CoolTux


[?wintergarten_schiebetuere] eq "open")
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Per

#13
Zitat von: limats am 04 Juni 2016, 23:57:24
Wenn jemand eine elegante Möglichkeit sieht, die Problemstellung einfacher (zB. mit nur einem DOIF) zu lösen, nur her damit.
Ob es "einfacher" oder "eleganter" wird, wenn du alles in ein DOIF "quetschst", sei mal dahingestellt.
Aber die Hilfsvariable Markisenanforderung (inkl. der dazugehörigen set) kannst du ersatzlos streichen, wenn du stattdessen in di_Markise auf den Status von di_Markisenanforderung prüfst.

limats

Hallo zusammen,

ich bräuchte nochmal eine Bestätigung, dass es tatsächlich so gewollt ist, dass ein DOIF-Trigger nur die Zweige *nach* dem getriggerten Zweig abarbeitet.
Falls das so ist, gäbe es vielleicht die Möglichkeit, das (optional) zu ändern?
Ansonsten leidet die Übersicht ja schon etwas, wenn ich die unrelevanten Readings zu jedem Zweig hinzufügen muss, damit er nicht ignoriert wird.
Vielleicht kann sich der Modulautor dazu äußern.

Falls es tatsächlich so ist: Kann ich die Triggerung auch durch eckige Klammern ohne Vergleich erreichen?

...
DOELSEIF
([wintergarten_schiebetuere] and
[Markisenanforderung] eq "runter" and
[twilight:azimuth] > 110 and
[twilight:azimuth] < 190)
    (set Markise pct 50)
DOELSEIF
...


Oder muss ich das mit der Regex-Variante machen?

...
DOELSEIF
([wintergarten_schiebetuere:""] and
[Markisenanforderung] eq "runter" and
[twilight:azimuth] > 110 and
[twilight:azimuth] < 190)
    (set Markise pct 50)
DOELSEIF
...


Gruß
Leo
Fhem auf BBB:
HM-CFG-USB für div. HM-Sensoren, CUL+WMBUS für EnergyCam, Nanocul für IT, Arduino Mega 2560 als 1-wire-Gateway und für div. digitale Ein-/Ausgänge, Volkszähler-USB-IR-Lesekopf mit SMLUSB, Solarsteuerung über VBUS