neues Modul DOIF

[Damian]

Nur noch mal zur Sicherheit:
Das heisst, wenn bei einem Intervall die zweite Angabe kleiner als die erste ist, wird der zweite Zeitpunkt auf den nächsten Tag verschoben?
[17:00-04:00] wäre also zwischen 17:00 Uhr abends heute und 4:00 Uhr morgens am nächsten Tag wahr?

Wenn du es noch vor 17:00 Uhr definierst, dann ja. Es wird immer jeweils der nächstmögliche Trigger-Zeitpunkt genommen. Wenn du es nach 17:00 Uhr definierst, dann wird logischerweise zu erst um 04:00 Uhr getriggert und dann am nächsten Tag um 17:00 Uhr. Es wird aber immer ab 17:00 Uhr der Ausdruck wahr sein und ab 04:00 Uhr false.

Gruß

Damian

[Damian]

Code Auswählen Erweitern

DOIF ([{sunset_abs()}] and [17:00-sunrise_abs()}]) (set Licht on) DOELSE (set Licht off)

Ich sehe gerade, das wird so nicht funktionieren und zwar für den Fall, dass sunsset vor 17:00 Uhr liegt, dann wird zwar nochmal um 17:00 Uhr getriggert aber sunset ist dann nicht wahr.

Das sollte mit Ausnutzung von sunset-Eigenschaften als Intervallangabe so besser funktionieren:

Code Auswählen Erweitern

DOIF ([{sunset(0,"17:00","21:00")}-{sunrise_abs()}]) (set Licht on) DOELSE (set Licht off)

Gruß

Damian

[cwagner]

Moin, Damian,

Urlaub ist eine prima Gelegenheit, mich in DOIF einzuarbeiten - es ist m.E. das vielseitigste und intuitivste Tools in FHEM.

Eine Anregung: I.d.R. will man ja in der Steuerung, dass etwas "allways" gedoed wird, was halten Du und die Mitbnenutzer davon, dass das attribut do als Default schon auf allways steht?

Wenn man dann eine Eintagsfliege will, kann es ja auf - huch - once gibt es gar nicht im Dropdown?

--------

Ein zweites Thema: Wie könnte ich verhindern, dass dieses DOIF ständig immer wieder CMD1 von Eintreten der Dunkelheit bis Ende der Dunkelheit und CMD2 vice versa "feuert". Ich hatte eigentlich ähnlich THRESHOLD erwartet, dass nur der Wechsel gesendet wird - so werden meine Rollläden viele Hundert Mal in am Tag angefunkt - sie tun nichts, aber es ist Funklast und die Relais werden unnötig betätigt.

Code Auswählen Erweitern

([Umweltsensor:Helligkeit]< 0.011 or $hms gt "23:00") (set Rolllaeden on,set ROLL_Schlafzimmer AB) DOELSEIF ([Umweltsensor:Helligkeit]> 0.011 or $hms gt "07:00") (set Rolllaeden off)

Was ich erreichen möchte ist: Rollläden gehen runter, wenn Dunkelheit erreicht, allerspätestens aber um 23 Uhr. Sie sollen hochgehen, wenn Helligkeitsschwelle überschritten, spätestens aber um 7 Uhr.

Grüße

Christian

P.S.: Aktuell nur noch 10 THRESHOLDs, schon 4 DOIFs, aber schon jetzt viel klarere Strukturen mit weniger Dummys und Hilfsstrukturen.

[Brockmann]

Eine Anregung: I.d.R. will man ja in der Steuerung, dass etwas "allways" gedoed wird, was halten Du und die Mitbnenutzer davon, dass das attribut do als Default schon auf allways steht?
Wenn man dann eine Eintagsfliege will, kann es ja auf - huch - once gibt es gar nicht im Dropdown?

Ich habe darüber auch schon nachgedacht, aber meiner Meinung nach ist es besser, wie es jetzt ist. Vor allem der Begriff "once" würde nahelegen, dass das DOIF nur ein einziges Mal und dann nie wieder ausgeführt wird. Und wenn man standardmäßig "do always" verwendet, würden genau solche Fälle, wie Du sie im Folgenden beschreibst, recht häufig auftreten.

Ein zweites Thema: Wie könnte ich verhindern, dass dieses DOIF ständig immer wieder CMD1 von Eintreten der Dunkelheit bis Ende der Dunkelheit und CMD2 vice versa "feuert".

Hast Du in diesem Fall vielleicht "do always" gesetzt? Das würde das beschriebene Verhalten jedenfalls erklären. Ohne "do always" sollte dieses DOIF immer nur einmal ausgeführt werden, wenn der Helligkeitswert unter die Schwelle sinkt und dann erst wieder, wenn er die Schwelle wieder überschreitet.

[Damian]

Hallo Christian,

zum Thema do always. Ein wichtiges Unterscheidungsmerkmal von DOIF zu notify oder at ist die Zustandsverwaltung wie beim THRESHOLD-Modul. Es gibt Anwendungsfälle, da ist do always sicherlich unabdingbar, allerdings in den meisten Fällen (aktuell von 19 Beispielen eins) ist es nicht erforderlich, sondern sogar kontraproduktiv. Das, was viele Anfänger immer wieder tun, sind Konstrukte der Art:

Code Auswählen Erweitern

define n notify sensor set aktor on
und merken nicht, dass sie evtl. alle paar Minuten einen Befehl unnötig senden. Beim DOIF muss man sich durch Angabe von do always eben vorher Gedanken machen, ob ständiges Ausführen eines Befehls sinnvoll ist oder eben nicht. Und wie gesagt, in den meisten Fällen braucht man es nicht.

Zu:

Code Auswählen Erweitern

([Umweltsensor:Helligkeit]< 0.011 or $hms gt "23:00") (set Rolllaeden on,set ROLL_Schlafzimmer AB) DOELSEIF ([Umweltsensor:Helligkeit]> 0.011 or $hms gt "07:00") (set Rolllaeden off)

Du hast hier keine Hysterese eingebaut, wenn dein Sensor schwankende Werte um 0.011 liefert, dann wechselt der Zustand ständig und führt zur Ausführung. Dann besser etwas Luft lassen, als THRESHOLD-Experte sollte es dir bekannt vorkommen

Besser also:

Code Auswählen Erweitern

([Umweltsensor:Helligkeit]< 0.011 or $hms gt "23:00") (set Rolllaeden on,set ROLL_Schlafzimmer AB) DOELSEIF ([Umweltsensor:Helligkeit]> 0.015 or $hms gt "07:00") (set Rolllaeden off)

Den genauen Wert musst du natürlich bei dir anpassen.

Edit: Bei der aktuellen Version 1.41 sollte auch ohne Hysterese bei Schwankungen kein Zustandswechsel erfolgten, da der nicht angegebene ELSE-Fall intern nicht mehr gesetzt wird. Ah ja, do always ist hier natürlich Gift 

Gruß

Damian

[cwagner]

Hallo "Brockmann",

danke für die Spur meines Verständnisfehlers, auf die Du mich gebracht hast.

Hallo Damian,

danke für die Erläuterung, ich hatte offenbar do allways zu oberflächlich verstanden. Mit der Absicht ist es auch für mich völlig nachvollziehbar, dass dies als Ausnahme in Form eines Attributes gesetzt werden soll.

Zur Hysterese: Da mein Sensor bei diesen schwachen Werten sowieso hin- und herschwankt, glaube ich  über das Attribut wait 300:300 vorgesorgt zu haben. Erfahrungen fehlen noch.

---------

Unter den Attributen fand ich das serienmäßige eventmap, dass ich schon bei THRESHOLD verwandt habe, um in einer Webübersicht "Klartext" zu haben. Das scheint aber bei DOIF (noch nicht?) zu funktionieren.


Grüße

Christian

[satprofi]

Poste mal deine Definition, dann kann ich dir sagen, ob die Sache sinnvoll ist. Vielleicht ist es nur ein Verständnisproblem.

Gruß

Damian

Hallo.
Vielleicht findest du den/die fehler.

Code Auswählen Erweitern


([Heizungsmode] eq "off" and [Pac:state] > 1500 and [HZ_Wohnzimmer_Weather] > 22 and [Terassentuer] eq "Closed" and $hms gt "10:00" and $hms lt "18:30") (set Klima_WZ on) DOELSEIF ([Heizungsmode] eq "auto" and [Pac:state] > 1500 and [HZ_Wohnzimmer_Weather] < 24 and [Terassentuer] eq "Closed" and $hms gt "08:00" and $hms lt "18:30") (set Klima_WZ on) DOELSEIF ([Klima_WZ_manuOn] eq "on" and [HZ_Wohnzimmer_Weather] > 23 and [Terassentuer] eq "Closed") (set Klima_WZ on) DOELSEIF ([Heizungsmode] eq "off" and [Pac:state] < 1000 and [Terassentuer] eq "Closed") (set Klima_WZ off) DOELSEIF ([Klima_WZ_manuOn] eq "off") (set Klima_WZ off) DOELSE (set Klima_WZ ff)


do always
   
wait 300:300:0:300:0:300

Gruss.

[Damian]

Unter den Attributen fand ich das serienmäßige eventmap, dass ich schon bei THRESHOLD verwandt habe, um in einer Webübersicht "Klartext" zu haben. Das scheint aber bei DOIF (noch nicht?) zu funktionieren.

Dafür habe ich bei THRESHOLD genau wenig programmiert wie beim DOIF. Das Verhalten sollte also gleich sein. Bei DOIF gibt es das Attribut cmdState, da kannst du den Zustand beliebig umdefinieren.

Geplant ist in der nächsten Version von DOIF  vollkommen unabhängig vom Zustand beliebige Informationen einstellen zu können. Beispiel:

attr di_test State Das ist der aktuelle Zustand des Moduls: [di_test], die aktuelle Temperatur beträgt [Sensor:temp]

Aktualisierung soll sofort erfolgen.

Gruß

Damian

[cwagner]

Hallo Damian,

das funktioniert einwandfrei. Jetzt wird das richtig informativ - aktuell bastele ich aus gegebenenen Anlass an einer Steuerung, die je nach Sommer/Winter für die Lüftung eine Klappe steuert, die diese 4 Fälle abdeckt:

1. Sommer: Die Luft draußen ist heiß - umschalten auf Erdwärmetauscher - ins Haus strömt gekühlte, entfeuchtete Luft
2. Sommer: Die Luft draußen ist kühler (in der Nacht) als der sich immer weiter erwärmende Erdwärmetauscher - schalte den Erdwärmetauscher aus.
3. Winter: Die Luft draußen ist kälter als die Luft aus dem Erdwärmetauscher - diesen benutzen
4. Winter: Die Lauft draußen ist wärmer als die Luft aus dem Erdwärmetauscher (typisch im zeitigen Frühjahr, wenn der Erdwärmetauscher durchgekühlt ist), den Erdwärmetauscher ausschalten.
Beim Umschalten wird immer der Zustand die letzte Temperatur des Erdwärmetauschers für die nächsten Vergleiche gespeichert.

Das war vorher ein Gewusel von zwei Thresholds und Dummys - nochmals danke für das tolle Modul, ich freu mich schon auf die nächste Version mit vereinfachter Angabe von Zeiträumen und Wochentagsabhängigkeiten.

Herzliche Grüße

Christian

[Damian]

Noch kurz vor Mitternacht: Version 1.5 mit Zeitintervallen ist im ersten Post verfügbar.

Die Tests zu Hause über eine 1000 km entfernte Remoteverbindung haben sich etwas schwieriger gestaltet als gedacht 

Bitte die komplett überarbeitete Dokumentation im ersten Post beachten.

Achtung: Diese Version ist intern nicht abwärtskompatibel zu der vorherigen. Daher:

System  anhalten, Modul kopieren, System wieder hochfahren (kein reload)

Danach bei allen bereits definierten DOIF-Modulen über die Weboberfläche auf DEF klicken und über modify-Button bestätigen.

Gruß

Damian

[Damian]

Hallo.
Vielleicht findest du den/die fehler.

Code Auswählen Erweitern


([Heizungsmode] eq "off" and [Pac:state] > 1500 and [HZ_Wohnzimmer_Weather] > 22 and [Terassentuer] eq "Closed" and $hms gt "10:00" and $hms lt "18:30") (set Klima_WZ on) DOELSEIF ([Heizungsmode] eq "auto" and [Pac:state] > 1500 and [HZ_Wohnzimmer_Weather] < 24 and [Terassentuer] eq "Closed" and $hms gt "08:00" and $hms lt "18:30") (set Klima_WZ on) DOELSEIF ([Klima_WZ_manuOn] eq "on" and [HZ_Wohnzimmer_Weather] > 23 and [Terassentuer] eq "Closed") (set Klima_WZ on) DOELSEIF ([Heizungsmode] eq "off" and [Pac:state] < 1000 and [Terassentuer] eq "Closed") (set Klima_WZ off) DOELSEIF ([Klima_WZ_manuOn] eq "off") (set Klima_WZ off) DOELSE (set Klima_WZ ff)


do always
   
wait 300:300:0:300:0:300

Gruss.

Ohne zu verstehen, was die Abfragen bei dir im Einzelnen bedeuten, habe ich dein Konstrukt etwas zusammengefasst und auf Intervalle umgestellt. do always macht hier keinen Sinn. Sonst wird unnötig bei dir ein set-Befehl wiederholt (wenn etwas auf off gesetzt wurde, dann muss man es beim nächsten Trigger nicht schon wieder auf off setzen)

Code Auswählen Erweitern

((([Heizungsmode] eq "off" and [HZ_Wohnzimmer_Weather] > 22) or ([Heizungsmode] eq "auto" and [HZ_Wohnzimmer_Weather] < 24))
and [Pac:state] > 1500 and [10:00-18:30] and [Terassentuer] eq "Closed")
(set Klima_WZ on)
DOELSEIF  ([Klima_WZ_manuOn] eq "on" and [HZ_Wohnzimmer_Weather] > 23 and [Terassentuer] eq "Closed")
(set Klima_WZ on)
DOELSEIF ([Heizungsmode] eq "off" and [Pac:state] < 1000 and [Terassentuer] eq "Closed")
(set Klima_WZ off)
DOELSEIF ([Klima_WZ_manuOn] eq "off")
  (set Klima_WZ off)
DOELSE
  (set Klima_WZ off)
 
wait 300:0:300:0:300


Gruß

Damian

[satprofi]

aha, danke.
kann man jetzt zeileneinrückung verwenden?
das wäre ja eine hilfe.

gruss

[Damian]

aha, danke.
kann man jetzt zeileneinrückung verwenden?
das wäre ja eine hilfe.

gruss

Immer schon! Oder haben wir die Doku mit allen 19! Beispielen nicht aufmerksam durchgelesen 

Gruß

Damian

[satprofi]

Ohne zu verstehen, was die Abfragen bei dir im Einzelnen bedeuten, habe ich dein Konstrukt etwas zusammengefasst und auf Intervalle umgestellt. do always macht hier keinen Sinn. Sonst wird unnötig bei dir ein set-Befehl wiederholt (wenn etwas auf off gesetzt wurde, dann muss man es beim nächsten Trigger nicht schon wieder auf off setzen)

Code Auswählen Erweitern

((([Heizungsmode] eq "off" and [HZ_Wohnzimmer_Weather] > 22) or ([Heizungsmode] eq "auto" and [HZ_Wohnzimmer_Weather] < 24))
and [Pac:state] > 1500 and [10:00-18:30] and [Terassentuer] eq "Closed")
(set Klima_WZ on)
DOELSEIF  ([Klima_WZ_manuOn] eq "on" and [HZ_Wohnzimmer_Weather] > 23 and [Terassentuer] eq "Closed")
(set Klima_WZ on)
DOELSEIF ([Heizungsmode] eq "off" and [Pac:state] < 1000 and [Terassentuer] eq "Closed")
(set Klima_WZ off)
DOELSEIF ([Klima_WZ_manuOn] eq "off")
  (set Klima_WZ off)
DOELSE
  (set Klima_WZ off)
 
wait 300:0:300:0:300


Gruß

Damian

leider heute keine einschaltung mehr mit diesem code.
timer läuft seit 10:00 aber keine aktivität.

[edit]
Habe fehler gefunden, vielöleicht ein bug? wenn einer der readings " -???- " hat läuft das ganze nicht an. dies ist aber nach stromausfall oder restart von fhem der fall.
wie kann man das umgehen?

gruss

[Damian]

leider heute keine einschaltung mehr mit diesem code.
timer läuft seit 10:00 aber keine aktivität.

[edit]
Habe fehler gefunden, vielöleicht ein bug? wenn einer der readings " -???- " hat läuft das ganze nicht an. dies ist aber nach stromausfall oder restart von fhem der fall.
wie kann man das umgehen?

gruss

Wenn eine Bedingung nicht erfüllt ist, weil ein Reading nicht existiert oder einen anderen Wert hat, dann wird natürlich auch das entsprechende Kommando nicht ausgeführt. Sobald jedoch alle Readings den erwarteten Wert haben und ein Event kommt, dann muss das Kommando ausgeführt werden.

Wenn du mir beweisen kannst, dass ein Kommando nicht ausgeführt wird, obwohl alle Werte, die abgefragt werden, den korrekten Wert haben und ein Event stattgefunden hat, dann kann ich nach einem Fehler suchen.

Gruß

Damian