DOIF mit Twilight löst leider mehrfach aus

[hirsch911]

Hallo,

ich habe nach langer Suche endlich den Kern meines Lichtproblems gefunden und bin jetzt auf der Suche nach einer Lösung. Eventuell kann ein DOIF-Profi mir da helfen (es lässt sich ja vermutlich lösen und wohl auch einfacher als gedacht). Ich komme nur nicht drauf mangels Erfahrung:

Es geht um die Tag/Nacht Schaltung von diversen Leuchten an oder im Haus, die Nachts gedimmt leuchten sollen. Am Tage sollen sie aus sein. Läuft soweit gut, die Helligkeitsschwellen sind gut und ich meine, dass das auch alles schon mal ohne Probleme lief. Eventuell kam ein Update dazwischen?

Dazu gibt es zwei DOIF's, die auf den Wert des Twilight Moduls reagieren (0-12 glaube ich).

([WETTER]==10) (set zentral.tagnacht off; set eg.treppenhaus.led.absolut value 7;set aussen.haustuer.licht.absolut value 15; set aussen.hausnummernleuchte.io on; set aussen.nordwest.licht.absolut value 15; set aussen.gartenleuchten.absolut value 35)

([WETTER]==3) (set zentral.tagnacht on; set eg.treppenhaus.led.absolut value 0; set aussen.haustuer.licht.absolut value 0; set aussen.hausnummernleuchte.io off; set aussen.nordwest.licht.absolut value 0; set aussen.gartenleuchten.absolut value 0)

Dummerweise setzt das Twilight Modul den Status bis zur Änderung auf den nächsten Wert (zB 11) mehrfach alle ca. 20min auf 10. Somit wird das DOIF dauernd getriggert. Das kommt aber auch den Bewegungsmeldern in die Quere, die bei Bewegung die Lampen auf 100% setzen teilweise. Dann gehen diese trotz Bewegung wieder auf 15%, weil das Twilight Modul wieder 10 gemeldet hat.

Das DOIF dürfte also nur bei der erstmaligen Änderung auf einen neuen Wert des Twilight Moduls ausgeführt werden. Kann ich das irgendwie basteln? MIt einem speziellen Attribut? Die ganze Logik wollte ich ungerne umbauen.

Vielen Dank schon Mal und Gruß

Stephan

[swsmily]

Ich nutze bei mir auch Twilight zur Lichtsteuerung. Statt == probiere mal mit >= und <= . Twilight heißt bei mir Daemmerung:

Code Auswählen Erweitern

([Daemmerung:state] >= "7")


Ich habe damit Lichtsteuerungen, dass, wenn es dunkel ist anderes Licht an geht, als wenn es hell ist (mit weiteren Bedingungen wie Bewegungsmelder usw.)
Hier mal auszüge eines DOIFs von mir (weitere Bedingungen hab ausgelassen)
Helles Licht bei mir:

Code Auswählen Erweitern

(([?Daemmerung:state] >= "4" and [?Daemmerung:state] <= "8" ) or ([09:00 - 20:30]))
Dunkel:

Code Auswählen Erweitern

(([?Daemmerung:state] >= "9" or [?Daemmerung:state] <= "3") and ([?20:30 - 09:00]))



Bei dir wäre es also eher so:

Code Auswählen Erweitern

([WETTER:state] >= "10" and [WETTER:state] <= "2") (set zentral.tagnacht off;....)
und

Code Auswählen Erweitern

([WETTER:state]>= "3" and [WETTER:state] <= "9") (set zentral.tagnacht on;....)

Attribute DO ALWAYS sollte nicht gesetzt sein, sonst führt es bei jeder Statusänderung von Twilight wieder aus.

Da DOIF dann jeweils entweder in CMD_1 oder CMD_2 steht und erst wieder ändert, wenn die andere Bedingung wieder wahr wird, sollte es nur jeweils einmal ausführen. Ich hab bei mir jedenfalls noch nie beobachtet, dass der jeweilige aktive Zweig mehrfach ausgeführt wird.


zentral.tagnacht  usw. sind bei dir ein Dummys, die in anderen DOIFs genutzt werden?

[Otto123]

Dummerweise setzt das Twilight Modul den Status bis zur Änderung auf den nächsten Wert (zB 11) mehrfach alle ca. 20min auf 10. Somit wird das DOIF dauernd getriggert.

Hallo Stephan,

ist das nicht einfach  mit dem Attribute event-on-change-reading beim Twilight Modul lösbar?
Zitat Doku

event-on-change-reading
The attribute takes a comma-separated list of readings. You may use regular expressions in that list. If set, only changes of the listed readings create events. In other words, if a reading listed here is updated with the new value identical to the old value, no event is created. If an optional [:threshold] is given after a reading name events are only generated if the change is >= threshold.

Gruß Otto

[CoolTux]

Wie Otto schon sagt sollte ein event-on-change-reading reichen.
Allerdings verstehe ich nicht wieso das DOIF mehrfach schalten sollte. Sofern keine Statusänderung erfolgt schaltet auch das DOIF nur einmal.
Zeig doch mal Dein ganzes DOIF. Am besten ein list von hier einstellen.

[hirsch911]

Hi,

ich habe jetzt mal das Attribut "do always" gelöscht. Eigentlich hätte einen das schon vorher anspringen müssen

do always
Ohne do always gilt:Die Befehle eines Bedingungszweiges werden ohne vorherigen Statuswechsel nur einmal ausgeführt.
Das Attribut setzt diese Regel ausser Kraft. Befehle werden wiederholt im bestehenden Status ausgeführt.

Das sagt ja sogar quasi im Klartext was es macht. Aber so sieht man halt manchmal den Wald vor Bäumen nicht. Ich warte jetzt mal einen Tag, dann werde ich berichten.

Bis dahin schon mal danke für den Tipp!

Gruß

Stephan

[Per]

Na Hauptsache, es wird bis zum nächsten Tag wieder auf einen anderen Status (so vorhanden) gesetzt. Sonst brauchst du das do always wieder.

[nils_]

([WETTER]==10) (set zentral.tagnacht off; set eg.treppenhaus.led.absolut value 7;set aussen.haustuer.licht.absolut value 15; set aussen.hausnummernleuchte.io on; set aussen.nordwest.licht.absolut value 15; set aussen.gartenleuchten.absolut value 35)

da du uns ja nur code-auszüge präsentierst, die frage:
hast du das hierher kopiert und mal eben schnell getippt??

denn das ist keine korrekte DOIF-Syntax!
bei DOIF werden die Befehle mit Komma getrennt ->https://fhem.de/commandref_DE.html#DOIF_Angaben_im_Ausfuehrungsteil

([WETTER]==10) (set zentral.tagnacht off, set eg.treppenhaus.led.absolut value 7,set aussen.haustuer.licht.absolut value 15, set aussen.hausnummernleuchte.io on, set aussen.nordwest.licht.absolut value 15, set aussen.gartenleuchten.absolut value 35)

[hirsch911]

@NILS:
Das sind keine Auszüge. Das ist der Text aus dem DEF Feld des Devices. Oder was meinst Du?
Und das mit den Semikolons funktioniert bei all meinen DOIFs schon seit mind. einem Jahr ganz gut wage ich mal zu behaupten. Darf das eigentlich nicht gehen?

@PER:
Der State von Twilight ändert sich ja über den Tag verteilt von 0-12 im Durchlauf. Dadurch ändert sich der Status dann ja. Oder habe ich da einen Gedankenfehler drin? Dadurch wird das DOIF Device doch auf einem anderen cmd hängen bleiben und wird dann beim nächsten mal wenn der State ==10 ist wieder getriggert.

Schönen Gruß

Stephan

[Otto123]

Darf das eigentlich nicht gehen?

Laut commandref eigentlich nicht, Zitat Doku

Sollen mehrere FHEM-Befehle ausgeführt werden, so werden sie mit Komma statt mit Semikolon angegeben ... (set lamp1 on, set lamp2 off)

Aber manchmal ist es anders als man denkt 

[Damian]

Nur mal zur Klärung:

Komma ist das eigentliche Trennzeichen beim DOIF. Es wurde wie beim IF statt Semikolon definiert, um dem Problem des Doppelns zu entgehen. Beim IF war es besonders wichtig, da bei tieferen Verschachtelungen, je Ebene eine Verdoppelung stattfinden müsste, zwei, vier, acht, sechzehn, usw.  Semikolons für "ein" Trennzeichen, das konnte man keinem zumuten, daher Komma. Das ist der fehlenden Klammer-Hierarchie des FHEM-Interpreters geschuldet.

Nun stört beim DOIF im Gegensatz zu IF das Semikolon nicht. Mit Semikolon getrennte Befehle werden aus Sicht von DOIF als eine Einheit an den FHEM-Interpreter weitergegeben und dieser zerstückelt dann die Befehle, daher funktionieren beim DOIF auch Semikolons als Trennzeichen.

 

[hirsch911]

Also das Ergebnis: DO ALWAYS war das Problem, jetzt funktioniert alles wieder tadellos. Vielen Dank an swsmily, das war die richtige Fährte!

Gruß

Stephan

[nils_]

Nur mal zur Klärung:

Komma ist das eigentliche Trennzeichen beim DOIF. Es wurde wie beim IF statt Semikolon definiert, um dem Problem des Doppelns zu entgehen. Beim IF war es besonders wichtig, da bei tieferen Verschachtelungen, je Ebene eine Verdoppelung stattfinden müsste, zwei, vier, acht, sechzehn, usw.  Semikolons für "ein" Trennzeichen, das konnte man keinem zumuten, daher Komma. Das ist der fehlenden Klammer-Hierarchie des FHEM-Interpreters geschuldet.

Nun stört beim DOIF im Gegensatz zu IF das Semikolon nicht. Mit Semikolon getrennte Befehle werden aus Sicht von DOIF als eine Einheit an den FHEM-Interpreter weitergegeben und dieser zerstückelt dann die Befehle, daher funktionieren beim DOIF auch Semikolons als Trennzeichen.

danke für die Erklärung!

Also das Ergebnis: DO ALWAYS war das Problem, jetzt funktioniert alles wieder tadellos. Vielen Dank an swsmily, das war die richtige Fährte!

siehste und das hätten wir gesehen, wenn du mehr als die DEF-Zeile ( = Auszug!) gepostet hättest.
list <devicename> in die fhem-kommandozeile eingeben und das Ergebnis in code-tags posten.
da steht dann halt doch noch etwas mehr

aber sei es drum, problem gelöst

[hirsch911]

Hi,

die Sache mit dem "list device" merke ich mir, habe ich gerade mal probiert. War mir vorher noch nicht bekannt. Für solche Beiträge schon sehr praktisch..

Schönen Gruß

Stephan

[nils_]

noch zum abschluß und dann ist es aber auch wirklich gut.

bitte durchlesen evtl. stehen da noch mehr hinweise und/oder tipps
https://forum.fhem.de/index.php/topic,71806.0.html