Liebe DOIF-Nutzer,
der Jahrestag des Moduls kommt immer näher (die erste eingecheckte Version war vom 19.08.2014). Das Modul wird die 10.000er-Grenze der genutzen DOIF-Module zum Jahrestag wahrscheinlich knapp verfehlen. Da wird es an der Zeit das Modul etwas zu tunen ;)
Ich habe heute etwas am Modul gebastelt. Herausgekommen ist, wie schon angekündigt, eine Version, die Befehlssequenzen mit Pausen unterstützt. Diese Version ist wie immer voll abwärtskompatibel zur aktuellen.
Zum Aufspielen: System herunterfahren, Modul aufspielen und System wieder hochfahren (reload funktioniert nicht, da sich Interna geändert haben, evtl. zur Sicherheit ein Backup der config-Datei machen).
Die erweiterte Syntax lautet:
DOIF (Bedingung1) (Kommandos1) (Kommandos2)... DOELSEIF (Bedingung2) (Kommandos3) (Kommandos4)... DOELESE (Kommandos5) (Kommandos6)...
Zwischen den jeweiligen Kommandos lassen sich wait-timer definieren, damit gibt es in DOIF eine Alternative zu sleep.
Beispiel für das Wait-Attribut:
wait 2,3:0,4:0.5,10
Damit würden die Kommandos1 um 2 Sekunden verzögert, Kommandos2 um 3 Sekunden, Kommandos3 haben keine Verzögerung, Kommandos4 4 Sekunden, Kommandos5 0,5 Sekunden Kommanods6 10 Sekunden.
Nun ein Beispiel für einen simulierten on_for_timer:
define di_on_for_timer ([Button:?])
(set lamp on)
(set lamp off)
attr di_on_for_timer do resetwait
attr di_on_for_timer wait 0,30
Das wiederholte Betätigen des Tasters setzt die Wartezeit für den zweiten Befehl immer wieder auf 30 Sekunden. Der erste on-Befehl wird dabei nicht wiederholt.
Bei do always würde der Waittimer nicht verlängert.
Bei mehreren DOELSEIF-Fällen wird, wie bisher, der aktuelle Waittimer unterbrochen, wenn ein anderer Fall zuschlägt.
Es handelt sich hierbei um eine Testversion. Die Dokumentation wird noch erweitert. Wer möchte kann die angehängte Version vorab testen.
Weitere Features werden noch zum Jahrestag folgen :)
Gruß
Damian
Edit: letzte Version wurde eingecheckt
Hi,
Super, dass die Entwicklung weiter, geht :-)
Für die neue Funktion habe ich auch schon eine Verwendung, momentan nehme ich mehrere sleeps.
Bin schon gespannt, was Du zum Geburtstag zauberst ;-)
Alex
Hallo Damian,
vielen Dank für Deine Weiterentwicklung und Deinen tollen Support!
Hast Du nicht Lust, mal eine Roadmap / ToDo-Liste zu posten ;) ?
Zitat von: Ralli am 15 Juli 2015, 07:03:02
Hallo Damian,
vielen Dank für Deine Weiterentwicklung und Deinen tollen Support!
Hast Du nicht Lust, mal eine Roadmap / ToDo-Liste zu posten ;) ?
Tja, das Schöne an Hobby-Projekten ist, dass man die Ziele und die Realisierungszeitpunkt selbst bestimmen kann. Und wenn etwas zu komplex wird, dann verschiebt man es einfach auf später, ohne dass einem der Kopf abgerissen wird (das ist bekanntlich auf der Arbeit anders ;)). Da ich selbst im Urlaub noch einige andere Hobby-Projekte habe, will ich nichts versprechen, meine aktuelle todo-Liste, die sich immer wieder ändert, kann ich aber hier posten.
0) Wait innerhalb von Befehlssequenzen (erledigt)
1) Nur ein Trigger für gleiche Zeitangaben, um Abarbeitungsreihenfolge sicherzustellen (aufwändig)
2) Kommentare innerhalb von DOIF-Definitionen eingeleitet mit # bis zum Ende der Zeile
3) Datumsangaben (aufwändig)
Datumsangaben mit Uhrzeit (mit Triggerung bzw. ohne Triggerung mit Fragezeichen wie bisher) [YYYY-MM-TT HH:MM[:SS]] oder [MM-TT HH:MM[:SS]] oder [TT HH:MM[:SS]]
Beispiel
[2015-10-30 10:00] oder [10-30 10:00] oder [30 10:00] oder Zeitintervalle [2015-10-30 10:00 - 2016-10-30 10:00] oder vom 1. September 10 Uhr bis zum ersten April 20:00 Uhr [09-01 10:00 - 04-01 20:00] oder vom ersten 10:00 Uhr bis 15. 20:00 Uhr [-01 10:00 - -15 20:00]
Datumsangaben ohne Zeitangabe: [YYYY-MM-TT] oder [MM-TT] oder [MM-] oder [-TT].
Bespiel: An meinem Geburtstag [02-26], nur im Februar [02-], immer am 15. des Monats [-15]
Beispiel mit Intervallen: Heizung soll laufen von September bis April [09- - 04-] oder vom 15.09 bis zum 30.04 [09-15 - 04-30]
(das "bis-Zeichen" muss dann mit Leerzeichen angegeben werden)
4. disable/enable per set (Zustand soll nach Neustart erhalten bleiben)
set di disable (timer werden gelöscht, state disable)
set di enable (timer werden neu gesetzen, state initialized)
5. Mehrere DOIF-Fälle innerhalb eines Moduls
DOIF (...) (...)
DOELSEIF (...) (...)
DOELSE (...)
DOIF (...) (...)
DOELSEIF (...) (...)
DOELSE (...)
DOELSEIF und DOELESE beziehen sich immer auf den vorhergehenden DOIF-Fall
6. Mehrere Bedingungen, die zum gleichen Kommando (gleichen Zustand) führen, können angegeben werden (es wird nur die jeweilige Bedingung, zu der ein Ereignis eintritt, überprüft)
DOIF (<Bedingung1>)|(<Bedingung2)|... (<Kommandos>)
So, mal schauen, was sich davon im kommenden Monat umsetzen lässt.
Gruß
Damian
Dankeschön!
Wichtig wäre m.E. noch die Problematik, dass DOIF bereits Kommandos ausführt, obwohl nach einem Restart (relative oder absolute) Zeitangaben noch nicht schlüssig durchinitialisiert sind.
Toll auch die Möglichkeit des Einbaus von Datums, Wochentagen, Tagen usw.
Zitat von: Ralli am 15 Juli 2015, 10:23:39
Dankeschön!
Wichtig wäre m.E. noch die Problematik, dass DOIF bereits Kommandos ausführt, obwohl nach einem Restart (relative oder absolute) Zeitangaben noch nicht schlüssig durchinitialisiert sind.
Toll auch die Möglichkeit des Einbaus von Datums, Wochentagen, Tagen usw.
ja, wird bis dahin auch erledigt sein.
Gruß
Damian
Feature 0 kommt mir gerade sehr gelegen - so kann ich schön kontrolliert hintereinander ein paar Kommandos an diverse Sonos absetzen beim morgendlichen Wecker mit Gruppendefinition.
Super Sache. DOIF entwickelt sich immer mehr zum Schweizer Taschenmesser in FHEM. Hat schon unzählige notify und at abgelöst, und jetzt offenbar auch noch ein watchdog wenn ich es richtig verstanden habe.
Danke Damian, mach weiter so!
Zitat von: MarkusN am 15 Juli 2015, 12:50:03
Super Sache. DOIF entwickelt sich immer mehr zum Schweizer Taschenmesser in FHEM. Hat schon unzählige notify und at abgelöst, und jetzt offenbar auch noch ein watchdog wenn ich es richtig verstanden habe.
Danke Damian, mach weiter so!
wait als watchdog-Ersatz gab es immer schon. Jetzt gibt es wait zwischen den einzelnen Befehlen.
Gruß
Damian
... da fehlt nur das, was dem "echten" watchdog auch fehlt: Device-übergreifende Funktionalität ;).
Zitat von: Ralli am 15 Juli 2015, 13:37:42
... da fehlt nur das, was dem "echten" watchdog auch fehlt: Device-übergreifende Funktionalität ;).
ja, das widerspricht jedoch dem Konzept des DOIF-Moduls, Bedingungen von Perl überprüfen zu lassen - das geht nur mit konkreten Bezeichnern, wie in jeder höheren Programmiersprache.
Gruß
Damian
Zitat von: Damian am 15 Juli 2015, 13:22:54
wait als watchdog-Ersatz gab es immer schon. Jetzt gibt es wait zwischen den einzelnen Befehlen.
Gruß
Damian
Aber jetzt kann ich (wie in deinem simulierten on-for-timer Beispiel) alles mit einem DOIF abbacken, oder nicht? Ich schalte bei einer gemeldeten Bewegung die Lampe ein, und schalte sie aus wenn innerhalb der nächsten zwei Minuten keine weitere Bewegung stattfindet. Habe ich bisher durch ein DOIF und watchdog umgesetzt.
Zitat von: MarkusN am 15 Juli 2015, 14:21:27
Aber jetzt kann ich (wie in deinem simulierten on-for-timer Beispiel) alles mit einem DOIF abbacken, oder nicht? Ich schalte bei einer gemeldeten Bewegung die Lampe ein, und schalte sie aus wenn innerhalb der nächsten zwei Minuten keine weitere Bewegung stattfindet. Habe ich bisher durch ein DOIF und watchdog umgesetzt.
Das war auch Ziel der Übung. Es war insb. mein Anliegen den on-for-timer mit einem DOIF-Modul abzudecken und nicht so umständlich mit zwei, wie in der bisherigen Commandref zu DOIF. Das zweite wichtige Anliegen war die sleeps zu umgehen oder die abenteuerlichen
at-Konstruktionen, die man umständlich löschen musste, wenn sie nicht zum Zuge kommen sollten.
Gruß
Damian
Wo du oben über Features gesprochen hast. (Offtopic hier)
Ich meine mal von dir gelesen zu haben, dass du an folgendes Thema nicht rangehen willst, aber ich frage doch einmal: :-)
Könntest du in deinem DOIF-Modul nicht eigentlich auch eine Art "Random"-Intervall einbauen?
Man könnte ein Zeitintervall [08:00-18:00] vorgeben, in dem - analog deiner Zeitraster-Idee - nach dem Zufallsprinzip die CMDs ausgeführt werden.
define di_lampe DOIF ([08:00-18:00] and [~:15])
(set lampe on)
DOELSE
(set lampe off)
Der obere Code ist natürlich nur ne Idee. Ich habe keine Ahnung, welches Zeichen man als Platzhalter dafür nutzen könnte.
Das nur so am Rande. :-)
Zitat von: FunkOdyssey am 15 Juli 2015, 15:55:32
Wo du oben über Features gesprochen hast. (Offtopic hier)
Ich meine mal von dir gelesen zu haben, dass du an folgendes Thema nicht rangehen willst, aber ich frage doch einmal: :-)
Könntest du in deinem DOIF-Modul nicht eigentlich auch eine Art "Random"-Intervall einbauen?
Man könnte ein Zeitintervall [08:00-18:00] vorgeben, in dem - analog deiner Zeitraster-Idee - nach dem Zufallsprinzip die CMDs ausgeführt werden.
define di_lampe DOIF ([08:00-18:00] and [~:15])
(set lampe on)
DOELSE
(set lampe off)
Der obere Code ist natürlich nur ne Idee. Ich habe keine Ahnung, welches Zeichen man als Platzhalter dafür nutzen könnte.
Das nur so am Rande. :-)
Was soll in deinem Beispiel der Zufall sein? Ungefähr 15 Minuten, plus minus welche Abweichung?
Das kannst du heute schon haben, hier alle 15 Minuten (nach Zeitraster ausgerichtet) plus Zufall von 60 Sekunden.
define di_lampe DOIF ([08:00-18:00] and [([+:15]+rand(60))])
(set lampe on)
DOELSE
(set lampe off)
Da man in der Bedingung mit Zeiten rechnen kann, kannst du jeden erdenklichen Zufall einbauen ;)
Gruß
Damian
Hmm, stimmt. Jetzt muss ich dann nur noch wissen, was ich überhaupt will. :-)
Danke für den Tipp.
Zitat von: FunkOdyssey am 15 Juli 2015, 17:24:32
Hmm, stimmt. Jetzt muss ich dann nur noch wissen, was ich überhaupt will. :-)
Danke für den Tipp.
ja, es gibt beliebig viele Möglichkeiten den Zufall zu definieren. Und dafür macht es wenig Sinn beliebige Syntax zu erfinden, denn die muss man erst mal lernen. Rechnen mit Grundrechenarten sollten dagegen die meisten beherrschen.
Hier ein Beispiel: Jede Stunden mit einer maximalen Verzögerung von 15 Minuten in Schritten von einer Minute:
define di_lampe DOIF ([08:00-18:00] and [([:00]+int(rand(15))*60)])
(set lampe on)
DOELSE
(set lampe off) Und auch dafür müsste man erst mal eine Syntax sich ausdenken, bis der Nächste einen neuen Wunsch äußert. In dieser Zeit zaubere ich dir einen neuen Einzeiler in der Bedingung mit etwas plus, minus, mal und geteilt, der den Zufalls-Wunsch realisiert. ;)
Gruß
Damian
Hi Damian, es tut mir leid, dass ich diesen Thread hier mit dem Zufallsthema zweckentfremde, aber ich muss zu deiner Idee leider noch einmal nachfragen.
Unabhängig davon, ob das Zeitraster statisch ist oder über eine Zufallsfunktion generiert wird; es spring afaik nie in den DOELSE-Teil. Darüber bin ich auch bereits bei der Steuerung meiner Zirkulationspumpe (anderes Thema) gestolpert.
Wenn ich zum Testen, den folgenden Code nehme, bleibt er immer bei CMD_1 stehen:
([+:02])
(set dummydev on)
DOELSE
(set dummydev off)
Ich würde in den letzten DOIF-Beispielen ungerne mit "on-for-timer" oder ähnliches arbeiten.
Stehe ich irgendwie auf dem Schlauch? Und könntest du mir einen Wink mit dem Zaunpfahl geben? Danke. :-)
Zitat von: FunkOdyssey am 16 Juli 2015, 08:50:30
Hi Damian, es tut mir leid, dass ich diesen Thread hier mit dem Zufallsthema zweckentfremde, aber ich muss zu deiner Idee leider noch einmal nachfragen.
Unabhängig davon, ob das Zeitraster statisch ist oder über eine Zufallsfunktion generiert wird; es spring afaik nie in den DOELSE-Teil. Darüber bin ich auch bereits bei der Steuerung meiner Zirkulationspumpe (anderes Thema) gestolpert.
Wenn ich zum Testen, den folgenden Code nehme, bleibt er immer bei CMD_1 stehen:
([+:02])
(set dummydev on)
DOELSE
(set dummydev off)
Ich würde in den letzten DOIF-Beispielen ungerne mit "on-for-timer" oder ähnliches arbeiten.
Stehe ich irgendwie auf dem Schlauch? Und könntest du mir einen Wink mit dem Zaunpfahl geben? Danke. :-)
Getriggert wird hier immer alle 2 Minuten und die Bedingung ist dann wahr. Wann soll deiner Meinung der DOELSE-Fall kommen. Es gibt hier keinen Trigger, bei dem die Bedingung nicht wahr wird, also kann DOELSE-Fall in dieser Konstruktion nie zum Zuge kommen.
Gruß
Damian
Ja, ich weiß. Darauf wollte ich hinaus.
Dann wäre eine Zufallsschaltung ja leider doch nicht umsetzbar.
Wenn ich "on-for-timer" oder ähnliches im Ausführungsteil nutze, dann laufe ich Gefahr, dass die Ausschaltzeit sich mit der neuen Einschaltzeit überschneidet.
Zitat von: FunkOdyssey am 16 Juli 2015, 09:21:12
Ja, ich weiß. Darauf wollte ich hinaus.
Dann wäre eine Zufallsschaltung ja leider doch nicht umsetzbar.
Wenn ich "on-for-timer" oder ähnliches im Ausführungsteil nutze, dann laufe ich Gefahr, dass die Ausschaltzeit sich mit der neuen Einschaltzeit überschneidet.
Ich weiß nicht, was du genau vorhast, aber "zufällig" kann man etwas einschalten, aber auch ausschalten. Es hängt auch davon ab, wie ich schon geschrieben habe, wie man den "Zufall" definiert. So kann man eine Überschneidung ausschließen. Bei Überschneidung dürfte sich die on-Dauer verlängern - wäre je nach Anwendungsfall auch nicht tragisch.
Gruß
Damian
Dann musst du das on-for-timer halt so setzen, dass es maximal bis zur nächsten Einschaltzeit läuft.
Also wenn du zB mit max. 15 Minuten verschiebung arbeitest, darfs halt nur maximal 44 Minuten laufen.
So, habe das Modul mal installiert. Das erste was mir aufgefallen ist war folgender Eintrag im Log (war vorher noch nicht da):
2015.07.17 18:42:49 1: PERL WARNING: Argument "" isn't numeric in addition (+) at ./FHEM/98_DOIF.pm line 550.
2015.07.17 18:38:24 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/98_DOIF.pm line 1011.
Ansonsten habe ich mal die Schaltung über einen Bewegungsmelder mit dem wait umgesetzt, und was soll ich sagen, es funktioniert!
Zitat von: MarkusN am 17 Juli 2015, 19:36:44
So, habe das Modul mal installiert. Das erste was mir aufgefallen ist war folgender Eintrag im Log (war vorher noch nicht da):
2015.07.17 18:42:49 1: PERL WARNING: Argument "" isn't numeric in addition (+) at ./FHEM/98_DOIF.pm line 550.
2015.07.17 18:38:24 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/98_DOIF.pm line 1011.
Ansonsten habe ich mal die Schaltung über einen Bewegungsmelder mit dem wait umgesetzt, und was soll ich sagen, es funktioniert!
Wird mit der nächsten Version korrigiert.
Gruß
Damian
Hi,
ich teste gerade das neue Feature für meine Rollladensteuerung. Ich habe aber zu den wait Einträgen noch eine Verständnisfrage.
Ich möchte an Arbeitstagen den Rollladen_Kueche um 6:20 hochfahren lassen, WZ_Links und WZ_Rechts 15 Sekunden später und WZ_Mitte 30 Sekunden später. An Nicht-Arbeitstagen soll das Ganze erst um 8:00 beginnen, dann aber mit den gleichen Versätzen. Passt das so wie in meinem Beispiel oder ist für die wait Einträge immer 6:20 die Referenzzeit?
DOIF ([?Rollladensteuerung] eq "off" and [6:20|8])
(set Rollladen_Kueche on)
(set Rollladen_WZ_Links on)
(set Rollladen_WZ_Rechts on)
(set Rollladen_WZ_Mitte on)
DOELSE ([8:00|7])
(set Rollladen_Kueche on)
(set Rollladen_WZ_Links on)
(set Rollladen_WZ_Rechts on)
(set Rollladen_WZ_Mitte on)
attr <device> do resetwait
attr <device> wait 0,15,15,30:0,15,15,30
Viele Grüße,
Christoph
Zitat von: Fritz!Maxi am 22 Juli 2015, 22:42:34
Hi,
ich teste gerade das neue Feature für meine Rollladensteuerung. Ich habe aber zu den wait Einträgen noch eine Verständnisfrage.
Ich möchte an Arbeitstagen den Rollladen_Kueche um 6:20 hochfahren lassen, WZ_Links und WZ_Rechts 15 Sekunden später und WZ_Mitte 30 Sekunden später. An Nicht-Arbeitstagen soll das Ganze erst um 8:00 beginnen, dann aber mit den gleichen Versätzen. Passt das so wie in meinem Beispiel oder ist für die wait Einträge immer 6:20 die Referenzzeit?
DOIF ([?Rollladensteuerung] eq "off" and [6:20|8])
(set Rollladen_Kueche on)
(set Rollladen_WZ_Links on)
(set Rollladen_WZ_Rechts on)
(set Rollladen_WZ_Mitte on)
DOELSE ([8:00|7])
(set Rollladen_Kueche on)
(set Rollladen_WZ_Links on)
(set Rollladen_WZ_Rechts on)
(set Rollladen_WZ_Mitte on)
attr <device> do resetwait
attr <device> wait 0,15,15,30:0,15,15,30
Viele Grüße,
Christoph
Bei Zeittriggerung war eine Verzögerung per wait bisher nicht möglich. Diese Einschränkung wirkt sich leider auch auf die neue Funktionalität. Das werde ich in einer kommenden Version ändern. Solange musst du dich gedulden.
Grundsätzlich ist die Zeitspanne immer auf den vorherigen Befehl bezogen (entsprechend einem sleep).
Gruß
Damian
Ab morgen sind bei uns Ferien, da gilt sowieso nur $we ;)
Vielen Dank erst mal, da warte ich mit Freuden auf die neue Version!
Zitat von: Fritz!Maxi am 22 Juli 2015, 23:13:02
Ab morgen sind bei uns Ferien, da gilt sowieso nur $we ;)
Vielen Dank erst mal, da warte ich mit Freuden auf die neue Version!
Ich habe gerade Blödsinn erzählt. Ich habe es gerade mal mit Zeiten getestet - es funktioniert. Offenbar habe ich mehr programmiert als ich noch weiß ;)
Gruß
Damian
Zitat von: Damian am 22 Juli 2015, 23:16:47
Ich habe gerade Blödsinn erzählt. Ich habe es gerade mal mit Zeiten getestet - es funktioniert. Offenbar habe ich mehr programmiert als ich noch weiß ;)
Gruß
Damian
Perfekt, dann kann ich ja alle meine komplizierten notifies und ats umstellen.
Vielen Dank!
Zitat von: Fritz!Maxi am 22 Juli 2015, 23:26:20
Perfekt, dann kann ich ja alle meine komplizierten notifiies und ats umstellen.
Vielen Dank!
ja und gut testen bevor ich diese Version einchecke, wenn denn svn wieder läuft.
Gruß
Damian
Hallo Damian,
habe mittlerweile alle notify und at durch DOIF ausgewechselt, und bin hier und da schon über einige DOIF-Besonderheiten gestolpert, bspw. dieses tolle Feature (Auszug aus commandref): Hinzu kommt, dass nur die Bedingungen überprüft werden, die zum ausgelösten Event auch das Device beinhalten.
Heute habe ich allerdings einen Fall bei dem ich irgendwie nicht weiter komme. Folgende Definition funktioniert bei mir leider nicht wie erwartet:
define doif_modus_beleuchtung_flur DOIF ([doif_zeitschaltuhr_ambient_light] eq "on" or [licht_ambient_light_manuell] eq "on") (set licht_rgbufo_flur RGB 6E6E6E 3) \
DOELSEIF ([doif_zeitschaltuhr_ambient_light] eq "off" and [licht_ambient_light_manuell] eq "off" and [{sunset("REAL")}-{sunrise("REAL")}]) (set licht_rgbufo_flur RGB 424242 3) \
DOELSE (set licht_rgbufo_flur off 3)
attr doif_modus_beleuchtung_flur alias Modus Beleuchtung Flur
attr doif_modus_beleuchtung_flur cmdState on|nacht|auto
attr doif_modus_beleuchtung_flur initialize auto
attr doif_modus_beleuchtung_flur room Flur
Mit diesem DOIF steuere ich einen LED-Stripe in meinem Flur, es gibt drei Modi (an, nachtbetrieb und automatikbetrieb durch ein weiteres DOIF mit Bewegungsmelder). Ein Fall funktioniert nicht wie erwartet, nämlich im ersten Zweig. Wenn doif_zeitschaltuhr_ambient_light auf "on" wechselt bleibt das DOIF auf auto, erst wenn ich licht_ambient_light_manuell (beide sind über ein oder verknüpft) schalte schlägt der Nachtbetrieb on-Modus zu.
Wo habe ich da einen Denkfehler?
Grüße,
Markus
Zitat von: MarkusN am 23 Juli 2015, 22:18:11
Hallo Damian,
habe mittlerweile alle notify und at durch DOIF ausgewechselt, und bin hier und da schon über einige DOIF-Besonderheiten gestolpert, bspw. dieses tolle Feature (Auszug aus commandref): Hinzu kommt, dass nur die Bedingungen überprüft werden, die zum ausgelösten Event auch das Device beinhalten.
Heute habe ich allerdings einen Fall bei dem ich irgendwie nicht weiter komme. Folgende Definition funktioniert bei mir leider nicht wie erwartet:
define doif_modus_beleuchtung_flur DOIF ([doif_zeitschaltuhr_ambient_light] eq "on" or [licht_ambient_light_manuell] eq "on") (set licht_rgbufo_flur RGB 6E6E6E 3) \
DOELSEIF ([doif_zeitschaltuhr_ambient_light] eq "off" and [licht_ambient_light_manuell] eq "off" and [{sunset("REAL")}-{sunrise("REAL")}]) (set licht_rgbufo_flur RGB 424242 3) \
DOELSE (set licht_rgbufo_flur off 3)
attr doif_modus_beleuchtung_flur alias Modus Beleuchtung Flur
attr doif_modus_beleuchtung_flur cmdState on|nacht|auto
attr doif_modus_beleuchtung_flur initialize auto
attr doif_modus_beleuchtung_flur room Flur
Mit diesem DOIF steuere ich einen LED-Stripe in meinem Flur, es gibt drei Modi (an, nachtbetrieb und automatikbetrieb durch ein weiteres DOIF mit Bewegungsmelder). Ein Fall funktioniert nicht wie erwartet, nämlich im ersten Zweig. Wenn doif_zeitschaltuhr_ambient_light auf "on" wechselt bleibt das DOIF auf auto, erst wenn ich licht_ambient_light_manuell (beide sind über ein oder verknüpft) schalte schlägt der Nachtbetrieb zu.
Wo habe ich da einen Denkfehler?
Grüße,
Markus
Dann musst du die Ausgabe von "list doif_modus_beleuchtung_flur" von diesem Fall hier posten, sonst kann ich dazu nichts sagen.
Gruß
Damian
Internals:
CFGFN
DEF ([doif_zeitschaltuhr_ambient_light] eq "on" or [licht_ambient_light_manuell] eq "on") (set licht_rgbufo_flur RGB 6E6E6E 3)
DOELSEIF ([doif_zeitschaltuhr_ambient_light] eq "off" and [licht_ambient_light_manuell] eq "off" and [{sunset("REAL")}-{sunrise("REAL")}]) (set licht_rgbufo_flur RGB 424242 3)
DOELSE (set licht_rgbufo_flur off 3)
NAME doif_modus_beleuchtung_flur
NR 840
NTFY_ORDER 50-doif_modus_beleuchtung_flur
STATE nacht
TYPE DOIF
CHANGETIME:
Readings:
2015-07-23 22:30:00 cmd_event doif_zeitschaltuhr_ambient_light
2015-07-23 22:30:00 cmd_nr 2
2015-07-23 22:30:00 e_doif_zeitschaltuhr_ambient_light_STATE off
2015-07-22 21:35:08 e_licht_ambient_light_manuell_STATE off
2015-07-23 22:30:00 state nacht
2015-07-23 21:31:59 timer_1_c2 24.07.2015 21:30:40
2015-07-23 05:48:47 timer_2_c2 24.07.2015 05:50:08
Condition:
0 InternalDoIf('doif_zeitschaltuhr_ambient_light','STATE','') eq "on" or InternalDoIf('licht_ambient_light_manuell','STATE','') eq "on"
1 InternalDoIf('doif_zeitschaltuhr_ambient_light','STATE','') eq "off" and InternalDoIf('licht_ambient_light_manuell','STATE','') eq "off" and DOIF_time($hash->{realtime}{0},$hash->{realtime}{1},$wday,$hms,"")
Days:
Devices:
0 doif_zeitschaltuhr_ambient_light licht_ambient_light_manuell
1 doif_zeitschaltuhr_ambient_light licht_ambient_light_manuell
all doif_zeitschaltuhr_ambient_light licht_ambient_light_manuell
Do:
0:
0 set licht_rgbufo_flur RGB 6E6E6E 3
1:
0 set licht_rgbufo_flur RGB 424242 3
2:
0 set licht_rgbufo_flur off 3
Helper:
last_timer 2
sleeptimer -1
Internals:
0 doif_zeitschaltuhr_ambient_light:STATE licht_ambient_light_manuell:STATE
1 doif_zeitschaltuhr_ambient_light:STATE licht_ambient_light_manuell:STATE
all doif_zeitschaltuhr_ambient_light:STATE licht_ambient_light_manuell:STATE
Itimer:
Readings:
Realtime:
0 21:30:40
1 05:50:08
State:
Time:
0 {sunset("REAL")}
1 {sunrise("REAL")}
Timecond:
0 1
1 1
Timer:
0 0
1 0
Timerfunc:
Timers:
1 0 1
Trigger:
Attributes:
alias Modus Beleuchtung Flur
cmdState on|nacht|auto
initialize auto
room Flur
"e_doif_zeitschaltuhr_ambient_light_STATE off" war bis vor wenigen Minuten natürlich noch "e_doif_zeitschaltuhr_ambient_light_STATE on".
Zitat von: MarkusN am 23 Juli 2015, 22:43:39
Internals:
CFGFN
DEF ([doif_zeitschaltuhr_ambient_light] eq "on" or [licht_ambient_light_manuell] eq "on") (set licht_rgbufo_flur RGB 6E6E6E 3)
DOELSEIF ([doif_zeitschaltuhr_ambient_light] eq "off" and [licht_ambient_light_manuell] eq "off" and [{sunset("REAL")}-{sunrise("REAL")}]) (set licht_rgbufo_flur RGB 424242 3)
DOELSE (set licht_rgbufo_flur off 3)
NAME doif_modus_beleuchtung_flur
NR 840
NTFY_ORDER 50-doif_modus_beleuchtung_flur
STATE nacht
TYPE DOIF
CHANGETIME:
Readings:
2015-07-23 22:30:00 cmd_event doif_zeitschaltuhr_ambient_light
2015-07-23 22:30:00 cmd_nr 2
2015-07-23 22:30:00 e_doif_zeitschaltuhr_ambient_light_STATE off
2015-07-22 21:35:08 e_licht_ambient_light_manuell_STATE off
2015-07-23 22:30:00 state nacht
2015-07-23 21:31:59 timer_1_c2 24.07.2015 21:30:40
2015-07-23 05:48:47 timer_2_c2 24.07.2015 05:50:08
Condition:
0 InternalDoIf('doif_zeitschaltuhr_ambient_light','STATE','') eq "on" or InternalDoIf('licht_ambient_light_manuell','STATE','') eq "on"
1 InternalDoIf('doif_zeitschaltuhr_ambient_light','STATE','') eq "off" and InternalDoIf('licht_ambient_light_manuell','STATE','') eq "off" and DOIF_time($hash->{realtime}{0},$hash->{realtime}{1},$wday,$hms,"")
Days:
Devices:
0 doif_zeitschaltuhr_ambient_light licht_ambient_light_manuell
1 doif_zeitschaltuhr_ambient_light licht_ambient_light_manuell
all doif_zeitschaltuhr_ambient_light licht_ambient_light_manuell
Do:
0:
0 set licht_rgbufo_flur RGB 6E6E6E 3
1:
0 set licht_rgbufo_flur RGB 424242 3
2:
0 set licht_rgbufo_flur off 3
Helper:
last_timer 2
sleeptimer -1
Internals:
0 doif_zeitschaltuhr_ambient_light:STATE licht_ambient_light_manuell:STATE
1 doif_zeitschaltuhr_ambient_light:STATE licht_ambient_light_manuell:STATE
all doif_zeitschaltuhr_ambient_light:STATE licht_ambient_light_manuell:STATE
Itimer:
Readings:
Realtime:
0 21:30:40
1 05:50:08
State:
Time:
0 {sunset("REAL")}
1 {sunrise("REAL")}
Timecond:
0 1
1 1
Timer:
0 0
1 0
Timerfunc:
Timers:
1 0 1
Trigger:
Attributes:
alias Modus Beleuchtung Flur
cmdState on|nacht|auto
initialize auto
room Flur
"e_doif_zeitschaltuhr_ambient_light_STATE off" war bis vor wenigen Minuten natürlich noch "e_doif_zeitschaltuhr_ambient_light_STATE on".
Das ist doch der Fall der korrekt funktioniert. Es geht doch hier um den ersten Fall, der nicht funktioniert, den musst du mir zeigen.
Um dir das richtige list zur Verfügung zu stellen habe ich doif_zeitschaltuhr_ambient_light so geändert, dass es heute noch mal auf on wechselt, und dieses mal hat doif_modus_beleuchtung_flur wie erwartet funktioniert.
Normalerweise sieht doif_zeitschaltuhr_ambient_light so aus:
([{sunset("REAL",-3600)}-22:30]) DOELSE
In diesem Fall springt doif_modus_beleuchtung_flur nicht auf on. Jetzt gerade mit folgendem Zeitraum jedoch schon:
([22:55-23:30]) DOELSE
Das macht die Fehlersuche gerade nicht einfacher, und der Knoten im Kopf wird schlimmer. Ich kann dir anbieten morgen noch mal ein list zu posten wenn das Problem wieder auftreten wird.
Zitat von: Fritz!Maxi am 22 Juli 2015, 22:42:34
...
Ich möchte an Arbeitstagen den Rollladen_Kueche um 6:20 hochfahren lassen, WZ_Links und WZ_Rechts 15 Sekunden später und WZ_Mitte 30 Sekunden später. An Nicht-Arbeitstagen soll das Ganze erst um 8:00 beginnen, dann aber mit den gleichen Versätzen. Passt das so wie in meinem Beispiel oder ist für die wait Einträge immer 6:20 die Referenzzeit?
DOIF ([?Rollladensteuerung] eq "off" and [6:20|8])
(set Rollladen_Kueche on)
(set Rollladen_WZ_Links on)
(set Rollladen_WZ_Rechts on)
(set Rollladen_WZ_Mitte on)
DOELSE ([8:00|7])
(set Rollladen_Kueche on)
(set Rollladen_WZ_Links on)
(set Rollladen_WZ_Rechts on)
(set Rollladen_WZ_Mitte on)
attr <device> do resetwait
attr <device> wait 0,15,15,30:0,15,15,30
So, ich habe das jetzt erfolgreich testen können. Allerdings hatte ich noch einen Fehler drin. DOELSE muss natürlich DOELSEIF sein. DOELSE konnte mit der Zeitangabe nicht anfangen, was dazu führte dass um 6:20 geschaltet wurde. Nach der Änderung auf DOELSEIF wird wie gewollt um 8:00 geschaltet, mit dem jeweils angegebenen Versatz.
VG,
Christoph
Zitat von: Damian am 23 Juli 2015, 22:51:33
Das ist doch der Fall der korrekt funktioniert. Es geht doch hier um den ersten Fall, der nicht funktioniert, den musst du mir zeigen.
Der Knoten im Kopf ist weg, ich habe den Fehler gefunden. Folgende Erkenntnisse habe ich erlangt:
1) doif_modus_beleuchtung_flur funktioniert, das licht wird um {sunset("REAL",-3600)} eingeschaltet
2) um {sunset("REAL")} wird es jedoch wieder abgeschaltet (siehe zweite Bedingung im doif)
3) die erste bedingung war wahr, durch ein event in der zweiten bedingung (die allerdings auch nicht erfüllt wird) trifft plötzlich die dritte bedingung (doelse) zu
4) vielleicht hätte mir ein "do always" geholfen, bin mir aber über die möglichen nebenwirkungen noch nicht so klar
5) mir erschien es jetzt als sinnvoll in der zweiten Bedingung die Zeitangabe [{sunset("REAL")}-{sunrise("REAL")}] als nicht triggernd zu definieren
6) sogar vermutlich einfache Aufgaben können ungeahnte Effekte haben
7) DOIF ist trotzdem ein großartiges Modul
Grüße,
Markus
neues Update:
- Warnings behoben
- Initialisierungsproblem behoben http://forum.fhem.de/index.php/topic,38266.0.html
- Kommentare an beliebiger Stelle beginnend mit # bis zum Ende der Zeile möglich
- im Attribut wait können jetzt indirekte Angaben mit eckigen Klammern gemacht werden
Beispiel:
define wait_2 dummy
set wait_2 20
define di_on_for_timer DOIF ([Button:?]) # Hier ist die Bedingung: Trigger für beliebige Events von Button
# Diese Zeile besteht nur aus einem Kommentar
(set lamp on) # Hier wird die Lampe eingeschaltet
(set lamp off) # Hier wird die Lampe zeitversetzt ausgeschaltet
attr di_on_for_timer do resetwait
attr di_on_for_timer wait 0,[wait_2]
Neues Modul ist im ersten Post angehängt.
Gruß
Damian
Vielen Dank, Damian!
Eingebaut und erstes shutdown restart ohne das Initialisierungs-Problem :)
Zitat von: Ralli am 25 Juli 2015, 17:13:24
Vielen Dank, Damian!
Eingebaut und erstes shutdown restart ohne das Initialisierungs-Problem :)
Du musst noch mal updaten. Ansonsten funktionieren Module erst nach dem Neustart, wenn man sie zur Laufzeit neu definiert.
Gruß
Damian
Erledigt ;)
# $Id: 98_DOIF.pm Testversion 0.3$
Erster Test mit neuer Funktionalität: klappt leider nicht wie erwartet. cmd_1_1 wird ausgeführt, cmd_1_2 jedoch gar nicht.
Internals:
DEF ([CCU_Btn1:?trig_aes_GEN_FB_open: ok:.*])
({if ((AttrVal("UEA","level5xec","0") ne "disarmed" or AttrVal("UEA","level4xec","0") ne "disarmed") and ReadingsVal("GAR_MK_Tor","state","0") eq "closed"){
fhem("set UEA.Unscharf.4 .");;
fhem("set UEA.Unscharf.5 .")}})
(set GEN_4SW_GarageToggle on-for-timer 1)
DOELSE ()
NAME GEN_FB_Garage_Oeffner
NR 345
NTFY_ORDER 50-GEN_FB_Garage_Oeffner
STATE cmd_1_1
TYPE DOIF
CHANGETIME:
Helper:
Dblog:
Cmd_event:
Eventlog:
TIME 1437890205.03036
VALUE CCU_Btn1
Cmd_nr:
Eventlog:
TIME 1437890205.03036
VALUE 1
Cmd_seqnr:
Eventlog:
TIME 1437890205.03036
VALUE 1
State:
Eventlog:
TIME 1437890205.03036
VALUE cmd_1_1
Wait_timer:
Eventlog:
TIME 1437890206.00872
VALUE no timer
Readings:
2015-07-26 07:56:45 cmd_event CCU_Btn1
2015-07-26 07:56:45 cmd_nr 1
2015-07-26 07:56:45 cmd_seqnr 1
2015-07-26 07:56:45 e_CCU_Btn1_events trig_aes_GEN_FB_open: ok:114
2015-07-26 07:56:45 state cmd_1_1
2015-07-26 07:56:46 wait_timer no timer
Condition:
0 EventDoIf('CCU_Btn1',$hash->{helper}{triggerDev},$hash->{helper}{triggerEvents},'trig_aes_GEN_FB_open')
Devices:
0 CCU_Btn1
all CCU_Btn1
Do:
0:
0 {if ((AttrVal("UEA","level5xec","0") ne "disarmed" or AttrVal("UEA","level4xec","0") ne "disarmed") and ReadingsVal("GAR_MK_Tor","state","0") eq "closed"){ fhem("set UEA.Unscharf.4 .");; fhem("set UEA.Unscharf.5 .")}}
1 set GEN_4SW_GarageToggle on-for-timer 1
1:
0
Helper:
globalinit 1
last_timer 0
sleepdevice CCU_Btn1
sleepsubtimer -1
sleeptimer -1
triggerDev CCU_Btn1
triggerEvents:
trig_aes_GEN_FB_open: ok:114
Internals:
Itimer:
Readings:
State:
Timerfunc:
Trigger:
all CCU_Btn1
Attributes:
cmdpause 3
do always
wait 0,1
Zitat von: Ralli am 26 Juli 2015, 08:14:36
Erledigt ;)
# $Id: 98_DOIF.pm Testversion 0.3$
Erster Test mit neuer Funktionalität: klappt leider nicht wie erwartet. cmd_1_1 wird ausgeführt, cmd_1_2 jedoch gar nicht.
Attributes:
cmdpause 3
do always
wait 0,1
Es liegt an cmdpause. Das Problem hatte ich bereits gestern schon behoben, aber korrigierte Version noch nicht hochgeladen. Ich bin noch dabei weitere Features einzubauen - es gibt heute Abend eine neue Version.
Gruß
Damian
Hi,
da mir die neue Funktion wie gerufen kam, um mein Internetradio zu steuern, habe ich es gleich ausprobiert.
Das Internetradio funktioniert damit sehr gut, aber das folgende DOIF leider nicht.
Es wird ständig mein Schloss auf und zu geschlossen. Nachdem ich die alte Version des Moduls wieder installiert habe, geht alles wieder sehr gut (natürlich nicht mein Internetradio).
Hier mal die Definition:
define DI_SchlossAutoZu DOIF ([Tuer_Wohnung] eq "closed" and [Schloss] eq "unlocked") \
(set Schloss lock) \
DOELSEIF ([Tuer_Wohnung] eq "closed" and [Schloss] eq "locked (uncertain)") \
(set Schloss unlock,set PBText message "Tuerstatus locked (uncertain)",set Schloss lock) \
DOELSEIF ([Tuer_Wohnung] eq "closed" and [Schloss] eq "unlocked (uncertain)") \
(set Schloss unlock,set PBText message "Tuerstatus unlocked (uncertain)",set Schloss lock) \
DOELSEIF ([Tuer_Wohnung] eq "closed" and [Schloss] eq "NACK") \
(set Schloss unlock,set PBText message "Tuerstatus Nack",set Schloss lock) \
DOELSEIF ([Tuer_Wohnung] eq "closed" and [Schloss] eq "Motor aborted") \
(set Schloss unlock,set PBText message "Tuerstatus Motor aborted",set Schloss lock)\
DOELSEIF ([Tuer_Wohnung] eq "closed" and [Schloss] eq "MISSING ACK") \
(set Schloss lock,set PBText message "Tuerstatus MISSING ACK",set Schloss lock)
attr DI_SchlossAutoZu do always
attr DI_SchlossAutoZu room Anwesenheit,CUL_HM
attr DI_SchlossAutoZu wait 10:10:10:10:10:10
Trotzdedm vielen Dank an der Stelle für das wirklich tolle Modul.
Zitat von: Damian am 26 Juli 2015, 11:01:27
Es liegt an cmdpause. Das Problem hatte ich bereits gestern schon behoben, aber korrigierte Version noch nicht hochgeladen.
Sei ehrlich, Du wolltest nur schauen, ob wir auch testen ;).
Zitat
Ich bin noch dabei weitere Features einzubauen - es gibt heute Abend eine neue Version.
Sehr schön! Vielen Dank!
Hallo!
Bekomme ich auch einen Wait timer bei diesem Code hin?
([AbendLicht] eq "on") ({HueOnSofa};{HueOnSideBoard})
Version 0.4 im ersten Post.
- Problembehebung
- das disable-Attribut deaktiviert jetzt komplett das Modul (Timer werden gelöscht) weniger Performanceverbrauch
- set disable setzt das Modul in Zustand disable (Timer laufen weiter) der Zustand bleibt auch nach einem Neustart
- set initialize aktiviert ein inaktives Modul, bzw. setzt den Status auf initialized - der nächste Trigger führt zur Ausführung
- rechnen mit Waittimern, z. B.
attr di_modul wait ([wait_time1]+[wait_time2]-1)*2
- neues Attribut timerWithWait, wenn das Attribut gesetzt wird, wird auch bei Timern wait berücksichtigt.
Gruß
Damian
Zitat von: Steffen am 26 Juli 2015, 19:32:26
Hallo!
Bekomme ich auch einen Wait timer bei diesem Code hin?
([AbendLicht] eq "on") ({HueOnSofa};{HueOnSideBoard})
Wo soll der Waittimer hinkommen? Was ist HueOnSofa bzw. HueOnSideBoar?
Gruß
Damian
Zitat von: Damian am 26 Juli 2015, 21:23:14
Wo soll der Waittimer hinkommen? Was ist HueOnSofa bzw. HueOnSideBoar?
Gruß
Damian
Das sind jeweils zwei Perl Scripte die meine hue steuern mit Farbe und Dimmzeit und würde gerne den WaitTimer benutzen um die Scripte zeit verzörgert zu starten.
Würde das gehen?
Mfg Steffen
Zitat von: Steffen am 26 Juli 2015, 22:20:04
Das sind jeweils zwei Perl Scripte die meine hue steuern mit Farbe und Dimmzeit und würde gerne den WaitTimer benutzen um die Scripte zeit verzörgert zu starten.
Würde das gehen?
Mfg Steffen
Warum sollte es nicht gehen?
z. B.
([AbendLicht] eq "on") ({HueOnSofa}) ({HueOnSideBoard})
attr di_dein_modul wait 10,20Edit: habe es gerade korrigiert
Gruß
Damian
Hallo Damian,
wird bei der Verwendung der neuen wait Sleep Funktion auch noch das cmdState Attribut entsprechend erweitert?
Mir ist aufgefallen, dass der Status zwischendurch cmd_X_Y ist und nicht meiner cmdState Definition entspricht. Es sollte also zumindest bei vorhandenem cmdState der dort definierte Status auch für die Sub-Tasks hergenommen werden oder cmdState sollte dafür erweitert werden die Status mit Komma abgetrennt (optional) ebenfalls mit anzugeben.
Gruß
Julian
Zitat von: Loredo am 26 Juli 2015, 23:51:13
Hallo Damian,
wird bei der Verwendung der neuen wait Sleep Funktion auch noch das cmdState Attribut entsprechend erweitert?
Mir ist aufgefallen, dass der Status zwischendurch cmd_X_Y ist und nicht meiner cmdState Definition entspricht. Es sollte also zumindest bei vorhandenem cmdState der dort definierte Status auch für die Sub-Tasks hergenommen werden oder cmdState sollte dafür erweitert werden die Status mit Komma abgetrennt (optional) ebenfalls mit anzugeben.
Gruß
Julian
Es geht hier um Zwischenzustände. Für Endzustände bleibt bei cmdState alles wie bisher. Es wäre kein Problem kommagetrennte Zwischenzustände zu erlauben, es dürfte dann allerdings kein Komma im cmd-String in den bisherigen (und zukünftigen) Definitionen geben, sonst ist man nicht abwärtskompatibel.
Gruß
Damian
Zitat von: Damian am 27 Juli 2015, 07:54:17
Es geht hier um Zwischenzustände. Für Endzustände bleibt bei cmdState alles wie bisher.
Hm, ich frage in meinen Eventauswertungen sehr häufig den Status des DOIF Moduls selbst mittels [?di_name:state] ab (insbesondere meiner Beschattungssteuerung). Damit kann es dann also vorkommen, dass eine zuvor wahre Aussage während der Abarbeitung der verschiedenen Kommandos wieder unwahr wird, richtig? Hat das eine Auswirkung, sprich wird nach jedem Sleep nochmals geprüft und bei unwahr ggf. abgebrochen? Kann ja auch wünschenswert sein, nur eben (wie meist bei mir) nicht immer... deshalb war mir die Angabe des Zwischenzustandes im state aufgefallen.
Mit der Abwärtskompatibilität beim cmdState Attribut hast du natürlich recht. Unschön dabei, dass man dann inzwischen mehr und mehr unterschiedliche Notationen in Attributen vorfindet. Da blickt man bald nicht mehr so leicht durch :-[
Zitat von: Loredo am 27 Juli 2015, 10:03:40
Hm, ich frage in meinen Eventauswertungen sehr häufig den Status des DOIF Moduls selbst mittels [?di_name:state] ab (insbesondere meiner Beschattungssteuerung). Damit kann es dann also vorkommen, dass eine zuvor wahre Aussage während der Abarbeitung der verschiedenen Kommandos wieder unwahr wird, richtig? Hat das eine Auswirkung, sprich wird nach jedem Sleep nochmals geprüft und bei unwahr ggf. abgebrochen? Kann ja auch wünschenswert sein, nur eben (wie meist bei mir) nicht immer... deshalb war mir die Angabe des Zwischenzustandes im state aufgefallen.
Mit der Abwärtskompatibilität beim cmdState Attribut hast du natürlich recht. Unschön dabei, dass man dann inzwischen mehr und mehr unterschiedliche Notationen in Attributen vorfindet. Da blickt man bald nicht mehr so leicht durch :-[
Es gibt mehrere Lösungsansätze. Man könnte z. B. über ein (neues) Attribut das Setzen der Zwischenzustände abschalten oder erst mal grundsätzlich per default den Status mit Zwischenzuständen nicht belegen und per Attribut einschaltbar machen. Ich kann noch nicht abschätzen was günstiger wäre.
Andererseits könntest du in deinen Abfragen statt DOELSE, z. B. DOELSEIF ([di_modul:cmd2]) abfragen.
Gruß
Damian
Mal zur Info:
Man kann jetzt mit der neuen Version auch solche Sachen machen:
define di_Zufall DOIF ([:00]) (set bla on)
attr di_Zufall do always
attr di_Zufall timerWithWait
attr di_Zufall wait rand(60)
Gruß
Damian
Hallo Damian,
da Du momentan wieder so aktiv programmierst, wollte ich Dich nochmal auf das Thema RegExp auf mehrere Devices bringen - ja ich weiß, ist nicht unbedingt DIREKT in Perl umsetzbar.
Aber Du findest ganz bestimmt eine interne Lösung :)
Für z.B. solche Sachen, die jetzt über Umweg realisiert werden:
define Helper notify .*:[Bb]attery.*[Ll]ow.* {
if (!($defs{"DOIF_lowbat_".$NAME})) {fhem("
define DOIF_lowbat_".$NAME." DOIF ([".$NAME.":?[Bb]attery.*[Ll]ow.*]) (set UEA.Batterie_niedrig ".$NAME.")
DOELSEIF ([".$NAME.":?[Bb]attery.*[Oo][Kk].*]) ()");fhem("
attr DOIF_lowbat_".$NAME." wait 3600:0");fhem("
define trigger_".$NAME." at +00:00:05 trigger ".$NAME)
}
}
Zitat von: Ralli am 28 Juli 2015, 12:42:49
Hallo Damian,
da Du momentan wieder so aktiv programmierst, wollte ich Dich nochmal auf das Thema RegExp auf mehrere Devices bringen - ja ich weiß, ist nicht unbedingt DIREKT in Perl umsetzbar.
Aber Du findest ganz bestimmt eine interne Lösung :)
Für z.B. solche Sachen, die jetzt über Umweg realisiert werden:
define Helper notify .*:[Bb]attery.*[Ll]ow.* {
if (!($defs{"DOIF_lowbat_".$NAME})) {fhem("
define DOIF_lowbat_".$NAME." DOIF ([".$NAME.":?[Bb]attery.*[Ll]ow.*]) (set UEA.Batterie_niedrig ".$NAME.")
DOELSEIF ([".$NAME.":?[Bb]attery.*[Oo][Kk].*]) ()");fhem("
attr DOIF_lowbat_".$NAME." wait 3600:0");fhem("
define trigger_".$NAME." at +00:00:05 trigger ".$NAME)
}
}
So etwas könnte man auf Events einschränken, also nur in Kombination mit Fragezeichen. Allerdings müsste ich intern einiges umstellen. Ich kann es auf die Todo-Liste setzen.
Gruß
Damian
Sehr schön :) Danke !
Ich denke, hier ist in zwei Richtungen zu denken:
1) In den Bedingungen eines DOIF auf unbestimmte Devices zu triggern (also z.B. mittels RegExp wie bei notify oder watchdog) ist das eine und dürfte - auch bei wahrscheinlich einigen Umstellungen - noch gut realisierbar sein.
2) Die eigentliche Herausforderung wird sein, zu erreichen, entsprechende "Nachbedingungen" dem auslösenden Device zuzordnen, dafür werden wahrscheinlich pro auslösendem Device entsprechende InternalDOIFs gebaut werden müssen.
Also:
define doif wenn device.*:Bedingung dann set dummy1 $NAME sonst set dummy2 $NAME
attr doif wait 60:60
Nun kann device.*:Bedingung durch mehrere Devices ausgelöst werden. Pro auslösendem Device sollten die auslösenden wait-timer mitgeführt und dann die entsprechenden cmd_1 bzw. cmd_2 ausgelöst werden. Die einfachere aber unflexiblere Möglichkeit wäre, die wait-timer und cmd-Auslösung "einfach" mitzuführen und auszulösen - wenn das Suchmuster passt, wird halt getriggert, dann sollte aber zumindest vor der weiteren Abarbeitung des DOIF irgendwo das auslösende Device und der auslösende Event verarbeitbar sein. So besteht nur die Gefahr, dass die Bedingung 1 durch ein Device gesetzt und die Sonst-Bedingung 2 durch ein anderes Device gesetzt werden kann. Schön wäre es daher, in DOELSEIF-Bedingungen auf das Device reagieren zu können, was in der DOIF-Definition auch den Auslöser gesetzt hat.
Hartes Stück Arbeit.
Zitat von: Ralli am 28 Juli 2015, 13:47:30
Sehr schön :) Danke !
Ich denke, hier ist in zwei Richtungen zu denken:
1) In den Bedingungen eines DOIF auf unbestimmte Devices zu triggern (also z.B. mittels RegExp wie bei notify oder watchdog) ist das eine und dürfte - auch bei wahrscheinlich einigen Umstellungen - noch gut realisierbar sein.
2) Die eigentliche Herausforderung wird sein, zu erreichen, entsprechende "Nachbedingungen" dem auslösenden Device zuzordnen, dafür werden wahrscheinlich pro auslösendem Device entsprechende InternalDOIFs gebaut werden müssen.
Also:
define doif wenn device.*:Bedingung dann set dummy1 $NAME sonst set dummy2 $NAME
attr doif wait 60:60
Nun kann device.*:Bedingung durch mehrere Devices ausgelöst werden. Pro auslösendem Device sollten die auslösenden wait-timer mitgeführt und dann die entsprechenden cmd_1 bzw. cmd_2 ausgelöst werden. Die einfachere aber unflexiblere Möglichkeit wäre, die wait-timer und cmd-Auslösung "einfach" mitzuführen und auszulösen - wenn das Suchmuster passt, wird halt getriggert, dann sollte aber zumindest vor der weiteren Abarbeitung des DOIF irgendwo das auslösende Device und der auslösende Event verarbeitbar sein. So besteht nur die Gefahr, dass die Bedingung 1 durch ein Device gesetzt und die Sonst-Bedingung 2 durch ein anderes Device gesetzt werden kann. Schön wäre es daher, in DOELSEIF-Bedingungen auf das Device reagieren zu können, was in der DOIF-Definition auch den Auslöser gesetzt hat.
Hartes Stück Arbeit.
Ich habe auch gerade nachgedacht und mir einen internen Lösungsweg überlegt (ist wahrscheinlich einfacher als ich dachte). Nach außen muss man die RegExp besonders kennzeichnen, sonst kann ich intern nicht zwischen Devices und Zeiten unterscheiden.
Eine Möglichkeit wäre die RegExp für Devices in Anführungszeichen zu setzen, z. B.
Alle Devices mit entsprechendem Event (mit Fragezeichen vor der Eventangabe wie bisher)
[ ".*":?[Bb]attery.*[Ll]ow.*] Status des Trigger-Devices, das "window" im Namen beinhaltet (im Gegensatz zu notify wird intern kein ^ und $ gesetzt)
["window":state]
ohne Triggerung, wie bisher mit Fragezeichen vor dem Device.
[?"window":state]
Reading "state" des Trigger-Devices, das "window" im Namen beinhalten.
["window":state]RegExp für Readings halte ich nicht für sinnvoll.
Waittimer gelten immer für die entsprechenden Ausführungsteile nicht für Devices in der Bedingung - das muss so bleiben.
Gruß
Damian
Damian, Danke für die Weiterentwicklung :D Die neue Sleep-Variante und Zufallszahlen im Wait kann ich gut gebrauchen!
Eine Erweiterungsidee habe ich noch. Heute geht bereits:
ZitatIndirekte Zeitangaben lassen sich mit Wochentagangaben kombinieren, z. B.:
define di_time DOIF ([[begin]-[end]|7]) (set radio on) DOELSE (set radio off)
Dort den Wochentag auch als Variable anzugeben wäre total hilfreich, also so:
define di_time DOIF ([[begin]-[end]|[day]]) (set radio on) DOELSE (set radio off)Grüße
Alex
Zitat von: All-Ex am 28 Juli 2015, 15:06:14
Damian, Danke für die Weiterentwicklung :D Die neue Sleep-Variante und Zufallszahlen im Wait kann ich gut gebrauchen!
Eine Erweiterungsidee habe ich noch. Heute geht bereits:
Dort den Wochentag auch als Variable anzugeben wäre total hilfreich, also so:
define di_time DOIF ([[begin]-[end]|[day]]) (set radio on) DOELSE (set radio off)
Grüße
Alex
Hast du einen konkreten Anwendungsfall? Normalerweise hängen Zeiten mit Wochentagen zusammen und die kann man mit or verknüpfen.
Gruß
Damian
Zitat von: Damian am 28 Juli 2015, 14:50:26
Ich habe auch gerade nachgedacht und mir einen internen Lösungsweg überlegt (ist wahrscheinlich einfacher als ich dachte).
:)
Zitat
Eine Möglichkeit wäre die RegExp für Devices in Anführungszeichen zu setzen, z. B.
Alle Devices mit entsprechendem Event (mit Fragezeichen vor der Eventangabe wie bisher)
[ ".*":?[Bb]attery.*[Ll]ow.*]
Also
[".*":battery] eq "low"
[?".*":battery] eq "low"
[".*":?battery.*low]
[".*":&Internal] eq "blub"
Damit wären alle bisherigen Möglichkeiten plus Device-übergreifend abgedeckt! Top.
Zitat
RegExp für Readings halte ich nicht für sinnvoll.
Ist doch über [".*":?battery.*low] abgedeckt?
Zitat
Waittimer gelten immer für die entsprechenden Ausführungsteile nicht für Devices in der Bedingung - das muss so bleiben.
Ja - aber :).
Wie geschrieben sehe ich hier ein Problem, wenn sich ein alternativer Ausführungsteil auf einen Ausführungsteil beziehen soll, der von einem anderen Device angetriggert wurde. Also das klassische Device-Übergreifende Watchdog-Problem. Nochmal ein Beispiel:
define Beispiel DOIF (["device.*"] eq "on") (set dummy1 §dev1:NAME) DOELSEIF ([§dev1] eq "off") (set dummy2 §dev1:NAME)
attr doif wait 60:60
Wenn Bedingung1 zutrifft, dann dummy1 mit dem auslösenden Devicenamen setzen. Wenn dieses auslösende Device in den state "off" wechselt, dann den dummy2 mit dem Devicenamen des Auslösers setzen.
Wenn Du hingegen
define Beispiel DOIF (["device.*"] eq "on") (set dummy1 §dev1:$NAME) DOELSEIF (["device.*"] eq "off") (set dummy2 §dev1:NAME)
attr doif wait 60:60
verwendest, kann irgendein device1 die Bedingung1 erfüllen und irgendein device2 die Alternativ-Bedingung erfüllen. Auch sinnvoll aber nicht alleine glückbringend :).
Zitat von: Ralli am 28 Juli 2015, 15:32:45
Ist doch über [".*":?battery.*low] abgedeckt?
hier wird das Event des Triggers ausgewertet nicht das Reading. Readings werden ohne Fragezeichen angegeben und ausgewertet. Diese müssen für das jeweilige Device eindeutig sein.
ZitatWie geschrieben sehe ich hier ein Problem, wenn sich ein alternativer Ausführungsteil auf einen Ausführungsteil beziehen soll, der von einem anderen Device angetriggert wurde. Also das klassische Device-Übergreifende Watchdog-Problem. Nochmal ein Beispiel:
define Beispiel DOIF (["device.*"] eq "on") (set dummy1 §dev1:NAME) DOELSEIF ([§dev1] eq "off") (set dummy2 §dev1:NAME)
attr doif wait 60:60
Wenn Bedingung1 zutrifft, dann dummy1 mit dem auslösenden Devicenamen setzen. Wenn dieses auslösende Device in den state "off" wechselt, dann den dummy2 mit dem Devicenamen des Auslösers setzen.
Wenn Du hingegen
define Beispiel DOIF (["device.*"] eq "on") (set dummy1 §dev1:$NAME) DOELSEIF (["device.*"] eq "off") (set dummy2 §dev1:NAME)
attr doif wait 60:60
verwendest, kann irgendein device1 die Bedingung1 erfüllen und irgendein device2 die Alternativ-Bedingung erfüllen. Auch sinnvoll aber nicht alleine glückbringend :).
Das wird auch der Grund sein, warum Rudi den Watchdog nicht devices-übergreifend programmiert hat. Auch im DOIF ist die einzige Gemeinsamkeit der Zustand des Moduls, ansonsten "wissen" die Bedingungen nichts von einander. Alles andere ist schwierig, weil man beliebig Bedingungen definieren kann.
Gruß
Damian
Ja, genau da liegt die besondere Herausforderung.
Wäre es nicht eine Idee, pro auslösendem Device einen Readings-Satz anzulegen, so wie Du es ja jetzt eigentlich schon für die auslösenden Trigger der tangierten Devices machst?
Es gibt ja bspw.
cmd_event GEN_Aussensensor 2015-07-28 13:46:19
cmd_nr 5 2015-07-28 13:46:19
e_GEN_Aussensensor_luminosity 7653 2015-07-28 16:18:41
e_GEN_Aussensensor_temperature 23.3 2015-07-28 16:18:41
e_Wetter_condition überwiegend wolkig 2015-07-28 16:13:52
e_Wetter_fc1_condition teilweise wolkig 2015-07-28 16:13:52
e_Wetter_fc1_high_c 19 2015-07-28 16:13:52
Um auslösende Devices mit zu erfassen, könnte man es doch genau so machen - pro auslösendem Device mit Reading und Value und Zeitstempel halt ein e_....
Dann müsste nur noch die Art und Weise der Weiterverarbeitung in den jeweiligen DOIF-Zweigen und -Bedingungen durchdacht werden und natürlich auch eine Variablen-Belegung für das aktuell triggernde Device und auslösende Event (also $NAME und $EVENT). Zum Beispiel nach folgendem Schema:
define Beispiel DOIF ([".*":battery] eq "low") (set dummy1 $NAME) DOELSEIF ([".*":battery] eq "ok" and [?Beispiel:e_$NAME_battery_prev] eq "low") (set dummy2 $NAME)
attr doif wait 60:0
... setze also dummy1 mit dem auslösenden Device, wenn 60 Sekunden kein anderer state erfolgt (und wenn noch kein e_$NAME_battery-Reading, lege es an mit den entsprechenden Werten; wenn bereits ein e_$NAME_battery besteht, schiebe die "alten" Werte in e_$NAME_battery_prev und belege die Werte von e_$NAME_battery neu). Ein anderer State kann erfolgen, wenn irgendein Device (also auch das primär auslösende) ok ist UND für dieses Device ein Reading (s.o.) im eigenen DOIF besteht, welches den Wert low hat.
Zitat von: Ralli am 28 Juli 2015, 16:33:55
Ja, genau da liegt die besondere Herausforderung.
Wäre es nicht eine Idee, pro auslösendem Device einen Readings-Satz anzulegen, so wie Du es ja jetzt eigentlich schon für die auslösenden Trigger der tangierten Devices machst?
Es gibt ja bspw.
cmd_event GEN_Aussensensor 2015-07-28 13:46:19
cmd_nr 5 2015-07-28 13:46:19
e_GEN_Aussensensor_luminosity 7653 2015-07-28 16:18:41
e_GEN_Aussensensor_temperature 23.3 2015-07-28 16:18:41
e_Wetter_condition überwiegend wolkig 2015-07-28 16:13:52
e_Wetter_fc1_condition teilweise wolkig 2015-07-28 16:13:52
e_Wetter_fc1_high_c 19 2015-07-28 16:13:52
Um auslösende Devices mit zu erfassen, könnte man es doch genau so machen - pro auslösendem Device mit Reading und Value und Zeitstempel halt ein e_....
Dann müsste nur noch die Art und Weise der Weiterverarbeitung in den jeweiligen DOIF-Zweigen und -Bedingungen durchdacht werden und natürlich auch eine Variablen-Belegung für das aktuell triggernde Device und auslösende Event (also $NAME und $EVENT). Zum Beispiel nach folgendem Schema:
define Beispiel DOIF ([".*":battery] eq "low") (set dummy1 $NAME) DOELSEIF ([".*":battery] eq "ok" and [?Beispiel:e_$NAME_battery] eq "low") (set dummy2 $NAME)
attr doif wait 60:0
... setze also dummy1 mit dem auslösenden Device, wenn 60 Sekunden kein anderer state erfolgt. Ein anderer State kann erfolgen, wenn irgendein Device (also auch das primär auslösende) ok ist UND für dieses Device ein Reading im eigenen DOIF besteht, welches den Wert low hat.
ja, da muss man sich ein schlüssiges Konzept ausdenken und paar mal drüber schlafen.
Gruß
Damian
Daumen hoch !! (hab oben noch mal was geändert)
Nach einigem Denken ist mir noch was eingefallen, was bei o.a. Konstellation mit bedacht werden muss:
Device 1 triggert auf cmd_1 und löst den wait-timer aus.
Device 2 kämme nun auch noch mit einem battery low.
Device 2 kommt nun innerhalb von 60 Sekunden wieder mit einem battery ok. cmd_2 löst damit aus und unterbricht den wait-timer von cmd_1.
Device 1 ist zwar immer noch low, triggert aber nicht mehr.
Somit wäre eigentlich folgende Funktionalität (also doch RegExp auf Reading) erforderlich, um das abzufangen:
define Beispiel DOIF ([".*":battery] eq "low") (set dummy1 $NAME) DOELSEIF ([".*":battery] eq "ok" and !([?"Beispiel:e_.*_battery.*low"])) (set dummy2 $NAME)
attr Beispiel wait 60:0
Sollte bewirken, dass irgendein Device mit Battery=low den wait-timer für cmd_1 auslöst. cmd_2 wird nur ausgelöst (und unterbricht damit cmd_1), wenn ein Device Battery=ok meldet UND KEIN EINZIGES aktuelles(!) Battery-Reading irgendeines Devices im DOIF mehr mit Wert low existiert (immer davon ausgehend, dass vor der Auswertung der Readings bereits diese Readings mit den Device- und Event-Werten des Triggers gefüttert werden bzw. die alten in ..._prev geschoben werden).
Ich muß hier mal eben was loswerden:
@Damian
Ich bin begeistert was man alles mit Deinem DOIF Modul anstellen kann. Jetzt wo Du auch noch die erweiterten Wait Funktionen eingebaut hast, ist mein config gleich wieder einwenig geschrumpft. Ich bin erst seit gut einem halben Jahr Fhem infiziert, und so ziemlich früh mit DOIF in Berührung gekommen. Also ich meine ich kenne die Zeiten vor DOIF nicht.
Ich habe von Anfang an versucht so wenig verschiedenen Module wie möglich einzusetzen. So versuche ich meine Ideen immer erst per DOIF zu lösen und nur wenn das nicht geht, greife ich zur commandref.
Leider konnte ich dank Deines Moduls noch nicht alzuviele Module einsetzten, weil einfach jede noch so kranke Idee mit DOIF umsetzbar war.
Manchmal habe ich das Gefühl das ich nicht mit Fhem sondern mit DOIF arbeite :-)
Lange Rede... Ein groooßes Lob und Danke Schön für Deine Arbeit.
Ich ziehe den Hut vor soviel Einfallsreichtum und Energie, und freue mich über jede weitere Entwicklung dieses in meinen Augen schon perfekten Moduls. Ich hoffe nur Du packst nicht irgendwann soviel Features hinein, das es instabil wird.
Also, weiter so....
--Skusi
Hi Damian!
Zitat von: Damian am 28 Juli 2015, 15:10:51
Hast du einen konkreten Anwendungsfall? Normalerweise hängen Zeiten mit Wochentagen zusammen und die kann man mit or verknüpfen.
Ich habe eine sonnenstandsabhängige Rollladensteuerung mit DOIF gebaut. An einem Wochentag ist "Putztag", während dessen von einer Start- bis zu einer Endeuhrzeit die Rollläden nicht bewegt werden sollen, um das Fensterputzen nicht zu stören.
Aktuell habe ich den Putztag fest auf Donnerstag (4) eingestellt:
([wet.twilight:azimuth]>124 and
[wet.twilight:azimuth]<266 and
[wet.yrno:temp]>22 and
not [?[putztag.start]-[putztag.ende]|4])
(set <fahre rollos halb runter...>)
DOELSEIF
(<irgendwann>)
(<fahre Rollos wieder rauf...>) Um auch für den Wochentag einen Dummy zu verwenden, der im Webinterface konfiguriert werden kann, könnte ich wahrscheinlich in etwa dies bauen:
and not ([?[putztag.start]-[putztag.ende]] and $wday==[?putztag.tag]) Aber eleganter und einfacher zu lesen wäre m.E.
and not [?[putztag.start]-[putztag.ende]|[putztag.tag]] Viele Grüße,
Alex
Zitat von: All-Ex am 28 Juli 2015, 21:27:12
Hi Damian!Ich habe eine sonnenstandsabhängige Rollladensteuerung mit DOIF gebaut. An einem Wochentag ist "Putztag", während dessen von einer Start- bis zu einer Endeuhrzeit die Rollläden nicht bewegt werden sollen, um das Fensterputzen nicht zu stören.
Aktuell habe ich den Putztag fest auf Donnerstag (4) eingestellt:
([wet.twilight:azimuth]>124 and
[wet.twilight:azimuth]<266 and
[wet.yrno:temp]>22 and
not [?[putztag.start]-[putztag.ende]|4])
(set <fahre rollos halb runter...>)
DOELSEIF
(<irgendwann>)
(<fahre Rollos wieder rauf...>)
Um auch für den Wochentag einen Dummy zu verwenden, der im Webinterface konfiguriert werden kann, könnte ich wahrscheinlich in etwa dies bauen:
and not ([?[putztag.start]-[putztag.ende]] and $wday==[?putztag.tag])
Aber eleganter und einfacher zu lesen wäre m.E.
and not [?[putztag.start]-[putztag.ende]|[putztag.tag]]
Viele Grüße,
Alex
OK, kommt dann auf die Todo-Liste.
Gruß
Damian
Zitat von: Skusi am 28 Juli 2015, 21:08:19
Ich muß hier mal eben was loswerden:
@Damian
Ich bin begeistert was man alles mit Deinem DOIF Modul anstellen kann. Jetzt wo Du auch noch die erweiterten Wait Funktionen eingebaut hast, ist mein config gleich wieder einwenig geschrumpft. Ich bin erst seit gut einem halben Jahr Fhem infiziert, und so ziemlich früh mit DOIF in Berührung gekommen. Also ich meine ich kenne die Zeiten vor DOIF nicht.
Ich habe von Anfang an versucht so wenig verschiedenen Module wie möglich einzusetzen. So versuche ich meine Ideen immer erst per DOIF zu lösen und nur wenn das nicht geht, greife ich zur commandref.
Leider konnte ich dank Deines Moduls noch nicht alzuviele Module einsetzten, weil einfach jede noch so kranke Idee mit DOIF umsetzbar war.
Manchmal habe ich das Gefühl das ich nicht mit Fhem sondern mit DOIF arbeite :-)
Lange Rede... Ein groooßes Lob und Danke Schön für Deine Arbeit.
Ich ziehe den Hut vor soviel Einfallsreichtum und Energie, und freue mich über jede weitere Entwicklung dieses in meinen Augen schon perfekten Moduls. Ich hoffe nur Du packst nicht irgendwann soviel Features hinein, das es instabil wird.
Also, weiter so....
--Skusi
Danke für´s Kompliment. Keine Sorge, immerhin greife ich auf mehr oder weniger 30 Jahre Softwareentwicklung zurück, das letzte Jahrzehnt allerdings nur privat, beruflich unterrichtend, da weiß ich, dass man vorsichtig Neuerungen einführen muss. Nicht umsonst ist diese Version noch nicht eingecheckt, weil sie an zentraler Stelle Änderungen erfahren hat. Wenn genügend Tester sich nicht beschweren und mein Haus in den nächsten Tagen nicht explodiert ist :), werde ich sie einchecken.
Gruß
Damian
Ich kann mich dem Lob voll und ganz anschließen. Ich kenne Fhem erst seit kurzem. Und kenne auch kaum andere Module außerhalb der DOIF-Welt. Wobei die Entwickler sicherlich auch eine wahre Meisterleistung abliefern.
Damian, danke dir. Fürs Modul und für den Support.
Zitat von: Damian am 28 Juli 2015, 21:41:35
OK, kommt dann auf die Todo-Liste.
Gruß
Damian
Perfekt, Danke :)
Version 0.6
Neue Readings im Modul:
Device (aktuelles Device des Triggers)
Event (aktuelles Event)
Beide Readings lassen sich im Ausführungsteil abfragen - sie werden vor der Ausführung bereits gesetzt.
Gruß
Damian
Damian, vielen vielen Dank!
Der erste Schritt für generisch-Device-übergreifende DOIFs, toll!
Nun bin ich ein paar Tage (leider ;)) nicht in der Lage, fleissig mit zu experimentieren, bin unterwegs. Daher die Frage, wie hast Du es nun realisiert, gibt es Device-spezifische Events, also pro Device ein Event-Reading? Da du nun (in meinen Augen richtigerweise) das Reading vor der Abarbeitung setzt, baust du noch ein prev(ious)-Reading pro Device ein, wo der zuletzt auslösende Event immer mitgeführt wird? Würde einige Dinge in der Abarbeitung vereinfachen (siehe mein Beitrag weiter oben).
Ich habe erstmal die PM-Datei aus dem ersten Post hochgeladen und ein Reload durchgeführt.
Ich weiß (noch) nicht, ob das zusammenhängt, aber es erschienen folgende Fehler und nun ist mein FHEM nicht mehr erreichbar. Ich begebe mich auf Fehlersuche.
Too many arguments for main::DOIF_SetSleepTimer at ./FHEM/98_DOIF.pm line 712, near "1)"
Too many arguments for main::DOIF_cmd at ./FHEM/98_DOIF.pm line 713, near "$event)"
Too many arguments for main::DOIF_SetSleepTimer at ./FHEM/98_DOIF.pm line 748, near "$timerNr)"
Too many arguments for main::DOIF_SetSleepTimer at ./FHEM/98_DOIF.pm line 761, near "$timerNr)"
Update: Sieht nach Fehlalarm aus. Scheinbar hatte ich einen anderen Bock im System. Sorry.
Hallo,
nach dem Einspielen der Datei ist ein shutdown restart erforderlich (steht irgendwo im Thread - ich glaube, erster Post)...
Ronny
Zitat von: Damian am 26 Juli 2015, 20:41:05
- das disable-Attribut deaktiviert jetzt komplett das Modul (Timer werden gelöscht) weniger Performanceverbrauch
- set disable setzt das Modul in Zustand disable (Timer laufen weiter) der Zustand bleibt auch nach einem Neustart
- set initialize aktiviert ein inaktives Modul, bzw. setzt den Status auf initialized - der nächste Trigger führt zur Ausführung
Hi Damian,
folgendes in diesem Zusammenhang...k.A. ob es ein bug ist, oder ob ich zu doof bin...
Ich habe Dummies, um diverse Automatiken an- und auszuschalten.
Der Dummy wird von einem DOIF abgefragt und in den Automatiken sind auch DOIFs.
Beispiel Dummy:
Internals:
CFGFN ./FHEM/999_automatik.cfg
NAME du_eg_rollos_beschattung_an_aus
NR 139
STATE on
TYPE dummy
Readings:
2015-07-31 18:56:16 state on
Attributes:
alias EG Rollos Beschattungsautomatik
devStateIcon on:general_an@green:off off:general_aus@red:on
room 105_Esszimmer,105_Wohnzimmer "Abfrage-DOIF":
Internals:
CFGFN ./FHEM/999_automatik.cfg
DEF ([du_eg_rollos_beschattung_an_aus] eq "off") (set di_eg_rollos_beschattung.* disable) DOELSE (set di_eg_rollos_beschattung.* initialize)
NAME di_eg_rollos_beschattung_an_aus
NR 140
NTFY_ORDER 50-di_eg_rollos_beschattung_an_aus
STATE cmd_1
TYPE DOIF
Readings:
2015-07-31 18:56:11 Device du_eg_rollos_beschattung_an_aus
2015-07-31 18:56:11 Event off
2015-07-31 18:56:11 cmd_event du_eg_rollos_beschattung_an_aus
2015-07-31 18:56:11 cmd_nr 1
2015-07-31 18:56:11 e_du_eg_rollos_beschattung_an_aus_STATE off
2015-07-31 18:56:11 mode disabled
2015-07-31 18:56:11 state cmd_1
Condition:
0 InternalDoIf('du_eg_rollos_beschattung_an_aus','STATE','') eq "off"
Devices:
0 du_eg_rollos_beschattung_an_aus
all du_eg_rollos_beschattung_an_aus
Do:
0:
0 set di_eg_rollos_beschattung.* disable
1:
0 set di_eg_rollos_beschattung.* initialize
Helper:
globalinit 1
last_timer 0
sleeptimer -1
Internals:
0 du_eg_rollos_beschattung_an_aus:STATE
all du_eg_rollos_beschattung_an_aus:STATE
Itimer:
Readings:
State:
Timerfunc:
Trigger:
Attributes:
room 999_Automatiken Die "zu schaltenden" DOIFs heißen:
di_eg_rollos_beschattung_suedund
di_eg_rollos_beschattung_westMit dieser Konstellation schaffe ich es GENAU EINMAL mit dem Dummy die "zu schaltenden" DOIFs in den Status disabled zu bringen und das wars. In den Status initialize bekomme ich sie nicht mehr...
Steht im Ausführungsteil des "Abfrage-DOIFs"
(set di_eg_rollos_beschattung.*(sued|west) disable) DOELSE (set di_eg_rollos_beschattung.*(sued|west) initialize)kann ich fröhlich hin und her schalten...
Mach ich da was falsch, oder woran kann es liegen?
Gruß
Andreas
Zitat von: Vize am 31 Juli 2015, 19:11:42
"Abfrage-DOIF":
Internals:
CFGFN ./FHEM/999_automatik.cfg
DEF ([du_eg_rollos_beschattung_an_aus] eq "off") (set di_eg_rollos_beschattung.* disable) DOELSE (set di_eg_rollos_beschattung.* initialize)
NAME di_eg_rollos_beschattung_an_aus
NR 140
NTFY_ORDER 50-di_eg_rollos_beschattung_an_aus
STATE cmd_1
TYPE DOIF
Readings:
2015-07-31 18:56:11 Device du_eg_rollos_beschattung_an_aus
2015-07-31 18:56:11 Event off
2015-07-31 18:56:11 cmd_event du_eg_rollos_beschattung_an_aus
2015-07-31 18:56:11 cmd_nr 1
2015-07-31 18:56:11 e_du_eg_rollos_beschattung_an_aus_STATE off
2015-07-31 18:56:11 mode disabled
2015-07-31 18:56:11 state cmd_1
Ich glaube du machst was falsch.
Mit "set di_eg_rollos_beschattung.* disable" hat sich dein doif-modul selbst ausgeschaltet. Wie soll es sich dann jemals selbst wieder einschalten, wenn es ausgeschaltet ist?
Gruß
Damian
Jau, jetzt seh ich es auch...
Danke fürs lösen des vorm Kopf befindlichen Brettes!!!
Gruß
Andreas
Version 0.7
indirekte Wochentagangaben:
([21:00|[wday])(...)
Gruß
Damian
Hallo
Mit deinen neuen Feature wollte ich meine notify und watchdog ablösen aber irgendwo ist da noch ein
Fehler drin. Meine Maschine soll wenn sie fertig ist nach 300sec abgeschalten werden "HR.Waschmaschine_Sw off"
mit entsprechender akustischer Meldung.In einen dummy HR.WaschmaschineBetrieb wird
der zustand jeweils gespeichert.Nur bekomme ich wenn Fall 3 und 4 eintrifft ständig gemeldet
das die Maschine fertig ist was ich so nicht möchte.Vieleicht kannst du mir ja etwas helfen
Internals:
DEF ([HR.Waschmaschine_Power:power]>=9) (set HR.WaschmaschineBetrieb on) DOELSEIF ([HR.Waschmaschine_Power:power]>=3 && [HR.Waschmaschine_Power:power]<6) (set HR.WaschmaschineBetrieb ready,set Tuer.GongMP3 playTone 091) DOELSEIF ([HR.Waschmaschine_Power:power]>0 and [HR.Waschmaschine_Power:power]<3) (set Tuer.GongMP3 playTone 012,set HR.WaschmaschineBetrieb standby,set Tuer.GongLED on,set Tuer.GongLED off,set HR.Waschmaschine_Sw off) DOELSEIF ([HR.Waschmaschine_Power:power]==0) (set HR.WaschmaschineBetrieb off,set Tuer.GongMP3 playTone 013; set Tuer.GongLED on,set Tuer.GongLED off)
NAME HRWaschmaschineBetriebAus
NR 465
NTFY_ORDER 50-HRWaschmaschineBetriebAus
STATE cmd_4
TYPE DOIF
Readings:
2015-08-02 20:45:24 Device HR.Waschmaschine_Power
2015-08-02 20:45:24 Event boot: off current: 0 energyCalc: 24414.7 frequency: 49.97 voltage: 232.3 statEnergy_kwh: Hour: 0.0000 Day: 3.0340 Month: 3.0340 Year: 3.0340 (since: ) statEnergyMonth: 3034.0 statEnergyCalc: Hour: 0.0 Day: 3034.0 Month: 3034.0 Year: 3034.0 (since: )
2015-08-02 17:51:03 cmd_count 2
2015-08-02 17:51:03 cmd_event HR.Waschmaschine_Power
2015-08-02 17:51:03 cmd_nr 4
2015-08-02 20:45:24 e_HR.Waschmaschine_Power_power 0
2015-08-02 17:51:03 state cmd_4
2015-08-02 20:45:27 wait_timer no timer
Condition:
0 ReadingValDoIf('HR.Waschmaschine_Power','power','')>=9
1 ReadingValDoIf('HR.Waschmaschine_Power','power','')>=3 && ReadingValDoIf('HR.Waschmaschine_Power','power','')<6
2 ReadingValDoIf('HR.Waschmaschine_Power','power','')>0 and ReadingValDoIf('HR.Waschmaschine_Power','power','')<3
3 ReadingValDoIf('HR.Waschmaschine_Power','power','')==0
Devices:
0 HR.Waschmaschine_Power
1 HR.Waschmaschine_Power
2 HR.Waschmaschine_Power
3 HR.Waschmaschine_Power
all HR.Waschmaschine_Power
Do:
0:
0 set HR.WaschmaschineBetrieb on
1:
0 set HR.WaschmaschineBetrieb ready,set Tuer.GongMP3 playTone 091
2:
0 set Tuer.GongMP3 playTone 012,set HR.WaschmaschineBetrieb standby,set Tuer.GongLED on,set Tuer.GongLED off,set HR.Waschmaschine_Sw off
3:
0 set HR.WaschmaschineBetrieb off,set Tuer.GongMP3 playTone 013; set Tuer.GongLED on,set Tuer.GongLED off
Helper:
globalinit 1
last_timer 0
sleepdevice HR.Waschmaschine_Power
sleepsubtimer -1
sleeptimer -1
Internals:
Itimer:
Readings:
0 HR.Waschmaschine_Power:power
1 HR.Waschmaschine_Power:power
2 HR.Waschmaschine_Power:power
3 HR.Waschmaschine_Power:power
all HR.Waschmaschine_Power:power
State:
Timerfunc:
Trigger:
Attributes:
do resetwait
icon scene_washing_machine
repeatsame 1:2:1:2
room Doif,Keller
wait 60:5,5:0,10,30,10,300:5,20,5,0
Zitat von: inesa394 am 02 August 2015, 21:14:41
Hallo
Mit deinen neuen Feature wollte ich meine notify und watchdog ablösen aber irgendwo ist da noch ein
Fehler drin. Meine Maschine soll wenn sie fertig ist nach 300sec abgeschalten werden "HR.Waschmaschine_Sw off"
mit entsprechender akustischer Meldung.In einen dummy HR.WaschmaschineBetrieb wird
der zustand jeweils gespeichert.Nur bekomme ich wenn Fall 3 und 4 eintrifft ständig gemeldet
das die Maschine fertig ist was ich so nicht möchte.Vieleicht kannst du mir ja etwas helfen
Internals:
DEF ([HR.Waschmaschine_Power:power]>=9) (set HR.WaschmaschineBetrieb on) DOELSEIF ([HR.Waschmaschine_Power:power]>=3 && [HR.Waschmaschine_Power:power]<6) (set HR.WaschmaschineBetrieb ready,set Tuer.GongMP3 playTone 091) DOELSEIF ([HR.Waschmaschine_Power:power]>0 and [HR.Waschmaschine_Power:power]<3) (set Tuer.GongMP3 playTone 012,set HR.WaschmaschineBetrieb standby,set Tuer.GongLED on,set Tuer.GongLED off,set HR.Waschmaschine_Sw off) DOELSEIF ([HR.Waschmaschine_Power:power]==0) (set HR.WaschmaschineBetrieb off,set Tuer.GongMP3 playTone 013; set Tuer.GongLED on,set Tuer.GongLED off)
NAME HRWaschmaschineBetriebAus
NR 465
NTFY_ORDER 50-HRWaschmaschineBetriebAus
STATE cmd_4
TYPE DOIF
Readings:
2015-08-02 20:45:24 Device HR.Waschmaschine_Power
2015-08-02 20:45:24 Event boot: off current: 0 energyCalc: 24414.7 frequency: 49.97 voltage: 232.3 statEnergy_kwh: Hour: 0.0000 Day: 3.0340 Month: 3.0340 Year: 3.0340 (since: ) statEnergyMonth: 3034.0 statEnergyCalc: Hour: 0.0 Day: 3034.0 Month: 3034.0 Year: 3034.0 (since: )
2015-08-02 17:51:03 cmd_count 2
2015-08-02 17:51:03 cmd_event HR.Waschmaschine_Power
2015-08-02 17:51:03 cmd_nr 4
2015-08-02 20:45:24 e_HR.Waschmaschine_Power_power 0
2015-08-02 17:51:03 state cmd_4
2015-08-02 20:45:27 wait_timer no timer
Condition:
0 ReadingValDoIf('HR.Waschmaschine_Power','power','')>=9
1 ReadingValDoIf('HR.Waschmaschine_Power','power','')>=3 && ReadingValDoIf('HR.Waschmaschine_Power','power','')<6
2 ReadingValDoIf('HR.Waschmaschine_Power','power','')>0 and ReadingValDoIf('HR.Waschmaschine_Power','power','')<3
3 ReadingValDoIf('HR.Waschmaschine_Power','power','')==0
Devices:
0 HR.Waschmaschine_Power
1 HR.Waschmaschine_Power
2 HR.Waschmaschine_Power
3 HR.Waschmaschine_Power
all HR.Waschmaschine_Power
Do:
0:
0 set HR.WaschmaschineBetrieb on
1:
0 set HR.WaschmaschineBetrieb ready,set Tuer.GongMP3 playTone 091
2:
0 set Tuer.GongMP3 playTone 012,set HR.WaschmaschineBetrieb standby,set Tuer.GongLED on,set Tuer.GongLED off,set HR.Waschmaschine_Sw off
3:
0 set HR.WaschmaschineBetrieb off,set Tuer.GongMP3 playTone 013; set Tuer.GongLED on,set Tuer.GongLED off
Helper:
globalinit 1
last_timer 0
sleepdevice HR.Waschmaschine_Power
sleepsubtimer -1
sleeptimer -1
Internals:
Itimer:
Readings:
0 HR.Waschmaschine_Power:power
1 HR.Waschmaschine_Power:power
2 HR.Waschmaschine_Power:power
3 HR.Waschmaschine_Power:power
all HR.Waschmaschine_Power:power
State:
Timerfunc:
Trigger:
Attributes:
do resetwait
icon scene_washing_machine
repeatsame 1:2:1:2
room Doif,Keller
wait 60:5,5:0,10,30,10,300:5,20,5,0
1. Ich sehe zweifaches Schalten im 4. Fall - wie gewünscht: repeatsame 1:2:1:2
2. Wenn du Pausen zwischen den Kommandos haben willst, musst du sie auch getrennt angeben (set HR.WaschmaschineBetrieb off)(set Tuer.GongMP3 playTone 013)(set Tuer.GongLED on)(set Tuer.GongLED off)
Gruß
Damian
ok danke werde das heute abend mal testen mit den zusätzlichen Klammern.
Die Wiederholungen kamen nicht wie gewünscht 2 mal sondern vielfach mehr
Gruß Inesa
ZitatDie Verzögerungen werden nur auf Events angewandt und nicht auf Zeitsteuerung.
Ist geplant, auch das einzubauen?
Könnte ich gut für meine SOMFY Rolladen gebrauchen, die ich aktuell nur einzeln verzögert steuern kann.
Das folgende funktioniert nämlich leider nicht mit sleep, alle werden gleichzeitig geschaltet und der CUL hängt sich auf:
([07:30|8] and [Wg.Rolladen.timer] eq "on") (set Sz.Rolladen open, sleep 1.5; set Az.Rolladen open, sleep 1.5; set Wz.Rolladen.Tuer open, sleep 1.5; set Wz.Rolladen.Fenster open, sleep 1.5;set Kc.Rolladen.Tuer open, sleep 1.5; set Kc.Rolladen.Fenster open)
Guten Morgen,
Ich meine, Damian hat ein paar Posts später festgestellt, dass es doch schon drin ist...
Ronny
Zitat von: Flexstarr am 05 August 2015, 23:17:00
Ist geplant, auch das einzubauen?
Könnte ich gut für meine SOMFY Rolladen gebrauchen, die ich aktuell nur einzeln verzögert steuern kann.
Das folgende funktioniert nämlich leider nicht mit sleep, alle werden gleichzeitig geschaltet und der CUL hängt sich auf:
([07:30|8] and [Wg.Rolladen.timer] eq "on") (set Sz.Rolladen open, sleep 1.5; set Az.Rolladen open, sleep 1.5; set Wz.Rolladen.Tuer open, sleep 1.5; set Wz.Rolladen.Fenster open, sleep 1.5;set Kc.Rolladen.Tuer open, sleep 1.5; set Kc.Rolladen.Fenster open)
Ist bereits drin http://forum.fhem.de/index.php/topic,39070.msg316597.html#msg316597:
([07:30|8] and [Wg.Rolladen.timer] eq "on")
(set Sz.Rolladen open)
(set Az.Rolladen open)
(set Wz.Rolladen.Tuer open)
(set Wz.Rolladen.Fenster open)
(set Kc.Rolladen.Tuer open)
(set Kc.Rolladen.Fenster open)
attr <dein_doif_modul> do always
attr <dein_doif_modul> timerWithWait
attr <dein_doif_modul> wait 0,1.5,1.5,1.5,1.5,1.5
Gruß
Damian
.. dabei dachte ich, ich hätte den Thread komplett gelesen.
Besten Dank - werde ich später direkt testen! 8)
Gibt es ein Limit der Anzahl von "wait", die definiert werden dürfen?
([07:30|8] and [Wg.Rolladen.timer] eq "on")
#1 (set Sz.Rolladen open)
#2 (set Az.Rolladen open)
#3 (set Wz.Rolladen.Tuer open)
#4 (set Wz.Rolladen.Fenster open)
#5 (set Kc.Rolladen.Tuer open)
#6 (set Kc.Rolladen.Fenster open)
DOELSEIF ([8:30|7] and [Wg.Rolladen.timer] eq "on")
#7 (set Az.Rolladen open)
#8 (set Wz.Rolladen.Tuer open)
#9 (set Wz.Rolladen.Fenster open)
#10 (set Kc.Rolladen.Tuer open)
#11 (set Kc.Rolladen.Fenster open)
DOELSEIF ([11:15|7] and [Wg.Rolladen.timer] eq "on")
#12 (set Sz.Rolladen open)
DOELSEIF ([([Twilight.Koblenz:ss_weather]+1800)] and [Wg.Rolladen.timer] eq "on")
#13 (set Wz.Rolladen.Tuer pos 90)
#14 (set Wz.Rolladen.Fenster pos 80)
#14 (set Kc.Rolladen.Tuer pos 90)
#15 (set Kc.Rolladen.Fenster pos 80)
#16 (set Az.Rolladen pos 90)
#17 (set Sz.Rolladen pos 90)
wait #1-6 verzögern, wenn das erste DOIF zutrifft, wait #7-11 wenn das erste DOELSEIF eintrifft etc.
Die Verzögerungszeiten gelten dann immer ab dem DOIF / DOELSEIF ?
#1, #7, #12 und #13 müssen nicht verzögern, daher dort eine 0 ? Bei allen anderen dann 1.5 oder addiert sich irgendwo/wann die Zeit auf?
Zitat von: Flexstarr am 06 August 2015, 14:07:40
.. dabei dachte ich, ich hätte den Thread komplett gelesen.
Besten Dank - werde ich später direkt testen! 8)
Gibt es ein Limit der Anzahl von "wait", die definiert werden dürfen?
([07:30|8] and [Wg.Rolladen.timer] eq "on")
#1 (set Sz.Rolladen open)
#2 (set Az.Rolladen open)
#3 (set Wz.Rolladen.Tuer open)
#4 (set Wz.Rolladen.Fenster open)
#5 (set Kc.Rolladen.Tuer open)
#6 (set Kc.Rolladen.Fenster open)
DOELSEIF ([8:30|7] and [Wg.Rolladen.timer] eq "on")
#7 (set Az.Rolladen open)
#8 (set Wz.Rolladen.Tuer open)
#9 (set Wz.Rolladen.Fenster open)
#10 (set Kc.Rolladen.Tuer open)
#11 (set Kc.Rolladen.Fenster open)
DOELSEIF ([11:15|7] and [Wg.Rolladen.timer] eq "on")
#12 (set Sz.Rolladen open)
DOELSEIF ([([Twilight.Koblenz:ss_weather]+1800)] and [Wg.Rolladen.timer] eq "on")
#13 (set Wz.Rolladen.Tuer pos 90)
#14 (set Wz.Rolladen.Fenster pos 80)
#14 (set Kc.Rolladen.Tuer pos 90)
#15 (set Kc.Rolladen.Fenster pos 80)
#16 (set Az.Rolladen pos 90)
#17 (set Sz.Rolladen pos 90)
wait #1-6 verzögern, wenn das erste DOIF zutrifft, wait #7-11 wenn das erste DOELSEIF eintrifft etc.
Die Verzögerungszeiten gelten dann immer ab dem DOIF / DOELSEIF ?
#1, #7, #12 und #13 müssen nicht verzögern, daher dort eine 0 ? Bei allen anderen dann 1.5 oder addiert sich irgendwo/wann die Zeit auf?
Es gibt kein Limit:
Die Syntax lautet:
wait <wait1>,<wait2>,<wait3>,<wait4>,<wait5>,<wait6>:<wait7>,<wait8>,<wait9>...
waits zwischen doif, doelsif usw. werden wie bisher mit Doppelpunkt getrennt. Innerhalb eines Falls dann mit Komma.
Die Waitangaben gelten wie beim Sleep immer bezogen auf den Vorgänger. Man muss also nichts addieren, wie bei mehreren at-Verzögerungen hintereinander.
Keine Verzögerungen werden mit 0 oder einfach durch auslassen definiert z. B. 3,,4,0,4:,4,1
Gruß
Damian
Verstanden - Dankeschön!
Was genau bedeutet noch "4:" als Verzögerung in deinem Beispiel?
Zitat von: Flexstarr am 06 August 2015, 23:05:52
Verstanden - Dankeschön!
Was genau bedeutet noch "4:" als Verzögerung in deinem Beispiel?
Ich glaube ich muss langsam die Doku fertigstellen.
Es war nur ein Beispiel und hatte nichts mit deinem Fall zu tun.
Wie bereits erklärt, ist Doppelpunkt, wie bisher der Trenner zwischen den Fällen. Also sind es 4 Sekunden Verzögerung des letzten Kommandos im ersten Fall.
Und noch ein Beispiel:
define di DOIF (Bedingung1)
(set ...) # soll nicht verzögert werden
(set ...) # soll um 1 Sekunde verzögert werden
DOELSE
(set ...) # soll um 2 Sekunden verzögert werden
(set ...) # soll um 3 Sekunden verzögert werden
attr di wait 0,1:2,3
Gruß
Damian
Zitat von: Damian am 06 August 2015, 15:28:04
Keine Verzögerungen werden mit 0 oder einfach durch auslassen definiert z. B. 3,,4,0,4:,4,1
Frage dazu hier ist hinter dem Doppelpunkt ein Komma
bei deinem letzten Beitrag ist im Attribut dieses ohne Komma angegeben, ist das OK..?
Zitatattr di wait 0,1:2,3
Frage nur wegen dem Verstehen... ;)
3,,4,0,4:,4,1
ist das gleiche wie
3,0,4,0,4:0,4,1
Zitat von: RoBra81 am 07 August 2015, 14:14:40
3,,4,0,4:,4,1
ist das gleiche wie
3,0,4,0,4:0,4,1
OK, dass verstehe ich aber für mich fehlt hier, dass Komma
Zitatattr di wait 0,1:2,3
also so:
attr di wait 0,1:,2,3
Zitat von: moonsorrox am 07 August 2015, 14:19:38
also so:
attr di wait 0,1:,2,3
Das wäre das gleiche wie
attr di wait 0,1:0,2,3Du hast also 3 Aktionen von denen die erste nicht verzögert wird.
Bei
attr di wait 0,1:2,3hast du zwei Aktionen bei denen die erste um 2 Sekunden verzögert wird...
Zitat von: RoBra81 am 07 August 2015, 14:22:17
Das wäre das gleiche wie
attr di wait 0,1:0,2,3
Du hast also 3 Aktionen von denen die erste nicht verzögert wird.
Bei
attr di wait 0,1:2,3
hast du zwei Aktionen bei denen die erste um 2 Sekunden verzögert wird...
Man kann sagen, wenn irgendetwas zwischen Doppelpunkten, Kommas oder beiden fehlt, ist es immer eine Null (also keine Verzögerung).
z. B. wait
::::3 ist einfach nur kürzer als
0:0:0:3Was so etwas wie:
,4,,,5::,,,3 bedeutet, dürfte inzwischen der aufmerksame Leser selbst herausfinden. Wem die abkürzende Schreibweise nicht gefällt, der kann gerne immer Nullen verwenden.
Nullen am Ende können dagegen inklusive Trennzeichen immer weggelassen werden:
3:2:0:0 ist das gleich wie
3:2oder
3,2,0:2,0,0:0 ist das Gleiche wie
3,2:2Gruß
Damian
Version 0.8 mit aktualisierter Doku zu den neuen Features im ersten Post.
Ich bin mit der Generalisierung des Moduls, wegen anderer Projekte, nicht weiter gekommen.
Auch das Belegen des neuen Readings "Event" gefällt mir noch nicht. Es werden dort nämlich alle Event-Angaben des Triggers abgelegt. Das kann je nach Device sehr viel sein. Das bläht die Detailsanzeige des Moduls unnötig auf. Auch das Auswerten des Event-Readings mit allen Angaben würde Perl-Kenntnisse erfordern und das widerspricht dem Konzept des Moduls - ohne Perl-Programmierung bei typischen Aufgaben auszukommen. Ich habe das Belegen des Event-Readings zunächst auskommentiert. Ich werde mir da noch etwas einfallen lassen müssen.
Leider ruft jetzt erstmal die richtige Arbeit - also erst einmal Entwicklungspause.
Die 0.8 Version werde ich in den nächsten Tagen einchecken. Es kann nicht schaden einen Zwischenzustand einzuchecken, bevor man
das Modul noch mehr auf den Kopf stellt.
Gruß
Damian
Hallo Damian,
danke dafür das es weiter geht. Ich muss aber wohl irgendwas falsch machen :-(
Ich habe FHEM angehalten, 98_DOIF.pm runtergeladen und installiert. Folgendes DOIF funktioniert dann nicht mehr:
([Poolpumpe_Schalter] eq "on") (set Poolpumpe on) DOELSEIF ([9:00 -17:00] and [+:15] and ([Poolpumpe_Schalter] eq "intervall")) (set Poolpumpe on-for-timer 120, define Poolpumpe_Schalter_off at +00:02:00 set Poolpumpe off, attr Poolpumpe_Schalter_off room Garten, attr Poolpumpe_Schalter_off icon hourglass) DOELSEIF (([Poolpumpe_Schalter] eq "countdown")) (set Poolpumpe on-for-timer 300, define Poolpumpe_Schalter_off at +00:05:00 set Poolpumpe_Schalter off, attr Poolpumpe_Schalter_off room Garten, attr Poolpumpe_Schalter_off icon hourglass) DOELSEIF ([Poolpumpe_Schalter] eq "off") (set Poolpumpe off)
Wenn ich die alte Version wieder installiere funktioniert es wieder.
Bei dem anderen DOIF habe ich wohl was kaputt gespielt, es funktioniert in beiden Versionen nicht mehr:
([taster_rolladen_down:?on]) (set gong_MP3 playTone 008, set Rolladen01 on, sleep 6; set Rolladen01 on, set Rolladen02 on, sleep 5; set Rolladen02 on)
Gruß
Micha
Zitat von: mfeske am 10 August 2015, 19:30:36
Hallo Damian,
danke dafür das es weiter geht. Ich muss aber wohl irgendwas falsch machen :-(
Ich habe FHEM angehalten, 98_DOIF.pm runtergeladen und installiert. Folgendes DOIF funktioniert dann nicht mehr:
([Poolpumpe_Schalter] eq "on") (set Poolpumpe on) DOELSEIF ([9:00 -17:00] and [+:15] and ([Poolpumpe_Schalter] eq "intervall")) (set Poolpumpe on-for-timer 120, define Poolpumpe_Schalter_off at +00:02:00 set Poolpumpe off, attr Poolpumpe_Schalter_off room Garten, attr Poolpumpe_Schalter_off icon hourglass) DOELSEIF (([Poolpumpe_Schalter] eq "countdown")) (set Poolpumpe on-for-timer 300, define Poolpumpe_Schalter_off at +00:05:00 set Poolpumpe_Schalter off, attr Poolpumpe_Schalter_off room Garten, attr Poolpumpe_Schalter_off icon hourglass) DOELSEIF ([Poolpumpe_Schalter] eq "off") (set Poolpumpe off)
Wenn ich die alte Version wieder installiere funktioniert es wieder.
Bei dem anderen DOIF habe ich wohl was kaputt gespielt, es funktioniert in beiden Versionen nicht mehr:
([taster_rolladen_down:?on]) (set gong_MP3 playTone 008, set Rolladen01 on, sleep 6; set Rolladen01 on, set Rolladen02 on, sleep 5; set Rolladen02 on)
Gruß
Micha
Was geht nicht? Du musst deine Aussage konkretisieren und am besten ein Fehlverhalten mit einem list deines Moduls belegen, sonst kann ich mit der Aussage "geht nicht" nichts anfangen.
Gruß
Damian
Danke für die neuen Features - spart mir viel Arbeit :-)
habs installiert und schon getestet mit meiner bewässerungssteuerung.
danke anton
Version 0.9
Negative Zeitangaben in der Zeitberechnung sind jetzt möglich, solange man nicht in der Vergangenheit landet ;)
siehe http://forum.fhem.de/index.php/topic,39911.msg321604.html#msg321604
Gruß
Damian
Bei der Verwendung der 98_DOIF.pm von gestern wurde die folgende bereits bestehende zweizeilige Definition nicht ausgeführt:
define VolTV_di DOIF ([osmc] eq "opened")({system "irsend SEND_ONCE receiver d-tv/cbl_alternative"},{system "irsend -#12 SEND_ONCE receiver KEY_VOLUMEUP"},set UE40D7090 connect)\
DOELSEIF ([osmc] eq "disconnected") (set UE40D7090 connect,{system "irsend -#12 SEND_ONCE receiver KEY_VOLUMEDOWN"})
Mit der gleichen einzeilig geschriebenen Definition gibt es keine Fehlermeldung und das DOIF wird korrekt ausgeführt.
define VolTV_di DOIF ([osmc] eq "opened")({system "irsend SEND_ONCE receiver d-tv/cbl_alternative"},{system "irsend -#12 SEND_ONCE receiver KEY_VOLUMEUP"},set UE40D7090 connect) DOELSEIF ([osmc] eq "disconnected") (set UE40D7090 connect,{system "irsend -#12 SEND_ONCE receiver KEY_VOLUMEDOWN"})Der Fehler lässt sich mit dem Versuch nachstellen, im DEF-Editor die folgende Definition auf zwei Zeilen umzubrechen:
define m_di DOIF ([m] == 1) (set m #a) DOELSEIF ([m] == 2) (set m #b)Es erscheint dann die Fehlermeldung:
Zitatm_di DOIF: no right bracket: (set m DOELSEIF ([m] == 2) (set m #b)
Ich vermute es liegt an der Raute (#), die evtl. als Kommentar interpretiert wird.
Eine mehrzeile Definition wäre für mich weiterhin wünschenswert, da die Übersichtlichkeit erhöht wird.
Verdoppeln ## oder \# hilft nicht.
Ich würde mich freuen, wenn ich einen Tip bekommen könnte, wie ich die Raute auch in mehrzeiligen Definitionen verwenden kann.
Zitat von: Ellert am 12 August 2015, 16:25:14
Bei der Verwendung der 98_DOIF.pm von gestern wurde die folgende bereits bestehende zweizeilige Definition nicht ausgeführt:
define VolTV_di DOIF ([osmc] eq "opened")({system "irsend SEND_ONCE receiver d-tv/cbl_alternative"},{system "irsend -#12 SEND_ONCE receiver KEY_VOLUMEUP"},set UE40D7090 connect)\
DOELSEIF ([osmc] eq "disconnected") (set UE40D7090 connect,{system "irsend -#12 SEND_ONCE receiver KEY_VOLUMEDOWN"})
Mit der gleichen einzeilig geschriebenen Definition gibt es keine Fehlermeldung und das DOIF wird korrekt ausgeführt.
define VolTV_di DOIF ([osmc] eq "opened")({system "irsend SEND_ONCE receiver d-tv/cbl_alternative"},{system "irsend -#12 SEND_ONCE receiver KEY_VOLUMEUP"},set UE40D7090 connect) DOELSEIF ([osmc] eq "disconnected") (set UE40D7090 connect,{system "irsend -#12 SEND_ONCE receiver KEY_VOLUMEDOWN"})
Der Fehler lässt sich mit dem Versuch nachstellen, im DEF-Editor die folgende Definition auf zwei Zeilen umzubrechen:
define m_di DOIF ([m] == 1) (set m #a) DOELSEIF ([m] == 2) (set m #b)
Es erscheint dann die Fehlermeldung:
Ich vermute es liegt an der Raute (#), die evtl. als Kommentar interpretiert wird.
Eine mehrzeile Definition wäre für mich weiterhin wünschenswert, da die Übersichtlichkeit erhöht wird.
Verdoppeln ## oder \# hilft nicht.
Ich würde mich freuen, wenn ich einen Tip bekommen könnte, wie ich die Raute auch in mehrzeiligen Definitionen verwenden kann.
ja, es liegt an dem neuen Feature # als Kommentarzeichen zu benutzen. Da muss ich mir noch etwas einfallen lassen.
Gruß
Damian
Nachdem ich das hier mit den neuen Features hier gelesen hatte habe ich einige
Doif neu angepaßt.
Mein Problem ist das nun beide DOIF ständig zwischen cmd 1 und cmd 2 springen was zur Folge hat
das das Licht immer an und aus geht.
nternals:
DEF ([?{sunset(-600,"17:00","22:30")}-01:00] and [rr_fernseher] eq "home") ((set BogenlampeFarbe HSV 0,0,80))DOELSEIF ([?{sunset(-3000,"18:00","22:00")}-01:00] and [mytwilight:twilight_weather] < 35 and ([rr_inesaS4] eq "home" or [rr_andreLG2] eq "home")) ((set BogenlampeFarbe HSV 184,100,80))DOELSE (set BogenlampeFarbe off)
NAME bogenlampe_abends
NR 683
NTFY_ORDER 50-bogenlampe_abends
STATE 0
TYPE DOIF
Readings:
2015-08-13 12:43:30 Device rr_fernseher
2015-08-13 01:00:50 cmd_event rr_fernseher
2015-08-13 01:00:50 cmd_nr 3
2015-08-13 12:36:32 e_mytwilight_twilight_weather 100
2015-08-13 12:43:30 e_rr_andreLG2_STATE home
2015-08-13 12:43:30 e_rr_fernseher_STATE home
2015-08-13 12:43:30 e_rr_inesaS4_STATE absent
2015-08-13 01:00:50 state 0
2015-08-13 12:41:28 timer_1_c1 13.08.2015 20:58:59
2015-08-13 12:41:28 timer_2_c1 14.08.2015 01:00:00
2015-08-13 12:41:28 timer_3_c2 13.08.2015 20:18:59
2015-08-13 12:41:28 timer_4_c2 14.08.2015 01:00:00
2015-08-13 12:43:36 wait_timer no timer
Condition:
0 DOIF_time($hash,$hash->{realtime}{0},$hash->{realtime}{1},$wday,$hms,"") and InternalDoIf('rr_fernseher','STATE','') eq "home"
1 DOIF_time($hash,$hash->{realtime}{2},$hash->{realtime}{3},$wday,$hms,"") and ReadingValDoIf('mytwilight','twilight_weather','') < 35 and (InternalDoIf('rr_inesaS4','STATE','') eq "home" or InternalDoIf('rr_andreLG2','STATE','') eq "home")
Days:
Devices:
0 rr_fernseher
1 mytwilight rr_inesaS4 rr_andreLG2
all rr_fernseher mytwilight rr_inesaS4 rr_andreLG2
Do:
0:
0 (set BogenlampeFarbe HSV 0,0,80)
1:
0 (set BogenlampeFarbe HSV 184,100,80)
2:
0 set BogenlampeFarbe off
Helper:
globalinit 1
last_timer 4
sleeptimer -1
Internals:
0 rr_fernseher:STATE
1 rr_inesaS4:STATE rr_andreLG2:STATE
all rr_fernseher:STATE rr_inesaS4:STATE rr_andreLG2:STATE
Itimer:
Readings:
1 mytwilight:twilight_weather
all mytwilight:twilight_weather
Realtime:
0 20:58:59
1 01:00:00
2 20:18:59
3 01:00:00
State:
Time:
0 {sunset(-600,"17:00","22:30")}
1 01:00:00
2 {sunset(-3000,"18:00","22:00")}
3 01:00:00
Timecond:
0 0
1 0
2 1
3 1
Timer:
0 0
1 0
2 0
3 0
Timerfunc:
Trigger:
Attributes:
cmdState on|off
group licht
icon light_floor_lamp
room wohnzimmer
wait 0:2:2
Internals:
DEF ([?{sunset(-3000,"18:00","22:00")}-01:00] and [rr_fernseher] eq "home") (set Tuer.GongMP3 playTone 047)(set RemotePI cmd set Beleuchtung_Fernseher on)(set RemotePI cmd set Wohnzimmer_Stehlampe on)DOELSEIF ([?{sunset(-1800,"18:00","22:00")}-22:30] and [mytwilight:twilight_weather] < 30 and ([rr_inesaS4] eq "home" or [rr_andreLG2] eq "home"))(set Tuer.GongMP3 playTone 047)(set RemotePI cmd set Beleuchtung_Fernseher on) (set RemotePI cmd set Wohnzimmer_Stehlampe on)
DOELSE (set Tuer.GongMP3 playTone 048)(set RemotePI cmd set Beleuchtung_Fernseher off) (set RemotePI cmd set Wohnzimmer_Stehlampe off)
NAME licht_beleuchtung
NR 401
NTFY_ORDER 50-licht_beleuchtung
STATE initialized
TYPE DOIF
Readings:
2015-08-13 12:48:38 state initialized
2015-08-13 12:48:38 timer_1_c1 13.08.2015 20:18:59
2015-08-13 12:48:38 timer_2_c1 14.08.2015 01:00:00
2015-08-13 12:48:38 timer_3_c2 13.08.2015 20:38:59
2015-08-13 12:48:38 timer_4_c2 13.08.2015 22:30:00
Condition:
0 DOIF_time($hash,$hash->{realtime}{0},$hash->{realtime}{1},$wday,$hms,"") and InternalDoIf('rr_fernseher','STATE','') eq "home"
1 DOIF_time($hash,$hash->{realtime}{2},$hash->{realtime}{3},$wday,$hms,"") and ReadingValDoIf('mytwilight','twilight_weather','') < 30 and (InternalDoIf('rr_inesaS4','STATE','') eq "home" or InternalDoIf('rr_andreLG2','STATE','') eq "home")
Days:
Devices:
0 rr_fernseher
1 mytwilight rr_inesaS4 rr_andreLG2
all rr_fernseher mytwilight rr_inesaS4 rr_andreLG2
Do:
0:
0 set Tuer.GongMP3 playTone 047
1 set RemotePI cmd set Beleuchtung_Fernseher on
2 set RemotePI cmd set Wohnzimmer_Stehlampe on
1:
0 set Tuer.GongMP3 playTone 047
1 set RemotePI cmd set Beleuchtung_Fernseher on
2 set RemotePI cmd set Wohnzimmer_Stehlampe on
2:
0 set Tuer.GongMP3 playTone 048
1 set RemotePI cmd set Beleuchtung_Fernseher off
2 set RemotePI cmd set Wohnzimmer_Stehlampe off
Helper:
globalinit 1
last_timer 4
sleeptimer -1
Internals:
0 rr_fernseher:STATE
1 rr_inesaS4:STATE rr_andreLG2:STATE
all rr_fernseher:STATE rr_inesaS4:STATE rr_andreLG2:STATE
Itimer:
Readings:
1 mytwilight:twilight_weather
all mytwilight:twilight_weather
Realtime:
0 20:18:59
1 01:00:00
2 20:38:59
3 22:30:00
State:
Time:
0 {sunset(-3000,"18:00","22:00")}
1 01:00:00
2 {sunset(-1800,"18:00","22:00")}
3 22:30:00
Timecond:
0 0
1 0
2 1
3 1
Timer:
0 0
1 0
2 0
3 0
Timerfunc:
Attributes:
group licht
icon it_television
room Doif,wohnzimmer
wait 0,2,2:6,6,2:6,6,2
Zitat von: inesa394 am 13 August 2015, 12:55:07
Nachdem ich das hier mit den neuen Features hier gelesen hatte habe ich einige
Doif neu angepaßt.
Mein Problem ist das nun beide DOIF ständig zwischen cmd 1 und cmd 2 springen was zur Folge hat
das das Licht immer an und aus geht.
nternals:
DEF ([?{sunset(-600,"17:00","22:30")}-01:00] and [rr_fernseher] eq "home") ((set BogenlampeFarbe HSV 0,0,80))DOELSEIF ([?{sunset(-3000,"18:00","22:00")}-01:00] and [mytwilight:twilight_weather] < 35 and ([rr_inesaS4] eq "home" or [rr_andreLG2] eq "home")) ((set BogenlampeFarbe HSV 184,100,80))DOELSE (set BogenlampeFarbe off)
NAME bogenlampe_abends
NR 683
NTFY_ORDER 50-bogenlampe_abends
STATE 0
TYPE DOIF
Readings:
2015-08-13 12:43:30 Device rr_fernseher
2015-08-13 01:00:50 cmd_event rr_fernseher
2015-08-13 01:00:50 cmd_nr 3
2015-08-13 12:36:32 e_mytwilight_twilight_weather 100
2015-08-13 12:43:30 e_rr_andreLG2_STATE home
2015-08-13 12:43:30 e_rr_fernseher_STATE home
2015-08-13 12:43:30 e_rr_inesaS4_STATE absent
2015-08-13 01:00:50 state 0
2015-08-13 12:41:28 timer_1_c1 13.08.2015 20:58:59
2015-08-13 12:41:28 timer_2_c1 14.08.2015 01:00:00
2015-08-13 12:41:28 timer_3_c2 13.08.2015 20:18:59
2015-08-13 12:41:28 timer_4_c2 14.08.2015 01:00:00
2015-08-13 12:43:36 wait_timer no timer
Condition:
0 DOIF_time($hash,$hash->{realtime}{0},$hash->{realtime}{1},$wday,$hms,"") and InternalDoIf('rr_fernseher','STATE','') eq "home"
1 DOIF_time($hash,$hash->{realtime}{2},$hash->{realtime}{3},$wday,$hms,"") and ReadingValDoIf('mytwilight','twilight_weather','') < 35 and (InternalDoIf('rr_inesaS4','STATE','') eq "home" or InternalDoIf('rr_andreLG2','STATE','') eq "home")
Days:
Devices:
0 rr_fernseher
1 mytwilight rr_inesaS4 rr_andreLG2
all rr_fernseher mytwilight rr_inesaS4 rr_andreLG2
Do:
0:
0 (set BogenlampeFarbe HSV 0,0,80)
1:
0 (set BogenlampeFarbe HSV 184,100,80)
2:
0 set BogenlampeFarbe off
Helper:
globalinit 1
last_timer 4
sleeptimer -1
Internals:
0 rr_fernseher:STATE
1 rr_inesaS4:STATE rr_andreLG2:STATE
all rr_fernseher:STATE rr_inesaS4:STATE rr_andreLG2:STATE
Itimer:
Readings:
1 mytwilight:twilight_weather
all mytwilight:twilight_weather
Realtime:
0 20:58:59
1 01:00:00
2 20:18:59
3 01:00:00
State:
Time:
0 {sunset(-600,"17:00","22:30")}
1 01:00:00
2 {sunset(-3000,"18:00","22:00")}
3 01:00:00
Timecond:
0 0
1 0
2 1
3 1
Timer:
0 0
1 0
2 0
3 0
Timerfunc:
Trigger:
Attributes:
cmdState on|off
group licht
icon light_floor_lamp
room wohnzimmer
wait 0:2:2
Internals:
DEF ([?{sunset(-3000,"18:00","22:00")}-01:00] and [rr_fernseher] eq "home") (set Tuer.GongMP3 playTone 047)(set RemotePI cmd set Beleuchtung_Fernseher on)(set RemotePI cmd set Wohnzimmer_Stehlampe on)DOELSEIF ([?{sunset(-1800,"18:00","22:00")}-22:30] and [mytwilight:twilight_weather] < 30 and ([rr_inesaS4] eq "home" or [rr_andreLG2] eq "home"))(set Tuer.GongMP3 playTone 047)(set RemotePI cmd set Beleuchtung_Fernseher on) (set RemotePI cmd set Wohnzimmer_Stehlampe on)
DOELSE (set Tuer.GongMP3 playTone 048)(set RemotePI cmd set Beleuchtung_Fernseher off) (set RemotePI cmd set Wohnzimmer_Stehlampe off)
NAME licht_beleuchtung
NR 401
NTFY_ORDER 50-licht_beleuchtung
STATE initialized
TYPE DOIF
Readings:
2015-08-13 12:48:38 state initialized
2015-08-13 12:48:38 timer_1_c1 13.08.2015 20:18:59
2015-08-13 12:48:38 timer_2_c1 14.08.2015 01:00:00
2015-08-13 12:48:38 timer_3_c2 13.08.2015 20:38:59
2015-08-13 12:48:38 timer_4_c2 13.08.2015 22:30:00
Condition:
0 DOIF_time($hash,$hash->{realtime}{0},$hash->{realtime}{1},$wday,$hms,"") and InternalDoIf('rr_fernseher','STATE','') eq "home"
1 DOIF_time($hash,$hash->{realtime}{2},$hash->{realtime}{3},$wday,$hms,"") and ReadingValDoIf('mytwilight','twilight_weather','') < 30 and (InternalDoIf('rr_inesaS4','STATE','') eq "home" or InternalDoIf('rr_andreLG2','STATE','') eq "home")
Days:
Devices:
0 rr_fernseher
1 mytwilight rr_inesaS4 rr_andreLG2
all rr_fernseher mytwilight rr_inesaS4 rr_andreLG2
Do:
0:
0 set Tuer.GongMP3 playTone 047
1 set RemotePI cmd set Beleuchtung_Fernseher on
2 set RemotePI cmd set Wohnzimmer_Stehlampe on
1:
0 set Tuer.GongMP3 playTone 047
1 set RemotePI cmd set Beleuchtung_Fernseher on
2 set RemotePI cmd set Wohnzimmer_Stehlampe on
2:
0 set Tuer.GongMP3 playTone 048
1 set RemotePI cmd set Beleuchtung_Fernseher off
2 set RemotePI cmd set Wohnzimmer_Stehlampe off
Helper:
globalinit 1
last_timer 4
sleeptimer -1
Internals:
0 rr_fernseher:STATE
1 rr_inesaS4:STATE rr_andreLG2:STATE
all rr_fernseher:STATE rr_inesaS4:STATE rr_andreLG2:STATE
Itimer:
Readings:
1 mytwilight:twilight_weather
all mytwilight:twilight_weather
Realtime:
0 20:18:59
1 01:00:00
2 20:38:59
3 22:30:00
State:
Time:
0 {sunset(-3000,"18:00","22:00")}
1 01:00:00
2 {sunset(-1800,"18:00","22:00")}
3 22:30:00
Timecond:
0 0
1 0
2 1
3 1
Timer:
0 0
1 0
2 0
3 0
Timerfunc:
Attributes:
group licht
icon it_television
room Doif,wohnzimmer
wait 0,2,2:6,6,2:6,6,2
Dann müsstest du versuchen das Verhalten einzugrenzen. Aus den Lists kann ich nichts erkennen, der eine steht auf cmd_3 und der andere hat noch gar nicht geschaltet.
Gruß
Damian
Ein neues list eigentlich müßte es jetzt auf cmd 1( da ich TV schaue )stehen tut es aber nicht.
Ich möchte wenn der Fernseher an ist die Beleuchtung an geht außerdem soll
bei Anwesenheit zusätzlich die Beleuchtung angehen cmd 2
Warum ist es jetzt aus?
Internals:
DEF ([?{sunset(-3000,"18:00","22:00")}-01:00] and [rr_fernseher] eq "home") (set Tuer.GongMP3 playTone 047)(set RemotePI cmd set Beleuchtung_Fernseher on)(set RemotePI cmd set Wohnzimmer_Stehlampe on)DOELSEIF ([?{sunset(-1800,"18:00","22:00")}-22:30] and [mytwilight:twilight_weather] < 30 and ([rr_inesaS4] eq "home" or [rr_andreLG2] eq "home"))(set Tuer.GongMP3 playTone 047)(set RemotePI cmd set Beleuchtung_Fernseher on) (set RemotePI cmd set Wohnzimmer_Stehlampe on)
DOELSE (set Tuer.GongMP3 playTone 048)(set RemotePI cmd set Beleuchtung_Fernseher off) (set RemotePI cmd set Wohnzimmer_Stehlampe off)
NAME licht_beleuchtung
NR 401
NTFY_ORDER 50-licht_beleuchtung
STATE initialized
TYPE DOIF
Readings:
2015-08-13 23:21:52 state initialized
2015-08-13 23:21:52 timer_1_c1 14.08.2015 20:17:04
2015-08-13 23:21:52 timer_2_c1 14.08.2015 01:00:00
2015-08-13 23:21:52 timer_3_c2 14.08.2015 20:37:04
2015-08-13 23:21:52 timer_4_c2 14.08.2015 22:30:00
Condition:
0 DOIF_time($hash,$hash->{realtime}{0},$hash->{realtime}{1},$wday,$hms,"") and InternalDoIf('rr_fernseher','STATE','') eq "home"
1 DOIF_time($hash,$hash->{realtime}{2},$hash->{realtime}{3},$wday,$hms,"") and ReadingValDoIf('mytwilight','twilight_weather','') < 30 and (InternalDoIf('rr_inesaS4','STATE','') eq "home" or InternalDoIf('rr_andreLG2','STATE','') eq "home")
Days:
Devices:
0 rr_fernseher
1 mytwilight rr_inesaS4 rr_andreLG2
all rr_fernseher mytwilight rr_inesaS4 rr_andreLG2
Do:
0:
0 set Tuer.GongMP3 playTone 047
1 set RemotePI cmd set Beleuchtung_Fernseher on
2 set RemotePI cmd set Wohnzimmer_Stehlampe on
1:
0 set Tuer.GongMP3 playTone 047
1 set RemotePI cmd set Beleuchtung_Fernseher on
2 set RemotePI cmd set Wohnzimmer_Stehlampe on
2:
0 set Tuer.GongMP3 playTone 048
1 set RemotePI cmd set Beleuchtung_Fernseher off
2 set RemotePI cmd set Wohnzimmer_Stehlampe off
Helper:
globalinit 1
last_timer 4
sleeptimer -1
Internals:
0 rr_fernseher:STATE
1 rr_inesaS4:STATE rr_andreLG2:STATE
all rr_fernseher:STATE rr_inesaS4:STATE rr_andreLG2:STATE
Itimer:
Readings:
1 mytwilight:twilight_weather
all mytwilight:twilight_weather
Realtime:
0 20:17:04
1 01:00:00
2 20:37:04
3 22:30:00
State:
Time:
0 {sunset(-3000,"18:00","22:00")}
1 01:00:00
2 {sunset(-1800,"18:00","22:00")}
3 22:30:00
Timecond:
0 0
1 0
2 1
3 1
Timer:
0 0
1 0
2 0
3 0
Timerfunc:
Attributes:
group licht
icon it_television
room Doif,wohnzimmer
wait 10,2,2:60,60,2:60,60,2
Dieses hier wechselt ständig zwischen cmd 1 und cmd 2
zur Zeit
Internals:
DEF ([?{sunset(-600,"17:00","22:30")}-01:00] and [rr_fernseher] eq "home") ((set BogenlampeFarbe HSV 0,0,80))DOELSEIF ([?{sunset(-3000,"18:00","22:00")}-01:00] and [mytwilight:twilight_weather] < 35 and ([rr_inesaS4] eq "home" or [rr_andreLG2] eq "home")) ((set BogenlampeFarbe HSV 184,100,80))DOELSE (set BogenlampeFarbe off)
NAME bogenlampe_abends
NR 683
NTFY_ORDER 50-bogenlampe_abends
STATE on
TYPE DOIF
Readings:
2015-08-13 23:31:54 Device rr_andreLG2
2015-08-13 23:31:54 cmd_event rr_fernseher
2015-08-13 23:31:54 cmd_nr 1
2015-08-13 23:28:58 e_mytwilight_twilight_weather 0
2015-08-13 23:31:54 e_rr_andreLG2_STATE home
2015-08-13 23:31:54 e_rr_fernseher_STATE home
2015-08-13 23:31:54 e_rr_inesaS4_STATE home
2015-08-13 23:31:54 state on
2015-08-13 20:58:59 timer_1_c1 14.08.2015 20:57:04
2015-08-13 19:30:36 timer_2_c1 14.08.2015 01:00:00
2015-08-13 20:18:59 timer_3_c2 14.08.2015 20:17:04
2015-08-13 19:30:36 timer_4_c2 14.08.2015 01:00:00
2015-08-13 23:31:54 wait_timer 13.08.2015 23:32:54 cmd_2 rr_andreLG2
Condition:
0 DOIF_time($hash,$hash->{realtime}{0},$hash->{realtime}{1},$wday,$hms,"") and InternalDoIf('rr_fernseher','STATE','') eq "home"
1 DOIF_time($hash,$hash->{realtime}{2},$hash->{realtime}{3},$wday,$hms,"") and ReadingValDoIf('mytwilight','twilight_weather','') < 35 and (InternalDoIf('rr_inesaS4','STATE','') eq "home" or InternalDoIf('rr_andreLG2','STATE','') eq "home")
Days:
Devices:
0 rr_fernseher
1 mytwilight rr_inesaS4 rr_andreLG2
all rr_fernseher mytwilight rr_inesaS4 rr_andreLG2
Do:
0:
0 (set BogenlampeFarbe HSV 0,0,80)
1:
0 (set BogenlampeFarbe HSV 184,100,80)
2:
0 set BogenlampeFarbe off
Helper:
globalinit 1
last_timer 4
sleepdevice rr_andreLG2
sleepsubtimer 0
sleeptimer 1
Internals:
0 rr_fernseher:STATE
1 rr_inesaS4:STATE rr_andreLG2:STATE
all rr_fernseher:STATE rr_inesaS4:STATE rr_andreLG2:STATE
Itimer:
Readings:
1 mytwilight:twilight_weather
all mytwilight:twilight_weather
Realtime:
0 20:57:04
1 01:00:00
2 20:17:04
3 01:00:00
State:
Time:
0 {sunset(-600,"17:00","22:30")}
1 01:00:00
2 {sunset(-3000,"18:00","22:00")}
3 01:00:00
Timecond:
0 0
1 0
2 1
3 1
Timer:
0 0
1 0
2 0
3 0
Timerfunc:
Timers:
Trigger:
Attributes:
cmdState on|off
group licht
icon light_floor_lamp
room wohnzimmer
wait 0:60:90
Dieses hier funktioniert wie es soll
([?{sunset(-3000,"17:00","22:00")}-01:30] and [rr_fernseher] eq "home") (set Tuer.GongMP3 playTone 047,set RemotePI cmd set Beleuchtung_Fernseher on, define at_sleep1 at +00:00:10 set RemotePI cmd set Wohnzimmer_Stehlampe on) DOELSE (set Tuer.GongMP3 playTone 048,set RemotePI cmd set Beleuchtung_Fernseher off , define at_sleep at +00:00:12 set RemotePI cmd set Wohnzimmer_Stehlampe off)
Habe das DOIF nochmal umgeändert so das direkt das Presence abgefragt wird und nicht Residents
Vieleicht klappt es ja damit heute abend
([?{sunset(-3000,"17:00","22:00")}-01:30] and [lgtv:state] eq "present")(set Tuer.GongMP3 playTone 047) (set RemotePI cmd set Beleuchtung_Fernseher on)(set RemotePI cmd set Wohnzimmer_Stehlampe on)DOELSEIF ([?{sunset(-1900,"18:00","22:00")}-22:30] and ([inesa:state] eq "present" or [andre:state] eq "present"))(set Tuer.GongMP3 playTone 047)(set RemotePI cmd set Beleuchtung_Fernseher on) (set RemotePI cmd set Wohnzimmer_Stehlampe on) DOELSE (set Tuer.GongMP3 playTone 048)(set RemotePI cmd set Beleuchtung_Fernseher off) (set RemotePI cmd set Wohnzimmer_Stehlampe off)
Meinen Status in Residents habe ich bei Abwesenheit so realisiert vorher habe ich das mit zwei Watchdog gemacht
Internals:
DEF ([inesa:state] eq "present") (set rr_inesaS4 home) DOELSE (set rr_inesaS4 absent)
NAME anwesenheit_inesa
NR 671
NTFY_ORDER 50-anwesenheit_inesa
STATE initialized
TYPE DOIF
Readings:
2015-08-14 11:49:37 state initialized
Condition:
0 ReadingValDoIf('inesa','state','') eq "present"
Devices:
0 inesa
all inesa
Do:
0:
0 set rr_inesaS4 home
1:
0 set rr_inesaS4 absent
Helper:
globalinit 1
last_timer 0
sleeptimer -1
Itimer:
Readings:
0 inesa:state
all inesa:state
State:
Timerfunc:
Attributes:
event-on-change-reading state
room Residents
wait :400
Vieleicht liegt dort ja das Problem?
Für mich sieht es so aus, als würden [lgtv] und [inesa] oder [andre] abwechselnd ihre Readings erneuern.
Wenn Du die Zeiteinschränkungen heraus nimmst, kannst Du das sofort beobachten.
ZitatNachdem ich das hier mit den neuen Features hier gelesen hatte habe ich einige
Doif neu angepaßt.
Ich sehe gerade nicht welches neue Feature Du eingebaut hast? Mehrere Komandos in einem DOIF-Zweig waren schon vorher möglich.
Wie sah das DOIF aus bevor, Du es umgebaut hast?
Damit meinte ich wie im ersten Thread hier beschrieben ein sleep mit einzubauen zwischen den kommandos was vorher so nicht möglich war.
Außerdem hatte es vorher ohne sleep funktioniert.
Werde das mit den Readings mal checken ob sie ihren
Status ständig ändern wie du schreibst
Inesa
Hallo Damian,
noch eine Frage zum wait bei dem neuen Feature der aneinandergereihten Kommandos:
1,1,1,1
bedeutet, dass die Wartezeit vor Ausführung der jeweiligen Kommandos immer zum vorherigen Kommando bezogen wird und nicht auf den Auslösezeitpunkt, gell?
Also cmd_1_1 wird eine Sekunde nach Trigger gestartet, cmd_1_2 eine Sekunde nach cmd_1_1, cmd_1_3 eine Sekunde nach cmd_1_2 und nicht alle cmd_1_x eine Sekunde nach Trigger, oder?
Zitat von: Ralli am 16 August 2015, 11:47:57
Hallo Damian,
noch eine Frage zum wait bei dem neuen Feature der aneinandergereihten Kommandos:
1,1,1,1
bedeutet, dass die Wartezeit vor Ausführung der jeweiligen Kommandos immer zum vorherigen Kommando bezogen wird und nicht auf den Auslösezeitpunkt, gell?
Also cmd_1_1 wird eine Sekunde nach Trigger gestartet, cmd_1_2 eine Sekunde nach cmd_1_1, cmd_1_3 eine Sekunde nach cmd_1_2 und nicht alle cmd_1_x eine Sekunde nach Trigger, oder?
Ja.
Gruß
Damian
@Damian: ist die 98_DOIF.pm Version in diesem Thread jetzt eigentlich die, die mittlerweile auch via normalem fhem Update reinkommt?
Nein.
Fragt mich nicht wieso, aber habe heute in geistiger Umnachtung ein FHEM Update gemacht. Hatte vergessen, dass SourceFrog irgendwie noch Probleme macht. Also hat es mir erst mal 2 meiner DOIF Bedingungen beim Neustart raus geworfen, weil diese angeblich Fehlerhaft waren. Dann habe ich das neuster DOIF Modul hier aus dem Thread runtergeladen, mittels Filezilla auf den PI geschoben und wieder einen restart gemacht. Allerdings zeigt er mir immer noch an, dass meine DOIF Befehle fehlerhaft seien. Habe dann das Modul über "restart 98_DOIF" versucht nochmal neu zu laden und es kam folgender Fehler:
Zitat
Too many arguments for main::DOIF_SetSleepTimer at ./FHEM/98_DOIF.pm line 727, near "1)"
Too many arguments for main::DOIF_cmd at ./FHEM/98_DOIF.pm line 728, near "$event)"
Too many arguments for main::DOIF_SetSleepTimer at ./FHEM/98_DOIF.pm line 763, near "$timerNr)"
Too many arguments for main::DOIF_cmd at ./FHEM/98_DOIF.pm line 764, near "$event)"
Too many arguments for main::DOIF_SetSleepTimer at ./FHEM/98_DOIF.pm line 776, near "$timerNr)"
Too many arguments for main::DOIF_cmd at ./FHEM/98_DOIF.pm line 777, near "$event) "
Too many arguments for main::DOIF_cmd at ./FHEM/98_DOIF.pm line 1156, near "})"
Die DOIF Fehler, welche er mir ankreidet sind, dass man mehrer Befehle nicht mehr in verschiedenen Klammern auflisten kann. Dies ist allerdings für den Waittimer nötig. Vor dem Update hat es auch noch Problemlos funktioniert. Werde jetzt das Backup, welches ich gott sei Dank noch hatte, wieder einspielen und hoffen, dass der Fehler dann weg ist. Aber dachte mir, dass die o.g. Fehlermeldugn für Damian vll interessant sein könnt.
Zitat von: Amenophis86 am 18 August 2015, 14:42:26
Fragt mich nicht wieso, aber habe heute in geistiger Umnachtung ein FHEM Update gemacht. Hatte vergessen, dass SourceFrog irgendwie noch Probleme macht. Also hat es mir erst mal 2 meiner DOIF Bedingungen beim Neustart raus geworfen, weil diese angeblich Fehlerhaft waren. Dann habe ich das neuster DOIF Modul hier aus dem Thread runtergeladen, mittels Filezilla auf den PI geschoben und wieder einen restart gemacht. Allerdings zeigt er mir immer noch an, dass meine DOIF Befehle fehlerhaft seien. Habe dann das Modul über "restart 98_DOIF" versucht nochmal neu zu laden und es kam folgender Fehler:
Die DOIF Fehler, welche er mir ankreidet sind, dass man mehrer Befehle nicht mehr in verschiedenen Klammern auflisten kann. Dies ist allerdings für den Waittimer nötig. Vor dem Update hat es auch noch Problemlos funktioniert. Werde jetzt das Backup, welches ich gott sei Dank noch hatte, wieder einspielen und hoffen, dass der Fehler dann weg ist. Aber dachte mir, dass die o.g. Fehlermeldugn für Damian vll interessant sein könnt.
Das hat weniger etwas mit deinen Definitionen zu tun, als viel mehr mit geänderten internen Funktionen. Daher das neue Modul nie zur Laufzeit laden, sondern System runterfahren, Modul kopieren und wieder hochfahren.
Gruß
Damian
Die neue Version ist bei mir nun seit einigen Tagen im Einsatz und sowohl die bisherigen DOIFs als auch die neuen Funktionen funktionieren einwandfrei :)
Durch die neuen Befehlsfolgen ( (set lamp1 on)(set lamp2 on) ) in Verbindung mit wait und den Wochentag über einen Dummy ( [[begin]-[end]|[Wochentag]] ) konnte ich einiges vereinfachen und übersichtlicher gestalten.
Vielen Dank !
Zitat von: Damian am 10 August 2015, 21:08:50
Was geht nicht? Du musst deine Aussage konkretisieren und am besten ein Fehlverhalten mit einem list deines Moduls belegen, sonst kann ich mit der Aussage "geht nicht" nichts anfangen.
Hallo Damian,
sorry für die unvollständige Beschreibung. Ich hatte mir ein DOIF gebaut um mit einem Taster die Rolläden zur Hälfte herunter zu fahren. Das hatte auch schon mal funktioniert. Jetzt geht es nicht mehr die Rolläden werden über dieses DOIF nicht mehr angesteuert :-(
Internals:
DEF ([taster_rolladen_down:?on]) (set gong_MP3 playTone 008, set Rolladen01 on, sleep 6; set Rolladen01 on, set Rolladen02 on, sleep 5; set Rolladen02 on)
NAME rolladen_kurz_down_doif
NR 373
NTFY_ORDER 50-rolladen_kurz_down_doif
STATE cmd_1
TYPE DOIF
Readings:
2015-08-10 09:42:51 Device taster_rolladen_down
2015-08-09 22:21:29 cmd_event taster_rolladen_down
2015-08-09 22:21:29 cmd_nr 1
2015-08-22 15:06:02 e_taster_rolladen_down_events on
2015-08-09 22:21:29 state cmd_1
Condition:
0 EventDoIf('taster_rolladen_down',$hash->{helper}{triggerDev},$hash->{helper}{triggerEvents},'on')
Devices:
0 taster_rolladen_down
all taster_rolladen_down
Do:
0 set gong_MP3 playTone 008, set Rolladen01 on, sleep 6; set Rolladen01 on, set Rolladen02 on, sleep 5; set Rolladen02 on
Helper:
last_timer 0
sleeptimer -1
triggerDev taster_rolladen_down
triggerEvents:
on
Internals:
Itimer:
Readings:
State:
Trigger:
all taster_rolladen_down
Attributes:
room Wohnzimmer
Zitat von: mfeske am 22 August 2015, 15:09:00
Hallo Damian,
sorry für die unvollständige Beschreibung. Ich hatte mir ein DOIF gebaut um mit einem Taster die Rolläden zur Hälfte herunter zu fahren. Das hatte auch schon mal funktioniert. Jetzt geht es nicht mehr die Rolläden werden über dieses DOIF nicht mehr angesteuert :-(
Internals:
DEF ([taster_rolladen_down:?on]) (set gong_MP3 playTone 008, set Rolladen01 on, sleep 6; set Rolladen01 on, set Rolladen02 on, sleep 5; set Rolladen02 on)
NAME rolladen_kurz_down_doif
NR 373
NTFY_ORDER 50-rolladen_kurz_down_doif
STATE cmd_1
TYPE DOIF
Readings:
2015-08-10 09:42:51 Device taster_rolladen_down
2015-08-09 22:21:29 cmd_event taster_rolladen_down
2015-08-09 22:21:29 cmd_nr 1
2015-08-22 15:06:02 e_taster_rolladen_down_events on
2015-08-09 22:21:29 state cmd_1
Condition:
0 EventDoIf('taster_rolladen_down',$hash->{helper}{triggerDev},$hash->{helper}{triggerEvents},'on')
Devices:
0 taster_rolladen_down
all taster_rolladen_down
Do:
0 set gong_MP3 playTone 008, set Rolladen01 on, sleep 6; set Rolladen01 on, set Rolladen02 on, sleep 5; set Rolladen02 on
Helper:
last_timer 0
sleeptimer -1
triggerDev taster_rolladen_down
triggerEvents:
on
Internals:
Itimer:
Readings:
State:
Trigger:
all taster_rolladen_down
Attributes:
room Wohnzimmer
Mit einer Bedingung ohne "do always" konnte es auch vorher nur einmal funktioniert haben. Es funktioniert also alles wie programmiert.
Gruß
Damian
Ich bin gerade dabei meinen Perl Code nach und nach mit DOIF umzusetzen, da das Teil wirklich genial ist!!
Nun bin ich bei einem Punkt angelangt, wo ich irritiert bin wieso das nicht funktioniert.
Folgende Problem:
Ich habe einen Saugroboter (walle ;) ) den ich mit IR Befehlen starte und stoppe. Da ich nicht mit der IR LED am RPi ständig hinter dem Ding her bin, möchte ich beim Stoppen für 5 Minuten alle 10 Sekunden den IR "go home" Befehl senden. Hier meine Implementierung, die leider nur einmal funktioniert, danach reagiert es nicht mehr.
define DI_wallestop DOIF ([walle:state] eq "KEY_HOME") (set walle KEY_HOME)
attr DI_wallestop do always
attr DI_wallestop repeatsame 30
attr DI_wallestop room AutoZeitschaltuhr
attr DI_wallestop wait 10
Wenn ich nun einmal KEY_HOME setze, so läuft es super 30x durch und sendet den IR Befehl alle 10s. Setze ich danach nochmals KEY_HOME, so tut sich nichts mehr. cmd_counter steht auf 30 - muss ich das selbst irgendwie auf 0 zurück setzen?
Zitat von: dominik am 23 August 2015, 19:03:18
Ich bin gerade dabei meinen Perl Code nach und nach mit DOIF umzusetzen, da das Teil wirklich genial ist!!
Nun bin ich bei einem Punkt angelangt, wo ich irritiert bin wieso das nicht funktioniert.
Folgende Problem:
Ich habe einen Saugroboter (walle ;) ) den ich mit IR Befehlen starte und stoppe. Da ich nicht mit der IR LED am RPi ständig hinter dem Ding her bin, möchte ich beim Stoppen für 5 Minuten alle 10 Sekunden den IR "go home" Befehl senden. Hier meine Implementierung, die leider nur einmal funktioniert, danach reagiert es nicht mehr.
define DI_wallestop DOIF ([walle:state] eq "KEY_HOME") (set walle KEY_HOME)
attr DI_wallestop do always
attr DI_wallestop repeatsame 30
attr DI_wallestop room AutoZeitschaltuhr
attr DI_wallestop wait 10
Wenn ich nun einmal KEY_HOME setze, so läuft es super 30x durch und sendet den IR Befehl alle 10s. Setze ich danach nochmals KEY_HOME, so tut sich nichts mehr. cmd_counter steht auf 30 - muss ich das selbst irgendwie auf 0 zurück setzen?
Du hast das Attribut repeatsame falsch verstanden. Es wird nichts automatisch wiederholt - es bedeutet einfach, dass bei einem Trigger die gleiche Bedingung bis zu 30 mal wiederholt wird - repeatsame impliziert do always. Zurückgesetzt wird der Counter, wenn eine andere Bedingung mit DOELSEIF oder DOELSE kommt, diese hast du aber nicht definiert.
Gruß
Damian
Das erklärt meinen Denkfehler. Danke!
So funktioniert es nun:
define DI_wallestop DOIF ([walle:state] eq "KEY_HOME") (set walle KEY_HOME) DOELSEIF ([walle:state:sec] < 10) ()
attr DI_wallestop repeatsame 30
attr DI_wallestop room AutoZeitschaltuhr
attr DI_wallestop wait 10
Wusste nicht was ich da beim DOELSEIF abfragen soll, daher diese komische Abfrage.
Hallo Damian,
so:
Internals:
DEF ([taster_rolladen_down:?on]) (set gong_MP3 playTone 008, set Rolladen01 on, sleep 6; set Rolladen01 on, set Rolladen02 on, sleep 5; set Rolladen02 on)
NAME rolladen_kurz_down_doif
NR 373
NTFY_ORDER 50-rolladen_kurz_down_doif
STATE cmd_1
TYPE DOIF
Readings:
2015-08-24 17:55:51 cmd_event taster_rolladen_down
2015-08-24 17:55:51 cmd_nr 1
2015-08-24 17:55:50 e_taster_rolladen_down_events on
2015-08-24 17:55:51 state cmd_1
Condition:
0 EventDoIf('taster_rolladen_down',$hash->{helper}{triggerDev},$hash->{helper}{triggerEvents},'on')
Devices:
0 taster_rolladen_down
all taster_rolladen_down
Do:
0 set gong_MP3 playTone 008, set Rolladen01 on, sleep 6; set Rolladen01 on, set Rolladen02 on, sleep 5; set Rolladen02 on
Helper:
last_timer 0
sleeptimer -1
triggerDev taster_rolladen_down
triggerEvents:
on
Internals:
Itimer:
Readings:
State:
Timerfunc:
Trigger:
all taster_rolladen_down
Attributes:
do always
room Wohnzimmer
funktioniert es jetzt auch, wenn auch leider nicht ganz zuverlässig, was aber bestimmt an anderen Sachen liegt. Manchmal fahren beide Rolläden zur gleichen Zeit komplett runter manchmal klappt es das beide nur zur Hälfte runterfahren.
Der Plan war ja:
Fahre Rolladen01 runter
warte 6 sec
stoppe Rolladen01
Fahre Rolladen02 runter
warte 5 sec
stoppe Rolladen02
eigentlich ist es doch schon komisch, das beide zur gleichen Zeit runterfahren?
Wie würde den der Umbau von sleep auf wait aussehen und wie stelle ich über die weboberfläche fest,welche 98_DOIF.pm verwendet wird?
Gruß
Micha
@mfeske: Die alte Variante funktioniert, wenn Du das Semikolon hinter den sleep-Befehlen gegen ein Komma austauschst.
Zitat von: Ellert am 25 August 2015, 09:22:07
@mfeske: Die alte Variante funktioniert, wenn Du das Semikolon hinter den sleep-Befehlen gegen ein Komma austauschst.
Das wäre ungünstig, dann steht das ganze System für die angegebene Zeit. Sleep muss immer ein Semikolon für den folgenden Befehl haben.
Gruß
Damian
@Damian: Danke für den Hinweis, das war mir nicht bewusst. Mit Semikolon klappt die Verzögerung bei mir auch nicht. Jetzt verstehe ich auch die Notwendigkeit der Sleep-Alternative.
@mfeske: In der neuen Variante müsste es ungetestet, im Ausführungsteil so aussehen:
(set gong_MP3 playTone 008, set Rolladen01 on) (set Rolladen01 on, set Rolladen02 on) (set Rolladen02 on)
und das Attribut wait setzen:
attr rolladen_kurz_down_doif wait 0,6,5
.. werde ich gleich heute abend testen, danke.
Hey,
beim Start bekomme ich noch diese Meldungen im Log:
2015.08.28 20:48:25 1: PERL WARNING: Use of uninitialized value $end in string gt at ./FHEM/98_DOIF.pm line 476.
2015.08.28 20:48:25 1: PERL WARNING: Use of uninitialized value $begin in string gt at ./FHEM/98_DOIF.pm line 476.
2015.08.28 20:48:25 1: PERL WARNING: Use of uninitialized value $begin in string ge at ./FHEM/98_DOIF.pm line 481.
Hi,
wenn ich ein DoIF wie folgt definiert habe:
([FS20_e4e401:&STATE] eq "on") (set HUEDevice4 pct 100)
Jetzt habe ich das Problem, dass wenn ich meinen FS20 Schalter schaltet in der Readings toggle steht und ich deswegen auf die Internal zugreife wo dank untoggle direkt on oder off steht. Also :&STATE statt :state. Allerdings scheint es mir so, dass er trotzdem auf den reading Wert zugreift. Denn im DOIF erscheint immer in den Readings des DoIF's: e_FS20_e4e401_state toggle
Kann das ein Bug sein?
Zitat von: v.i.p.e.r am 28 August 2015, 22:26:12
Hi,
wenn ich ein DoIF wie folgt definiert habe:
([FS20_e4e401:&STATE] eq "on") (set HUEDevice4 pct 100)
Jetzt habe ich das Problem, dass wenn ich meinen FS20 Schalter schaltet in der Readings toggle steht und ich deswegen auf die Internal zugreife wo dank untoggle direkt on oder off steht. Also :&STATE statt :state. Allerdings scheint es mir so, dass er trotzdem auf den reading Wert zugreift. Denn im DOIF erscheint immer in den Readings des DoIF's: e_FS20_e4e401_state toggle
Kann das ein Bug sein?
Bei &STATE wird intern das Internal benutzt, wenn ein beliebiger Trigger des Devices kommt, insb. auch vom Reading state. Ein Trigger vom Internal STATE ist im Event nicht erkennbar. Bei mir erscheint mit einem Dummy FS auch das Reading e_FS_STATE. Ist vielleicht Device spezifisch.
Gruß
Damian
Zitat von: Virsacer am 28 August 2015, 20:52:57
Hey,
beim Start bekomme ich noch diese Meldungen im Log:
2015.08.28 20:48:25 1: PERL WARNING: Use of uninitialized value $end in string gt at ./FHEM/98_DOIF.pm line 476.
2015.08.28 20:48:25 1: PERL WARNING: Use of uninitialized value $begin in string gt at ./FHEM/98_DOIF.pm line 476.
2015.08.28 20:48:25 1: PERL WARNING: Use of uninitialized value $begin in string ge at ./FHEM/98_DOIF.pm line 481.
Sollte mit der neuen Version nur noch kommen, wenn nach der Initilialisierungsphase die entsprechenden Dummys für Zeitintervalle immer noch nicht definiert sind.
Gruß
Damian
Zitat von: Ellert am 12 August 2015, 16:25:14
Bei der Verwendung der 98_DOIF.pm von gestern wurde die folgende bereits bestehende zweizeilige Definition nicht ausgeführt:
define VolTV_di DOIF ([osmc] eq "opened")({system "irsend SEND_ONCE receiver d-tv/cbl_alternative"},{system "irsend -#12 SEND_ONCE receiver KEY_VOLUMEUP"},set UE40D7090 connect)\
DOELSEIF ([osmc] eq "disconnected") (set UE40D7090 connect,{system "irsend -#12 SEND_ONCE receiver KEY_VOLUMEDOWN"})
Mit der gleichen einzeilig geschriebenen Definition gibt es keine Fehlermeldung und das DOIF wird korrekt ausgeführt.
define VolTV_di DOIF ([osmc] eq "opened")({system "irsend SEND_ONCE receiver d-tv/cbl_alternative"},{system "irsend -#12 SEND_ONCE receiver KEY_VOLUMEUP"},set UE40D7090 connect) DOELSEIF ([osmc] eq "disconnected") (set UE40D7090 connect,{system "irsend -#12 SEND_ONCE receiver KEY_VOLUMEDOWN"})
Der Fehler lässt sich mit dem Versuch nachstellen, im DEF-Editor die folgende Definition auf zwei Zeilen umzubrechen:
define m_di DOIF ([m] == 1) (set m #a) DOELSEIF ([m] == 2) (set m #b)
Es erscheint dann die Fehlermeldung:
Ich vermute es liegt an der Raute (#), die evtl. als Kommentar interpretiert wird.
Eine mehrzeile Definition wäre für mich weiterhin wünschenswert, da die Übersichtlichkeit erhöht wird.
Verdoppeln ## oder \# hilft nicht.
Ich würde mich freuen, wenn ich einen Tip bekommen könnte, wie ich die Raute auch in mehrzeiligen Definitionen verwenden kann.
Ich denke, ich werde Kommentare nur mit ## erlauben, in der Hoffnung, dass ## sonst nirgendwo vorkommt.
Gruß
Damian
Zitat von: Damian am 29 August 2015, 08:01:52
Sollte mit der neuen Version nur noch kommen, wenn nach der Initilialisierungsphase die entsprechenden Dummys für Zeitintervalle immer noch nicht definiert sind.
Und das heißt?
Ich nutze die aktuelle SVN Version und habe alle DOIFs in der fhem.cfg ganz am Ende stehen...
Also sind alle (eigenen) Dummys und referenzierten Devices vorher definiert - muss man für die Zeitintervalle selbst Dummys anlegen, oder wie meinst du das?
Zitat von: Damian am 29 August 2015, 09:52:16
Ich denke, ich werde Kommentare nur mit ## erlauben, in der Hoffnung, dass ## sonst nirgendwo vorkommt.
Was ist mit /* */ ?
Zitat von: Virsacer am 29 August 2015, 11:01:02
Und das heißt?
Ich nutze die aktuelle SVN Version und habe alle DOIFs in der fhem.cfg ganz am Ende stehen...
Also sind alle (eigenen) Dummys und referenzierten Devices vorher definiert - muss man für die Zeitintervalle selbst Dummys anlegen, oder wie meinst du das?
Was ist mit /* */ ?
Die SVN-Version hat da ja ein Problem, das Problem wurde mit der angehängten Version im ersten Post behoben (ich werde sie bald einchecken).
/* */ wäre eine Alternative, allerdings wird gerade in Perl oft # als Kommentarzeichen zeilenweise benutzt. Hierbei kann man nichts vergessen, weil man nichts schließen muss.
Gruß
Damian
/* */ könnte evtl. als regulärer Ausdruck in verwendet werden.
Aktuelle Version wurde eingecheckt. Kommentare beginnen mit ##. Aktualisierte Commandref zu neuen Features beachten.
Gruß
Damian
sehr gut! 1000 Dank
Dann werde ich mal vorsichtshalber alle meine Kommentare schnell überarbeiten, damit es morgen beim Update nicht knallt.
Eins meiner DOIFs hat heute morgen "Mist" gebaut:
Dabei handelt es sich um einen "Watchdog", der prüft, ob ein State bei set_x hängen bleibt und nach einer Minute den Befehl nochmal abschickt.
Allerdings hat er jetzt den Befehl für den vorherigen Zustand abgeschickt und jede Minute wiederholt :o
Hat sich da mit der neuen Version was geändert?
Ich konnte jetzt aber auch noch nicht prüfen, ob sich vielleicht am Device was geändert hat...
Also ich habs jetzt nochmal getestet:
Mit der vorherigen Version von DOIF funktionierts einwandfrei...
Ich hab jetzt eine zusätzliche if-Abfrage eingebaut, ob "set_" tatsächlich noch im Status enthalten ist :)
Damit sollte es auch in der neuen Version funktionieren - das seh ich dann morgen bzw. wenn der Status das nächste mal hängen bleibt :D
Zitat von: Virsacer am 01 September 2015, 18:31:23
Also ich habs jetzt nochmal getestet:
Mit der vorherigen Version von DOIF funktionierts einwandfrei...
Ich hab jetzt eine zusätzliche if-Abfrage eingebaut, ob "set_" tatsächlich noch im Status enthalten ist :)
Damit sollte es auch in der neuen Version funktionieren - das seh ich dann morgen bzw. wenn der Status das nächste mal hängen bleibt :D
Was ist bei dir die vorherige Version von DOIF?
Vorherige Version ist trunk/fhem@8432
Und neue Version ist trunk/fhem@9184
;)
Zitat von: Virsacer am 01 September 2015, 18:39:37
Vorherige Version ist trunk/fhem@8432
Und neue Version ist trunk/fhem@9184
;)
Bei einer Fehlerbeschreibung musst du am besten ein list des Moduls im Fehlerzustand hier posten, damit ich ein Fehlverhalten analysieren kann.
Gruß
Damian
Danke für das Update :)
Alles läuft, nur ein DOIF, das sich selbst abschalten soll, macht Probleme. Ich habe das nun auf diesen Einzeiler reduziert und erhalte den Fehler "error: Wrong timespec":
define test3.doif DOIF ([+[1]:17])(attr test3.doif disable 1)
Internals:
CFGFN
DEF ([+[1]:17])(attr test3.doif disable 1)
NAME test3.doif
NR 642
NTFY_ORDER 50-test3.doif
STATE cmd_1
TYPE DOIF
Readings:
2015-09-01 20:17:00 cmd_event timer_1
2015-09-01 20:17:00 cmd_nr 1
2015-09-01 20:17:00 state cmd_1
2015-09-01 20:17:00 timer_1_c1 error: Wrong timespec : either HH:MM:SS or {perlcode}
Devices:
Do:
0:
Itimer:
Realtime:
0 00:00:00
State:
Time:
Timecond:
Timer:
0 0
Timerfunc:
Attributes:
disable 1
Wenn ich disable 0 statt disable 1 setze, funktioniert es:
Internals:
CFGFN
DEF ([+[1]:24])(attr test3.doif disable 0)
NAME test3.doif
NR 642
NTFY_ORDER 50-test3.doif
STATE cmd_1
TYPE DOIF
Readings:
2015-09-01 20:24:00 cmd_event timer_1
2015-09-01 20:24:00 cmd_nr 1
2015-09-01 20:24:00 state cmd_1
2015-09-01 20:24:00 timer_1_c1 01.09.2015 21:24:00
Condition:
0 DOIF_time_once($hash,$hash->{timer}{0},$wday,"")
Days:
Devices:
Do:
0:
0 attr test3.doif disable 0
Helper:
globalinit 1
last_timer 1
sleeptimer -1
Itimer:
Realtime:
0 21:24:00
State:
Time:
0 +[1]:24
Timecond:
0 0
Timer:
0 0
Timerfunc:
Timers:
0 0
Attributes:
disable 0
Getestet habe ich mit # $Id: 98_DOIF.pm 9184 2015-08-31 18:35:06Z damian-s $
Sollte das funktionieren oder soll ich das ganze ohne ein "Selbstabschaltungs-DOIF" lösen?
Grüße,
Alex
Zitat von: All-Ex am 01 September 2015, 20:27:54
Danke für das Update :)
Alles läuft, nur ein DOIF, das sich selbst abschalten soll, macht Probleme. Ich habe das nun auf diesen Einzeiler reduziert und erhalte den Fehler "error: Wrong timespec":
define test3.doif DOIF ([+[1]:17])(attr test3.doif disable 1)
Internals:
CFGFN
DEF ([+[1]:17])(attr test3.doif disable 1)
NAME test3.doif
NR 642
NTFY_ORDER 50-test3.doif
STATE cmd_1
TYPE DOIF
Readings:
2015-09-01 20:17:00 cmd_event timer_1
2015-09-01 20:17:00 cmd_nr 1
2015-09-01 20:17:00 state cmd_1
2015-09-01 20:17:00 timer_1_c1 error: Wrong timespec : either HH:MM:SS or {perlcode}
Devices:
Do:
0:
Itimer:
Realtime:
0 00:00:00
State:
Time:
Timecond:
Timer:
0 0
Timerfunc:
Attributes:
disable 1
Wenn ich disable 0 statt disable 1 setze, funktioniert es:
Internals:
CFGFN
DEF ([+[1]:24])(attr test3.doif disable 0)
NAME test3.doif
NR 642
NTFY_ORDER 50-test3.doif
STATE cmd_1
TYPE DOIF
Readings:
2015-09-01 20:24:00 cmd_event timer_1
2015-09-01 20:24:00 cmd_nr 1
2015-09-01 20:24:00 state cmd_1
2015-09-01 20:24:00 timer_1_c1 01.09.2015 21:24:00
Condition:
0 DOIF_time_once($hash,$hash->{timer}{0},$wday,"")
Days:
Devices:
Do:
0:
0 attr test3.doif disable 0
Helper:
globalinit 1
last_timer 1
sleeptimer -1
Itimer:
Realtime:
0 21:24:00
State:
Time:
0 +[1]:24
Timecond:
0 0
Timer:
0 0
Timerfunc:
Timers:
0 0
Attributes:
disable 0
Getestet habe ich mit # $Id: 98_DOIF.pm 9184 2015-08-31 18:35:06Z damian-s $
Sollte das funktionieren oder soll ich das ganze ohne ein "Selbstabschaltungs-DOIF" lösen?
Grüße,
Alex
Bei mir läuft die Syntax ([+[1]:17]) mit der aktuellen Version ohne Probleme. Allerdings ist die Angabe nicht gerade sinnvoll, denn stündlich um 17 Minuten nach voller Stunde lässt sich einfacher definieren mit [:17]
Kurzfristig disablen kann man jetzt mit set <modulname> disable. Mit attr <modulname> disable 1 wird das Modul jetzt komplett deaktiviert. EDIT: Das wird wohl hier das Problem sein.
Steht aber alles in der aktuellen Commandref des Moduls.
Gruß
Damian
Zitat von: Damian am 01 September 2015, 20:59:26
Bei mir läuft die Syntax ([+[1]:17]) mit der aktuellen Version ohne Probleme. Allerdings ist die Angabe nicht gerade sinnvoll, denn stündlich um 17 Minuten nach voller Stunde lässt sich einfacher definieren mit [:17]
Kurzfristig disablen kann man jetzt mit set <modulname> disable. Mit attr <modulname> disable 1 wird das Modul jetzt komplett deaktiviert. EDIT: Das wird wohl hier das Problem sein.
Steht aber alles in der aktuellen Commandref des Moduls.
Gruß
Damian
Ich habe das Problem gefixt. Dennoch sollte man aus dem Code heraus ein DOIF-Modul per set <DOIF-Modul> disable deaktivieren, dadurch ändert sich im Gegensatz zum Deaktivieren per Attribut nicht die Konfiguration (rotes Fragezeichen).
Ein dauerhaftes Deaktivieren eines DOIF-Moduls sollte man dagegen per Attribut disable vornehmen - das Modul reagiert dann auf keine Trigger und braucht weniger Performance.
Gruß
Damian
Zitat von: Damian am 02 September 2015, 09:13:31
Ein dauerhaftes Deaktivieren eines DOIF-Moduls sollte man dagegen per Attribut disable vornehmen - das Modul reagiert dann auf keine Trigger und braucht weniger Performance.
Was sind dann die Schritte, um es wieder in Betrieb zu nehmen? Hatte das gerade (allerdings noch nicht mit der aktuelle DOIF-Version), dass ich ein rein zeitgesteuertes DOIF nach ein paar Monaten wieder mal verwenden wollte. Also das disable-Attribut gelöscht (nicht auf Null gesetzt, sondern direkt gelöscht). Danach waren aber immer noch die alten Timer von vor Monaten drin und aktualisierten sich auch nicht mehr. Erst das Erneuern der Definition (-> "initialized") brachte dann auch wieder aktuelle Timer.
([07:30|1])(set ...)
DOELSEIF([12:30|1])(set ...)
Zitat von: Brockmann am 02 September 2015, 14:24:59
Was sind dann die Schritte, um es wieder in Betrieb zu nehmen? Hatte das gerade (allerdings noch nicht mit der aktuelle DOIF-Version), dass ich ein rein zeitgesteuertes DOIF nach ein paar Monaten wieder mal verwenden wollte. Also das disable-Attribut gelöscht (nicht auf Null gesetzt, sondern direkt gelöscht). Danach waren aber immer noch die alten Timer von vor Monaten drin und aktualisierten sich auch nicht mehr. Erst das Erneuern der Definition (-> "initialized") brachte dann auch wieder aktuelle Timer.
([07:30|1])(set ...)
DOELSEIF([12:30|1])(set ...)
Die Funktionalität des alten Moduls mit Attribut disable entspricht der neuen Funktionalität mit set ... disable.
Das Aktivieren des Moduls mit einem gesetzten disable-Attribut wird durch das Löschen des Attributs mit deleteattr erreicht - beim set ... disable mit set ... initialize.
Gruß
Damian
Ein attr ... disable 0 funktioniert nicht mehr zum "Reaktivieren" bzw. Initialisieren nach einem attr ... disable 1 ?
Zitat von: Ralli am 03 September 2015, 05:50:44
Ein attr ... disable 0 funktioniert nicht mehr zum "Reaktivieren" bzw. Initialisieren nach einem attr ... disable 1 ?
Kann ich nicht bestätigen, wenn es eine Aussage ist.
Doch, wenn es eine Frage ist.
kurzum:
attr ... disable 0 bewirkt das Gleiche wie deleteattr ... disable.
Gruß
Damian
Hallo Damian, könntest du mal hier (http://forum.fhem.de/index.php/topic,39516.msg328325.html#msg328325) drauf schauen und mir einen Tipp geben..?
Also irgendwas stimmt mit der neuen Version (also rev9184 bzw. rev9193) nicht:
Ich hab in meinem DOIF
([Shutter] =~ /set_\d+/) als Bedingung. Attribute sind "do always" und "wait 60".
Der Timer wird korrekt gestartet, aber anscheinend nicht gestoppt, wenn die Bedingung nicht mehr erfüllt ist:
| Device | Shutter | 2015-09-03 17:43:59 |
| cmd_event | Shutter | 2015-09-03 16:36:12 |
| cmd_nr | 1 | 2015-09-03 16:36:12 |
| e_Shutter_STATE | up | 2015-09-03 17:43:59 |
| state | cmd_1 | 2015-09-03 16:36:12 |
| wait_timer | 03.09.2015 17:44:24 cmd_1 Shutter | 2015-09-03 17:43:24 |
Habs auch mal manuell gestartet und die Events geloggt:
2015-09-03 17:52:53 CUL_HM Shutter level: set_90
2015-09-03 17:52:53 DOIF WatchdogShutter wait_timer: 03.09.2015 17:53:53 cmd_1 Shutter
2015-09-03 17:52:53 CUL_HM Shutter set_90
2015-09-03 17:52:54 CUL_HM Shutter deviceMsg: up (to VCCU)
2015-09-03 17:52:54 CUL_HM Shutter level: 100
2015-09-03 17:52:54 CUL_HM Shutter motor: down:up
2015-09-03 17:52:54 CUL_HM Shutter pct: 100
2015-09-03 17:52:54 CUL_HM Shutter up
2015-09-03 17:52:54 CUL_HM Shutter timedOn: down
...
2015-09-03 17:53:00 CUL_HM Shutter deviceMsg: 90 (to VCCU)
2015-09-03 17:53:00 CUL_HM Shutter level: 90
2015-09-03 17:53:00 CUL_HM Shutter motor: stop:90
2015-09-03 17:53:00 CUL_HM Shutter pct: 90
2015-09-03 17:53:00 CUL_HM Shutter 90
2015-09-03 17:53:00 CUL_HM Shutter timedOn: down
...
2015-09-03 17:53:53 DOIF WatchdogShutter wait_timer: no timer
2015-09-03 17:53:53 DOIF WatchdogShutter cmd_nr: 1
2015-09-03 17:53:53 DOIF WatchdogShutter cmd_event: Shutter
2015-09-03 17:53:53 DOIF WatchdogShutter cmd_1
Hallo,
hast du ein DOELSE? Ich habe mal festgestellt, dass dieses Verhalten dann auftritt, wenn wenn es nur einen einzigen Zweig ohne DOELSE gibt...
Ronny
Nein, da ich nur einen Fall habe, sollte das DOELSE eigentlich implizit sein, mit der alten Version gings auch ohne und in der Commandref stehts auch nur so drin:
ZitatAnwendungsbeispiel: Benachrichtung "Waschmaschine fertig", wenn Verbrauch mindestens 5 Minuten unter 2 Watt (Perl-Code wird in geschweifte Klammern gesetzt):
define di_washer DOIF ([power:watt]<2) ({system("wmail washer finished")})
attr di_washer wait 300
...aber mit einem expliziten DOELSE() funktioniert es tatsächlich :o
Danke :)
Zitat von: Virsacer am 03 September 2015, 18:12:26
Nein, da ich nur einen Fall habe, sollte das DOELSE eigentlich implizit sein, mit der alten Version gings auch ohne und in der Commandref stehts auch nur so drin:
...aber mit einem expliziten DOELSE() funktioniert es tatsächlich :o
Danke :)
ja, das wurde irgendwann geändert. Der imaginäre DOELSE-Fall wird nur noch ohne do always gesetzt. In Verbindung mit do always muss man explizit DOELSE ohne etwas angeben. Das hat aber nichts mit der neuen Version zu tun.
Gruß
Damian
Hallo Damian
Besten Dank für Dein absolut cooles Modul. Mittlerweilen habe ich fast alle Notifys durch DOIF ersetzt, da es für mich als "nichtprogrammierer" doch sehr viel einfacher zum nachvollziehen ist...
Ich setzte folgendes DOIF seit mehreren Monaten ein. Es hat immer perfekt funktioniert. Komischerweise heute nicht mehr... Kann es einen Zusammenhang mit dem update des Moduls haben?
Es ist eine Beschattungssteuereung, welche einen Dummy "Beschattung_OG" schaltet, welcher wiederum die Rollladen Temperaturabhängig ganz oder teilweise zu fährt....
Hier das List:
Internals:
DEF ([Auto_Beschattung] eq "on" and [Beschattung_OG] eq "off" and [Helligkeit_Twilight:azimuth] > 109 and [Helligkeit_Twilight:azimuth] < 270 and ([Multisensor_Ost:state] > 25000 or [Sensor_Licht_Sued:state] > 19000)) (set Beschattung_OG on)
DOELSEIF ([Auto_Beschattung] eq "on" and [Beschattung_OG] eq "on" and [Helligkeit_Twilight:azimuth] > 109 and [Helligkeit_Twilight:azimuth] < 270 and [Sensor_Licht_Sued:state] < 9000) (set Beschattung_OG off)
DOELSEIF ([Auto_Beschattung] eq "on" and [Beschattung_OG] eq "on" and ([Helligkeit_Twilight:azimuth] > 277 or [Helligkeit_Twilight:compasspoint] eq "west")) (set Beschattung_OG off)
NAME di_SoSchu_OG
NR 119
NTFY_ORDER 50-di_SoSchu_OG
STATE cmd_1
TYPE DOIF
Readings:
2015-09-07 11:48:38 Device Helligkeit_Twilight
2015-09-05 10:32:45 cmd_event Multisensor_Ost
2015-09-05 10:32:45 cmd_nr 1
2015-09-07 11:44:03 e_Beschattung_OG_STATE off
2015-09-07 11:48:38 e_Helligkeit_Twilight_azimuth 148.18
2015-09-07 11:48:38 e_Helligkeit_Twilight_compasspoint southeast
2015-09-07 11:48:31 e_Multisensor_Ost_state 37134
2015-09-07 11:47:07 e_Sensor_Licht_Sued_state 39640
2015-09-05 10:32:45 state cmd_1
2015-09-06 08:50:23 wait_timer no timer
Condition:
0 InternalDoIf('Auto_Beschattung','STATE','') eq "on" and InternalDoIf('Beschattung_OG','STATE','') eq "off" and ReadingValDoIf('Helligkeit_Twilight','azimuth','') > 109 and ReadingValDoIf('Helligkeit_Twilight','azimuth','') < 270 and (ReadingValDoIf('Multisensor_Ost','state','') > 25000 or ReadingValDoIf('Sensor_Licht_Sued','state','') > 19000)
1 InternalDoIf('Auto_Beschattung','STATE','') eq "on" and InternalDoIf('Beschattung_OG','STATE','') eq "on" and ReadingValDoIf('Helligkeit_Twilight','azimuth','') > 109 and ReadingValDoIf('Helligkeit_Twilight','azimuth','') < 270 and ReadingValDoIf('Sensor_Licht_Sued','state','') < 9000
2 InternalDoIf('Auto_Beschattung','STATE','') eq "on" and InternalDoIf('Beschattung_OG','STATE','') eq "on" and (ReadingValDoIf('Helligkeit_Twilight','azimuth','') > 277 or ReadingValDoIf('Helligkeit_Twilight','compasspoint','') eq "west")
Devices:
0 Auto_Beschattung Beschattung_OG Helligkeit_Twilight Multisensor_Ost Sensor_Licht_Sued
1 Auto_Beschattung Beschattung_OG Helligkeit_Twilight Sensor_Licht_Sued
2 Auto_Beschattung Beschattung_OG Helligkeit_Twilight
all Auto_Beschattung Beschattung_OG Helligkeit_Twilight Multisensor_Ost Sensor_Licht_Sued
Do:
0:
0 set Beschattung_OG on
1:
0 set Beschattung_OG off
2:
0 set Beschattung_OG off
3:
Helper:
globalinit 1
last_timer 0
sleeptimer -1
Internals:
0 Auto_Beschattung:STATE Beschattung_OG:STATE
1 Auto_Beschattung:STATE Beschattung_OG:STATE
2 Auto_Beschattung:STATE Beschattung_OG:STATE
all Auto_Beschattung:STATE Beschattung_OG:STATE
Itimer:
Readings:
0 Helligkeit_Twilight:azimuth Multisensor_Ost:state Sensor_Licht_Sued:state
1 Helligkeit_Twilight:azimuth Sensor_Licht_Sued:state
2 Helligkeit_Twilight:azimuth Helligkeit_Twilight:compasspoint
all Helligkeit_Twilight:azimuth Multisensor_Ost:state Sensor_Licht_Sued:state Helligkeit_Twilight:compasspoint
State:
Trigger:
Attributes:
wait 900:2400
Aus meiner Sicht müsste mittlerweilen ein Timer gestartet sein, da sämtliche Bedingungen für die Erfüllung gegeben sind, oder?
Danke fürs anschauen
Hallo zusammen,
im kleinen funktioniert es mit dem wait ganz gut bei mir, aber wenn es etwas länger wird, blicke sich selber nicht mehr durch :-( da war das setzen vom sleep zwischendrin einfacher, das scheint jetzt aber nicht mehr zuverlässig zu funktionieren. Könnt Ihr mir beim überführen zu wait behilflich sein ?
Kompliziert wird es natürlich auch, wenn man im Ausführungsteil etwas ergänzt und dann mit den waits durcheinander kommt.
([{sunset(-1200)}|8]) (set Rolladen01 on, set Rolladen01_Zustand down, set gong_MP3 playTone 0, sleep 1; set gong_MP3 playTone 008, sleep 1; set gong_MP3 playTone 0) DOELSEIF ([{sunset(-2400)}|7]) (set Rolladen01 on, set Rolladen01_Zustand down, set gong_MP3 playTone 0, sleep 1; set gong_MP3 playTone 008, sleep 1; set gong_MP3 playTone 0) DOELSEIF ([{sunrise(+2)}|8]) (set Rolladen01 off, set Rolladen01_Zustand up, set gong_MP3 playTone 0, sleep 1; set gong_MP3 playTone 009, sleep 1; set gong_MP3 playTone 0) DOELSEIF ([{sunrise(+1200)}|7]) (set Rolladen01 off, set Rolladen01_Zustand up, set gong_MP3 playTone 0, sleep 1; set gong_MP3 playTone 009, sleep 1; set gong_MP3 playTone 0)
Gruß
Micha
Zitat von: Mumpitz am 07 September 2015, 11:50:34
Hallo Damian
Besten Dank für Dein absolut cooles Modul. Mittlerweilen habe ich fast alle Notifys durch DOIF ersetzt, da es für mich als "nichtprogrammierer" doch sehr viel einfacher zum nachvollziehen ist...
Ich setzte folgendes DOIF seit mehreren Monaten ein. Es hat immer perfekt funktioniert. Komischerweise heute nicht mehr... Kann es einen Zusammenhang mit dem update des Moduls haben?
Es ist eine Beschattungssteuereung, welche einen Dummy "Beschattung_OG" schaltet, welcher wiederum die Rollladen Temperaturabhängig ganz oder teilweise zu fährt....
Hier das List:
Internals:
DEF ([Auto_Beschattung] eq "on" and [Beschattung_OG] eq "off" and [Helligkeit_Twilight:azimuth] > 109 and [Helligkeit_Twilight:azimuth] < 270 and ([Multisensor_Ost:state] > 25000 or [Sensor_Licht_Sued:state] > 19000)) (set Beschattung_OG on)
DOELSEIF ([Auto_Beschattung] eq "on" and [Beschattung_OG] eq "on" and [Helligkeit_Twilight:azimuth] > 109 and [Helligkeit_Twilight:azimuth] < 270 and [Sensor_Licht_Sued:state] < 9000) (set Beschattung_OG off)
DOELSEIF ([Auto_Beschattung] eq "on" and [Beschattung_OG] eq "on" and ([Helligkeit_Twilight:azimuth] > 277 or [Helligkeit_Twilight:compasspoint] eq "west")) (set Beschattung_OG off)
NAME di_SoSchu_OG
NR 119
NTFY_ORDER 50-di_SoSchu_OG
STATE cmd_1
TYPE DOIF
Readings:
2015-09-07 11:48:38 Device Helligkeit_Twilight
2015-09-05 10:32:45 cmd_event Multisensor_Ost
2015-09-05 10:32:45 cmd_nr 1
2015-09-07 11:44:03 e_Beschattung_OG_STATE off
2015-09-07 11:48:38 e_Helligkeit_Twilight_azimuth 148.18
2015-09-07 11:48:38 e_Helligkeit_Twilight_compasspoint southeast
2015-09-07 11:48:31 e_Multisensor_Ost_state 37134
2015-09-07 11:47:07 e_Sensor_Licht_Sued_state 39640
2015-09-05 10:32:45 state cmd_1
2015-09-06 08:50:23 wait_timer no timer
Condition:
0 InternalDoIf('Auto_Beschattung','STATE','') eq "on" and InternalDoIf('Beschattung_OG','STATE','') eq "off" and ReadingValDoIf('Helligkeit_Twilight','azimuth','') > 109 and ReadingValDoIf('Helligkeit_Twilight','azimuth','') < 270 and (ReadingValDoIf('Multisensor_Ost','state','') > 25000 or ReadingValDoIf('Sensor_Licht_Sued','state','') > 19000)
1 InternalDoIf('Auto_Beschattung','STATE','') eq "on" and InternalDoIf('Beschattung_OG','STATE','') eq "on" and ReadingValDoIf('Helligkeit_Twilight','azimuth','') > 109 and ReadingValDoIf('Helligkeit_Twilight','azimuth','') < 270 and ReadingValDoIf('Sensor_Licht_Sued','state','') < 9000
2 InternalDoIf('Auto_Beschattung','STATE','') eq "on" and InternalDoIf('Beschattung_OG','STATE','') eq "on" and (ReadingValDoIf('Helligkeit_Twilight','azimuth','') > 277 or ReadingValDoIf('Helligkeit_Twilight','compasspoint','') eq "west")
Devices:
0 Auto_Beschattung Beschattung_OG Helligkeit_Twilight Multisensor_Ost Sensor_Licht_Sued
1 Auto_Beschattung Beschattung_OG Helligkeit_Twilight Sensor_Licht_Sued
2 Auto_Beschattung Beschattung_OG Helligkeit_Twilight
all Auto_Beschattung Beschattung_OG Helligkeit_Twilight Multisensor_Ost Sensor_Licht_Sued
Do:
0:
0 set Beschattung_OG on
1:
0 set Beschattung_OG off
2:
0 set Beschattung_OG off
3:
Helper:
globalinit 1
last_timer 0
sleeptimer -1
Internals:
0 Auto_Beschattung:STATE Beschattung_OG:STATE
1 Auto_Beschattung:STATE Beschattung_OG:STATE
2 Auto_Beschattung:STATE Beschattung_OG:STATE
all Auto_Beschattung:STATE Beschattung_OG:STATE
Itimer:
Readings:
0 Helligkeit_Twilight:azimuth Multisensor_Ost:state Sensor_Licht_Sued:state
1 Helligkeit_Twilight:azimuth Sensor_Licht_Sued:state
2 Helligkeit_Twilight:azimuth Helligkeit_Twilight:compasspoint
all Helligkeit_Twilight:azimuth Multisensor_Ost:state Sensor_Licht_Sued:state Helligkeit_Twilight:compasspoint
State:
Trigger:
Attributes:
wait 900:2400
Aus meiner Sicht müsste mittlerweilen ein Timer gestartet sein, da sämtliche Bedingungen für die Erfüllung gegeben sind, oder?
Danke fürs anschauen
Der letzte Schaltvorgang war um 2015-09-05 10:32:45 allerdings ohne Verzögerung, denn das Event war zum gleichen Zeitpunkt.
Hast du wait später gesetzt?
Bei mir laufen alle Verzögerung seit über einem Monat mit der neuen Version fehlerfrei.
Gruß
Damian
Nein. Das wait war schon immer so!
Kann es sein, dass das Problem war, dass der Status auf cmd_1 stand? Und dann wäre ja cmd_1 erneut aufgerufen worden wenn genug Sonne vorhanden war. Dann klappt es glaub nicht, oder? Könnte ich das mit dem do always umgehen?
Zitat von: Mumpitz am 07 September 2015, 22:33:59
Nein. Das wait war schon immer so!
Kann es sein, dass das Problem war, dass der Status auf cmd_1 stand? Und dann wäre ja cmd_1 erneut aufgerufen worden wenn genug Sonne vorhanden war. Dann klappt es glaub nicht, oder? Könnte ich das mit dem do always umgehen?
do always ist nicht sinnvoll, falls ein Device zyklisch sendet.
Ich weiß nicht, ob du zwischendurch das System neu gestartet hast. Du kannst das DOIF-Modul mit dem Attribut initialize beim Hochfahren neuinitialisieren lassen, dann wird nach dem Neustart unabhängig vom alten Zustand auf jeden Fall geschaltet, wenn die entsprechende Bedingung wahr wird.
Gruß
Damian
Zitat von: Damian am 27 Juli 2015, 10:36:43
Mal zur Info:
Man kann jetzt mit der neuen Version auch solche Sachen machen:
define di_Zufall DOIF ([:00]) (set bla on)
attr di_Zufall do always
attr di_Zufall timerWithWait
attr di_Zufall wait rand(60)
Gruß
Damian
Geht das dann auch in der Form?
attr di_Zufall wait rand(60):rand(900):0,5:10
Zitat von: Toto1973 am 09 September 2015, 10:43:07
Geht das dann auch in der Form?
attr di_Zufall wait rand(60):rand(900):0,5:10
Klar. Zitat aus der Commandref:
Verzögerungen
...
Statt Sekundenangaben können ebenfalls Stati in eckigen Klammen oder Perlbefehle angegeben werden.
Gruß
Damian
Ich hätte da noch "Vorschläge/Verbesserungen" :-)
Ich würde mir eine Datumssteuerung wünschen. Also das ich sagen kann, am XX.12.12 um 14 Uhr steuern. Dazu dann eben Dinge wie ab XX.12. alle 2 Tage usw...
Der 2. Vorschlag wäre, das DOIF alle "Zeilen" (also alle DOIFs und DOELSEIF) bis zum Ende durchsucht und alle Bedingungen, die eben wahr sind ausführt.
Nach meinen Kenntnisstand hört DOIF ja dann auf zu suchen, wenn eine "Zeile" (Bedingung) wahr ist.
Um das steuern zu können, könnte man ja das Attribut Do um einen Befehl erweitern.
Anwendungsbeispiel ist hier zum Beispiel eine Lichtsteuerung. Abhängig von Uhrzeiträumen sollen 2 Lampen gesteuert werden. Lampe 1 von 16:00 bis 22:00 Uhr wenn TV an ist, 2. Lampe von 17:00 bis 22:00 Uhr, wenn TV an ist.
Überschneidet sich dann der Zeitraum (TV geht um 17:10 Uhr an), wird ja nun die erste Bedingung (Lampe 1) geschaltet. Somit muss man die Steuerung in 2 DOIFs packen.
Ich würde es aber schöner finden, wenn ich beides in ein DOIF packen könnte. Dann müssen nicht so viele Prozesse im Hintergrund laufen!
Hallo Toto,
die Datumssteuerung ist m.W. in der Pipeline.
Den 2. Vorschlag finde ich in dieser Form unpassend - das hat mit if und else dann gar nichts mehr zu tun. Aber auch hier plant Damian m.W. die Möglichkeit, in der Def zusätzlich zu DOELSEIF und DOELSE noch weitere DOIFs einzubauen - damit wäre vermutlich das erfüllt, was Du Dir vorstellst.
@Toto1973: Fall 2 ist mit einer hinreichend genauen Bedingung zu lösen.
define du DOIF ([16:00:00-16:59:59] and [TVan]) (set Lampe1 on)
DOELSEIF ([17:00:00-22:00:00] and [TVan]) (set Lampe1:FILTER=STATE=off on, set Lampe2 on)
Zitat von: Ralli am 11 September 2015, 10:32:41
Hallo Toto,
die Datumssteuerung ist m.W. in der Pipeline.
Den 2. Vorschlag finde ich in dieser Form unpassend - das hat mit if und else dann gar nichts mehr zu tun. Aber auch hier plant Damian m.W. die Möglichkeit, in der Def zusätzlich zu DOELSEIF und DOELSE noch weitere DOIFs einzubauen - damit wäre vermutlich das erfüllt, was Du Dir vorstellst.
Ich habe mal überlegt mehrere DOIF-Fälle in einem Modul zu erlauben, das hätte allerdings einen entscheidenden Nachteil, dass mehrere Zustände (von verschiedenen DOIF-Fällen) bei einem Trigger nacheinander gesetzt und sich damit überschreiben würden. Damit würde man Problemfälle kaum noch nachvollziehen können - daher bleibt erst einmal alles beim alten.
In solch einem Fall muss man einfach mehrere DOIFs definieren.
Gruß
Damian
Zitat von: Ellert am 11 September 2015, 21:00:06
define du DOIF ([16:00:00-16:59:59] and [TVan]) (set Lampe1 on)
DOELSEIF ([17:00:00-22:00:00] and [TVan]) (set Lampe1:FILTER=STATE=off on, set Lampe2 on)
Kurze Frage dazu: Was bewirkt dieses ":FILTER=STATE=off"?
Das soll bewirken, dass Lampe1 nur eingeschaltet wird, wenn sie aus ist.
Siehe commandref, Abschnitt "Geräte-Spezifikation (devspec)".
Hier im konkreten Fall wird sie aber wohl auf jeden Fall eingeschaltet - auch wenn sie an ist.
Zitat
falls ein Gerätename exakt dem Spezifikation entspricht, dann werden keine reguläre Ausdrücke oder Filter ausgewertet.
Oh, das ist mir entgangen, dann müsste der nicht getestete Ausführungsteil so aussehen:
(set Lampe.?:FILTER=STATE=off on)
Wenn man über Steckdosen schaltet, die mit "on" ihren Zustand wechseln, kann man verhindern, dass Lampe1 wieder ausgeschaltet wird.
Ich benutze das DOIF sehr gern, deshalb bin ich gerade dabei meine Verzögerungen mit flüchtigen at auf die neuen wait Eigenschaften umzustellen.
Meine Verzögerungen sind von $we abhängig, die Startzeiten stehen in s7 und s8, die Verzögerungszeiten in Sekunden stehen in t7 und t8.
Ich könnte das DOIF so definieren:
([s7|7] or [s8|8]) ()
mit dem wait geht es nicht, dies funktioniert nicht:
wait [t7|7] or [t8|8]
wait if($we){return Value("t7")} else {return Value("t8")}
(Alternativ könnte man natürlich eine Funktion in der 99_myUtils.pm definieren, um vom Wochentag abhängige Zeiten zu erhalten.)
daher kann ich das DOIF nur so definieren:
([s7|7]) ()
DOELSEIF ([s8|8]) ()
(Für komplexere Bedingungen wird es dadurch unübersichtlicher.)
und das wait so:
wait [t7]:[t8]
Wäre es nicht wünschenswert, die Syntax der Zeitangaben in den Bedingungen auch für die wait timer einzuführen? Das könnte die Zahl der Bedingungszweige reduzieren.
Eine wait Definition sieht bei mir so aus:
0:0,300,[wendoHeatStartSZdur]:0,300,[workoHeatStartSZdur]:0,300,abs([wendoHeatEndSZ])*60:0,300,abs([workoHeatEndSZ])*60:3600:0
Da die Eingabezeile für Attribute recht kurz ist, schlage ich vor hier ein Editorfenster zur übersichtlichen Eingabe zu nutzen, wie es z.B. für das Attribut cellStyle der readingsGroup geschieht. Wird das im Modul gesteuert?
Zitat von: Ellert am 12 September 2015, 09:44:19
Ich benutze das DOIF sehr gern, deshalb bin ich gerade dabei meine Verzögerungen mit flüchtigen at auf die neuen wait Eigenschaften umzustellen.
Meine Verzögerungen sind von $we abhängig, die Startzeiten stehen in s7 und s8, die Verzögerungszeiten in Sekunden stehen in t7 und t8.
Ich könnte das DOIF so definieren:
([s7|7] or [s8|8]) ()
mit dem wait geht es nicht, dies funktioniert nicht:
wait [t7|7] or [t8|8]
wait if($we){return Value("t7")} else {return Value("t8")}
(Alternativ könnte man natürlich eine Funktion in der 99_myUtils.pm definieren, um vom Wochentag abhängige Zeiten zu erhalten.)
daher kann ich das DOIF nur so definieren:
([s7|7]) ()
DOELSEIF ([s8|8]) ()
(Für komplexere Bedingungen wird es dadurch unübersichtlicher.)
und das wait so:
wait [t7]:[t8]
Wäre es nicht wünschenswert, die Syntax der Zeitangaben in den Bedingungen auch für die wait timer einzuführen? Das könnte die Zahl der Bedingungszweige reduzieren.
Eine wait Definition sieht bei mir so aus:
0:0,300,[wendoHeatStartSZdur]:0,300,[workoHeatStartSZdur]:0,300,abs([wendoHeatEndSZ])*60:0,300,abs([workoHeatEndSZ])*60:3600:0
Da die Eingabezeile für Attribute recht kurz ist, schlage ich vor hier ein Editorfenster zur übersichtlichen Eingabe zu nutzen, wie es z.B. für das Attribut cellStyle der readingsGroup geschieht. Wird das im Modul gesteuert?
Du kannst auch mit Zeiten rechnen:
define s1 dummy
set s1 10:00
define t1 dummy
set t1 300
DOIF ([([s1]+[t1])|7] or ...) ()
oder
DOIF ([([s1]+myfunction())|7] or ...) ()Hier brauchst du kein wait.
Weitere Informationen siehe: Zeitsteuerung mit Zeitberechnung in der Commandref des Moduls
Gruß
Damian
Ja, da ist bei meiner Vereinfachung etwas untergegangen, es müsste so aussehen:
([s7|7]) () ()
DOELSEIF ([s8|8]) () ()
wait 0,[t7]:0,[t8]
Hier wäre folgendes wünschenswert, aus meiner Sicht.
([s7|7] or [s8|8]) () ()
wait 0,[t7|7] or [t8|8]
Bei mir konkret sind diese Dummys [work...] für Werktags und diese [wend...] fürs Wochenende. Die massgeblichen Bedingungszweige haben 3 Komandos:
wait 0:0,300,[wendoHeatStartSZdur]:0,300,[workoHeatStartSZdur]:0,300,abs([wendoHeatEndSZ])*60:0,300,abs([workoHeatEndSZ])*60:3600:0
Zitat von: Ellert am 12 September 2015, 11:19:09
Ja, da ist bei meiner Vereinfachung etwas untergegangen, es müsste so aussehen:
([s7|7]) () ()
DOELSEIF ([s8|8]) () ()
wait 0,[t7]:0,[t8]
Hier wäre folgendes wünschenswert, aus meiner Sicht.
([s7|7] or [s8|8]) () ()
wait 0,[t7|7] or [t8|8]
Bei mir konkret sind diese Dummys [work...] für Werktags und diese [wend...] fürs Wochenende. Die massgeblichen Bedingungszweige haben 3 Komandos:
wait 0:0,300,[wendoHeatStartSZdur]:0,300,[workoHeatStartSZdur]:0,300,abs([wendoHeatEndSZ])*60:0,300,abs([workoHeatEndSZ])*60:3600:0
ja, da wirst du erst mal mit mehreren DO-Fällen arbeiten müssen. Mangels Zeit wird es voraussichtlich erst im nächsten Jahr weitere Erweiterungen des Moduls geben. Bis dahin bietet das Modul bereits genügend Potential, um es nach belieben auszureizen ;)
Gruß
Damian
...bietet das Modul bereits genügend Potential... Deshalb bleibt das DOIF auch mein funktionales Lieblingsmodul :)
Ich steuere inzwischen alles mit DOIF.
Es ist sehr verständlich und hat fast unendlich viele Möglichkeiten ;-)
hallo zusammen
Ich habe heute bei meinem DOIF folgendes Verhalten festgestellt, welches ich nicht nachvollziehen kann:
ich habe folgendes DOIF für meine Beschattung:
Internals:
DEF ([Auto_Beschattung] eq "on" and [Beschattung_OG] eq "off" and [Helligkeit_Twilight:azimuth] > 109 and [Helligkeit_Twilight:azimuth] < 270 and ([Multisensor_Ost:state] > 25000 or [Sensor_Licht_Sued:state] > 19000)) (set Beschattung_OG on)
DOELSEIF ([Auto_Beschattung] eq "on" and [Beschattung_OG] eq "on" and [Helligkeit_Twilight:azimuth] > 109 and [Helligkeit_Twilight:azimuth] < 270 and [Sensor_Licht_Sued:state] < 9000) (set Beschattung_OG off)
DOELSEIF ([Auto_Beschattung] eq "on" and [Beschattung_OG] eq "on" and ([Helligkeit_Twilight:azimuth] > 277 or [Helligkeit_Twilight:compasspoint] eq "west")) (set Beschattung_OG off)
NAME di_SoSchu_OG
NR 119
NTFY_ORDER 50-di_SoSchu_OG
STATE cmd_2
TYPE DOIF
Readings:
2015-09-14 11:26:28 Device Multisensor_Ost
2015-09-14 11:17:15 cmd_event Beschattung_OG
2015-09-14 11:17:15 cmd_nr 2
2015-09-14 11:17:15 e_Beschattung_OG_STATE off
2015-09-14 11:24:36 e_Helligkeit_Twilight_azimuth 142.97
2015-09-14 11:24:36 e_Helligkeit_Twilight_compasspoint southeast
2015-09-14 11:26:28 e_Multisensor_Ost_state 2175
2015-09-14 04:33:17 e_Sensor_Licht_Sued_state 0
2015-09-14 11:17:15 state cmd_2
2015-09-14 11:17:15 wait_timer no timer
Condition:
0 InternalDoIf('Auto_Beschattung','STATE','') eq "on" and InternalDoIf('Beschattung_OG','STATE','') eq "off" and ReadingValDoIf('Helligkeit_Twilight','azimuth','') > 109 and ReadingValDoIf('Helligkeit_Twilight','azimuth','') < 270 and (ReadingValDoIf('Multisensor_Ost','state','') > 25000 or ReadingValDoIf('Sensor_Licht_Sued','state','') > 19000)
1 InternalDoIf('Auto_Beschattung','STATE','') eq "on" and InternalDoIf('Beschattung_OG','STATE','') eq "on" and ReadingValDoIf('Helligkeit_Twilight','azimuth','') > 109 and ReadingValDoIf('Helligkeit_Twilight','azimuth','') < 270 and ReadingValDoIf('Sensor_Licht_Sued','state','') < 9000
2 InternalDoIf('Auto_Beschattung','STATE','') eq "on" and InternalDoIf('Beschattung_OG','STATE','') eq "on" and (ReadingValDoIf('Helligkeit_Twilight','azimuth','') > 277 or ReadingValDoIf('Helligkeit_Twilight','compasspoint','') eq "west")
Devices:
0 Auto_Beschattung Beschattung_OG Helligkeit_Twilight Multisensor_Ost Sensor_Licht_Sued
1 Auto_Beschattung Beschattung_OG Helligkeit_Twilight Sensor_Licht_Sued
2 Auto_Beschattung Beschattung_OG Helligkeit_Twilight
all Auto_Beschattung Beschattung_OG Helligkeit_Twilight Multisensor_Ost Sensor_Licht_Sued
Do:
0:
0 set Beschattung_OG on
1:
0 set Beschattung_OG off
2:
0 set Beschattung_OG off
3:
Helper:
globalinit 1
last_timer 0
sleepdevice Beschattung_OG
sleepsubtimer -1
sleeptimer -1
Internals:
0 Auto_Beschattung:STATE Beschattung_OG:STATE
1 Auto_Beschattung:STATE Beschattung_OG:STATE
2 Auto_Beschattung:STATE Beschattung_OG:STATE
all Auto_Beschattung:STATE Beschattung_OG:STATE
Itimer:
Readings:
0 Helligkeit_Twilight:azimuth Multisensor_Ost:state Sensor_Licht_Sued:state
1 Helligkeit_Twilight:azimuth Sensor_Licht_Sued:state
2 Helligkeit_Twilight:azimuth Helligkeit_Twilight:compasspoint
all Helligkeit_Twilight:azimuth Multisensor_Ost:state Sensor_Licht_Sued:state Helligkeit_Twilight:compasspoint
State:
Trigger:
Attributes:
wait 900:2400
nach meiner Ansicht müsste der Multisensor_Ost während 900 sec den Wert von 25'000lx überschreiten, erst dann sollte er ausgelöst werden.
Anhand des Logs des Sensors ist jedoch ersichtlich, dass er nur um 1022 Uhr und 1024 Uhr diesen Wert überschritten hat. Daher hätte das DOIF den cmd_1 nicht auslösen dürfen. Oder sehe ich das falsch?
der Rollladen wurde jedoch um:
2015.09.14 10:37:15 3: CUL_HM set Rollladen_Eltern_1 0
ausgelöst :-(
Hier die Werte meines Sensors:
2015-09-14_10:40:21 Multisensor_Ost humidity: 63
2015-09-14_10:40:21 Multisensor_Ost temperature: 24
2015-09-14_10:40:21 Multisensor_Ost 5044
2015-09-14_10:40:21 Multisensor_Ost lux: 5044
2015-09-14_10:38:21 Multisensor_Ost humidity: 64
2015-09-14_10:38:21 Multisensor_Ost temperature: 23
2015-09-14_10:38:21 Multisensor_Ost 5698
2015-09-14_10:38:21 Multisensor_Ost lux: 5698
2015-09-14_10:36:21 Multisensor_Ost humidity: 64
2015-09-14_10:36:21 Multisensor_Ost temperature: 23
2015-09-14_10:36:21 Multisensor_Ost 7720
2015-09-14_10:36:21 Multisensor_Ost lux: 7720
2015-09-14_10:34:22 Multisensor_Ost humidity: 64
2015-09-14_10:34:22 Multisensor_Ost temperature: 22
2015-09-14_10:34:22 Multisensor_Ost 28036
2015-09-14_10:34:22 Multisensor_Ost lux: 28036
2015-09-14_10:32:14 Multisensor_Ost humidity: 64
2015-09-14_10:32:14 Multisensor_Ost temperature: 22
2015-09-14_10:32:14 Multisensor_Ost 17910
2015-09-14_10:32:14 Multisensor_Ost lux: 17910
2015-09-14_10:30:14 Multisensor_Ost humidity: 65
2015-09-14_10:30:14 Multisensor_Ost temperature: 22
2015-09-14_10:30:14 Multisensor_Ost 5340
2015-09-14_10:30:14 Multisensor_Ost lux: 5340
2015-09-14_10:28:15 Multisensor_Ost humidity: 67
2015-09-14_10:28:15 Multisensor_Ost temperature: 22
2015-09-14_10:28:15 Multisensor_Ost 5339
2015-09-14_10:28:15 Multisensor_Ost lux: 5339
2015-09-14_10:26:14 Multisensor_Ost humidity: 68
2015-09-14_10:26:14 Multisensor_Ost temperature: 22
2015-09-14_10:26:14 Multisensor_Ost 8084
2015-09-14_10:26:14 Multisensor_Ost lux: 8084
2015-09-14_10:24:14 Multisensor_Ost humidity: 67
2015-09-14_10:24:14 Multisensor_Ost temperature: 21
2015-09-14_10:24:14 Multisensor_Ost 32354
2015-09-14_10:24:14 Multisensor_Ost lux: 32354
2015-09-14_10:22:14 Multisensor_Ost humidity: 66
2015-09-14_10:22:14 Multisensor_Ost temperature: 20
2015-09-14_10:22:14 Multisensor_Ost 54612
2015-09-14_10:22:14 Multisensor_Ost lux: 54612
Den Licht_Sensor_Süd kann man vernachlässigen, der sendet zur Zeit immer 0. Sprich für die Auslösung nicht relevant...
Ich möchte auch sagen, dass das DOIF in den letzten Monaten immer funktioniert hat. Diesen, aus meiner Sicht, Fehler stelle ich erst jetzt fest...
Weiss jemand rat oder kann den Fehler nachvollziehen?
Hallo,
ein Schuss ins blaue: Kann es sein, dass du einen expliziten DOELSE-Zweig brauchst? Du hast nämlich den Multisensor in keinem anderen Zweig, daher wird der 1. Zweig nicht verlassen...
Ronny
Aus meiner Sicht braucht ich das nicht. Wenn der Sensorwert unterboten oder der azimuth wert größer ist wird ja cmd_2 oder 3 ausgelöst!
Aus meiner Sicht passiert nichts, wenn der Sensorwert unterboten wird, da keiner der anderen Trigger greift...
Zitat von: RoBra81 am 14 September 2015, 13:15:09
Aus meiner Sicht passiert nichts, wenn der Sensorwert unterboten wird, da keiner der anderen Trigger greift...
ja, in der Commandref steht auch:
Die Angaben werden immer von links nach rechts abgearbeitet. Zu
beachten ist, dass nur die Bedingungen überprüft werden, die zum ausgelösten Event das dazughörige Device bzw. die dazugehörige Triggerzeit beinhalten. Kommt ein Device in mehreren Bedingungen vor, so wird immer nur ein Kommando ausgeführt, und zwar das erste, für das die dazugehörige Bedingung in der abgearbeiteten Reihenfolge wahr ist.
Gruß
Damian
Hmm, jetzt steh ich etwas auf dem Schlauch:
Heißt das das ich einen doelse Zweig brauche welcher trigert wenn der Wert unter 25'000 ist?
Wenn ja, was soll der tun?
Wenn er dann nichts machen soll hängst du einfach ein DOELSE ohne Aktion hinten dran...
Zitat von: Mumpitz am 14 September 2015, 12:21:07
Aus meiner Sicht braucht ich das nicht. Wenn der Sensorwert unterboten oder der azimuth wert größer ist wird ja cmd_2 oder 3 ausgelöst!
Da der Sensorwert in den beiden anderen Bedingungen gar nicht abgefragt wird, können diese auch nicht reagieren, wenn er unterboten wird.
Die eigentlich entscheidende Stelle der Commandref ist vielleicht diese:
Zitat von: Commandref
Eine bereits ausgelöste Verzögerung wird zurückgesetzt, wenn während der Wartezeit ein Kommando eines anderen DO-Falls, ausgelöst durch ein neues Ereignis, ausgeführt werden soll.
Und zwar nur dann!
wait bedeutet also nicht, dass eine Aktion A ausgeführt wird, wenn die Bedingung A für die bei wait spezifizierte Zeit Bestand hat.
wait bedeutet: Wenn irgendwann mal Bedingung A galt und seitdem keine andere Bedingung desselben DOIF wahr geworden ist, wird nach Ablauf der in wait spezifierten Zeit Aktion A ausgeführt, egal ob Bedingung A zu diesem Zeitpunkt immer noch wahr ist oder nicht.
Man kann sich darüber streitet ob das nun ein Feature oder ein Fehler ist (DOIF vs. DOEVENIFNOTANYMORE). Aber so ist es nunmal und man muss sein DOIF ggf. um diese Eigenart herumprogrammieren. Wie hier ja schon geschrieben wurde, ist ein "leeres" DOELSE der bevorzugte Workaround.
das heisst wenn ich nun:
([Auto_Beschattung] eq "on" and [Beschattung_OG] eq "off" and [Helligkeit_Twilight:azimuth] > 109 and [Helligkeit_Twilight:azimuth] < 270 and ([Multisensor_Ost:state] > 25000 or [Sensor_Licht_Sued:state] > 19000)) (set Beschattung_OG on)
DOELSEIF ([Auto_Beschattung] eq "on" and [Beschattung_OG] eq "on" and [Helligkeit_Twilight:azimuth] > 109 and [Helligkeit_Twilight:azimuth] < 270 and [Sensor_Licht_Sued:state] < 9000) (set Beschattung_OG off)
DOELSEIF ([Auto_Beschattung] eq "on" and [Beschattung_OG] eq "on" and ([Helligkeit_Twilight:azimuth] > 277 or [Helligkeit_Twilight:compasspoint] eq "west")) (set Beschattung_OG off) DOLESE ()
dann habe ich mein gewünschtes verhalten?
Fast, wenn du DOELSE statt DOLESE schreibst...
:) :) :) :) :)
merci!
8)
meine Frage betrifft das Initialisieren des DOIF ich kann das mit einem zusätzlichem DOIF Ein und Aus schalten und dieses funktioniert auch mit diesem Code:
DEF
([du_ZeitsteuerungWegTage] eq "Aus") (set di_WegBeleuchtung_Morgens disable)
DOELSEIF ([du_ZeitsteuerungWegTage] ne "Aus") (set di_WegBeleuchtung_Morgens initialize)
Was mir nicht gelingt ist dieses alles in dem DOIF zu machen welches ich für eine Beleuchtung nutze, hier kann ich es zwar ausschalten, aber das einschalten klappt irgendwie nicht, dass geht wohl nicht..?
Ich hatte beide obigen set Befehle an den Anfang des DOIF gesetzt aber das funktioniert nicht das DOIF bleibt immer auf "disable"
Zitat von: moonsorrox am 14 September 2015, 18:20:23
meine Frage betrifft das Initialisieren des DOIF ich kann das mit einem zusätzlichem DOIF Ein und Aus schalten und dieses funktioniert auch mit diesem Code:
DEF
([du_ZeitsteuerungWegTage] eq "Aus") (set di_WegBeleuchtung_Morgens disable)
DOELSEIF ([du_ZeitsteuerungWegTage] ne "Aus") (set di_WegBeleuchtung_Morgens initialize)
Was mir nicht gelingt ist dieses alles in dem DOIF zu machen welches ich für eine Beleuchtung nutze, hier kann ich es zwar ausschalten, aber das einschalten klappt irgendwie nicht, dass geht wohl nicht..?
Ich hatte beide obigen set Befehle an den Anfang des DOIF gesetzt aber das funktioniert nicht das DOIF bleibt immer auf "disable"
Mit der aktuellen Version muss "set di_WegBeleuchtung_Morgens initialize" funktionieren. Der Status des Moduls steht dann auf initialize und das Modul ist scharf gestellt. Den Befehl kannst du ja über die Kommandozeile testen.
Ich gehe jetzt schwer davon aus, dass dein Modul (dessen Namen ich hier nicht sehe) sich nicht selbst deaktiviert, dann kann es sich natürlich nicht mehr selbst initialisieren, weil es ja nicht mehr aktiv ist.
Gruß
Damian
Zitat von: Damian am 14 September 2015, 18:31:35
Den Befehl kannst du ja über die Kommandozeile testen.
ja klar das funktioniert und mit meinem sogenannten Ausschalt DOIF funktioniert das auch. Ich wollte es nur in diesem DOIF integrieren und habe es nicht hinbekommen:
DEF:
([du_ZeitsteuerungWegTage] eq "Mo-Do" and [04:55-{sunrise_rel(0,"05:54","07:00")}|1234] and [myTwilight:twilight_weather] < 9) (set WegLampe_Sw_02 on)
DOELSEIF ([du_ZeitsteuerungWegTage] eq "Di-Fr" and [04:55-{sunrise_rel(0,"05:54","07:00")}|2345] and [myTwilight:twilight_weather] < 9) (set WegLampe_Sw_02 on)
DOELSEIF ([du_ZeitsteuerungWegTage] eq "Mi-Sa" and [04:55-{sunrise_rel(0,"05:54","07:00")}|3456] and [myTwilight:twilight_weather] < 9) (set WegLampe_Sw_02 on)
DOELSEIF ([du_ZeitsteuerungWegTage] eq "Do-So" and [04:55-{sunrise_rel(0,"05:54","07:00")}|4560] and [myTwilight:twilight_weather] < 9) (set WegLampe_Sw_02 on)
DOELSEIF ([du_ZeitsteuerungWegTage] eq "Fr-Mo" and [04:55-{sunrise_rel(0,"05:54","07:00")}|5601] and [myTwilight:twilight_weather] < 9) (set WegLampe_Sw_02 on)
DOELSEIF ([du_ZeitsteuerungWegTage] eq "Sa-Di" and [04:55-{sunrise_rel(0,"05:54","07:00")}|6012] and [myTwilight:twilight_weather] < 9) (set WegLampe_Sw_02 on)
DOELSEIF ([du_ZeitsteuerungWegTage] eq "So-Mi" and [04:55-{sunrise_rel(0,"05:54","07:00")}|0123] and [myTwilight:twilight_weather] < 9) (set WegLampe_Sw_02 on)
DOELSEIF ([du_ZeitsteuerungWegTage] eq "Mo-Fr" and [04:55-{sunrise_rel(0,"05:54","07:00")}|12345] and [myTwilight:twilight_weather] < 9) (set WegLampe_Sw_02 on)
DOELSEIF ([du_ZeitsteuerungWegTage] eq "Mo-Sa" and [04:55-{sunrise_rel(0,"05:54","07:00")}|123456] and [myTwilight:twilight_weather] < 9) (set WegLampe_Sw_02 on)
DOELSEIF ([du_ZeitsteuerungWegTage] eq "Sa-So" and [04:55-{sunrise_rel(0,"05:54","07:00")}|06] and [myTwilight:twilight_weather] < 9) (set WegLampe_Sw_02 on)
DOELSE (set WegLampe_Sw_02 off, set di_WegBeleuchtung_Morgens initialize)Ich hatte das am Anfang eingetragen aber es funktionierte nicht...
so hatte ich es vor dem ersten Timer drin: natürlich mit einem weiteren DOELSEIF vor dem 1.Timer
([du_ZeitsteuerungWegTage] eq "Aus") (set di_WegBeleuchtung_Morgens disable)
DOELSEIF ([du_ZeitsteuerungWegTage] ne "Aus") (set di_WegBeleuchtung_Morgens initialize)
Zitat von: moonsorrox am 14 September 2015, 18:39:19
ja klar das funktioniert und mit meinem sogenannten Ausschalt DOIF funktioniert das auch. Ich wollte es nur in diesem DOIF integrieren und habe es nicht hinbekommen:
DEF:
([du_ZeitsteuerungWegTage] eq "Mo-Do" and [04:55-{sunrise_rel(0,"05:54","07:00")}|1234] and [myTwilight:twilight_weather] < 9) (set WegLampe_Sw_02 on)
DOELSEIF ([du_ZeitsteuerungWegTage] eq "Di-Fr" and [04:55-{sunrise_rel(0,"05:54","07:00")}|2345] and [myTwilight:twilight_weather] < 9) (set WegLampe_Sw_02 on)
DOELSEIF ([du_ZeitsteuerungWegTage] eq "Mi-Sa" and [04:55-{sunrise_rel(0,"05:54","07:00")}|3456] and [myTwilight:twilight_weather] < 9) (set WegLampe_Sw_02 on)
DOELSEIF ([du_ZeitsteuerungWegTage] eq "Do-So" and [04:55-{sunrise_rel(0,"05:54","07:00")}|4560] and [myTwilight:twilight_weather] < 9) (set WegLampe_Sw_02 on)
DOELSEIF ([du_ZeitsteuerungWegTage] eq "Fr-Mo" and [04:55-{sunrise_rel(0,"05:54","07:00")}|5601] and [myTwilight:twilight_weather] < 9) (set WegLampe_Sw_02 on)
DOELSEIF ([du_ZeitsteuerungWegTage] eq "Sa-Di" and [04:55-{sunrise_rel(0,"05:54","07:00")}|6012] and [myTwilight:twilight_weather] < 9) (set WegLampe_Sw_02 on)
DOELSEIF ([du_ZeitsteuerungWegTage] eq "So-Mi" and [04:55-{sunrise_rel(0,"05:54","07:00")}|0123] and [myTwilight:twilight_weather] < 9) (set WegLampe_Sw_02 on)
DOELSEIF ([du_ZeitsteuerungWegTage] eq "Mo-Fr" and [04:55-{sunrise_rel(0,"05:54","07:00")}|12345] and [myTwilight:twilight_weather] < 9) (set WegLampe_Sw_02 on)
DOELSEIF ([du_ZeitsteuerungWegTage] eq "Mo-Sa" and [04:55-{sunrise_rel(0,"05:54","07:00")}|123456] and [myTwilight:twilight_weather] < 9) (set WegLampe_Sw_02 on)
DOELSEIF ([du_ZeitsteuerungWegTage] eq "Sa-So" and [04:55-{sunrise_rel(0,"05:54","07:00")}|06] and [myTwilight:twilight_weather] < 9) (set WegLampe_Sw_02 on)
DOELSE (set WegLampe_Sw_02 off, set di_WegBeleuchtung_Morgens initialize)
Ich hatte das am Anfang eingetragen aber es funktionierte nicht...
so hatte ich es vor dem ersten Timer drin: natürlich mit einem weiteren DOELSEIF vor dem 1.Timer
([du_ZeitsteuerungWegTage] eq "Aus") (set di_WegBeleuchtung_Morgens disable)
DOELSEIF ([du_ZeitsteuerungWegTage] ne "Aus") (set di_WegBeleuchtung_Morgens initialize)
Wenn es über Kommandozeile funktioniert, dann muss es auch in einem anderen DOIF funktioniert (ich habe es gerade bei mir nachgestellt). Offenbar wird dein DOELSE-Zweig nicht ausgeführt. Aber das kannst du ja im Log nachvollziehen.
Gruß
Damian
OK, ich lasse das mit dem 2. DOIF das funktioniert ja ;)
Hallo Damian,
ich würde gerne im wait Minuten in Sekunden umrechnen.
attr di_test wait 0:([d_test:hysteresis]*60):0
Ist so etwas schon implementiert? Laut Commandref geht
Zitat
Statt Sekundenangaben können ebenfalls Stati in eckigen Klammen oder Perlbefehle angegeben werden.
Aber auch wenn ich statt der eckigen Klammern ReadingsVal nehme findet keine Verzögerung statt.
Danke und Grüße
igami
Zitat von: igami am 15 September 2015, 12:49:27
Hallo Damian,
ich würde gerne im wait Minuten in Sekunden umrechnen.
attr di_test wait 0:([d_test:hysteresis]*60):0
Ist so etwas schon implementiert? Laut Commandref gehtAber auch wenn ich statt der eckigen Klammern ReadingsVal nehme findet keine Verzögerung statt.
Danke und Grüße
igami
Es war mir klar, dass die Anforderung früher oder später kommen wird. Das Problem ist der Doppelpunkt vor hysteresis, denn dieser Doppelpunkt wird als Trennzeichen für wait ausgewertet. Die Klammerung mit runden Klammern hast du schon intuitiv richtig gemacht - so wird es mal funktionieren, allerdings ist die Sache noch nicht programmiert.
Z. Zt. kann man beliebige Perlausdrücke bei wait verwenden, solange kein Doppelpunkt bzw. Komma im Ausdruck vorkommt.
Gruß
Damian
Habe ich schon geahnt, dass die beiden Zeichen das Problem verursachen.
Trotztdem Danke, werde ich es vorerst über ein readingsProxy lösen.
Hallo zusammen,
ich habe es leider nch nicht hinbekommen mein DOIF auf wait umzubauen, damit die Töne vernünftig abgespeilt werden:
([{sunset(-600)}|8] and [Kontakt_Garten] eq "closed") (set Rolladen02 on, set Rolladen02_Zustand down, set gong_MP3 playTone 0, sleep 1; set gong_MP3 playTone 008, sleep 1; set gong_MP3 playTone 0) DOELSEIF ([{sunset(-1200)}|7]) (set Rolladen02 on, set Rolladen02_Zustand down, set gong_MP3 playTone 0, sleep 1; set gong_MP3 playTone 008, sleep 1; set gong_MP3 playTone 0) DOELSEIF ([{sunrise(+1)}|8]) (set Rolladen02 off, set Rolladen02_Zustand up, set gong_MP3 playTone 0, sleep 1; set gong_MP3 playTone 009, sleep 1; set gong_MP3 playTone 0) DOELSEIF ([{sunrise(+600)}|7]) (set Rolladen02 off, set Rolladen02_Zustand up, set gong_MP3 playTone 0, sleep 1; set gong_MP3 playTone 009, sleep 1; set gong_MP3 playTone 0)
Wenn ich die neue Datei verwende, dann werden auch die sleep Befehle nicht mehr ausgeführt. Wird die neue Datei eigentlich bei einem Update überschrieben?
Eins ist mir ja schon klar, das die sleep Anweisungen entfernt werden müssen:
([{sunset(-600)}|8] and [Kontakt_Garten] eq "closed") (set Rolladen02 on, set Rolladen02_Zustand down, set gong_MP3 playTone 0, set gong_MP3 playTone 008, set gong_MP3 playTone 0) DOELSEIF ([{sunset(-1200)}|7]) (set Rolladen02 on, set Rolladen02_Zustand down, set gong_MP3 playTone 0, set gong_MP3 playTone 008, set gong_MP3 playTone 0) DOELSEIF ([{sunrise(+1)}|8]) (set Rolladen02 off, set Rolladen02_Zustand up, set gong_MP3 playTone 0, set gong_MP3 playTone 009, set gong_MP3 playTone 0) DOELSEIF ([{sunrise(+600)}|7]) (set Rolladen02 off, set Rolladen02_Zustand up, set gong_MP3 playTone 0, set gong_MP3 playTone 009, set gong_MP3 playTone 0)
Aber wie werden jetzt die attr wait auf die einzelnen Ereignisse und Aktionen verteilt nur mit hilfe des : ?
und aus ([{sunrise(-0)}]) ((set gong_MP3 playTone 254,016)) muss dann ([{sunrise(-0)}]) (set gong_MP3 playTone 254, set gong_MP3 playTone 016) werden mit attr wait 0,1
Gruß
Micha
Hast du mal hier geschaut:
http://fhem.de/commandref_DE.html#DOIF (http://fhem.de/commandref_DE.html#DOIF) und dann unter Verzögerungen??
Du musst jeden Befehl, der verzögert werden soll in eine eigene () setzen. Dann mit dem attr wait dieses Ansprechen. Gezählt werden alle () mit Befehlen von links nach rechts, wobei sie mit einem , getrennt sind. Die einzelnen DOELSEIF werden mittels eines : angesprochen.
ErsterBefehl nach DOIF, ZweiterBefehl nach DOIF : ErsterBefehl nach DOELSEIF, ZweiterBefehl nach DOELSEIF : ...
Danke Amenophisophis86,
also wäre für meinen Fall dann:
define sonnenuntergang_doif DOIF ([{sunset(-0)}]) (set gong_MP3 playTone 254)(set gong_MP3 playTone 017)
attr sonnenuntergang_doif room gong_ansagen
attr sonnenuntergang_doif wait 0,1
korrekt ?!
Gruß
Micha
Hallo,
ich hatte ein Problem mit einem DOIF, das ich auf dieses Minimal-DOIF reduziert habe:
So funktioniert es:
([20:42]) ## Um 20:42
(set PushMessage msg 'test')
Mit einem Kommentar in der letzten Zeile funktioniert es nicht:
([20:42]) ## Um 20:42
(set PushMessage msg 'test') ## Sende Nachricht
sondern meldet beim Speichern im Webfrontend test.doif DOIF: expected DOELSEIF or DOELSE:
Ich nutze # $Id: 98_DOIF.pm 9193 2015-09-02 07:08:58Z damian-s $
Zitat von: All-Ex am 15 September 2015, 20:43:54
Hallo,
ich hatte ein Problem mit einem DOIF, das ich auf dieses Minimal-DOIF reduziert habe:
So funktioniert es:
([20:42]) ## Um 20:42
(set PushMessage msg 'test')
Mit einem Kommentar in der letzten Zeile funktioniert es nicht:
([20:42]) ## Um 20:42
(set PushMessage msg 'test') ## Sende Nachricht
sondern meldet beim Speichern im Webfrontend test.doif DOIF: expected DOELSEIF or DOELSE:
Ich nutze # $Id: 98_DOIF.pm 9193 2015-09-02 07:08:58Z damian-s $
Habe es gefixt. Es liegt an den Leerzeichen in der letzten Zeile. Bis zum Update kannst du dir behelfen mit:
(set PushMessage msg 'test')## Sende NachrichtGruß
Damian
Hallo Damin,
Boh, Danke für den Raketenschnellen Fix ;D Werd ich morgen testen...
Nun bin ich grad auf noch ein Thema gestoßen:
ZitatMit dem Attribut cmdpause <Sekunden für cmd_1>:<Sekunden für cmd_2>:... wird die Zeitspanne in Sekunden angegeben für eine Zwangspause seit der letzten Zustandsänderung. In der angegebenen Zeitspanne wird ein Kommando nicht ausgeführt, auch wenn die dazugehörige Bedingung wahr wird.
Ich hab einen Dummy-Taster mit dem Namen
taster1 und ein DOIF mit dem Namen
test.doif. Das DOIF soll alle 15 Sekunden etwas tun. Wenn der
taster1 gedrückt wird, soll es etwas anderes machen:
([+00:00:15])
( { Log 1,"Alle 15 Sekunden" } )
DOELSEIF
([taster1])
( { Log 1,"Taster 1 gedrückt" } )
Attributes: do alwaysDas funktioniert.
Nun möchte ich den 2. Fall nur ausführen, wenn taster1 länger als 30 Sekunden nicht mehr gedrückt wurde. Daher habe ich das Attribut
cmdpause 0:30 gesetzt.
Aber cmd_2 wird nun gar nicht mehr getriggert, im Log steht:
2015.09.15 22:21:23.859 1: Alle 15 Sekunden
2015.09.15 22:21:38.013 1: Alle 15 Sekunden
2015.09.15 22:21:53.011 1: Alle 15 Sekunden
Um 22:21:43 habe ich
taster1 getriggert, aber der hat kein cmd_2 ausgelöst:
Internals:
DEF ([+00:00:15])
( { Log 1,"Alle 15 Sekunden" } )
DOELSEIF
([taster1])
( { Log 1,"Taster 1 gedrückt" } )
NAME test.doif
NR 185
NTFY_ORDER 50-test.b.doif
STATE cmd_1
TYPE DOIF
Readings:
2015-09-15 22:21:43 Device taster1
2015-09-15 22:21:38 cmd_event timer_1
2015-09-15 22:21:38 cmd_nr 1
2015-09-15 22:21:43 e_taster1_STATE something
2015-09-15 22:21:38 state cmd_1
2015-09-15 22:21:38 timer_1_c1 15.09.2015 22:21:53
Condition:
0 DOIF_time_once($hash,$hash->{timer}{0},$wday,"")
1 InternalDoIf('taster1','STATE','')
Days:
Devices:
1 taster1
all taster1
Do:
0:
0 { Log 1,"Alle 15 Sekunden" }
1:
0 { Log 1,"Taster 1 gedrückt" }
Helper:
globalinit 1
last_timer 1
sleeptimer -1
Internals:
1 taster1:STATE
all taster1:STATE
Itimer:
Readings:
Realtime:
0 22:21:53
State:
Time:
0 +00:00:15
Timecond:
0 0
Timer:
0 0
Timerfunc:
Timers:
0 0
Trigger:
Attributes:
cmdpause 0:30
do always
room testraum Sollte das funktionieren? Oder nehm ich einfach 2 DOIFs, wenn sich Zeitangaben nach Zeitraster und cmdpause überschneiden?
Viele Grüße,
Alex
Zitat von: All-Ex am 15 September 2015, 22:32:11
Sollte das funktionieren? Oder nehm ich einfach 2 DOIFs, wenn sich Zeitangaben nach Zeitraster und cmdpause überschneiden?
Bin zwar nicht Damian, aber im List siehst Du, dass die letzte Zustandsänderung des DOIF um 22:21:38 erfolgte.
Wenn Du nun fünf Sekunden später den Taster drückst, sind noch keine 30 Sekunden rum und das Kommando wird wegen der cmdpause nicht ausgeführt.
Dein DOIF wird wegen do always alle 15 Sekunden getriggert, von daher dürfte cmdpause 30 in diesem Fall dafür sorgen, dass cmd_2 nie ausgeführt wird.
Vielleicht könntest Du statt cmdpause das Alter des Readings verwenden, etwa so:
DOELSEIF ([taster1] and [test.doif:e_taster1_STATE:sec] > 30)Dieses Reading existiert zwar beim Define noch nicht, aber ich meine, damit kann DOIF umgehen. Ohne Gewähr, aber ist vielleicht einen Versuch wert.
Hi Brockmann,
Danke für die Antwort, hört sich logisch an und ich war wohl auf dem Holzweg... Ich werde das probieren.
Hallo zusammen,
ich experementiere gerade mit den waits ein wenig rum, damit die MP3 Ansagen vom Gong korrekt gemacht werden.
Ohne wait funktioniert
define gong_mp3_taster_doif DOIF ([taster_gong:?on]) ((set gong_MP3 playTone 0,002,0))
attr gong_mp3_taster_doif do always
attr gong_mp3_taster_doif room gong_ansagen
define taster_gong dummy
attr taster_gong devStateIcon on:remotecontrol/black_btn_GREEN:on
attr taster_gong room gong_ansagen
attr taster_gong setList state:on off
attr taster_gong webCmd :
aber das hier funktioniert leider nicht (wobei es nur um den letzten Block geht
define Rolladen01_timer_test DOIF ([10:00]) (set Rolladen01 on)(set Rolladen01_Zustand down)(set gong_MP3 playTone 0)(set gong_MP3 playTone 008)(set gong_MP3 playTone 0) DOELSEIF ([10:01]) (set Rolladen01 on)(set Rolladen01_Zustand down)(set gong_MP3 playTone 0)(set gong_MP3 playTone 008)(set gong_MP3 playTone 0) DOELSEIF ([10:10]) (set Rolladen01 off, set Rolladen01_Zustand up)(set gong_MP3 playTone 0)(set gong_MP3 playTone 009)(set gong_MP3 playTone 0) DOELSEIF ([10:33]) (set Rolladen01 off, set Rolladen01_Zustand up)(set gong_MP3 playTone 0,009,0)
attr Rolladen01_timer_test room Wohnzimmer
attr Rolladen01_timer_test wait 0,0,1,1,1:0,0,1,1,1:0,1,1,1:0,0
wenn ich es ändere in:
define Rolladen01_timer_test DOIF ([10:00]) (set Rolladen01 on)(set Rolladen01_Zustand down)(set gong_MP3 playTone 0)(set gong_MP3 playTone 008)(set gong_MP3 playTone 0) DOELSEIF ([10:01]) (set Rolladen01 on)(set Rolladen01_Zustand down)(set gong_MP3 playTone 0)(set gong_MP3 playTone 008)(set gong_MP3 playTone 0) DOELSEIF ([10:10]) (set Rolladen01 off, set Rolladen01_Zustand up)(set gong_MP3 playTone 0)(set gong_MP3 playTone 009)(set gong_MP3 playTone 0) DOELSEIF ([11:03]) (set Rolladen01 off, set Rolladen01_Zustand up)(set gong_MP3 playTone 0)(set gong_MP3 playTone 009)(set gong_MP3 playTone 0)
attr Rolladen01_timer_test room Wohnzimmer
attr Rolladen01_timer_test wait 0,0,1,1,1:0,0,1,1,1:0,1,1,1:0,0,2,4
funktioniert es.
Gruß
Micha
P.S. in den Logs tauch auch nichtzs zu set Rolladen01_Zustand up auf :-(
Zitat von: mfeske am 17 September 2015, 11:05:03
Hallo zusammen,
ich experementiere gerade mit den waits ein wenig rum, damit die MP3 Ansagen vom Gong korrekt gemacht werden.
Ohne wait funktioniert
define gong_mp3_taster_doif DOIF ([taster_gong:?on]) ((set gong_MP3 playTone 0,002,0))
attr gong_mp3_taster_doif do always
attr gong_mp3_taster_doif room gong_ansagen
define taster_gong dummy
attr taster_gong devStateIcon on:remotecontrol/black_btn_GREEN:on
attr taster_gong room gong_ansagen
attr taster_gong setList state:on off
attr taster_gong webCmd :
aber das hier funktioniert leider nicht (wobei es nur um den letzten Block geht
define Rolladen01_timer_test DOIF ([10:00]) (set Rolladen01 on)(set Rolladen01_Zustand down)(set gong_MP3 playTone 0)(set gong_MP3 playTone 008)(set gong_MP3 playTone 0) DOELSEIF ([10:01]) (set Rolladen01 on)(set Rolladen01_Zustand down)(set gong_MP3 playTone 0)(set gong_MP3 playTone 008)(set gong_MP3 playTone 0) DOELSEIF ([10:10]) (set Rolladen01 off, set Rolladen01_Zustand up)(set gong_MP3 playTone 0)(set gong_MP3 playTone 009)(set gong_MP3 playTone 0) DOELSEIF ([10:33]) (set Rolladen01 off, set Rolladen01_Zustand up)(set gong_MP3 playTone 0,009,0)
attr Rolladen01_timer_test room Wohnzimmer
attr Rolladen01_timer_test wait 0,0,1,1,1:0,0,1,1,1:0,1,1,1:0,0
wenn ich es ändere in:
define Rolladen01_timer_test DOIF ([10:00]) (set Rolladen01 on)(set Rolladen01_Zustand down)(set gong_MP3 playTone 0)(set gong_MP3 playTone 008)(set gong_MP3 playTone 0) DOELSEIF ([10:01]) (set Rolladen01 on)(set Rolladen01_Zustand down)(set gong_MP3 playTone 0)(set gong_MP3 playTone 008)(set gong_MP3 playTone 0) DOELSEIF ([10:10]) (set Rolladen01 off, set Rolladen01_Zustand up)(set gong_MP3 playTone 0)(set gong_MP3 playTone 009)(set gong_MP3 playTone 0) DOELSEIF ([11:03]) (set Rolladen01 off, set Rolladen01_Zustand up)(set gong_MP3 playTone 0)(set gong_MP3 playTone 009)(set gong_MP3 playTone 0)
attr Rolladen01_timer_test room Wohnzimmer
attr Rolladen01_timer_test wait 0,0,1,1,1:0,0,1,1,1:0,1,1,1:0,0,2,4
funktioniert es.
Gruß
Micha
P.S. in den Logs tauch auch nichtzs zu set Rolladen01_Zustand up auf :-(
Du hast am Ende (set gong_MP3 playTone 0,009,0) stehen, dann musst du wie beim ersten DOIF wegen der Kommata, den set Befehl zusätzlich in Klammern packen ((set gong_MP3 playTone 0,009,0))
Gruß
Damian
Hallo Damian,
danke; wieder mal diese syntax :-(
Habe es jetzt mal in das reale Leben übertragen und bin gespannt was heute abend passiert ;-)
define Rolladen01_timer DOIF ([{sunset(-1200)}|8])((set gong_MP3 playTone 0,008,0))(set Rolladen01 on)(set Rolladen01_Zustand down) DOELSEIF ([{sunset(-2400)}|7])((set gong_MP3 playTone 0,008,0))(set Rolladen01 on)(set Rolladen01_Zustand down) DOELSEIF ([{sunrise(+2)}|8])((set gong_MP3 playTone 0,009,0))(set Rolladen01 off)(set Rolladen01_Zustand up) DOELSEIF ([{sunrise(+1200)}|7])((set gong_MP3 playTone 0,009,0))(set Rolladen01 off)(set Rolladen01_Zustand up)
attr Rolladen01_timer room Wohnzimmer
attr Rolladen01_timer wait 0,5,5:0,5,5:0,5,5:0,5,5
Gruß
Micha
ZitatDa die Eingabezeile für Attribute recht kurz ist, schlage ich vor hier ein Editorfenster zur übersichtlichen Eingabe zu nutzen, wie es z.B. für das Attribut cellStyle der readingsGroup geschieht. Wird das im Modul gesteuert?
Es wird mit dem Attribut widgetOverride gesteuert: http://fhem.de/commandref#widgetOverride (http://fhem.de/commandref#widgetOverride)
attr meindoif widgetOverride wait:textField-long
Hi Damian,
ich bekomme gerade bei meiner neuen Lichtsteuerung eine Fehlermeldung mit dem aktuellen Modul:
error
perl error in condition: DOIF_time($hash,$hash->{realtime}{0},$hash->{realtime}{1},$wday,$hms,"") andReadingValDoIf('twilightHome','twilight','') < 30 andInternalDoIf('SamsungTV','STATE','') eq "absent": syntax error at (eval 23616) line 1, near ") andReadingValDoIf"
2015-09-21 19:43:27
Folgende Definition:
define DI_kleineslicht DOIF ([17:00:00 - 23:30:00] and\
[twilightHome:twilight] < 30 and\
[SamsungTV] eq "absent")\
(set kleineslicht on;;set DominikPushbullet message Kleine Lampen eingeschalten.)\
DOELSEIF\
([SamsungTV] eq "present" or [23:00:01])\
(set kleineslicht off;;set DominikPushbullet message Kleine Lampen ausgeschalten.)
attr DI_kleineslicht room AutoZeitschaltuhr
Eine Idee was ich hier falsch mache?
Zitat von: dominik am 21 September 2015, 19:48:12
Hi Damian,
ich bekomme gerade bei meiner neuen Lichtsteuerung eine Fehlermeldung mit dem aktuellen Modul:
error
perl error in condition: DOIF_time($hash,$hash->{realtime}{0},$hash->{realtime}{1},$wday,$hms,"") andReadingValDoIf('twilightHome','twilight','') < 30 andInternalDoIf('SamsungTV','STATE','') eq "absent": syntax error at (eval 23616) line 1, near ") andReadingValDoIf"
2015-09-21 19:43:27
Folgende Definition:
define DI_kleineslicht DOIF ([17:00:00 - 23:30:00] and\
[twilightHome:twilight] < 30 and\
[SamsungTV] eq "absent")\
(set kleineslicht on;;set DominikPushbullet message Kleine Lampen eingeschalten.)\
DOELSEIF\
([SamsungTV] eq "present" or [23:00:01])\
(set kleineslicht off;;set DominikPushbullet message Kleine Lampen ausgeschalten.)
attr DI_kleineslicht room AutoZeitschaltuhr
Eine Idee was ich hier falsch mache?
Hinter and muss ein Leerzeichen, weil Zeilenende eliminiert wird und dann klebt and am nächsten Begriff. Das dürfte bei der alten Version nicht anders gewesen sein.
Gruß
Damian
:o mann o mann. Danke für deine schnelle Hilfe! :)
Funktioniert nun
@Damian
ist es möglich mit dem DOIF z.B. auf ein Datum abzufragen..?
Als Beispiel mal von mir ich möchte Kalender readings dazu nutzen eine Beleuchtung einzuschalten
Wobei er suchen soll einmal nach der Schichtart hier bei mir z.B nach Nachtschicht und Frühschicht und auch das Datum berücksichtigen soll, so das an den Tagen wo eben diese Schichtart nicht drin steht eben keine Beleuchtung angehen soll.
Dabei würde ja ich sage mal ein Status "Heute" reichen wenn er aus einem Datum Reading erkennt es ist heute Frühschicht oder Nachtschicht.
Ich habe schon ein wenig experimentiert wobei er dazu schon die Schichtart anzeigt aber eben nur weil er sie gefunden hat in den Readings...
Ich habe hier erst mal nur 3 Termine drin, denn es könnten ja in der Zahl von "maxreadings" eine ganze Menge mehr sein, ich habe hier 20 eingestellt
Das Datum würde ich als reading bekommen von Calview, da wären das BeginnDatum (t_001_bdate) und das EndDatum (t_001_edate) und dann die Schicht Art als (t_001_summary)... hier weiß ich leider nicht wie ich das Datum abfragen soll/könnte :-\
hier mal das list, wobei ich habe hier kein Set Befehl drin, weil ich eigentlich nur den Status brauche und mit einem anderen DOIF dann die Beleuchtung schalte...
Evtl. kann ich die beiden DOIFs zusammen legen wenn das möglich ist was ich mir denke
Internals:
CFGFN ./FHEM/Kalender.cfg
DEF ([04:55-07:00] and [View_S:t_001_summary] eq "Frühschicht")
DOELSEIF ([04:55-07:00] and [View_S:t_002_summary] eq "Frühschicht")
DOELSEIF ([04:55-07:00] and [View_S:t_003_summary] eq "Frühschicht")
NAME di_WegBeleuchtung_Calender
NR 2958
NTFY_ORDER 50-di_WegBeleuchtung_Calender
STATE initialized
TYPE DOIF
Readings:
2015-09-22 18:05:26 state initialized
2015-09-22 18:05:26 timer_1_c1 23.09.2015 04:55:00
2015-09-22 18:05:26 timer_2_c1 23.09.2015 07:00:00
2015-09-22 18:05:26 timer_3_c2 23.09.2015 04:55:00
2015-09-22 18:05:26 timer_4_c2 23.09.2015 07:00:00
2015-09-22 18:05:26 timer_5_c3 23.09.2015 04:55:00
2015-09-22 18:05:26 timer_6_c3 23.09.2015 07:00:00
Condition:
0 DOIF_time($hash,$hash->{realtime}{0},$hash->{realtime}{1},$wday,$hms,"") and ReadingValDoIf('View_S','t_002_summary','') eq "Frühschicht"
1 DOIF_time($hash,$hash->{realtime}{2},$hash->{realtime}{3},$wday,$hms,"") and ReadingValDoIf('View_S','t_002_summary','') eq "Frühschicht"
2 DOIF_time($hash,$hash->{realtime}{4},$hash->{realtime}{5},$wday,$hms,"") and ReadingValDoIf('View_S','t_003_summary','') eq "Frühschicht"
Days:
Devices:
0 View_S
1 View_S
2 View_S
all View_S
Do:
0:
0
1:
0
2:
0
Helper:
globalinit 1
last_timer 6
sleeptimer -1
Itimer:
Readings:
0 View_S:t_002_summary
1 View_S:t_002_summary
2 View_S:t_003_summary
all View_S:t_002_summary View_S:t_003_summary
Realtime:
0 04:55:00
1 07:00:00
2 04:55:00
3 07:00:00
4 04:55:00
5 07:00:00
State:
Time:
0 04:55:00
1 07:00:00
2 04:55:00
3 07:00:00
4 04:55:00
5 07:00:00
Timecond:
0 0
1 0
2 1
3 1
4 2
5 2
Timer:
0 0
1 0
2 0
3 0
4 0
5 0
Timerfunc:
Timers:
0 0 1
1 2 3
2 4 5
Attributes:
cmdState Nachtschicht|Frühschicht
room Kalender
Ich komme schon wieder mit einer Anfrage an Euch. Und zwar habe ich von Euch den Tipp bekommen, dass ich meine Beschattungssteuerung, welche ich mit dem DOIF und dem Wert eines Lux Sensors betreibe, mit einem DOELSE (soll) abschliessen soll. Siehe dazu Post #180
ZitatZitat von: Mumpitz am 14 September 2015, 12:21:07
Aus meiner Sicht braucht ich das nicht. Wenn der Sensorwert unterboten oder der azimuth wert größer ist wird ja cmd_2 oder 3 ausgelöst!
Da der Sensorwert in den beiden anderen Bedingungen gar nicht abgefragt wird, können diese auch nicht reagieren, wenn er unterboten wird.
Die eigentlich entscheidende Stelle der Commandref ist vielleicht diese:
Zitat von: Commandref
Eine bereits ausgelöste Verzögerung wird zurückgesetzt, wenn während der Wartezeit ein Kommando eines anderen DO-Falls, ausgelöst durch ein neues Ereignis, ausgeführt werden soll.
Und zwar nur dann!
wait bedeutet also nicht, dass eine Aktion A ausgeführt wird, wenn die Bedingung A für die bei wait spezifizierte Zeit Bestand hat.
wait bedeutet: Wenn irgendwann mal Bedingung A galt und seitdem keine andere Bedingung desselben DOIF wahr geworden ist, wird nach Ablauf der in wait spezifierten Zeit Aktion A ausgeführt, egal ob Bedingung A zu diesem Zeitpunkt immer noch wahr ist oder nicht.
Man kann sich darüber streitet ob das nun ein Feature oder ein Fehler ist (DOIF vs. DOEVENIFNOTANYMORE). Aber so ist es nunmal und man muss sein DOIF ggf. um diese Eigenart herumprogrammieren. Wie hier ja schon geschrieben wurde, ist ein "leeres" DOELSE der bevorzugte Workaround.
Nun, ich habe das gemacht und grundsätzlich funktioniert das wait nun. Allerdings wird das wait wenige Sekunden nach starten des Wait Timers wieder zurück gestellt..
Folgendes DOIF:
Internals:
DEF ([Auto_Beschattung] eq "on" and [Beschattung_OG] eq "off" and [Helligkeit_Twilight:azimuth] > 109 and [Helligkeit_Twilight:azimuth] < 270 and ([Multisensor_Ost:state] > 25000 or [Sensor_Licht_Sued:state] > 19000)) (set Beschattung_OG on)
DOELSEIF ([Auto_Beschattung] eq "on" and [Beschattung_OG] eq "on" and [Helligkeit_Twilight:azimuth] > 109 and [Helligkeit_Twilight:azimuth] < 270 and [Sensor_Licht_Sued:state] < 9000) (set Beschattung_OG off)
DOELSEIF ([Auto_Beschattung] eq "on" and [Beschattung_OG] eq "on" and ([Helligkeit_Twilight:azimuth] > 277 or [Helligkeit_Twilight:compasspoint] eq "west" or [18:45])) (set Beschattung_OG off)
DOELSE ()
NAME di_SoSchu_OG
NR 119
NTFY_ORDER 50-di_SoSchu_OG
STATE cmd_4
TYPE DOIF
Readings:
2015-09-22 19:48:00 Device Multisensor_Ost
2015-09-22 18:45:46 cmd_event Multisensor_Ost
2015-09-22 18:45:46 cmd_nr 4
2015-09-22 11:47:03 e_Auto_Beschattung_STATE on
2015-09-22 18:45:00 e_Beschattung_OG_STATE off
2015-09-22 19:45:25 e_Helligkeit_Twilight_azimuth 275.15
2015-09-22 19:45:25 e_Helligkeit_Twilight_compasspoint west
2015-09-22 19:48:00 e_Multisensor_Ost_state 2
2015-09-22 17:48:15 e_Sensor_Licht_Sued_state 383
2015-09-22 18:45:46 state cmd_4
2015-09-22 18:45:00 timer_1_c3 23.09.2015 18:45:00
2015-09-22 18:45:00 wait_timer no timer
Condition:
0 InternalDoIf('Auto_Beschattung','STATE','') eq "on" and InternalDoIf('Beschattung_OG','STATE','') eq "off" and ReadingValDoIf('Helligkeit_Twilight','azimuth','') > 109 and ReadingValDoIf('Helligkeit_Twilight','azimuth','') < 270 and (ReadingValDoIf('Multisensor_Ost','state','') > 25000 or ReadingValDoIf('Sensor_Licht_Sued','state','') > 19000)
1 InternalDoIf('Auto_Beschattung','STATE','') eq "on" and InternalDoIf('Beschattung_OG','STATE','') eq "on" and ReadingValDoIf('Helligkeit_Twilight','azimuth','') > 109 and ReadingValDoIf('Helligkeit_Twilight','azimuth','') < 270 and ReadingValDoIf('Sensor_Licht_Sued','state','') < 9000
2 InternalDoIf('Auto_Beschattung','STATE','') eq "on" and InternalDoIf('Beschattung_OG','STATE','') eq "on" and (ReadingValDoIf('Helligkeit_Twilight','azimuth','') > 277 or ReadingValDoIf('Helligkeit_Twilight','compasspoint','') eq "west" or DOIF_time_once($hash,$hash->{timer}{0},$wday,""))
Days:
Devices:
0 Auto_Beschattung Beschattung_OG Helligkeit_Twilight Multisensor_Ost Sensor_Licht_Sued
1 Auto_Beschattung Beschattung_OG Helligkeit_Twilight Sensor_Licht_Sued
2 Auto_Beschattung Beschattung_OG Helligkeit_Twilight
all Auto_Beschattung Beschattung_OG Helligkeit_Twilight Multisensor_Ost Sensor_Licht_Sued
Do:
0:
0 set Beschattung_OG on
1:
0 set Beschattung_OG off
2:
0 set Beschattung_OG off
3:
0
Helper:
globalinit 1
last_timer 1
sleepdevice Helligkeit_Twilight
sleepsubtimer 0
sleeptimer -1
Internals:
0 Auto_Beschattung:STATE Beschattung_OG:STATE
1 Auto_Beschattung:STATE Beschattung_OG:STATE
2 Auto_Beschattung:STATE Beschattung_OG:STATE
all Auto_Beschattung:STATE Beschattung_OG:STATE
Itimer:
Readings:
0 Helligkeit_Twilight:azimuth Multisensor_Ost:state Sensor_Licht_Sued:state
1 Helligkeit_Twilight:azimuth Sensor_Licht_Sued:state
2 Helligkeit_Twilight:azimuth Helligkeit_Twilight:compasspoint
all Helligkeit_Twilight:azimuth Multisensor_Ost:state Sensor_Licht_Sued:state Helligkeit_Twilight:compasspoint
Realtime:
0 18:45:00
State:
Time:
0 18:45:00
Timecond:
0 2
Timer:
0 0
Timerfunc:
Timers:
2 0
Trigger:
Attributes:
wait 900:2400 ergibt folgende Einträge wenn ich das DOIF logge:
2015-09-22_18:45:00 Beschattung_OG off
2015-09-22_18:45:00 di_SoSchu_OG wait_timer: no timer
2015-09-22_18:44:49 di_SoSchu_OG wait_timer: 22.09.2015 19:24:49 cmd_2 Helligkeit_Twilight
2015-09-22_18:41:46 di_SoSchu_OG wait_timer: no timer
2015-09-22_18:41:40 di_SoSchu_OG wait_timer: 22.09.2015 19:21:40 cmd_2 Helligkeit_Twilight
2015-09-22_18:39:46 di_SoSchu_OG wait_timer: no timer
2015-09-22_18:39:46 di_SoSchu_OG wait_timer: 22.09.2015 19:19:46 cmd_2 Helligkeit_Twilight
2015-09-22_18:35:46 di_SoSchu_OG wait_timer: no timer
2015-09-22_18:35:46 di_SoSchu_EG cmd_4
2015-09-22_18:35:46 di_SoSchu_EG cmd_event: Multisensor_Ost
2015-09-22_18:35:46 di_SoSchu_EG cmd_nr: 4
2015-09-22_18:34:43 di_SoSchu_OG wait_timer: 22.09.2015 19:14:43 cmd_2 Helligkeit_Twilight
2015-09-22_18:34:43 di_SoSchu_EG cmd_2
2015-09-22_18:34:43 di_SoSchu_EG cmd_event: Helligkeit_Twilight
2015-09-22_18:34:43 di_SoSchu_EG cmd_nr: 2
2015-09-22_18:34:43 Beschattung_EG off
2015-09-22_18:29:46 di_SoSchu_OG wait_timer: no timer
2015-09-22_18:29:40 di_SoSchu_OG wait_timer: 22.09.2015 19:09:40 cmd_2 Helligkeit_Twilight
2015-09-22_18:25:46 di_SoSchu_OG wait_timer: no timer
2015-09-22_18:24:37 di_SoSchu_OG wait_timer: 22.09.2015 19:04:37 cmd_2 Helligkeit_Twilight
2015-09-22_18:19:46 di_SoSchu_OG wait_timer: no timer
2015-09-22_18:19:34 di_SoSchu_OG wait_timer: 22.09.2015 18:59:34 cmd_2 Helligkeit_Twilight
2015-09-22_18:17:46 di_SoSchu_OG wait_timer: no timer
2015-09-22_18:17:45 di_SoSchu_OG wait_timer: 22.09.2015 18:57:45 cmd_2 Helligkeit_Twilight
2015-09-22_18:15:46 di_SoSchu_OG wait_timer: no timer
2015-09-22_18:14:31 di_SoSchu_OG wait_timer: 22.09.2015 18:54:31 cmd_2 Helligkeit_Twilight
2015-09-22_18:09:46 di_SoSchu_OG wait_timer: no timer
2015-09-22_18:09:28 di_SoSchu_OG wait_timer: 22.09.2015 18:49:28 cmd_2 Helligkeit_Twilight
2015-09-22_18:05:46 di_SoSchu_OG wait_timer: no timer
2015-09-22_18:04:25 di_SoSchu_OG wait_timer: 22.09.2015 18:44:25 cmd_2 Helligkeit_Twilight
2015-09-22_18:01:46 di_SoSchu_OG wait_timer: no timer
2015-09-22_17:59:22 di_SoSchu_OG wait_timer: 22.09.2015 18:39:22 cmd_2 Helligkeit_Twilight
2015-09-22_17:55:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_17:54:19 di_SoSchu_OG wait_timer: 22.09.2015 18:34:19 cmd_2 Helligkeit_Twilight
2015-09-22_17:49:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_17:49:16 di_SoSchu_EG wait_timer: no timer
2015-09-22_17:48:15 di_SoSchu_OG wait_timer: 22.09.2015 18:28:15 cmd_2 Sensor_Licht_Sued
2015-09-22_17:48:15 di_SoSchu_EG wait_timer: 22.09.2015 18:28:15 cmd_3 Sensor_Licht_Sued
2015-09-22_17:45:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_17:44:13 di_SoSchu_OG wait_timer: 22.09.2015 18:24:13 cmd_2 Helligkeit_Twilight
2015-09-22_17:43:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_17:41:40 di_SoSchu_OG wait_timer: 22.09.2015 18:21:40 cmd_2 Helligkeit_Twilight
2015-09-22_17:41:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_17:41:37 di_SoSchu_EG wait_timer: no timer
2015-09-22_17:40:15 di_SoSchu_OG wait_timer: 22.09.2015 18:20:15 cmd_2 Sensor_Licht_Sued
2015-09-22_17:40:15 di_SoSchu_EG wait_timer: 22.09.2015 18:20:15 cmd_3 Sensor_Licht_Sued
2015-09-22_17:39:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_17:39:10 di_SoSchu_OG wait_timer: 22.09.2015 18:19:10 cmd_2 Helligkeit_Twilight
2015-09-22_17:35:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_17:34:07 di_SoSchu_OG wait_timer: 22.09.2015 18:14:07 cmd_2 Helligkeit_Twilight
2015-09-22_17:33:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_17:33:37 di_SoSchu_EG wait_timer: no timer
2015-09-22_17:32:15 di_SoSchu_OG wait_timer: 22.09.2015 18:12:15 cmd_2 Sensor_Licht_Sued
2015-09-22_17:32:15 di_SoSchu_EG wait_timer: 22.09.2015 18:12:15 cmd_3 Sensor_Licht_Sued
2015-09-22_17:29:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_17:29:04 di_SoSchu_OG wait_timer: 22.09.2015 18:09:04 cmd_2 Helligkeit_Twilight
2015-09-22_17:27:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_17:27:22 di_SoSchu_OG wait_timer: 22.09.2015 18:07:22 cmd_2 Helligkeit_Twilight
2015-09-22_17:25:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_17:24:01 di_SoSchu_OG wait_timer: 22.09.2015 18:04:01 cmd_2 Helligkeit_Twilight
2015-09-22_17:19:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_17:18:58 di_SoSchu_OG wait_timer: 22.09.2015 17:58:58 cmd_2 Helligkeit_Twilight
2015-09-22_17:17:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_17:17:37 di_SoSchu_EG wait_timer: no timer
2015-09-22_17:16:15 di_SoSchu_OG wait_timer: 22.09.2015 17:56:15 cmd_2 Sensor_Licht_Sued
2015-09-22_17:16:15 di_SoSchu_EG wait_timer: 22.09.2015 17:56:15 cmd_3 Sensor_Licht_Sued
2015-09-22_17:15:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_17:15:37 di_SoSchu_EG wait_timer: no timer
2015-09-22_17:14:15 di_SoSchu_EG wait_timer: 22.09.2015 17:54:15 cmd_3 Sensor_Licht_Sued
2015-09-22_17:13:55 di_SoSchu_OG wait_timer: 22.09.2015 17:53:55 cmd_2 Helligkeit_Twilight
2015-09-22_17:11:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_17:11:37 di_SoSchu_EG wait_timer: no timer
2015-09-22_17:10:15 di_SoSchu_OG wait_timer: 22.09.2015 17:50:15 cmd_2 Sensor_Licht_Sued
2015-09-22_17:10:15 di_SoSchu_EG wait_timer: 22.09.2015 17:50:15 cmd_3 Sensor_Licht_Sued
2015-09-22_17:09:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_17:08:52 di_SoSchu_OG wait_timer: 22.09.2015 17:48:52 cmd_2 Helligkeit_Twilight
2015-09-22_17:05:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_17:03:49 di_SoSchu_OG wait_timer: 22.09.2015 17:43:49 cmd_2 Helligkeit_Twilight
2015-09-22_16:59:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_16:58:46 di_SoSchu_OG wait_timer: 22.09.2015 17:38:46 cmd_2 Helligkeit_Twilight
2015-09-22_16:55:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_16:53:43 di_SoSchu_OG wait_timer: 22.09.2015 17:33:43 cmd_2 Helligkeit_Twilight
2015-09-22_16:49:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_16:48:40 di_SoSchu_EG wait_timer: no timer
2015-09-22_16:48:15 di_SoSchu_OG wait_timer: 22.09.2015 17:28:15 cmd_2 Sensor_Licht_Sued
2015-09-22_16:48:15 di_SoSchu_EG wait_timer: 22.09.2015 17:28:15 cmd_3 Sensor_Licht_Sued
2015-09-22_16:47:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_16:47:37 di_SoSchu_EG wait_timer: no timer
2015-09-22_16:46:15 di_SoSchu_OG wait_timer: 22.09.2015 17:26:15 cmd_2 Sensor_Licht_Sued
2015-09-22_16:46:15 di_SoSchu_EG wait_timer: 22.09.2015 17:26:15 cmd_3 Sensor_Licht_Sued
2015-09-22_16:43:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_16:43:37 di_SoSchu_OG wait_timer: 22.09.2015 17:23:37 cmd_2 Helligkeit_Twilight
2015-09-22_16:39:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_16:38:34 di_SoSchu_OG wait_timer: 22.09.2015 17:18:34 cmd_2 Helligkeit_Twilight
2015-09-22_16:33:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_16:33:31 di_SoSchu_OG wait_timer: 22.09.2015 17:13:31 cmd_2 Helligkeit_Twilight
2015-09-22_16:29:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_16:28:28 di_SoSchu_OG wait_timer: 22.09.2015 17:08:28 cmd_2 Helligkeit_Twilight
2015-09-22_16:23:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_16:23:25 di_SoSchu_EG wait_timer: no timer
2015-09-22_16:22:16 di_SoSchu_OG wait_timer: 22.09.2015 17:02:16 cmd_2 Sensor_Licht_Sued
2015-09-22_16:22:16 di_SoSchu_EG wait_timer: 22.09.2015 17:02:15 cmd_3 Sensor_Licht_Sued
2015-09-22_16:19:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_16:18:22 di_SoSchu_EG wait_timer: no timer
2015-09-22_16:18:15 di_SoSchu_OG wait_timer: 22.09.2015 16:58:15 cmd_2 Sensor_Licht_Sued
2015-09-22_16:18:15 di_SoSchu_EG wait_timer: 22.09.2015 16:58:15 cmd_3 Sensor_Licht_Sued
2015-09-22_16:15:37 di_SoSchu_OG wait_timer: no timer
2015-09-22_16:15:37 di_SoSchu_EG wait_timer: no timer
2015-09-22_16:14:15 di_SoSchu_OG wait_timer: 22.09.2015 16:54:15 cmd_2 Sensor_Licht_Sued
2015-09-22_16:14:15 di_SoSchu_EG wait_timer: 22.09.2015 16:54:15 cmd_3 Sensor_Licht_Sued
2015-09-22_16:13:38 di_SoSchu_OG wait_timer: no timer
2015-09-22_16:13:19 di_SoSchu_EG wait_timer: no timer
2015-09-22_16:12:16 di_SoSchu_OG wait_timer: 22.09.2015 16:52:16 cmd_2 Sensor_Licht_Sued
2015-09-22_16:12:16 di_SoSchu_EG wait_timer: 22.09.2015 16:52:16 cmd_3 Sensor_Licht_Sued
2015-09-22_16:09:30 di_SoSchu_OG wait_timer: no timer
2015-09-22_16:08:16 di_SoSchu_OG wait_timer: 22.09.2015 16:48:16 cmd_2 Helligkeit_Twilight
2015-09-22_16:07:30 di_SoSchu_OG wait_timer: no timer
2015-09-22_16:07:30 di_SoSchu_EG wait_timer: no timer
2015-09-22_16:06:16 di_SoSchu_OG wait_timer: 22.09.2015 16:46:16 cmd_2 Sensor_Licht_Sued
2015-09-22_16:06:16 di_SoSchu_EG wait_timer: 22.09.2015 16:46:16 cmd_3 Sensor_Licht_Sued
2015-09-22_16:03:23 di_SoSchu_OG wait_timer: no timer
2015-09-22_16:03:13 di_SoSchu_OG wait_timer: 22.09.2015 16:43:13 cmd_2 Helligkeit_Twilight
2015-09-22_15:59:23 di_SoSchu_OG wait_timer: no timer
2015-09-22_15:58:10 di_SoSchu_OG wait_timer: 22.09.2015 16:38:10 cmd_2 Helligkeit_Twilight
2015-09-22_15:53:14 di_SoSchu_OG wait_timer: no timer
2015-09-22_15:53:07 di_SoSchu_OG wait_timer: 22.09.2015 16:33:07 cmd_2 Helligkeit_Twilight
2015-09-22_15:49:14 di_SoSchu_OG wait_timer: no timer
2015-09-22_15:48:04 di_SoSchu_OG wait_timer: 22.09.2015 16:28:04 cmd_2 Helligkeit_Twilight
2015-09-22_15:45:14 di_SoSchu_OG wait_timer: no timer
2015-09-22_15:45:14 di_SoSchu_EG wait_timer: no timer
2015-09-22_15:44:16 di_SoSchu_OG wait_timer: 22.09.2015 16:24:16 cmd_2 Sensor_Licht_Sued
2015-09-22_15:44:16 di_SoSchu_EG wait_timer: 22.09.2015 16:24:16 cmd_3 Sensor_Licht_Sued
2015-09-22_15:43:14 di_SoSchu_OG wait_timer: no timer
2015-09-22_15:43:01 di_SoSchu_OG wait_timer: 22.09.2015 16:23:01 cmd_2 Helligkeit_Twilight
2015-09-22_15:39:15 di_SoSchu_OG wait_timer: no timer
2015-09-22_15:37:58 di_SoSchu_OG wait_timer: 22.09.2015 16:17:58 cmd_2 Helligkeit_Twilight
2015-09-22_15:35:04 di_SoSchu_OG wait_timer: no timer
2015-09-22_15:35:04 di_SoSchu_EG wait_timer: no timer
2015-09-22_15:34:15 di_SoSchu_OG wait_timer: 22.09.2015 16:14:15 cmd_2 Sensor_Licht_Sued
2015-09-22_15:34:15 di_SoSchu_EG wait_timer: 22.09.2015 16:14:15 cmd_3 Sensor_Licht_Sued
2015-09-22_15:33:04 di_SoSchu_OG wait_timer: no timer
2015-09-22_15:32:55 di_SoSchu_EG wait_timer: no timer
2015-09-22_15:32:15 di_SoSchu_OG wait_timer: 22.09.2015 16:12:15 cmd_2 Sensor_Licht_Sued
2015-09-22_15:32:15 di_SoSchu_EG wait_timer: 22.09.2015 16:12:15 cmd_3 Sensor_Licht_Sued
2015-09-22_15:29:04 di_SoSchu_OG wait_timer: no timer
2015-09-22_15:29:04 di_SoSchu_EG wait_timer: no timer
2015-09-22_15:28:16 di_SoSchu_EG wait_timer: 22.09.2015 16:08:16 cmd_3 Sensor_Licht_Sued
2015-09-22_15:27:52 di_SoSchu_OG wait_timer: 22.09.2015 16:07:52 cmd_2 Helligkeit_Twilight
2015-09-22_15:25:04 di_SoSchu_OG wait_timer: no timer
2015-09-22_15:25:04 di_SoSchu_EG wait_timer: no timer
2015-09-22_15:24:15 di_SoSchu_OG wait_timer: 22.09.2015 16:04:15 cmd_2 Sensor_Licht_Sued
2015-09-22_15:24:15 di_SoSchu_EG wait_timer: 22.09.2015 16:04:15 cmd_3 Sensor_Licht_Sued
2015-09-22_15:23:04 di_SoSchu_OG wait_timer: no timer
2015-09-22_15:22:49 di_SoSchu_EG wait_timer: no timer
2015-09-22_15:22:16 di_SoSchu_OG wait_timer: 22.09.2015 16:02:16 cmd_2 Sensor_Licht_Sued
2015-09-22_15:22:16 di_SoSchu_EG wait_timer: 22.09.2015 16:02:16 cmd_3 Sensor_Licht_Sued
2015-09-22_15:18:56 di_SoSchu_OG wait_timer: no timer
2015-09-22_15:17:46 di_SoSchu_OG wait_timer: 22.09.2015 15:57:46 cmd_2 Helligkeit_Twilight
2015-09-22_15:14:56 di_SoSchu_OG wait_timer: no timer
2015-09-22_15:14:56 di_SoSchu_EG wait_timer: no timer
2015-09-22_15:14:15 di_SoSchu_OG wait_timer: 22.09.2015 15:54:15 cmd_2 Sensor_Licht_Sued
2015-09-22_15:14:15 di_SoSchu_EG wait_timer: 22.09.2015 15:54:15 cmd_3 Sensor_Licht_Sued
2015-09-22_15:12:56 di_SoSchu_OG wait_timer: no timer
2015-09-22_15:12:43 di_SoSchu_EG wait_timer: no timer
2015-09-22_15:12:16 di_SoSchu_OG wait_timer: 22.09.2015 15:52:16 cmd_2 Sensor_Licht_Sued
2015-09-22_15:12:16 di_SoSchu_EG wait_timer: 22.09.2015 15:52:16 cmd_3 Sensor_Licht_Sued
2015-09-22_15:10:56 di_SoSchu_OG wait_timer: no timer
2015-09-22_15:10:56 di_SoSchu_EG wait_timer: no timer
2015-09-22_15:10:15 di_SoSchu_OG wait_timer: 22.09.2015 15:50:15 cmd_2 Sensor_Licht_Sued
2015-09-22_15:10:15 di_SoSchu_EG wait_timer: 22.09.2015 15:50:15 cmd_3 Sensor_Licht_Sued
2015-09-22_15:08:56 di_SoSchu_OG wait_timer: no timer
2015-09-22_15:07:40 di_SoSchu_OG wait_timer: 22.09.2015 15:47:40 cmd_2 Helligkeit_Twilight
2015-09-22_15:06:56 di_SoSchu_OG wait_timer: no timer
2015-09-22_15:06:56 di_SoSchu_EG wait_timer: no timer
2015-09-22_15:06:15 di_SoSchu_OG wait_timer: 22.09.2015 15:46:15 cmd_2 Sensor_Licht_Sued
2015-09-22_15:06:15 di_SoSchu_EG wait_timer: 22.09.2015 15:46:15 cmd_3 Sensor_Licht_Sued
2015-09-22_15:02:56 di_SoSchu_OG wait_timer: no timer
2015-09-22_15:02:37 di_SoSchu_OG wait_timer: 22.09.2015 15:42:37 cmd_2 Helligkeit_Twilight
2015-09-22_14:58:56 di_SoSchu_OG wait_timer: no timer
2015-09-22_14:57:34 di_SoSchu_OG wait_timer: 22.09.2015 15:37:34 cmd_2 Helligkeit_Twilight
2015-09-22_14:52:56 di_SoSchu_OG wait_timer: no timer
2015-09-22_14:52:31 di_SoSchu_OG wait_timer: 22.09.2015 15:32:31 cmd_2 Helligkeit_Twilight
2015-09-22_14:48:56 di_SoSchu_OG wait_timer: no timer
2015-09-22_14:47:28 di_SoSchu_OG wait_timer: 22.09.2015 15:27:28 cmd_2 Helligkeit_Twilight
2015-09-22_14:42:56 di_SoSchu_OG wait_timer: no timer
2015-09-22_14:42:25 di_SoSchu_OG wait_timer: 22.09.2015 15:22:25 cmd_2 Helligkeit_Twilight
2015-09-22_14:38:56 di_SoSchu_OG wait_timer: no timer
2015-09-22_14:37:22 di_SoSchu_OG wait_timer: 22.09.2015 15:17:22 cmd_2 Helligkeit_Twilight
2015-09-22_14:32:56 di_SoSchu_OG wait_timer: no timer
2015-09-22_14:32:19 di_SoSchu_OG wait_timer: 22.09.2015 15:12:19 cmd_2 Helligkeit_Twilight
2015-09-22_14:28:48 di_SoSchu_OG wait_timer: no timer
2015-09-22_14:27:16 di_SoSchu_OG wait_timer: 22.09.2015 15:07:16 cmd_2 Helligkeit_Twilight
2015-09-22_14:22:48 di_SoSchu_OG wait_timer: no timer
2015-09-22_14:22:13 di_SoSchu_OG wait_timer: 22.09.2015 15:02:13 cmd_2 Helligkeit_Twilight
2015-09-22_14:20:48 di_SoSchu_OG wait_timer: no timer
2015-09-22_14:20:48 di_SoSchu_EG wait_timer: no timer
2015-09-22_14:20:15 di_SoSchu_OG wait_timer: 22.09.2015 15:00:15 cmd_2 Sensor_Licht_Sued
2015-09-22_14:20:15 di_SoSchu_EG wait_timer: 22.09.2015 15:00:15 cmd_3 Sensor_Licht_Sued
2015-09-22_14:18:48 di_SoSchu_OG wait_timer: no timer
2015-09-22_14:17:10 di_SoSchu_OG wait_timer: 22.09.2015 14:57:10 cmd_2 Helligkeit_Twilight
2015-09-22_14:12:48 di_SoSchu_OG wait_timer: no timer
2015-09-22_14:12:48 di_SoSchu_EG wait_timer: no timer
2015-09-22_14:12:15 di_SoSchu_EG wait_timer: 22.09.2015 14:52:15 cmd_3 Sensor_Licht_Sued
2015-09-22_14:12:07 di_SoSchu_OG wait_timer: 22.09.2015 14:52:07 cmd_2 Helligkeit_Twilight
2015-09-22_14:10:48 di_SoSchu_OG wait_timer: no timer
2015-09-22_14:10:48 di_SoSchu_EG wait_timer: no timer
2015-09-22_14:10:16 di_SoSchu_OG wait_timer: 22.09.2015 14:50:16 cmd_2 Sensor_Licht_Sued
2015-09-22_14:10:16 di_SoSchu_EG wait_timer: 22.09.2015 14:50:16 cmd_3 Sensor_Licht_Sued
2015-09-22_14:08:48 di_SoSchu_OG wait_timer: no timer
2015-09-22_14:07:04 di_SoSchu_OG wait_timer: 22.09.2015 14:47:04 cmd_2 Helligkeit_Twilight
2015-09-22_14:02:48 di_SoSchu_OG wait_timer: no timer
2015-09-22_14:02:48 di_SoSchu_EG wait_timer: no timer
2015-09-22_14:02:15 di_SoSchu_EG wait_timer: 22.09.2015 14:42:15 cmd_3 Sensor_Licht_Sued
2015-09-22_14:02:01 di_SoSchu_OG wait_timer: 22.09.2015 14:42:01 cmd_2 Helligkeit_Twilight
2015-09-22_14:00:48 di_SoSchu_OG wait_timer: no timer
2015-09-22_14:00:48 di_SoSchu_EG wait_timer: no timer
2015-09-22_14:00:16 di_SoSchu_OG wait_timer: 22.09.2015 14:40:16 cmd_2 Sensor_Licht_Sued
2015-09-22_14:00:16 di_SoSchu_EG wait_timer: 22.09.2015 14:40:16 cmd_3 Sensor_Licht_Sued
2015-09-22_13:48:48 di_SoSchu_OG wait_timer: no timer
2015-09-22_13:46:52 di_SoSchu_OG wait_timer: 22.09.2015 14:26:52 cmd_2 Helligkeit_Twilight
2015-09-22_13:46:48 di_SoSchu_OG wait_timer: no timer
2015-09-22_13:46:48 di_SoSchu_EG wait_timer: no timer
2015-09-22_13:46:15 di_SoSchu_OG wait_timer: 22.09.2015 14:26:15 cmd_2 Sensor_Licht_Sued
2015-09-22_13:46:15 di_SoSchu_EG wait_timer: 22.09.2015 14:26:15 cmd_3 Sensor_Licht_Sued
2015-09-22_13:42:34 di_SoSchu_OG wait_timer: no timer
2015-09-22_13:42:34 di_SoSchu_EG wait_timer: no timer
2015-09-22_13:42:16 di_SoSchu_EG wait_timer: 22.09.2015 14:22:16 cmd_3 Sensor_Licht_Sued
2015-09-22_13:41:49 di_SoSchu_OG wait_timer: 22.09.2015 14:21:49 cmd_2 Helligkeit_Twilight
2015-09-22_13:40:34 di_SoSchu_OG wait_timer: no timer
2015-09-22_13:40:34 di_SoSchu_EG wait_timer: no timer
2015-09-22_13:40:17 di_SoSchu_OG wait_timer: 22.09.2015 14:20:17 cmd_2 Sensor_Licht_Sued
2015-09-22_13:40:17 di_SoSchu_EG wait_timer: 22.09.2015 14:20:17 cmd_3 Sensor_Licht_Sued
2015-09-22_13:38:34 di_SoSchu_OG wait_timer: no timer
2015-09-22_13:38:34 di_SoSchu_EG wait_timer: no timer
2015-09-22_13:38:15 di_SoSchu_EG wait_timer: 22.09.2015 14:18:15 cmd_3 Sensor_Licht_Sued
2015-09-22_13:36:45 di_SoSchu_OG wait_timer: 22.09.2015 14:16:45 cmd_2 Helligkeit_Twilight
2015-09-22_13:36:34 di_SoSchu_OG wait_timer: no timer
2015-09-22_13:36:34 di_SoSchu_EG wait_timer: no timer
2015-09-22_13:36:16 di_SoSchu_OG wait_timer: 22.09.2015 14:16:16 cmd_2 Sensor_Licht_Sued
2015-09-22_13:36:16 di_SoSchu_EG wait_timer: 22.09.2015 14:16:16 cmd_3 Sensor_Licht_Sued
2015-09-22_13:34:34 di_SoSchu_OG wait_timer: no timer
2015-09-22_13:34:34 di_SoSchu_EG wait_timer: no timer
2015-09-22_13:34:16 di_SoSchu_OG wait_timer: 22.09.2015 14:14:16 cmd_2 Sensor_Licht_Sued
2015-09-22_13:34:16 di_SoSchu_EG wait_timer: 22.09.2015 14:14:16 cmd_3 Sensor_Licht_Sued
2015-09-22_13:32:34 di_SoSchu_OG wait_timer: no timer
2015-09-22_13:32:34 di_SoSchu_EG wait_timer: no timer
2015-09-22_13:32:15 di_SoSchu_EG wait_timer: 22.09.2015 14:12:15 cmd_3 Sensor_Licht_Sued
2015-09-22_13:31:42 di_SoSchu_OG wait_timer: 22.09.2015 14:11:42 cmd_2 Helligkeit_Twilight
2015-09-22_13:30:34 di_SoSchu_OG wait_timer: no timer
2015-09-22_13:30:34 di_SoSchu_EG wait_timer: no timer
2015-09-22_13:30:15 di_SoSchu_OG wait_timer: 22.09.2015 14:10:15 cmd_2 Sensor_Licht_Sued
2015-09-22_13:30:15 di_SoSchu_EG wait_timer: 22.09.2015 14:10:15 cmd_3 Sensor_Licht_Sued
2015-09-22_13:28:34 di_SoSchu_OG wait_timer: no timer
2015-09-22_13:28:34 di_SoSchu_EG wait_timer: no timer
2015-09-22_13:28:15 di_SoSchu_OG wait_timer: 22.09.2015 14:08:15 cmd_2 Sensor_Licht_Sued
2015-09-22_13:28:15 di_SoSchu_EG wait_timer: 22.09.2015 14:08:15 cmd_3 Sensor_Licht_Sued
2015-09-22_12:54:16 di_SoSchu_OG cmd_4
2015-09-22_12:54:16 di_SoSchu_OG cmd_event: Sensor_Licht_Sued
2015-09-22_12:54:16 di_SoSchu_OG cmd_nr: 4
2015-09-22_12:54:16 di_SoSchu_EG cmd_4
2015-09-22_12:54:16 di_SoSchu_EG cmd_event: Sensor_Licht_Sued
2015-09-22_12:54:16 di_SoSchu_EG cmd_nr: 4
2015-09-22_12:53:17 di_SoSchu_OG cmd_1
2015-09-22_12:53:17 di_SoSchu_OG cmd_event: Sensor_Licht_Sued
2015-09-22_12:53:17 di_SoSchu_OG cmd_nr: 1
2015-09-22_12:53:17 di_Push_Beschattung_OG cmd_1
2015-09-22_12:53:17 di_Push_Beschattung_OG cmd_event: Beschattung_OG
2015-09-22_12:53:17 di_Push_Beschattung_OG cmd_nr: 1
2015-09-22_12:53:16 Beschattung_OG onMeiner Ansicht nach hat das DOIF um 12:53 richtigerweise ausgelöst, es hätte allerdings bereits um 1328 Uhr mit dem Waittimer von 2400 sec starten sollen und schlussendlich die Beschattung um 1408 Uhr aufheben müssen.
Hier die Werte des Sensors:
2015-09-22_17:48:15 Sensor_Licht_Sued 383
2015-09-22_17:40:15 Sensor_Licht_Sued 408
2015-09-22_17:32:15 Sensor_Licht_Sued 327
2015-09-22_17:16:15 Sensor_Licht_Sued 242
2015-09-22_17:14:15 Sensor_Licht_Sued 270
2015-09-22_17:10:15 Sensor_Licht_Sued 400
2015-09-22_16:48:15 Sensor_Licht_Sued 1014
2015-09-22_16:46:15 Sensor_Licht_Sued 1436
2015-09-22_16:22:15 Sensor_Licht_Sued 2602
2015-09-22_16:18:15 Sensor_Licht_Sued 2526
2015-09-22_16:14:15 Sensor_Licht_Sued 2946
2015-09-22_16:12:16 Sensor_Licht_Sued 3033
2015-09-22_16:06:16 Sensor_Licht_Sued 5235
2015-09-22_15:44:16 Sensor_Licht_Sued 3316
2015-09-22_15:34:15 Sensor_Licht_Sued 2853
2015-09-22_15:32:15 Sensor_Licht_Sued 2731
2015-09-22_15:28:16 Sensor_Licht_Sued 2515
2015-09-22_15:24:15 Sensor_Licht_Sued 2897
2015-09-22_15:22:16 Sensor_Licht_Sued 3175
2015-09-22_15:14:15 Sensor_Licht_Sued 3320
2015-09-22_15:12:16 Sensor_Licht_Sued 3290
2015-09-22_15:10:15 Sensor_Licht_Sued 3184
2015-09-22_15:06:15 Sensor_Licht_Sued 2750
2015-09-22_14:20:15 Sensor_Licht_Sued 3524
2015-09-22_14:12:15 Sensor_Licht_Sued 3698
2015-09-22_14:10:16 Sensor_Licht_Sued 4580
2015-09-22_14:02:15 Sensor_Licht_Sued 6317
2015-09-22_14:00:16 Sensor_Licht_Sued 8721
2015-09-22_13:58:16 Sensor_Licht_Sued 12265
2015-09-22_13:56:17 Sensor_Licht_Sued 12002
2015-09-22_13:54:16 Sensor_Licht_Sued 11547
2015-09-22_13:52:15 Sensor_Licht_Sued 12580
2015-09-22_13:50:15 Sensor_Licht_Sued 11715
2015-09-22_13:46:15 Sensor_Licht_Sued 8070
2015-09-22_13:42:16 Sensor_Licht_Sued 7715
2015-09-22_13:40:17 Sensor_Licht_Sued 6871
2015-09-22_13:38:15 Sensor_Licht_Sued 6306
2015-09-22_13:36:16 Sensor_Licht_Sued 5789
2015-09-22_13:34:16 Sensor_Licht_Sued 5950
2015-09-22_13:32:15 Sensor_Licht_Sued 6413
2015-09-22_13:30:15 Sensor_Licht_Sued 7720
2015-09-22_13:28:15 Sensor_Licht_Sued 8525
2015-09-22_13:26:15 Sensor_Licht_Sued 13275
2015-09-22_13:24:15 Sensor_Licht_Sued 11070
2015-09-22_13:22:16 Sensor_Licht_Sued 14519
2015-09-22_13:20:15 Sensor_Licht_Sued 26362
2015-09-22_13:18:16 Sensor_Licht_Sued 48619
2015-09-22_13:16:16 Sensor_Licht_Sued 39037
2015-09-22_13:14:16 Sensor_Licht_Sued 47112
2015-09-22_13:12:15 Sensor_Licht_Sued 44532
2015-09-22_13:10:16 Sensor_Licht_Sued 41364
2015-09-22_13:08:16 Sensor_Licht_Sued 28090
2015-09-22_13:06:16 Sensor_Licht_Sued 18864
2015-09-22_13:04:16 Sensor_Licht_Sued 12936
2015-09-22_13:02:16 Sensor_Licht_Sued 10595
2015-09-22_13:00:16 Sensor_Licht_Sued 12430
2015-09-22_12:58:16 Sensor_Licht_Sued 13803
2015-09-22_12:56:16 Sensor_Licht_Sued 17080
2015-09-22_12:54:16 Sensor_Licht_Sued 31285
2015-09-22_12:52:16 Sensor_Licht_Sued 25750
2015-09-22_12:50:16 Sensor_Licht_Sued 26220
2015-09-22_12:48:16 Sensor_Licht_Sued 36460
2015-09-22_12:46:16 Sensor_Licht_Sued 24220
2015-09-22_12:44:16 Sensor_Licht_Sued 25456
2015-09-22_12:42:16 Sensor_Licht_Sued 39101
2015-09-22_12:40:16 Sensor_Licht_Sued 36313
2015-09-22_12:38:16 Sensor_Licht_Sued 32035Daher frage ich mich, warum das Wait Kommando sofort wieder aufgehoben wird???
Danke für die Hilfe
mumpitz
Der Waittimer wird zurückgesetzt, wenn in der Wartezeit eine andere Bedingung zuschlägt. Das kannst du an den e_...- Readings sehen. Evtl. kannst du diese Trigger mit einem Fragezeichen als reine Abfrage definieren.
Gruß
Damian
Das erklärt auch das Problem meines DOIF:
([Schicht] eq "Nachtdienst")
(set Schicht Frei1)
DOELSEIF ([Schicht] eq "Frei1")
(set Schicht Frei)
wait 86500;86500
do always
Das Problem ist, bei mir könnte ich nicht mit einem Fragezeichen arbeiten um ein Triggern zu verhindern. Muss es wohl oder übel in das hier ändern:
([Schicht] eq "Nachtdienst")
(set Schicht Frei1) (set Schicht Frei)
wait 86500,86500
do always
Hallo Damian
Danke für Deine Antwort. Aus meiner Sicht macht es keinen Sinn, den Sensorwert als nicht triggerndes Argument zu definieren. Ich will ja genau das, dass aufgrund der Helligkeit das entsprechende Event (Beschattung on oder off) ausgelöst wird.
Gibt es eine andere Möglichkeit???
Oder muss ich schlussendlich zwei verschiedene DOIF's machen? (was ich allerdings nicht will)
Merci!
Zitat von: Mumpitz am 23 September 2015, 19:12:24
Hallo Damian
Danke für Deine Antwort. Aus meiner Sicht macht es keinen Sinn, den Sensorwert als nicht triggerndes Argument zu definieren. Ich will ja genau das, dass aufgrund der Helligkeit das entsprechende Event (Beschattung on oder off) ausgelöst wird.
Gibt es eine andere Möglichkeit???
Oder muss ich schlussendlich zwei verschiedene DOIF's machen? (was ich allerdings nicht will)
Merci!
Hast du denn geschaut, wer da die Bedingung so kurzfristig unwahr werden lässt? Der Multisensor kann es wohl nicht sein.
Gruß
Damian
Doch, es ist der MultiSensor. Also zumindest die Zeit stimmt überein!
Aber ich frage mich schon warum der reinspielt, beim Beschattung_off frage ich den gar nicht ab! Wieso kann der den Timer wieder aufheben?
2015-09-22_13:28:34 di_SoSchu_OG wait_timer: no timer
2015-09-22_13:28:34 di_SoSchu_EG wait_timer: no timer
2015-09-22_13:28:15 di_SoSchu_OG wait_timer: 22.09.2015 14:08:15 cmd_2 Sensor_Licht_Sued
2015-09-22_13:28:15 di_SoSchu_EG wait_timer: 22.09.2015 14:08:15 cmd_3 Sensor_Licht_Sued
2015-09-22_13:28:34 Multisensor_Ost humidity: 40
2015-09-22_13:28:34 Multisensor_Ost temperature: 26
2015-09-22_13:28:34 Multisensor_Ost 7101
2015-09-22_13:28:34 Multisensor_Ost lux: 7101
Zitat von: Mumpitz am 23 September 2015, 21:10:13
Doch, es ist der MultiSensor. Also zumindest die Zeit stimmt überein!
Aber ich frage mich schon warum der reinspielt, beim Beschattung_off frage ich den gar nicht ab! Wieso kann der den Timer wieder aufheben?
Der Multisensor triggert, aber die Bedingungen, in denen er enthalten ist, sind nicht wahr, also geht es zum DOELSE-Fall. Das hebt den Timer auf.
Ich würde versuchen, ohne leeres DOELSE auszukommen. So nach dem Prinzip:
DOIF (Variante1)(Beschattung off)
DOELSEIF (Variante2)(Beschattung off)
DOELSE(Beschattung on)
Du kannst on und off auch vertauschen, aber entscheidend ist, dass wenn eine der Bedingungen erfüllt ist, Aktion A ausgeführt wird und wenn keine der Bedingungen erfüllt ist, Aktion B.
Dann wäre das DOIF sozusagen immer in einem wohldefinierten Zustand. Ich weiß nicht, ob das in Deinem Szenario möglich ist. Aber irgendwie sollte man es hinbekommen.
Und wirklich nur die Bedingungen triggern lassen, wo es unbedingt nötig ist. Das reduziert die Gefahr solcher Seiteneffekte.
Zitat von: Mumpitz am 23 September 2015, 21:10:13
Doch, es ist der MultiSensor. Also zumindest die Zeit stimmt überein!
Aber ich frage mich schon warum der reinspielt, beim Beschattung_off frage ich den gar nicht ab! Wieso kann der den Timer wieder aufheben?
2015-09-22_13:28:34 di_SoSchu_OG wait_timer: no timer
2015-09-22_13:28:34 di_SoSchu_EG wait_timer: no timer
2015-09-22_13:28:15 di_SoSchu_OG wait_timer: 22.09.2015 14:08:15 cmd_2 Sensor_Licht_Sued
2015-09-22_13:28:15 di_SoSchu_EG wait_timer: 22.09.2015 14:08:15 cmd_3 Sensor_Licht_Sued
2015-09-22_13:28:34 Multisensor_Ost humidity: 40
2015-09-22_13:28:34 Multisensor_Ost temperature: 26
2015-09-22_13:28:34 Multisensor_Ost 7101
2015-09-22_13:28:34 Multisensor_Ost lux: 7101
Der Multisensor führt zu einer wahren Bedingung, zurückgesetzt wird dieser Zustand vermutlich aber durch einen anderen (zyklischen) Trigger.
Ich arbeite bei mehreren Bedingung selten mit DOELSE, vor allem nicht bei zyklischen Triggern, weil man schnell etwas übersieht, was zu diesem Fall führt.
Deswegen wird ein Sonst-Zustand bei mehreren Bedingungen nur bei Angabe von DOELSE gesetzt und sonst nicht. Es ist also ein gewolltes Features und eben kein Bug.
Gruß
Damian
Ich habe da leider auch mal wieder ein Problem.
Ich habe mal meinen Wecker als DOIF umgebaut. Der Wochentag sowie die Weckzeit, werden über ein Dummy bestimmt.
define wecker DOIF ([([wakeUp_dummy]-[0:20])|[tag]]) ((set sz_LED_Schrank HSV 240,100,100))
Das Dummy für die Weckzeit sieht so aus:
define wakeUp_dummy dummy
attr wakeUp_dummy alias Weckzeit
attr wakeUp_dummy group Weckereinstellung
attr wakeUp_dummy icon time_timer@yellow
attr wakeUp_dummy room Schlafzimmer
attr wakeUp_dummy setList state:time
attr wakeUp_dummy webCmd state
Als State liefert es eine Uhrzeit (11:35).
Das Dummy für den Wochentag sieht so aus:
define tag dummy
attr tag alias Wecker Tag
attr tag eventMap 1:Montag 2:Dienstag 3:Mittwoch 4:Donnerstag 5:Freitag 6:Samstag 0:Sonntag 7:Wochenende 8:Werktags 9:aus
attr tag group Weckereinstellung
attr tag icon time_calendar@yellow
attr tag room Schlafzimmer
attr tag setList state:Montag,Dienstag,Mittwoch,Donnerstag,Freitag,Samstag,Sonntag,Wochende,Werktags,aus
attr tag webCmd state
Als State habe ich hier die entsprechende zahl (für Mittwoch 3).
Im DOIF selbst bei den Uhrzeiten steht das hier: timer_1_c1 26.09.2015 11:05:00|[tag]
Sollte da nicht die Zahl aus dem Dummy angezeigt werden?
Die Commandref sagt ja das hier:
Anwendungsbeispiel: Der Wochentag soll über einen Dummy bestimmt werden.
define dummy Wochentag
set Wochentag 135
define di_radio DOIF ([06:30|[Wochentag]] (set radio on) DOELSEIF ([07:30|[Wochentag]]) (set radio off)
So, manchmal findet man auch selbst den Fehler!
Da ich ja mit einer SetList und der EventMap arbeitet, wird der interne Status des Dummys auf den Namen des Wochentages gesetzt. Dadurch kann die Zeitangabe nix damit anfangen!
Beispiel: ([11:25|Montag])
Also muss ich im DOIF zum Dummyname auch noch :state anhängen, damit er das reading state verwendet!
Hier mal der Dummy:
tag Internals
NAME tag
NR 65
STATE Freitag
TYPE dummy
Readings state 5
Und hier die funktionierende DOIF:
define wecker DOIF ([([wakeUp_dummy]-[0:20])|[tag:state]]) ((set sz_LED_Schrank HSV 240,100,100))
Vielleicht wäre das auch in der Commandref als Ergänzung gut aufgehoben!?
Alles Gute ist 3...
Ich hätte da noch eine Idee!
Und zwar geht es um Zeiten. Wenn man {sunrise(0,"03:00","10:00")} benutzt, kann man ja durch die Zeitangaben den Zeitraum eingrenzen. So etwas würde ich mir auch für Dummys mit Zeitangaben wünschen.
Hintergrund ist folgender:
Ich habe eine DOIF, die mir optisch Bescheid gibt, wenn die Luftfeuchtigkeit in der Wohnung zu hoch wird. Diese soll aber nur in einem Bestimmten Zeitraum aktiv sein. Dieser Zeitraum soll aber auch von der Weckzeit abhängig sein.
Liegt nun quasi die Weckzeit außerhalb des Zeitraumes, dann soll das DOIF erst aktiv werden, wenn der Zeitraum erreicht ist.
Liegt die Weckzeit innerhalb des Zeitraumes, dann soll das DOIF ab der Weckzeit aktiv werden.
Beispiel: define feuchte DOIF ({[weckzeit_dummy](0,"09:00","23:00")} and [wz_Temperatur:humidity]>57) (set LED_Lampe on)
Wäre so etwas machbar?
Zitat von: Toto1973 am 25 September 2015, 11:44:56
Beispiel: define feuchte DOIF ({[weckzeit_dummy](0,"09:00","23:00")} and [wz_Temperatur:humidity]>57) (set LED_Lampe on)
Wäre so etwas machbar?
Reicht dafür nicht einfach eine zusätzliche Bedingung?
define feuchte DOIF ({[weckzeit_dummy]} and [09:00-23:00] and [wz_Temperatur:humidity]>57) (set LED_Lampe on)
Zitat von: Brockmann
Reicht dafür nicht einfach eine zusätzliche Bedingung?
define feuchte DOIF ({[weckzeit_dummy]} and [09:00-23:00] and [wz_Temperatur:humidity]>57) (set LED_Lampe on)
In dem Fall würde das DOIF nur "schalten" wenn die Weckzeit innerhalb dem Zeitraum 9-23 Uhr liegt.
Liegt die Weckzeit aber außerhalb des Zeitraumes, würde nichts schalten, weil dann die Bedingung nie wahr wird!
Zitat von: Toto1973 am 25 September 2015, 11:44:56
Alles Gute ist 3...
Ich hätte da noch eine Idee!
Und zwar geht es um Zeiten. Wenn man {sunrise(0,"03:00","10:00")} benutzt, kann man ja durch die Zeitangaben den Zeitraum eingrenzen. So etwas würde ich mir auch für Dummys mit Zeitangaben wünschen.
Hintergrund ist folgender:
Ich habe eine DOIF, die mir optisch Bescheid gibt, wenn die Luftfeuchtigkeit in der Wohnung zu hoch wird. Diese soll aber nur in einem Bestimmten Zeitraum aktiv sein. Dieser Zeitraum soll aber auch von der Weckzeit abhängig sein.
Liegt nun quasi die Weckzeit außerhalb des Zeitraumes, dann soll das DOIF erst aktiv werden, wenn der Zeitraum erreicht ist.
Liegt die Weckzeit innerhalb des Zeitraumes, dann soll das DOIF ab der Weckzeit aktiv werden.
Beispiel: define feuchte DOIF ({[weckzeit_dummy](0,"09:00","23:00")} and [wz_Temperatur:humidity]>57) (set LED_Lampe on)
Wäre so etwas machbar?
ja.
in myÚtils.pm:
sub startzeit($$$)
{
my ($weckzeit, $anfang, $ende) = @_;
if ($weckzeit lt $anfang or $weckzeit gt $ende) {
return $anfang;
} else {
return $weckzeit;
}
}
define feuchte DOIF ([{startzeit(Value("weckzeit_dummy"),"09:00","23:00")}-23:00] and [wz_Temperatur:humidity]>57) (set LED_Lampe on)Gruß
Damian
Du bist einfach nur genial!
Werde ich gleich mal testen ;-)
Dankeschön!
Hi Damian,
ist es möglich über DOIF ein Datum abzufragen? Ich möchte ein DOIF schreiben, welches 6h vor Ende meines Urlaubs (CALVIEW) den Staugsaugerroboter startet.
Wie man die -6h rechnet, habe ich herausgefunden, aber für eine gezielte Datumsabfrage konnte ich nichts finden. Ein Umweg wäre wohl über $year, $month, $day zu gehen und das abzufragen.
moonsorrox hatte hier eine ähnliche Frage die wohl untergegangen ist (http://forum.fhem.de/index.php/topic,39070.msg335728.html#msg335728).
Zitat von: dominik am 26 September 2015, 10:01:38
Hi Damian,
ist es möglich über DOIF ein Datum abzufragen? Ich möchte ein DOIF schreiben, welches 6h vor Ende meines Urlaubs (CALVIEW) den Staugsaugerroboter startet.
Wie man die -6h rechnet, habe ich herausgefunden, aber für eine gezielte Datumsabfrage konnte ich nichts finden. Ein Umweg wäre wohl über $year, $month, $day zu gehen und das abzufragen.
moonsorrox hatte hier eine ähnliche Frage die wohl untergegangen ist (http://forum.fhem.de/index.php/topic,39070.msg335728.html#msg335728).
Datumsangaben sind bisher nicht programmiert. Ich habe allerdings folgende Variablen zum Abfragen in der Bedingung vorgesehen:
$sec,$min,$hour,$mday,$month,$year,$wday,$yday,$isdst sowie $hms und $hm.
Gruß
Damian
Wie kann ich mit Hilfe von DOIF eine Methode aus 99_myUtils.pm aufrufen? Ich probiere es so:
define tkDoorOpen DOIF ([Eingangstuer] eq "open") ({ DebianMail('email@server.de', 'Tür ist geöffnet!', '');; })
Im Log bekomme ich den folgenden Fehler:
ZitattkDoorOpen: { DebianMail('email@server.de', 'Tür ist geöffnet!', ''); }: Unknown command {, try help.
Unknown command }, try help.
Wenn ich
{ DebianMail('email@server.de', 'Tür ist geöffnet!', '');; }in fhem direkt ausführe, wird eine eMail ohne Fehler verschickt.
Zitat von: Joesky am 26 September 2015, 12:26:18
Wie kann ich mit Hilfe von DOIF eine Methode aus 99_myUtils.pm aufrufen? Ich probiere es so:
define tkDoorOpen DOIF ([Eingangstuer] eq "open") ({ DebianMail('email@server.de', 'Tür ist geöffnet!', '');; })
Im Log bekomme ich den folgenden Fehler:
Wenn ich
{ DebianMail('email@server.de', 'Tür ist geöffnet!', '');; }
in fhem direkt ausführe, wird eine eMail ohne Fehler verschickt.
Bei mir funktioniert eine eigene Routine ohne Probleme. Übrigens: die beiden Semikolons machen an dieser Stelle grundsätzlich keinen Sinn.
Gruß
Damian
Aber ohne das zweite Semikolon bekomme ich die Fehlermeldung, dass eine Klammer fehlt... Ich habe eben noch eine interessante Fehlermeldung im Log gefunden:
Zitat2015.09.26 12:03:48 1: reload: Error:Modul 99_myUtils deactivated:
Nach dem deactivated kommt eine leere Zeile. Kann es damit zu tun haben? Wie gesagt, in der "Shell" vom FHEM kann ich den Befehl so ausführen.
Zitat von: Joesky am 26 September 2015, 21:09:15
Aber ohne das zweite Semikolon bekomme ich die Fehlermeldung, dass eine Klammer fehlt... Ich habe eben noch eine interessante Fehlermeldung im Log gefunden:Nach dem deactivated kommt eine leere Zeile. Kann es damit zu tun haben? Wie gesagt, in der "Shell" vom FHEM kann ich den Befehl so ausführen.
keine Ahnung. Ich benutze Debianmail nicht. Bei mir funktioniert eine eigene Funktion mit mehreren Parametern mit Komma getrennt mit Anführungszeichen " und auch mit '
Gruß
Damian
Zitat von: Joesky am 26 September 2015, 21:09:15
Aber ohne das zweite Semikolon bekomme ich die Fehlermeldung, dass eine Klammer fehlt... Ich habe eben noch eine interessante Fehlermeldung im Log gefunden:Nach dem deactivated kommt eine leere Zeile. Kann es damit zu tun haben? Wie gesagt, in der "Shell" vom FHEM kann ich den Befehl so ausführen.
Da es nur ein Befehl ist kannst du beide Semikolon weg lassen...
Zitat von: dominik am 26 September 2015, 10:01:38
ist es möglich über DOIF ein Datum abzufragen?
moonsorrox hatte hier eine ähnliche Frage die wohl untergegangen ist (http://forum.fhem.de/index.php/topic,39070.msg335728.html#msg335728).
ich war ein paar Tage außer Gefecht gesetzt und wollte mal fragen ob es bei dir inzwischen mit dem Datum klappt.
Hast du mal ein Beispiel, wenn es gehen sollte
Hallo ihr DOIF-Experten :)
Ich schlage mich nun seit geraumer Zeit mit einem Notify herum, welches immer 2 mal ausgelöst wird. Ich hoffe ihr könnt mir dabei helfen.
Ausgangssituation:
Meine Klingelanlage mit Analoger Kamera ist an einem Videoserver angeschlossen, welcher das Bild ins Netzwerk transportiert. Am Videoserver ist Motion-Detect aktiviert, welches beim Klingeln auslöst (weil ja die Kamera angeht) und eine UDP-Message an den FHEM-Server schickt. In FHEM setzt die UDP-Message ein Notify aus, welches das Touchpanel einschaltet und zum Raum Überwachung wechselt in dem dann das Bild per iframe zu sehen ist.
Problem:
Sobald die Klingelkamera abschaltet (nach 60 Sekunden) aktiviert sie wieder das Motion-Detect im Videoserver und setzt die komplette Kette wieder in Gang.
Das Ergebnis ist, dass das Tablet wieder den Raum wechselt, dann sagt es habe geklingelt und ein blaues Bild zu sehen ist.... >:(
Nun möchte ich gerne das Notify per DOIF nach dem Auslösen in eine Zwangspause von 61 Sekunden schicken.
Ich bekomme es aber leider nicht hin.
Das lange suchen und rangieren hat mich eher verwirrt.
Ich hoffe es kann mir jemand helfen
Hier das Notify
EsKlingelt.*|cmd=trigger%20EsKlingelt
;
trigger WEB JS:location="/fhem?room=Überwachung" ;
{UDP_Msg("192.168.2.6" , "wolido:displayon")} ; sleep 3 ; {UDP_Msg("192.168.2.6" , "wolido:speak:Es hat geklingelt")} ;
sleep 39 ;
trigger WEB JS:location="/fhem?room=Küche" ;
{UDP_Msg("192.168.2.6" , "wolido:displayoff")}
ohne notify:
define di_EsKlingelt DOIF ([EsKlingelt:?])
(trigger WEB JS:location="/fhem?room=Überwachung", {UDP_Msg("192.168.2.6" , "wolido:displayon")})
({UDP_Msg("192.168.2.6" , "wolido:speak:Es hat geklingelt")},trigger WEB JS:location="/fhem?room=Küche")
({UDP_Msg("192.168.2.6" , "wolido:displayoff")})
attr di_EsKlingelt do always
attr di_EsKlingelt wait 0,3,39
attr di_EsKlinglet cmdpause 61
Gruß
Damian
Vielen Dank für die schnelle Antwort und dem Code!
Ich habe vorhin etwas falsches geschrieben.....
Das Notify wird nicht mit UDP sondern über die http-Notify Funktion des Videoservers ausgelöst. Wie reagiert das DOIF darauf?
RegexpPart ist:
cmd=trigger%20EsKlingelt
Das Bild zeigt einen Ausschnitt der Gui vom Videoserver
Gruß
Zitat von: eberlrudi am 29 September 2015, 18:16:57
Vielen Dank für die schnelle Antwort und dem Code!
Ich habe vorhin etwas falsches geschrieben.....
Das Notify wird nicht mit UDP sondern über die http-Notify Funktion des Videoservers ausgelöst. Wie reagiert das DOIF darauf?
RegexpPart ist:
cmd=trigger%20EsKlingelt
Das Bild zeigt einen Ausschnitt der Gui vom Videoserver
Gruß
Wie sieht denn der Trigger im Event monitor aus?
Das gibt der Event Monitor aus:
(Ich musste den Rest deaktivieren, da FHEM beim auslösen ja den Raum wechselt)
2015-09-29 19:39:14 LaCrosse LaCrosse_09 temperature: 23.2
2015-09-29 19:39:14 LaCrosse LaCrosse_09 humidity: 51
2015-09-29 19:39:16 LaCrosse LaCrosse_11 battery: ok
2015-09-29 19:39:16 LaCrosse LaCrosse_11 temperature: 20.1
2015-09-29 19:39:16 LaCrosse LaCrosse_11 humidity: 63
2015-09-29 19:39:20 notify EsKlingelt
2015-09-29 19:39:22 LaCrosse LaCrosse_09 battery: ok
2015-09-29 19:39:22 LaCrosse LaCrosse_09 temperature: 23.2
2015-09-29 19:39:22 LaCrosse LaCrosse_09 humidity: 51
2015-09-29 19:39:24 LaCrosse LaCrosse_11 battery: ok
Zitat von: eberlrudi am 29 September 2015, 19:46:01
Das gibt der Event Monitor aus:
(Ich musste den Rest deaktivieren, da FHEM beim auslösen ja den Raum wechselt)
2015-09-29 19:39:14 LaCrosse LaCrosse_09 temperature: 23.2
2015-09-29 19:39:14 LaCrosse LaCrosse_09 humidity: 51
2015-09-29 19:39:16 LaCrosse LaCrosse_11 battery: ok
2015-09-29 19:39:16 LaCrosse LaCrosse_11 temperature: 20.1
2015-09-29 19:39:16 LaCrosse LaCrosse_11 humidity: 63
2015-09-29 19:39:20 notify EsKlingelt
2015-09-29 19:39:22 LaCrosse LaCrosse_09 battery: ok
2015-09-29 19:39:22 LaCrosse LaCrosse_09 temperature: 23.2
2015-09-29 19:39:22 LaCrosse LaCrosse_09 humidity: 51
2015-09-29 19:39:24 LaCrosse LaCrosse_11 battery: ok
ja, dann sollte mein Code-Vorschlag bereits funktionieren.
Gruß
Damian
Wahnsinn!! Danke!!
Es funktioniert!!!
jetzt ist DOIF gerade für mich etwas durchsichtiger geworden.
Nur die Pausen stimmen irgendwie nicht.
Das schaff ich aber alles selbst.
Vielen Dank nochmal
Jetzt muss ich doch nochmal was fragen.
Ich bekomme das mit den Pausen nicht in den griff. Kann ich die auch einfach wie im Notify ins Def schreiben? Das fände ich einfacher
Ich verstehe den zusammenhang nicht ganz. 0,3,39... kann man die Null nicht auch weglassen? Werden die Pausen nach einem trigger gemacht?
Mit dem Code, den du mir geschickt hast, geht das Display an, wechselt den Raum und springt sofort wieder zurück in den Raum Küche.
Zudem bekomme ich komischerweise in den Readings mit
{UDP_Msg("192.168.2.6" , "wolido:displayoff")}: send wolido:displayoff
einen ERROR.... :o
Zitat von: eberlrudi am 29 September 2015, 21:12:28
Jetzt muss ich doch nochmal was fragen.
Ich bekomme das mit den Pausen nicht in den griff. Kann ich die auch einfach wie im Notify ins Def schreiben? Das fände ich einfacher
Ich verstehe den zusammenhang nicht ganz. 0,3,39... kann man die Null nicht auch weglassen? Werden die Pausen nach einem trigger gemacht?
Mit dem Code, den du mir geschickt hast, geht das Display an, wechselt den Raum und springt sofort wieder zurück in den Raum Küche.
Zudem bekomme ich komischerweise in den Readings mit
{UDP_Msg("192.168.2.6" , "wolido:displayoff")}: send wolido:displayoff
einen ERROR.... :o
Hast du überhaupt die aktuelle Version des Moduls? Die Features sind relativ neu.
Gruß
Damian
ist das nicht im Update enthalten? das habe ich gestern erst gemacht.
Zitat von: eberlrudi am 29 September 2015, 21:45:06
ist das nicht im Update enthalten? das habe ich gestern erst gemacht.
Die Sache mit der Verzögerung ist realativ einfach
wait 0,3,39 bedeutet einfach
0 Sekunden also keine Verzögerung für:
(trigger WEB JS:location="/fhem?room=Überwachung", {UDP_Msg("192.168.2.6" , "wolido:displayon")})3 Sekunden danach für:
({UDP_Msg("192.168.2.6" , "wolido:speak:Es hat geklingelt")},trigger WEB JS:location="/fhem?room=Küche")39 Sekunden danach für:
({UDP_Msg("192.168.2.6" , "wolido:displayoff")})Der error-code bedeutet nur, dass deine UDP_Msg-Funktion einen Returncode ungleich Null liefert.
Gruß
Damian
Haben wir es vielleicht mit einem Fehler des Moduls zu tun?
Ich habe nochmal alle Zeichen im Code kontrolliert.
Eigentlich sollte alles stimmen.
Dann ist mir aber schleierhaft warum nach ca. 1 Sekunde der Raum wieder zurückgewechselt wird. Das sollte doch erst nach 39 Sekunden der Fall sein.
Hab ich da was übersehen?
Gruß Rudi
Zitat von: eberlrudi am 29 September 2015, 22:12:37
Haben wir es vielleicht mit einem Fehler des Moduls zu tun?
Ich habe nochmal alle Zeichen im Code kontrolliert.
Eigentlich sollte alles stimmen.
Dann ist mir aber schleierhaft warum nach ca. 1 Sekunde der Raum wieder zurückgewechselt wird. Das sollte doch erst nach 39 Sekunden der Fall sein.
Hab ich da was übersehen?
Gruß Rudi
Dann fangen wir von vorne an.
Was liefert Version DOIF in der Kommandozeile?
# $Id: 98_DOIF.pm 9259 2015-09-15 20:49:46Z damian-s $
Zitat von: eberlrudi am 29 September 2015, 22:19:38
# $Id: 98_DOIF.pm 9259 2015-09-15 20:49:46Z damian-s $
ok. Das ist das aktuelle Modul
jetzt mal Ausgabe von "list di_EsKlingelt" hier posten.
Internals:
DEF ([EsKlingelt:?]) (trigger WEB JS:location="/fhem?room=Überwachung", {UDP_Msg("192.168.2.6" , "wolido:displayon")})
({UDP_Msg("192.168.2.6" , "wolido:speak:Es hat geklingelt")},trigger WEB JS:location="/fhem?room=Küche")
({UDP_Msg("192.168.2.6" , "wolido:displayoff")})
NAME di_EsKlingelt
NR 59
NTFY_ORDER 50-di_EsKlingelt
STATE cmd_1
TYPE DOIF
Readings:
2015-09-29 22:02:30 Device EsKlingelt
2015-09-29 22:03:32 cmd_event EsKlingelt
2015-09-29 22:03:32 cmd_nr 1
2015-09-29 22:03:32 cmd_seqnr 3
2015-09-29 22:02:30 e_EsKlingelt_events
2015-09-29 22:03:32 error {UDP_Msg("192.168.2.6" , "wolido:displayoff")}: send wolido:displayoff
2015-09-29 22:03:32 state cmd_1
2015-09-29 22:03:32 wait_timer no timer
Condition:
0 EventDoIf('EsKlingelt',$hash->{helper}{triggerDev},$hash->{helper}{triggerEvents},'')
Devices:
0 EsKlingelt
all EsKlingelt
Do:
0:
0 trigger WEB JS:location="/fhem?room=Überwachung", {UDP_Msg("192.168.2.6" , "wolido:displayon")}
1 {UDP_Msg("192.168.2.6" , "wolido:speak:Es hat geklingelt")},trigger WEB JS:location="/fhem?room=Küche"
2 {UDP_Msg("192.168.2.6" , "wolido:displayoff")}
Helper:
globalinit 1
last_timer 0
sleepdevice EsKlingelt
sleepsubtimer -1
sleeptimer -1
triggerDev EsKlingelt
triggerEvents:
Internals:
Itimer:
Readings:
State:
Trigger:
all EsKlingelt
Attributes:
cmdpause 61
do always
wait 0,3,59
Das sieht auch gut aus.
Du kannst auf die Details-Anzeige von di_EsKlingelt wechseln. Dann kann man beim Auslösen von EsKlingelt den Statuswechsel beobachten:
Der Statuswechsel sollte wie folgt stattfinden:
sofort: cmd_1_1
3 Sekunden danach: cmd_1_2
39 Sekunden danach: cmd_1
Gruß
Damian
Puh...
Es werden ja ständig die Räume gewechselt....
Wie kann man das bewerkstelligen?
Morgen ist auch noch ein Tag.
Vielen Vielen Dank für deine Mühen bis hier hin.
mfg Rudi
Mir ist da heute morgen auch aufgefallen, das sich DOIF seit dem letzten Update etwas "komisch" verhält.
Ich habe ein DOIF, das mir den State eine Dummys Anwesend auf on oder off setzt.
Damit verbunden ist wiederum ein DOIF, das meine Heizungssteuerung übernimmt. Dort gibt es eine DOELSEIF-Zeile, die dann schalten soll, wenn der State von Anwesend auf off springt.
Heute morgen wurde der State von Anwesend aber mit on gemeldet, und dennoch wurde genau diese DOELSEIF-Zeile getriggert!
Ich hatte extra geschaut, wer da denn nun getriggert hatte.
Dann mal noch eine Verständnis-Frage:
Wenn jetzt ein Device einen Zustand meldet und daraufhin das DOIF geschallten wird, dann sollte doch das DOIF erst dann wieder schalten, wenn sich der Zustand dieses Device ändert!? Ausser ich habe natürlich Do always gesetzt.
Ich kann hier nämlich feststellen, das mir öfters mal der selbe Zustand wieder triggert!
Zitat von: Toto1973 am 30 September 2015, 16:32:50
Mir ist da heute morgen auch aufgefallen, das sich DOIF seit dem letzten Update etwas "komisch" verhält.
Ich habe ein DOIF, das mir den State eine Dummys Anwesend auf on oder off setzt.
Damit verbunden ist wiederum ein DOIF, das meine Heizungssteuerung übernimmt. Dort gibt es eine DOELSEIF-Zeile, die dann schalten soll, wenn der State von Anwesend auf off springt.
Heute morgen wurde der State von Anwesend aber mit on gemeldet, und dennoch wurde genau diese DOELSEIF-Zeile getriggert!
Ich hatte extra geschaut, wer da denn nun getriggert hatte.
Dann mal noch eine Verständnis-Frage:
Wenn jetzt ein Device einen Zustand meldet und daraufhin das DOIF geschallten wird, dann sollte doch das DOIF erst dann wieder schalten, wenn sich der Zustand dieses Device ändert!? Ausser ich habe natürlich Do always gesetzt.
Ich kann hier nämlich feststellen, das mir öfters mal der selbe Zustand wieder triggert!
Es kann tatsächlich passieren, dass der gleiche Zustand (ohne do always) zwei Mal nacheinander geschaltet wird, nämlich dann, wenn man einen Loop (eine Rekursion) direkt oder indirekt über mehrere Module einbaut, das hat aber nichts mit dem neuen Modul zu tun.
Ich könnte dieses Problem einfach lösen, wenn ich den Status vor der Ausführung setzen würde, da dieser auf jeden Fall gesetzt wird, unabhängig davon, ob sich das auszuführende Kommando fehlerhaft verhält oder nicht.
Das hätte auf der einen Seite den Vorteil, dass man sogar in der Ausführung bestimmte Readings des Moduls bereits abfragen könnte, auf der anderen Seite wäre das Modul nicht 100% kompatibel zu der jetzigen Version, insb. dann nicht, wenn jemand die Tatsache ausnutzt, dass der Zustand des Moduls sich erst nach der Ausführung verändert.
Ansonsten: Für eine Fehleranalyse sind genaue Angaben mit list des Moduls, Event-Log wichtig, sonst kann ich nichts zu einem möglichen Problem sagen.
Gruß
Damian
Alles klar!
Sobald ich den "Fehler" (vielleicht liegt der ja auch bei mir irgendwo) wieder aufspüre, werde ich alles loggen bzw dann hier Posten.
Zitat von: Toto1973 am 30 September 2015, 17:40:08
Sobald ich den "Fehler" (vielleicht liegt der ja auch bei mir irgendwo) wieder aufspüre, werde ich alles loggen bzw dann hier Posten.
Da ich selbst ein ganz ähnliches Problem mit der aktuellen DOIF-Version hatte, ein kleiner Hinweis: Möglicherweise war der Loop immer schon da, hat sich aber nie manifestiert, weil das Timing mehr oder weniger zufällig passte.
Durch marginale Änderungen an DOIF oder auch an FHEM selbst in Bezug auf das Abarbeiten der Queue hat sich das Timing verändert und nun manifestiert sich der Loop plötzlich. So in etwa war es jedenfalls bei mir. Durch Hinzufügen einer Bedingung, dass die fragliche Statusänderung mindestens x Sekunden her ist, konnte ich mein DOIF "reparieren".
Zitat von: Brockmann am 01 Oktober 2015, 09:07:54
Da ich selbst ein ganz ähnliches Problem mit der aktuellen DOIF-Version hatte, ein kleiner Hinweis: Möglicherweise war der Loop immer schon da, hat sich aber nie manifestiert, weil das Timing mehr oder weniger zufällig passte.
Durch marginale Änderungen an DOIF oder auch an FHEM selbst in Bezug auf das Abarbeiten der Queue hat sich das Timing verändert und nun manifestiert sich der Loop plötzlich. So in etwa war es jedenfalls bei mir. Durch Hinzufügen einer Bedingung, dass die fragliche Statusänderung mindestens x Sekunden her ist, konnte ich mein DOIF "reparieren".
Wenn du etwas Konkretes, Nachvollziehbares hast, dann kannst du es ja hier posten.
Gruß
Damian
Zitat von: Damian am 01 Oktober 2015, 10:09:34
Wenn du etwas Konkretes, Nachvollziehbares hast, dann kannst du es ja hier posten.
Warum sollte ich das? Wie ich schrieb, habe ich mein Problem gelöst.
Ich wollte mit meinem Hinweis nur dem Fragesteller behilflich sein, weil ich eine gewisse Parallele zwischen meinem Problem und seinem sehe.
Vielleicht hilft ihm ja die Perspektive "In meinem DOIF war immer schon was falsch, nur hat es bislang keine Rolle gespielt." bei der Fehlersuche weiter.
Falls Du aus dem Satz "Durch marginale Änderungen an DOIF oder auch an FHEM selbst in Bezug auf das Abarbeiten der Queue hat sich das Timing verändert" Kritik oder irgendeinen Vorwurf ablesen solltest, siehst Du das falsch.
Also Ich verstehe bei meinem DOIF jetzt gar nichts mehr...
Ich muss das Notify aktiviert lassen, dass DOIF überhaupt funktioniert... Es sieht so aus, als würde DOIF doch nicht ausgelöst werden...
Damian möchtest du dir mein FHEM einmal anschauen? Ich könnte dir eine URL freigeben.
Zitat von: Brockmann am 01 Oktober 2015, 10:38:50
Warum sollte ich das? Wie ich schrieb, habe ich mein Problem gelöst.
Ich wollte mit meinem Hinweis nur dem Fragesteller behilflich sein, weil ich eine gewisse Parallele zwischen meinem Problem und seinem sehe.
Vielleicht hilft ihm ja die Perspektive "In meinem DOIF war immer schon was falsch, nur hat es bislang keine Rolle gespielt." bei der Fehlersuche weiter.
Falls Du aus dem Satz "Durch marginale Änderungen an DOIF oder auch an FHEM selbst in Bezug auf das Abarbeiten der Queue hat sich das Timing verändert" Kritik oder irgendeinen Vorwurf ablesen solltest, siehst Du das falsch.
Ich habe es nicht als Vorwurf verstanden, sondern eher als ein unterschiedliches Verhalten des Moduls durch unterschiedliches Timing. Und das hat mich interessiert, denn möglicherweise ist es kein Timinigproblem, sondern einfach das Problem, was es immer schon gab, aber jetzt den Usern erst auffällt.
z. B.
set test_d on
define di_test DOIF ([test_d] eq "on" and [test_1:?]) (set test_1 on) DOELSE (set test_1 off)
trigger test_1
Es wird zwei mal set test1 on geschaltet, obwohl kein do always gesetzt ist.
Das ist jetzt so und war vorher schon so. Es ist auch erklärbar warum es so ist und ließe sich beheben, wenn man eine Inkompatibilät des Moduls in Kauf nehmen würde, wie ich ein paar Posts zuvor geschrieben habe.
Gruß
Damian
Zitat von: eberlrudi am 01 Oktober 2015, 11:06:40
Also Ich verstehe bei meinem DOIF jetzt gar nichts mehr...
Ich muss das Notify aktiviert lassen, dass DOIF überhaupt funktioniert... Es sieht so aus, als würde DOIF doch nicht ausgelöst werden...
Damian möchtest du dir mein FHEM einmal anschauen? Ich könnte dir eine URL freigeben.
poste einfach list dein_modul hier.
Gruß
Damian
Vielen Dank für deine Geduld...
Das DOIF:
Internals:
DEF ([EsKlingelt:?]) (trigger WEB JS:location="/fhem?room=Überwachung", {UDP_Msg("192.168.2.6" , "wolido:displayon")})
({UDP_Msg("192.168.2.6" , "wolido:speak:Es hat geklingelt")},trigger WEB JS:location="/fhem?room=Küche")
({UDP_Msg("192.168.2.6" , "wolido:displayoff")})
NAME di_EsKlingelt
NR 58
NTFY_ORDER 50-di_EsKlingelt
STATE cmd_1
TYPE DOIF
Readings:
2015-10-01 20:25:15 Device EsKlingelt
2015-10-01 20:26:17 cmd_event EsKlingelt
2015-10-01 20:26:17 cmd_nr 1
2015-10-01 20:26:17 cmd_seqnr 3
2015-10-01 20:25:15 e_EsKlingelt_events
2015-10-01 20:26:17 error {UDP_Msg("192.168.2.6" , "wolido:displayoff")}: send wolido:displayoff
2015-10-01 20:26:17 state cmd_1
2015-10-01 20:26:17 wait_timer no timer
Condition:
0 EventDoIf('EsKlingelt',$hash->{helper}{triggerDev},$hash->{helper}{triggerEvents},'')
Devices:
0 EsKlingelt
all EsKlingelt
Do:
0:
0 trigger WEB JS:location="/fhem?room=Überwachung", {UDP_Msg("192.168.2.6" , "wolido:displayon")}
1 {UDP_Msg("192.168.2.6" , "wolido:speak:Es hat geklingelt")},trigger WEB JS:location="/fhem?room=Küche"
2 {UDP_Msg("192.168.2.6" , "wolido:displayoff")}
Helper:
globalinit 1
last_timer 0
sleepdevice EsKlingelt
sleepsubtimer -1
sleeptimer -1
triggerDev EsKlingelt
triggerEvents:
Internals:
Itimer:
Readings:
State:
Trigger:
all EsKlingelt
Attributes:
cmdpause 61
do always
wait 3,59
Das Notify:
Internals:
DEF EsKlingelt.*|cmd=trigger%20EsKlingelt
;
trigger WEB JS:location="/fhem?room=Überwachung" ;
{UDP_Msg("192.168.2.6" , "wolido:displayon")} ; sleep 3 ; {UDP_Msg("192.168.2.6" , "wolido:speak:Es hat geklingelt")} ;
sleep 39 ;
trigger WEB JS:location="/fhem?room=Küche" ;
{UDP_Msg("192.168.2.6" , "wolido:displayoff")}
NAME EsKlingelt
NR 40
NTFY_ORDER 50-EsKlingelt
REGEXP EsKlingelt.*|cmd=trigger%20EsKlingelt
STATE 2015-10-01 20:25:15
TYPE notify
Readings:
2015-10-01 13:36:10 state active
Attributes:
Du kannst an den Readings einiges erkennen:
Hier kannst du sehen, ob und wann ein relevates Event kam:
2015-10-01 20:25:15 e_EsKlingelt_events
Hier kannst du sehen, welches Device die Ausführung ausgelöst hat:
2015-10-01 20:26:17 cmd_event EsKlingelt
Hier kannst du sehen welches Kommando ausgeführt wurde:
2015-10-01 20:26:17 cmd_nr 1
Und hier welches Kommado der Befehlssequenz zuletzt ausgeführt wurde:
2015-10-01 20:26:17 cmd_seqnr 3
hier hat also alles Funktioniert.
das notify macht im prinzip das Gleiche, wäre also doppelt gemoppelt.
Sobald das Event kommt, sollte die Abfolge abgearbeitet werden und das sollte von dem notify unabhängig sein.
Gruß
Damian
ich versuche es noch einmal. Ich deaktiviere das Notify......
So.
Nach ausgiebigen tests, funktioniert es soweit.
Nur:
Der Befehl :
{UDP_Msg("192.168.2.6" , "wolido:displayoff")}: send wolido:displayoff
wird tatsächlich verschluckt, da das Display nicht mehr ausgeht...
Die Sprachausgabe:
({UDP_Msg("192.168.2.6" , "wolido:speak:Es hat geklingelt")}
kommt gleichzeitig mit dem Wechsel zurück in den Raum Küche.
trigger WEB JS:location="/fhem?room=Küche")
Was macht eigentlich die letzte Klammer da?
Zitat von: eberlrudi am 01 Oktober 2015, 21:51:59
So.
Nach ausgiebigen tests, funktioniert es soweit.
Nur:
Der Befehl :
{UDP_Msg("192.168.2.6" , "wolido:displayoff")}: send wolido:displayoff
wird tatsächlich verschluckt, da das Display nicht mehr ausgeht...
Die Sprachausgabe:
({UDP_Msg("192.168.2.6" , "wolido:speak:Es hat geklingelt")}
kommt gleichzeitig mit dem Wechsel zurück in den Raum Küche.
trigger WEB JS:location="/fhem?room=Küche")
Was macht eigentlich die letzte Klammer da?
Ob und wann tatsächlich das Kommdo ausgeführt wird, kannst du testen, indem du statt des Kommandos z. B. die Ausführung loggst.
anstatt
{UDP_Msg("192.168.2.6" , "wolido:speak:Es hat geklingelt")} angeben
{Log 3," wolido:speak:Es hat geklingelt"}Im Log siehst du dann, ob und wann die UDP_Msg geschickt worden wäre.
Die letzte Klammer schließt die Befehlssequenz, die zuvor mit einer Klammer auf geöffnet wurde.
Gruß
Damian
Hallo,
ich wollte jetzt nicht unbedingt ein neues Thema aufmachen denn ich grübel nun schon lange über einen doif nach wo ich einfach keine richtige lösung finde...
ich habe 3x define erstellt, unten das bsp. ist nur eins die anderen sind gleich aufgebaut nur mit anderen namen:
([Liescha:state] eq "present") (set TuerSchloss open) (set Fl_LampeDecke press short) DOELSE ([Steffen:state] eq "absent" and [Doreen:state] eq "absent" and [Liescha:state] eq "absent") (set TuerSchloss lock)
könnte man die drei zusammen fassen in eins denn das Problem ist ja wenn schon present ist also wenn schon da ist fragt er ja die anderen nicht mehr ab oder habe ich da einen denkfehler?!?
Denn selbst wenn ein oder zwei present sind soll noch "open" geschaltet werden.
Mfg Steffen
Zitat von: Steffen am 02 Oktober 2015, 15:04:29
Hallo,
ich wollte jetzt nicht unbedingt ein neues Thema aufmachen denn ich grübel nun schon lange über einen doif nach wo ich einfach keine richtige lösung finde...
ich habe 3x define erstellt, unten das bsp. ist nur eins die anderen sind gleich aufgebaut nur mit anderen namen:
([Liescha:state] eq "present") (set TuerSchloss open) (set Fl_LampeDecke press short) DOELSE ([Steffen:state] eq "absent" and [Doreen:state] eq "absent" and [Liescha:state] eq "absent") (set TuerSchloss lock)
könnte man die drei zusammen fassen in eins denn das Problem ist ja wenn schon present ist also wenn schon da ist fragt er ja die anderen nicht mehr ab oder habe ich da einen denkfehler?!?
Denn selbst wenn ein oder zwei present sind soll noch "open" geschaltet werden.
Mfg Steffen
Du kannst ja mehrere mit or verknüpfen:
([Steffen:state] eq "present" or [Doreen:state] eq "present" or [Liescha:state] eq "present") (set TuerSchloss open ...Gruß
Damian
Wenn ich dich richtig verstanden habe, hast du für jeden Person ein DOIF erstellt, wenn sie anwesend ist. Alle drei sind so aufgebaut, wie das von dir gepostete, nur, dass sich das erste Command in der Person unterscheidet. Und du willst diese alle zusammen fassen. Dann würde das so aussehen:
([Liescha] eq "present" or [Steffen] eq "present" or [Doreen] eq "present") (set TuerSchloss open) (set Fl_LampeDecke press short) DOELSEIF ([Steffen] eq "absent" and [Doreen] eq "absent" and [Liescha] eq "absent") (set TuerSchloss lock)
:state kannste dir übrigens sparen, weil immer state genommen wird, wenn kein Reading angegeben wird.
Und wichtig, dass zweite ist ein DOELSEIF
Vielen dank für eure Hilfe, so klappt es erstmal hatte irgendwie nicht an "or" gedacht und hatte auch bei meinen ersten Versuchen "DOELSE" versucht anstatt "DOELSEIF"!
Aber eine Frage hätte ich noch ist es richtig das ich "attr do always" bei dem von euch vorgeschlagen code verwenden muss, denn sonnst schaltet er nur bei dem ersten "Present"???
Mfg Steffen
Zitat von: Steffen am 02 Oktober 2015, 20:15:07
Vielen dank für eure Hilfe, so klappt es erstmal hatte irgendwie nicht an "or" gedacht und hatte auch bei meinen ersten Versuchen "DOELSE" versucht anstatt "DOELSEIF"!
Aber eine Frage hätte ich noch ist es richtig das ich "attr do always" bei dem von euch vorgeschlagen code verwenden muss, denn sonnst schaltet er nur bei dem ersten "Present"???
Mfg Steffen
ja.
Gruß
Damian
Hallo,
Leider wird doch bei diesem define auch der Befehl zum "open" gegeben selbst wenn der state von einen von den 3 device als absent gegeben wird?! Sollte eigentlich nur bei "present" sein...hier nochmal der code:
([Liescha] eq "present" or [Steffen] eq "present" or [Doreen] eq "present") (set TuerSchloss open) (set Fl_LampeDecke press short) DOELSEIF ([Steffen] eq "absent" and [Doreen] eq "absent" and [Liescha] eq "absent") (set TuerSchloss lock)
Hat jemand noch Idee wo der Fehler loegen könnte?
attr do always ist auch Akteviert
Nein, da liegst Du falsch.
Erst wenn alle 3 auf absent sind, wird das Schloss verriegelt. Deshalb sind die 3 mit AND verknüpft.
Wenn alle 3 "absent" sind wird es auch auf "locked" gesetzt das klappt auch aber ich wollten nur wenn"present" als state kommt dann "open" aber jetzt schaltet er auch auf "open" wenn einer der 3 "absent" als state bekommt?!?
Mfg Steffen
Zitat von: Steffen am 03 Oktober 2015, 10:35:09
Hallo,
Leider wird doch bei diesem define auch der Befehl zum "open" gegeben selbst wenn der state von einen von den 3 device als absent gegeben wird?!
ist ja auch richtig...!
([Liescha] eq "present" or [Steffen] eq "present" or [Doreen] eq "present") (set TuerSchloss open)- ist Liescha da... zuhause oder was auch immer also (present) triggert er "set open..."
- ist Steffen da... zuhause oder was auch immer also (present) triggert er "set open..."
- ist Doreen da... zuhause oder was auch immer also (present) triggert er "set open..."
von der Logik her richtig
Ja aber wenn dann zb.:
- doreen "absent" getriggert wird dann macht er trotzdem "open" also zur zeit immer, das ist aber nur wenn "do always" aktiviert ist...so dachte ich mir das aber leider nicht!
Gibt es einen weg wo er wirklich nur bei "present" öffnet??
Mfg Steffen
Richtig, weil Du OR genommen hast.
Du könntest anstelle von OR AND nehmen, dann müssen aber alle 3 zu Hause sein, damit aufgemacht wird.
Weil ich weis sonst nicht, wie Du das sonst machen willst.
Es sollte doch aufgehen, wenn einer der 3 nach Hause kommt, und zu gehen, wenn alle 3 weg sind. Weil geht es schon zu, wenn z.B. Doreen geht (absent), dann wären ja die anderen eingesperrt!
Oder wie möchtest Du denn haben, das es schaltet?
Eigentlich ganz einfach :o
Wenn Doreen oder Steffen oder Liescha kommt soll der befehl "open" ausglöst werden, egal ob einer/zwei von uns drein schon da ist(present) und wenn gar keiner da ist dann "lock", wenn nur einer oder zwei gehen(absent) dann soll nichts passieren, das ist aber leider nicht der Fall denn komisch ist wenn alle present sind und dann einer "absent" wird dann schaltet er trotzdem "open" was ja eigentlich gar nicht im Code steht oder?!?
Wie gesagt das er "open" bei nur einen absent schaltet ist nur wenn ich "do always" aktiviert habe...
Hoffe finden noch ne lösung...trotzdem danke schonmal für eure geduld
Mfg Steffen
Bei Open muss OR genommen werden, damit dann geschaltet wird, wenn einer der 3 auf "present" steht und
bei Close muss AND stehen, damit es nur schließt, wenn alle 3 auf "absent" stehen.
Wenn Du natürlich do always stehen hast, dann wird immer getriggert, wenn sich ein Status ändert! Und das möchtest Du ja nicht.
do always ist zum Beispiel dann zu setzten, wenn nur eine Uhrzeit triggern soll und das nicht nur einmal, sondern immer dann, wenn diese Uhrzeit wieder erreicht wird.
Hast Du aber einen "Schalter" (hier dein present/absent), dann braucht man kein do always.
Das Problem ist aber leider wenn ich nicht "do always" aktiviere das er dann nur beim ersten "present" triggert und "open" als befehl raus gibt, die weiteren "present" werden zwar regestriert aber es wird kein befehl "open" rausgegeben?!?
Ich versuche es nochmal in einem notify oder mit 2 doif, wenn aber noch von euch einer eine idee hat, wäre ich sehr dankbar!
Mfg Steffen
Zitat von: Steffen am 03 Oktober 2015, 18:28:22
Eigentlich ganz einfach :o
Wenn Doreen oder Steffen oder Liescha kommt soll der befehl "open" ausglöst werden, egal ob einer/zwei von uns drein schon da ist(present) und wenn gar keiner da ist dann "lock", wenn nur einer oder zwei gehen(absent) dann soll nichts passieren, das ist aber leider nicht der Fall denn komisch ist wenn alle present sind und dann einer "absent" wird dann schaltet er trotzdem "open" was ja eigentlich gar nicht im Code steht oder?!?
Wie gesagt das er "open" bei nur einen absent schaltet ist nur wenn ich "do always" aktiviert habe...
Hoffe finden noch ne lösung...trotzdem danke schonmal für eure geduld
Mfg Steffen
Dann musst du mit Event- statt Statusabfrage arbeiten:
([Liescha:?present] or [Steffen:?present] or [Doreen:?present])...DOELSEIF muss so bleiben und do always solltest du setzen.
Gruß
Damian
Zitat von: Damian am 03 Oktober 2015, 20:30:53
Dann musst du mit Event- statt Statusabfrage arbeiten:
([Liescha:?present] or [Steffen:?present] or [Doreen:?present])...
DOELSEIF muss so bleiben und do always solltest du setzen.
Gruß
Damian
Ach mensch danke...jetzt scheint es zu klappen, werde es die Tage testen aber die ersten Test haben geklappt!
Vielen Vielen dank nochmal an alle und Damian...
Mfg Steffen
Hallo Damian,
danke für die tollen neuen Funktionen.
Meine Rollladensteuerung wird langsam immer komplexer:
- Hoch/runter bei Sonnenauf/-untergang abhängig von Temperatur
- Beschattung abhängig von Sonnenstand, Helligkeit, Temperatur
- Lüftungssteuerung mit Fensterkontakten
- ...
Dadurch werden die DOIF's recht komplex und etwas unübersichtlich. Ich würde diese gerne etwas optimieren und vereinfachen.
Du hast Funktionen wie mehrere DOIF in einem Modul und mehrere Bedingungen angekündigt.
Wie ist der aktuelle Entwicklungsstand?
Danke
Gruß Chris
Zitat von: hatamoto am 11 Oktober 2015, 15:12:28
Hallo Damian,
danke für die tollen neuen Funktionen.
Meine Rollladensteuerung wird langsam immer komplexer:
- Hoch/runter bei Sonnenauf/-untergang abhängig von Temperatur
- Beschattung abhängig von Sonnenstand, Helligkeit, Temperatur
- Lüftungssteuerung mit Fensterkontakten
- ...
Dadurch werden die DOIF's recht komplex und etwas unübersichtlich. Ich würde diese gerne etwas optimieren und vereinfachen.
Du hast Funktionen wie mehrere DOIF in einem Modul und mehrere Bedingungen angekündigt.
Wie ist der aktuelle Entwicklungsstand?
Danke
Gruß Chris
Diese Erweiterungen habe ich zunächst zurückgestellt.
Module, die logisch zusammenhängen, kann man zwecks Übersicht in eine gemeinsame Gruppe packen. Bei umfangreichen Definitionen helfen Einrückungen in der Definition und Kommentierungen beginnend mit ##.
Gruß
Damian
Hi Damian,
kann es sein, dass bei einem wait der Status nicht gespeichert wird um einen Reboot zu überleben? Ich nutze wait um am Abend nach Sonnenuntergang die Außenbeleuchtung für 2,5h an zu haben. Nach 2,5h kommt dann der off Befehle. Funktioniert super.
Zuletzt hatte ich aber das Phänomen, dass ich den RPi rebootet habe und danach das DOIF wieder auf cmd_1 stand statt cmd_1_1. Daher vermute ich mal, dass wait nicht gespeichert wird?
Dann noch eine Frage für folgendes Szenario:
Ich möchte das in der Früh wenn ich aufstehe (Weckzeit in fhem + 10min) das Wakeuplight bis zum Sonnenaufgang+10min leuchtet. Aktuell kann ich das mit
[([Wecker_dummy]+[0:10:00])-([twilightHome:sr_indoor]+[0:10:00])|8]
lösen, aber was passiert wenn der Sonnenaufgang mal VOR der Weckzeit ist? Mir fällt da gerade keine schöne Lösung ein. Vielleicht hast du einen passenden Trick parat :)
Zitat von: dominik am 17 Oktober 2015, 09:35:35
Hi Damian,
kann es sein, dass bei einem wait der Status nicht gespeichert wird um einen Reboot zu überleben? Ich nutze wait um am Abend nach Sonnenuntergang die Außenbeleuchtung für 2,5h an zu haben. Nach 2,5h kommt dann der off Befehle. Funktioniert super.
Zuletzt hatte ich aber das Phänomen, dass ich den RPi rebootet habe und danach das DOIF wieder auf cmd_1 stand statt cmd_1_1. Daher vermute ich mal, dass wait nicht gespeichert wird?
Dann noch eine Frage für folgendes Szenario:
Ich möchte das in der Früh wenn ich aufstehe (Weckzeit in fhem + 10min) das Wakeuplight bis zum Sonnenaufgang+10min leuchtet. Aktuell kann ich das mit
[([Wecker_dummy]+[0:10:00])-([twilightHome:sr_indoor]+[0:10:00])|8]
lösen, aber was passiert wenn der Sonnenaufgang mal VOR der Weckzeit ist? Mir fällt da gerade keine schöne Lösung ein. Vielleicht hast du einen passenden Trick parat :)
Timer werden nach dem Neustart neugesetzt, Wait-Timer gehen verloren.
Wenn die zweite Zeit vor der ersten liegt, dann gilt das Intervall über Mitternacht (siehe Beispiel in der Commandref zu DOIF).
Gruß
Damian
Hallo zusammen,
ich würde gerne meinen Watchdog für die Fensterüberwachung durch DOIF ersetzen.
Folgendes habe ich aktuell definiert:
Internals:
CFGFN
DEF ([2_02_KL_Fensterkontakt:?open] && [?Heizungmodus] eq "Winter")
({PushMassage("Fhem","doif 2_02_KL_Fensterkontakt ist offen","",0,"")})
({EximMail("test@test.de", "doif FHEM Überwachung: 2_02_KL_Fensterkontakt", "Fenster ist offen")})
DOELSEIF ([2_03_SZ_Fensterkontakt:?open] && [?Heizungmodus] eq "Winter")
({PushMassage("Fhem","doif 2_03_SZ_Fensterkontakt ist offen","",0,"")})
({EximMail("test@test.de", "doif FHEM Überwachung: 2_03_SZ_Fensterkontakt", "Fenster ist offen")})
DOELSEIF ([2_05_BZ_Fensterkontakt:?open] && [?Heizungmodus] eq "Winter")
({PushMassage("Fhem","doif 2_05_BZ_Fensterkontakt ist offen","",0,"")})
({EximMail("test@test.de", "doif FHEM Überwachung: 2_05_BZ_Fensterkontakt", "Fenster ist offen")})
...
Attributes:
do always
group Überwachung
loglevel 6
room 9_09_Einstellungen
wait 900:900:900
Leider funktioniert das nicht so wie ich gerne hätte. Vielleicht habe ich auch etwas bzgl. "wait" etc. übersehen.
Problem ist folgendes:
- Wenn ich 2 Fenster offen habe kommt nach 15 Minuten nur die Meldung von einem.
- Wenn ich 1 Fenster innerhalb der 15 Minuten schließe kommt trotzdem eine Meldung.
Wo liegt mein Denkfehler? Oder gehen mehrere DOELSEIFs nicht?
Mein watchdog sieht folgendermaßen aus.
DEF ([0123]).([0-9][0-9]).([A-Z][A-Z0-9])(.2)?.(Fensterkontakt):open 00:15:00 ([A-Z][A-Z0-9]).(Fensterkontakt):closed {
my $heizungmodus = ReadingsVal("Heizungmodus","state",undef);
if ($heizungmodus eq "Winter") {
PushMassage("Fhem","Fenster ist offen","",0,"");
EximMail("test@test.de", "FHEM Überwachung: Fenster", "Fenster ist offen");
fhem("setstate watchdog_Ueberwachung_Fenster defined");
}
Vielen Dank.
Gruß Daniel
Zitat von: dancatt am 18 Oktober 2015, 09:32:06
Wo liegt mein Denkfehler? Oder gehen mehrere DOELSEIFs nicht?
klar gehen mehrere DOELSEIF, aber was ich in einem DOIF noch nicht gesehen habe ist dieses"&&" soll das "und" sein - also "and"..?
Zitat von: moonsorrox am 18 Oktober 2015, 12:02:03
..., aber was ich in einem DOIF noch nicht gesehen habe ist dieses"&&" soll das "und" sein - also "and"..?
Zitat aus der Commandref zu DOIF
ZitatVergleichende Abfragen werden, wie in Perl gewohnt, mit Operatoren ==, !=, <, <=, >, >= bei Zahlen und mit eq, ne, lt, le, gt, ge, =~, !~ bei Zeichenketten angegeben. Logische Verknüpfungen sollten zwecks Übersichtlichkeit mit and bzw. or vorgenommen werden. Selbstverständlich lassen sich auch alle anderen Perl-Operatoren verwenden, da die Auswertung der Bedingung vom Perl-Interpreter vorgenommen wird.
Da in der Bedingung 100% Perl gilt, kannst du auch noch all das verwenden:
++ -- (Inkrementieren, Dekrementieren)
** (Potenzierung)
! ~ (logische und bitweise Negation)
=~ !~ (Bindung an reguläre Ausdrücke)
* / % x (Multiplikation, Division, Modulo-Operation, Zeichenkettenwiederholung)
<< >> (Verschieben von Bits)
< > <= >= lt gt le ge (Vergleich größer/kleiner)
== != <=> eq ne cmp ~~ (Gleichheit/Ungleichheit)
& (bitweises UND)
| ^ (bitweises ODER - inklusiv/exklusiv)
&& (logisches UND)
|| (logisches ODER)
not (logische Negation)
and (logisches UND)
or xor (logisches ODER (inklusiv/exklusiv)
Gruß
Damian
@dancatt: Senden deine Fensterkontakte regelmäßig Ereignisse? Es wird immer der Befehlszweig ausgeführt, bei dem, nach seinem Ereigniss "open", 900 s kein anderer Fensterkontakt ein Ereignis "open" sendet.
versuch es so:
([+900] and [Fenster] eq "open") (push ...)
do always
Für jedes Fenster ein DOIF.
Zitat von: Damian am 18 Oktober 2015, 12:58:38
Zitat aus der Commandref zu DOIF
Da in der Bedingung 100% Perl gilt, kannst du auch noch all das verwenden:
++ -- (Inkrementieren, Dekrementieren)
** (Potenzierung)
! ~ (logische und bitweise Negation)
=~ !~ (Bindung an reguläre Ausdrücke)
* / % x (Multiplikation, Division, Modulo-Operation, Zeichenkettenwiederholung)
<< >> (Verschieben von Bits)
< > <= >= lt gt le ge (Vergleich größer/kleiner)
== != <=> eq ne cmp ~~ (Gleichheit/Ungleichheit)
& (bitweises UND)
| ^ (bitweises ODER - inklusiv/exklusiv)
&& (logisches UND)
|| (logisches ODER)
not (logische Negation)
and (logisches UND)
or xor (logisches ODER (inklusiv/exklusiv)
Gruß
Damian
OK Danke :D
ZitatSenden deine Fensterkontakte regelmäßig Ereignisse? Es wird immer der Befehlszweig ausgeführt, bei dem, nach seinem Ereigniss "open", 900 s kein anderer Fensterkontakt ein Ereignis "open" sendet.
Sobald ich ein Fenster öffne wird auch ein Ereignis "open" ausgelöst.
Zitat
versuch es so:
([+900] and [Fenster] eq "open") (push ...)
do always
Für jedes Fenster ein DOIF.
Ich möchte eigentlich lieber nur ein DOIF. Desweiteren wäre es bei dieser Lösung so, dass alle 15 Minuten überprüft wird. Sympathischer wäre mir meine Lösung, da nur dann reagiert wird, wenn ein Fenster geöffnet wird. Aber vielleicht geht meine Lösung ja garnicht :-(
Zitat von: dancatt am 18 Oktober 2015, 17:14:01
Ich möchte eigentlich lieber nur ein DOIF. Desweiteren wäre es bei dieser Lösung so, dass alle 15 Minuten überprüft wird. Sympathischer wäre mir meine Lösung, da nur dann reagiert wird, wenn ein Fenster geöffnet wird. Aber vielleicht geht meine Lösung ja garnicht :-(
Kannst du nochmal in Textform sagen, was genau du möchtest was das DOIF machen soll unter welchen Bedingungen? Habe es leider noch nicht ganz verstanden, vll kann ich dir dann helfen.
Zitat
Kannst du nochmal in Textform sagen, was genau du möchtest was das DOIF machen soll unter welchen Bedingungen? Habe es leider noch nicht ganz verstanden, vll kann ich dir dann helfen.
:-)
Ich möchte eine Fensterüberwachung. Wenn das Fenster 15 Minuten offen ist möchte ich eine Nachricht. Die Nachricht soll dann auch nur kommen wenn das Fenster auch nach 15 Minuten noch offen ist. Also wenn es innerhalb der 15 Minuten nicht geschlossen wird. Und das Ganze nach 15 Minuten wieder.
Nun habe ich mehrere Fensterkontakte und ich würde gerne alle in einem DOIF abfackeln. Z.B. so:
Internals:
CFGFN
DEF ([2_02_KL_Fensterkontakt:?open] && [?Heizungmodus] eq "Winter")
({PushMassage("Fhem","doif 2_02_KL_Fensterkontakt ist offen","",0,"")})
({EximMail("test@test.de", "doif FHEM Überwachung: 2_02_KL_Fensterkontakt", "Fenster ist offen")})
DOELSEIF ([2_03_SZ_Fensterkontakt:?open] && [?Heizungmodus] eq "Winter")
({PushMassage("Fhem","doif 2_03_SZ_Fensterkontakt ist offen","",0,"")})
({EximMail("test@test.de", "doif FHEM Überwachung: 2_03_SZ_Fensterkontakt", "Fenster ist offen")})
DOELSEIF ([2_05_BZ_Fensterkontakt:?open] && [?Heizungmodus] eq "Winter")
({PushMassage("Fhem","doif 2_05_BZ_Fensterkontakt ist offen","",0,"")})
({EximMail("test@test.de", "doif FHEM Überwachung: 2_05_BZ_Fensterkontakt", "Fenster ist offen")})
...
Attributes:
do always
group Überwachung
loglevel 6
room 9_09_Einstellungen
wait 900:900:900Mit watchdog (funktioniert) sieht die Lösung so aus:
DEF ([0123]).([0-9][0-9]).([A-Z][A-Z0-9])(.2)?.(Fensterkontakt):open 00:15:00 ([A-Z][A-Z0-9]).(Fensterkontakt):closed {
my $heizungmodus = ReadingsVal("Heizungmodus","state",undef);
if ($heizungmodus eq "Winter") {
PushMassage("Fhem","Fenster ist offen","",0,"");
EximMail("test@test.de", "FHEM Überwachung: Fenster", "Fenster ist offen");
fhem("setstate watchdog_Ueberwachung_Fenster defined");
}
Zusatz:
wenn man natürlich nacheinander alle 3 Fenster aufmacht und mindestens 15 min. offen lässt, dann sollen auch je eine Nachricht gesendet werden.
Zitat von: dancatt am 18 Oktober 2015, 17:36:40
Zusatz:
wenn man natürlich nacheinander alle 3 Fenster aufmacht und mindestens 15 min. offen lässt, dann sollen auch je eine Nachricht gesendet werden.
Folgendes Problem sehe ich:
Sobald ein Fenster geöffnet wird, kannst du nach 15 Minuten eine Meldung mittels Wait schicken, jedoch wird der Waittimer überschrieben, wenn eine andere Bedingung des DOIFs wahr wird. Dh wenn zb nach 7 Minuten Fenster zwei geöffnet wurde, dann wird der Waittimer von Fenster 1 gelöscht und die Nachricht wird nicht kommen, sondern nach 15 Minuten nur die Meldung, dass Fenster 2 geöffnet wurde.
Somit wird es nicht wirklich möglich sein das ganze entweder in einem DOIF zu machen, oder die Funktionen zu haben, wie du sie willst. Selbst, wenn du mittels "or" arbeiten wirst, sehe ich keine Lösung. Bzw die einzige wäre, dass du jeden Fall im DOIF genau beschreibst und anlegst, aber das wäre keine schöne und auch keine clevere Lösung, da du dich dumm und dämmlich schreibst. Dann würde ich lieber einfach beim watchdog bleiben, wenn dieser doch funktioniert, oder du musst auf meherere DOIF ausweichen, wenn es unbedingt DOIF sein soll.
Zitat von: Amenophis86 am 18 Oktober 2015, 18:04:49
Dann würde ich lieber einfach beim watchdog bleiben, wenn dieser doch funktioniert,...
In meinem generischen Watchdog kann ich leider nicht auf $NAME zugreifen und somit weiß ich leider nicht um welches Fenster es sich handelt. Und mehrere Watchdogs wollte ich auch nicht anlegen.
Danke noch für deine ausführliche Erklärung.
Zitat von: dancatt am 18 Oktober 2015, 18:26:27
In meinem generischen Watchdog kann ich leider nicht auf $NAME zugreifen und somit weiß ich leider nicht um welches Fenster es sich handelt. Und mehrere Watchdogs wollte ich auch nicht anlegen.
Danke noch für deine ausführliche Erklärung.
define di_fenster DOIF ([?Heizungmodus] eq "Winter" and ([2_02_KL_Fensterkontakt:?open] or [2_03_SZ_Fensterkontakt:?open] or [2_05_BZ_Fensterkontakt:?open]))
({PushMassage("Fhem","doif [di_fenster:Device]","",0,"")},{EximMail("test@test.de", "doif FHEM Überwachung: [di_fenster:Device]", "Fenster ist offen")})
attr di_fenster wait 300Allerdings sind mehrer Fenster, die gleichzeitig geöffnet werden (innerhalb von 300 Sekunden) kritisch zu sehen - es kann gleichzeitig nur ein Waittimer laufen.
Die sauberste Lösung ist tatsächlich, pro Fenster ein eigenes Modul (paste und copy) zu definieren.
Gruß
Damian
Zitat von: dancatt am 18 Oktober 2015, 18:26:27
In meinem generischen Watchdog kann ich leider nicht auf $NAME zugreifen und somit weiß ich leider nicht um welches Fenster es sich handelt. Und mehrere Watchdogs wollte ich auch nicht anlegen.
Danke noch für deine ausführliche Erklärung.
Ok, dachteder Watchdog hätte die Ansprüche zu 100% erfüllt. Dann bleibt wohl wirklich nur ein DOIF pro Fenster. Sry
Zitat von: Amenophis86 am 18 Oktober 2015, 19:37:45
Ok, dachteder Watchdog hätte die Ansprüche zu 100% erfüllt. Dann bleibt wohl wirklich nur ein DOIF pro Fenster. Sry
lieber ein DOIF mehr als eines zu wenig...! ;) :D ;) sind doch gut die Teile...!
Ich baue mir auch immer lieber ein DOIF dazu als alles in einem unterzubringen und da dann evtl. Fehlschaltungen zu haben :D
Zitat von: Damian am 18 Oktober 2015, 18:42:37
Die sauberste Lösung ist tatsächlich, pro Fenster ein eigenes Modul (paste und copy) zu definieren.
Das habe ich nun gemacht. Allerdings bekomme ich auch eine Meldung, wenn da Fenster innerhalb der 15 Minuten wieder geschlossen wird.
Fehlt mir da noch eine Definition eines Attributes?
Definition:
Internals:
CFGFN
DEF ([2_05_BZ_Fensterkontakt:?open] && [?Heizungmodus] eq "Winter")
({PushMassage("Fhem","doif 2_05_BZ_Fensterkontakt ist offen","",0,"")})
({EximMail("test\@test.de", "doif FHEM Überwachung: 2_05_BZ_Fensterkontakt", "Fenster ist offen")})
NAME doif_Ueberwachung_2_05_BZ_Fensterkontakt
NR 1025
NTFY_ORDER 50-doif_Ueberwachung
STATE cmd_1
TYPE DOIF
CHANGETIME:
Helper:
Dblog:
Cmd_event:
Dblog:
TIME 1445193369.45506
VALUE 2_05_BZ_Fensterkontakt
Cmd_nr:
Dblog:
TIME 1445193369.45506
VALUE 1
Cmd_seqnr:
Dblog:
TIME 1445193369.45506
VALUE 2
Error:
Dblog:
TIME 1445193369.45506
VALUE {EximMail("test\@test.de", "doif FHEM Überwachung: 2_05_BZ_Fensterkontakt", "Fenster ist offen")}: -1
State:
Dblog:
TIME 1445193369.45506
VALUE cmd_1
Wait_timer:
Dblog:
TIME 1445193369.01392
VALUE no timer
Readings:
2015-10-18 20:21:24 Device 2_05_BZ_Fensterkontakt
2015-10-18 20:36:09 cmd_event 2_05_BZ_Fensterkontakt
2015-10-18 20:36:09 cmd_nr 1
2015-10-18 20:36:09 cmd_seqnr 2
2015-10-18 20:21:24 e_2_05_BZ_Fensterkontakt_events battery: ok contact: closed (to VCCU) closed trigDst_VCCU: noConfig trigger_cnt: 98
2015-10-18 20:36:09 error {EximMail("test\@test.de", "doif FHEM Überwachung: 2_05_BZ_Fensterkontakt", "Fenster ist offen")}: -1
2015-10-18 20:36:09 state cmd_1
2015-10-18 20:36:09 wait_timer no timer
Condition:
0 EventDoIf('2_05_BZ_Fensterkontakt',$hash->{helper}{triggerDev},$hash->{helper}{triggerEvents},'open') && InternalDoIf('Heizungmodus','STATE','') eq "Winter"
Devices:
0 2_05_BZ_Fensterkontakt
all 2_05_BZ_Fensterkontakt
Do:
0:
0 {PushMassage("Fhem","doif 2_05_BZ_Fensterkontakt ist offen","",0,"")}
1 {EximMail("test\@test.de", "doif FHEM Überwachung: 2_05_BZ_Fensterkontakt", "Fenster ist offen")}
1:
Helper:
globalinit 1
last_timer 0
sleepdevice 2_05_BZ_Fensterkontakt
sleepsubtimer -1
sleeptimer -1
triggerDev 2_05_BZ_Fensterkontakt
triggerEvents:
battery: ok
contact: closed (to VCCU)
closed
trigDst_VCCU: noConfig
trigger_cnt: 98
Internals:
Itimer:
Readings:
State:
Timerfunc:
Trigger:
all 2_05_BZ_Fensterkontakt
Attributes:
do always
group Überwachung
room 9_09_Einstellungen
wait 900
Du kannst alles in ein DOIF bauen und für jede Fenster "offen" Kombination einen Bedingungszweig erstellen. Dann bestimmt allerdings des zuletzt geöffnete Fenster wann die 15 Minuten zu zählen beginnen.
F1 and F2 push "F1 und F2 sind offen"
F1 and !F2 push ...
!F1 and F2 push ...
Syntax verkürzt
Zitat von: dancatt am 18 Oktober 2015, 20:44:36
Das habe ich nun gemacht. Allerdings bekomme ich auch eine Meldung, wenn da Fenster innerhalb der 15 Minuten wieder geschlossen wird.
Fehlt mir da noch eine Definition eines Attributes?
Definition:
Internals:
CFGFN
DEF ([2_05_BZ_Fensterkontakt:?open] && [?Heizungmodus] eq "Winter")
({PushMassage("Fhem","doif 2_05_BZ_Fensterkontakt ist offen","",0,"")})
({EximMail("test\@test.de", "doif FHEM Überwachung: 2_05_BZ_Fensterkontakt", "Fenster ist offen")})
NAME doif_Ueberwachung_2_05_BZ_Fensterkontakt
NR 1025
NTFY_ORDER 50-doif_Ueberwachung
STATE cmd_1
TYPE DOIF
CHANGETIME:
Helper:
Dblog:
Cmd_event:
Dblog:
TIME 1445193369.45506
VALUE 2_05_BZ_Fensterkontakt
Cmd_nr:
Dblog:
TIME 1445193369.45506
VALUE 1
Cmd_seqnr:
Dblog:
TIME 1445193369.45506
VALUE 2
Error:
Dblog:
TIME 1445193369.45506
VALUE {EximMail("test\@test.de", "doif FHEM Überwachung: 2_05_BZ_Fensterkontakt", "Fenster ist offen")}: -1
State:
Dblog:
TIME 1445193369.45506
VALUE cmd_1
Wait_timer:
Dblog:
TIME 1445193369.01392
VALUE no timer
Readings:
2015-10-18 20:21:24 Device 2_05_BZ_Fensterkontakt
2015-10-18 20:36:09 cmd_event 2_05_BZ_Fensterkontakt
2015-10-18 20:36:09 cmd_nr 1
2015-10-18 20:36:09 cmd_seqnr 2
2015-10-18 20:21:24 e_2_05_BZ_Fensterkontakt_events battery: ok contact: closed (to VCCU) closed trigDst_VCCU: noConfig trigger_cnt: 98
2015-10-18 20:36:09 error {EximMail("test\@test.de", "doif FHEM Überwachung: 2_05_BZ_Fensterkontakt", "Fenster ist offen")}: -1
2015-10-18 20:36:09 state cmd_1
2015-10-18 20:36:09 wait_timer no timer
Condition:
0 EventDoIf('2_05_BZ_Fensterkontakt',$hash->{helper}{triggerDev},$hash->{helper}{triggerEvents},'open') && InternalDoIf('Heizungmodus','STATE','') eq "Winter"
Devices:
0 2_05_BZ_Fensterkontakt
all 2_05_BZ_Fensterkontakt
Do:
0:
0 {PushMassage("Fhem","doif 2_05_BZ_Fensterkontakt ist offen","",0,"")}
1 {EximMail("test\@test.de", "doif FHEM Überwachung: 2_05_BZ_Fensterkontakt", "Fenster ist offen")}
1:
Helper:
globalinit 1
last_timer 0
sleepdevice 2_05_BZ_Fensterkontakt
sleepsubtimer -1
sleeptimer -1
triggerDev 2_05_BZ_Fensterkontakt
triggerEvents:
battery: ok
contact: closed (to VCCU)
closed
trigDst_VCCU: noConfig
trigger_cnt: 98
Internals:
Itimer:
Readings:
State:
Timerfunc:
Trigger:
all 2_05_BZ_Fensterkontakt
Attributes:
do always
group Überwachung
room 9_09_Einstellungen
wait 900
Das verhindert die Ansage nach dem Schließen.
DOELSEIF ([Fenster] eq "closed") ()
Zitat von: dancatt am 18 Oktober 2015, 20:44:36
Das habe ich nun gemacht. Allerdings bekomme ich auch eine Meldung, wenn da Fenster innerhalb der 15 Minuten wieder geschlossen wird.
Fehlt mir da noch eine Definition eines Attributes?
Bei do always brauchst du noch ein DOELSE am Ende.
Gruß
Damian
Zitat von: Damian am 18 Oktober 2015, 21:03:03
Bei do always brauchst du noch ein DOELSE am Ende.
Danke. Das wars.
Gruß Daniel
Hey Damian,
könntest du auch mal die englische Commandref ergänzen?
Irgendwie doof wenn man auf "Device specific help" klickt und dann nur dasteht, dass in der deutschen Version Beispiele sind...
Danke :)
Zitat von: Virsacer am 20 Oktober 2015, 15:38:19
Hey Damian,
könntest du auch mal die englische Commandref ergänzen?
Irgendwie doof wenn man auf "Device specific help" klickt und dann nur dasteht, dass in der deutschen Version Beispiele sind...
Danke :)
Wenn ich mal dazu komme ... Ich habe schon vor längerer Zeit aufgegeben, bei den ständigen Erweiterungen des Moduls, beide Version zu pflegen. Immerhin sind alle Code-Beispiele in englisch.
Gruß
Damian
Zitat von: Virsacer am 20 Oktober 2015, 15:38:19
Hey Damian,
könntest du auch mal die englische Commandref ergänzen?
Irgendwie doof wenn man auf "Device specific help" klickt und dann nur dasteht, dass in der deutschen Version Beispiele sind...
Danke :)
Ja, die englische Version ist nicht sehr ergiebig, aber es würde auch schon sehr helfen, wenn die deutsche Version in der Gerätehilfe erscheinen würde.
Zitat von: Ellert am 20 Oktober 2015, 17:03:13
Ja, die englische Version ist nicht sehr ergiebig, aber es würde auch schon sehr helfen, wenn die deutsche Version in der Gerätehilfe erscheinen würde.
Ok, ich habe gerade gelernt, dass es ein globales Attribut language gibt, damit kann die bevorzugte Sprache eingestellt werden.
Es soll auf die englische Hilfe umgeleitet werden, wenn keine deutsche Hilfe verfügbar ist.
... wobei es sinnvoll wäre, dieses Attribut auch auszuwerten bei dem Commandref-Link auf der Hauptseite von der lokalen fhem-Installation.
Hi,
ich baue mir gerade einen Sleep Timer für kodi. Ziel ist folgendes
Sobald ich den Sleep Timer aktiviere, soll nach Ende der aktuellen Sendung der TV ausgeschaltet und kodi gestoppt werden. Ist kein EPG hinterlegt, so soll der TV und kodi nach 1h gestoppt werden.
Aktuell setze ich nur mal die erste Bedingung um
([+([{substr(ReadingsVal("kodi","totaltime",0),0,8)}]-[{substr(ReadingsVal("kodi","time",0),0,8)}]+[0:02:00])]
and [TVSleepMode] eq "on") (set kodi stop;set TVSleepMode off;set TV KEY_POWER)
Problem:
Wenn ich einmal den TVSleepMode aktiviere, wird die Endzeit berechnet. Schalte ich dann einen Sender um, so wird diese nicht neu berechnet obwohl sich [kodi:totaltime] ändert. Wie schaffe ich es, dass bei jeder [kodi:totaltime] Änderung der Perl Ausdruck neu berechnet wird?
Zitat von: dominik am 27 Oktober 2015, 20:17:39
Hi,
ich baue mir gerade einen Sleep Timer für kodi. Ziel ist folgendes
Sobald ich den Sleep Timer aktiviere, soll nach Ende der aktuellen Sendung der TV ausgeschaltet und kodi gestoppt werden. Ist kein EPG hinterlegt, so soll der TV und kodi nach 1h gestoppt werden.
Aktuell setze ich nur mal die erste Bedingung um
([+([{substr(ReadingsVal("kodi","totaltime",0),0,8)}]-[{substr(ReadingsVal("kodi","time",0),0,8)}]+[0:02:00])]
and [TVSleepMode] eq "on") (set kodi stop;set TVSleepMode off;set TV KEY_POWER)
Problem:
Wenn ich einmal den TVSleepMode aktiviere, wird die Endzeit berechnet. Schalte ich dann einen Sender um, so wird diese nicht neu berechnet obwohl sich [kodi:totaltime] ändert. Wie schaffe ich es, dass bei jeder [kodi:totaltime] Änderung der Perl Ausdruck neu berechnet wird?
Da wirst du einen Umweg über einen Dummy machen müssen, welchen du bei Änderung von kodi:total über substr belegst. Diesen Dummy kannst du dann in DOIF als Intervallgrenze angeben.
Übrigens: Trenner bei DOIF ist Komma und nicht Semikolon.
Gruß
Damian
Danke für die rasche Antwort Damian! Werde das mal so umsetzen.
Aus irgendeinen Grund habe ich bei mir überall Semikolon in Verwendung :-\ Funktionieren tuts, werde es aber korrigieren.
Gruß,
Dominik
Zitat von: dominik am 27 Oktober 2015, 20:56:39
Danke für die rasche Antwort Damian! Werde das mal so umsetzen.
Aus irgendeinen Grund habe ich bei mir überall Semikolon in Verwendung :-\ Funktionieren tuts, werde es aber korrigieren.
Gruß,
Dominik
Im Grunde funktionieren Semikolons auch. Um der Dopplungsproblematik aus dem Wege zu gehen, habe ich seiner Zeit das Komma bei IF und DOIF als Trennzeichen definiert.
Gruß
Damian
Hallo zusammen,
mir ist aufgefallen wenn ich mehrere Zwave Befehle in einen doif mit wait verzögern möchte, keine Werte kleiner 1 berücksichtigt werden.
Bsp.:
(set Lamp1 on)(set Lamp2 on)(set Lamp3 on)
wait 0,0.5,0.5
Hier werden alle 3 Befehle ohne Verzögerung ausgeführt.
Bei wait 0,1,1 gibt es keine Probleme. Laut Log hier 1 Sekunde Verzögerung.
Als Workaround habe ich jetzt sleep im Doif eingesetzt.
Das funktioniert sauber.
vg
Florian
Zitat von: FlorianZ am 03 November 2015, 19:09:37
Hallo zusammen,
mir ist aufgefallen wenn ich mehrere Zwave Befehle in einen doif mit wait verzögern möchte, keine Werte kleiner 1 berücksichtigt werden.
Bsp.:
(set Lamp1 on)(set Lamp2 on)(set Lamp3 on)
wait 0,0.5,0.5
Hier werden alle 3 Befehle ohne Verzögerung ausgeführt.
Bei wait 0,1,1 gibt es keine Probleme. Laut Log hier 1 Sekunde Verzögerung.
Als Workaround habe ich jetzt sleep im Doif eingesetzt.
Das funktioniert sauber.
vg
Florian
Ist offenbar bisher keinem aufgefallen. Habe es gerade gefixt. Morgen per Update verfügbar.
Gruß
Damian
Wow das nenne ich mal schnellen Support.
Vielen Dank
Gruß
Florian
Das es nicht aufgefallen ist, liegt wohl daran, das bis jetzt keiner auf die Idee kam, Befehle unter einer Sekunde aus zu führen ;-)
Weil 1 Sekunde als geringste Verzögerung reicht mir eigentlich...
Liegt es an meiner Programmierung, oder wieso geht der Wait Timer mit Random nicht? Habe das Wait wie folgt definiert:
wait rand(600):rand(600),0:0:0:0:0
Habe es so aus der Commandref bezüglich des random, aber irgendwie wird das random komplett ignoriert.
Zitat von: Amenophis86 am 12 November 2015, 20:27:09
Liegt es an meiner Programmierung, oder wieso geht der Wait Timer mit Random nicht? Habe das Wait wie folgt definiert:
wait rand(600):rand(600),0:0:0:0:0
Habe es so aus der Commandref bezüglich des random, aber irgendwie wird das random komplett ignoriert.
Bei mir nicht. Um mehr dazu sagen zu können, braucht man schon mehr Infos.
Gruß
Damian
Hier das zugehörige Doif:
([{sunset("HORIZON=-2.5",0,"20:00","22:00")}] and [WZ.Tuer.L] eq "closed" and [WZ.Tuer.R] eq "closed")
(set WR.Rollladen.Alle off)
DOELSEIF ([{sunset("HORIZON=-2.5",0,"20:00","22:00")}] and [?WZ.Tuer.L] ne "closed" and [?WZ.Tuer.R] ne "closed" and [?EZ.Rollladen] ne "off")
(set EZ.Rollladen off)
(set Pushover1 msg 'Rollladen Info' 'Wohnzimmer Rollläden nicht geschlossen, Tür noch geöffnet!')
DOELSEIF (([WZ.Tuer.L] eq "open" or [WZ.Tuer.R] eq "open") and [?WZ.Rollladen] ne "on")
(set WZ.Rollladen on)
DOELSEIF (([WZ.Tuer.L] eq "tilted" or [WZ.Tuer.R] eq "tilted") and [?WZ.Rollladen] eq "off")
(set WZ.Rollladen pct 25)
DOELSEIF ([WZ.Tuer.L] eq "closed" and [WZ.Tuer.R] eq "closed" and [?EZ.Rollladen] eq "off" and [?WZ.Rollladen] ne "off")
(set WZ.Rollladen off)
DOELSEIF ([{sunrise(0,"07:30","09:00")}] and [Gast.Uebernachtung] eq "off")
(set WR.Rollladen.Alle on)
Das Wait wird praktisch ignoriert und die Rollläden gehen trotzdem um 20uhr runter und nicht die random Zeit später.
Zitat von: Amenophis86 am 12 November 2015, 21:36:08
Hier das zugehörige Doif:
([{sunset("HORIZON=-2.5",0,"20:00","22:00")}] and [WZ.Tuer.L] eq "closed" and [WZ.Tuer.R] eq "closed")
(set WR.Rollladen.Alle off)
DOELSEIF ([{sunset("HORIZON=-2.5",0,"20:00","22:00")}] and [?WZ.Tuer.L] ne "closed" and [?WZ.Tuer.R] ne "closed" and [?EZ.Rollladen] ne "off")
(set EZ.Rollladen off)
(set Pushover1 msg 'Rollladen Info' 'Wohnzimmer Rollläden nicht geschlossen, Tür noch geöffnet!')
DOELSEIF (([WZ.Tuer.L] eq "open" or [WZ.Tuer.R] eq "open") and [?WZ.Rollladen] ne "on")
(set WZ.Rollladen on)
DOELSEIF (([WZ.Tuer.L] eq "tilted" or [WZ.Tuer.R] eq "tilted") and [?WZ.Rollladen] eq "off")
(set WZ.Rollladen pct 25)
DOELSEIF ([WZ.Tuer.L] eq "closed" and [WZ.Tuer.R] eq "closed" and [?EZ.Rollladen] eq "off" and [?WZ.Rollladen] ne "off")
(set WZ.Rollladen off)
DOELSEIF ([{sunrise(0,"07:30","09:00")}] and [Gast.Uebernachtung] eq "off")
(set WR.Rollladen.Alle on)
Das Wait wird praktisch ignoriert und die Rollläden gehen trotzdem um 20uhr runter und nicht die random Zeit später.
Dann kennst du offenbar noch nicht das Attribut
timerWithWait ;)
Gruß
Damian
In der Tat war mir dieses unbekannt. Das brauche ich also um bei wait ein random eizubauen. Schau an. Danke
PS. In der Commandref ist im Beispiel ein kleiner Fehler:
ZitatAnwendungsbeispiel: Lampe soll zufällig nach Sonnenuntergang verzögert werden.
define di_rand_sunset([{sunset()}])(set lamp on)
attr di_rand_sunset wait rand(1200)
attr di_rand_sunset timerWithWait
attr di_rand_sunset do always
Es fehlt das DOIF beim define. Gerade beim Nachlesen gesehen.
Zitat von: Amenophis86 am 12 November 2015, 22:40:27
In der Tat war mir dieses unbekannt. Das brauche ich also um bei wait ein random eizubauen. Schau an. Danke
PS. In der Commandref ist im Beispiel ein kleiner Fehler:
Es fehlt das DOIF beim define. Gerade beim Nachlesen gesehen.
Danke für die Info - wird beim nächsten Update korrigiert.
Gruß
Damian
Nun muß ich auch mal nach Brain-Hilfe schreien...
Ich habe meine Rolladen auch alle über mitlerweile ziehmlich gewachsene DOIF´s laufen. Aber hin und wieder verstehe ich die denkensweise des Moduls wohl nicht richtig.
Ich hatte gerade wieder den Fall, das 2 identisch Programmierte DOIF´s das eine mal den Rolladen am Abend runter fährt, und der andre Rolladen oben bleibt. Die beiden DOIF´s sehen aber völlig gleich aus:
([([AussenLux:sr_civil]+int(rand(300)))-10:00]
and [([05:50]+int(rand(900)))-10:00|8] and [?Sonnenschutz_Buero] == 0 and [?Status] ne "Gaeste"
or [([AussenLux:sr_civil]+int(rand(300)))-10:00]
and [([08:00]+int(rand(1800)))-10:00|7] and [?Sonnenschutz_Buero] == 0 and [?Status] ne "Gaeste"
or [Sonnenschutz_Buero] == 0 and [?RolloBuero:position] < 75)
(set RolloBuero off)
DOELSEIF ([Sonnenschutz_Buero] == 1 and [?RolloBuero:position] < 75) (set RolloBuero Sonne)
DOELSEIF ([([AussenLux:ss_civil]+int(rand(180)))])
(set RolloBuero on)
Zur Erklärung: "Aussenlux" = Twilight
Etwas abgespeckt und vielleicht für Euch übersichtlicher:
([([AussenLux:sr_civil]+int(rand(300)))-10:00]
and [([05:50]+int(rand(900)))-10:00|8]
(set RolloBuero off)
DOELSEIF ([([AussenLux:ss_civil]+int(rand(180)))])
(set RolloBuero on)
Komisch ist auch das es Tagelang funktioniert, und dann setz mal wieder ein Rollo aus. Ich verstehe das nicht ! hat das was mit den (rand...) einträgen zutun.
Kann mir mal einer auf die Sprünge helfen wo das Modul anders denkt als ich ?
---Skusi
Hallo Skusi,
was sagen die Logs ? Ich hatte es ähnlich und in den Logs wurde angezeigt das alles ausgeführt wird. Ursache war der CUL der etwas in der Position verändert war.
Gruß
Micha
In den logs gibts nichts was weiter hilft.
Der Status vom bertoffenen DOIF ist auch seit morgens unverändert "AUF"
Deshalb hab ich auch nicht weiter geforscht. Das DOIF wollte laut Status ja noch gar nicht runter fahren !?
---Skusi
Zitat von: Skusi am 15 November 2015, 19:45:46
In den logs gibts nichts was weiter hilft.
Du hast in der Bedingung zwei Intervalle jeweils mit einer Zufallskomponenten. Bist Du sicher, dass diese beiden Intervalle sich unter keinen Umständen gegenseitig ausschließen können?
Generell: Vielleicht definierst Du Dir mal ein Filelog für dieses DOIF. Da kannst Du auch im Nachhinein ganz gut nachvollziehen, warum das DOIF wann was getan hat.
Wenn Du Twilight-Events da auch noch mit reinloggst, hast Du alles an einer Stelle im zeitlichen Kontext. Vielleicht bringt Dich die Analyse dann weiter.
Hallo Damian,
kann das: http://forum.fhem.de/index.php/topic,10033.msg359955.html#msg359955 seine Ursache im DOIF haben?
Zitat von: Ralli am 17 November 2015, 07:24:10
Hallo Damian,
kann das: http://forum.fhem.de/index.php/topic,10033.msg359955.html#msg359955 seine Ursache im DOIF haben?
Das wird deine Problemzeile sein:
(set Sonos Groups [Sonos_Bad], [Sonos_Esszimmer], [Sonos_Kind1], [Sonos_Schlafzimmer], [Sonos_Kind2]) Komma ist ein Trenner in DOIF, daher musst du den Ausdruck in zusätzliche Klammern packen.
((set Sonos Groups [Sonos_Bad], [Sonos_Esszimmer], [Sonos_Kind1], [Sonos_Schlafzimmer], [Sonos_Kind2]))Gruß
Damian
Danke 8) - da habe ich nicht dran gedacht.
Hallo Brockmann,
ich habe nun einen FileLog für alle Rolladen DOIF´s mitlaufen lassen. Heute fuhr wieder ein anderer nicht zu bei Twilight:ss_civil. Das DOIF tauchte im gegensatz zu den anderen in dem Log gar nicht erst auf. Die cmd 3 Zeile ist aber bei allen DOIF´s gleich. 3 Rolladen reagieren darauf und einer (immer mal eine anderer) bleiben auf Status "off" von dem Morgen Timer auf cmd 1 stehen.
Ich versteh das nicht.
Alle DOIF´s haben
DOELSEIF ([([AussenLux:ss_civil]+int(rand(180)))])
(set RolloBuero on)
als letzte Bedingung. Warum geht das an einem Tag und an einem anderen wieder nicht ?
Die beiden Bedingungen am Anfang:
([([AussenLux:sr_civil]+int(rand(300)))-10:00]
and [([05:50]+int(rand(900)))-10:00|8]
sollen bewirken das die Rolladen erst aufgehen wenn
a. die Sonne "ungefähr" aufgegangen ist
und
b. nicht vor "ungefähr" 05:50 Uhr
Das "ungefähr" soll verhindern das alle Rolladen im Winter bei Sonnenaufgang exakt gleichzeitig auffahren. Und das "ungefähr" bei der 2. Bedingung das sie im Sommer nicht alle gleichzeitig öffnen, sonder immer leicht unterschiedlich in zufälliger Reihenfolge.
Aber mein Problem ist ja eigentlich die 3. Bedingung fürs Abendliche zufahren.
Hab ich da was mit dem Triggern falsch verstanden ? Muß AussenLux:ss_civil auch in der ersten Bedingung stehen damit das DOIF überhaupt triggert ?
Aber ich will ja bei morgendlichen Auffahren nicht den Sonnenuntergang abfragen.
Ich bin verwirrt....
---Skusi
Zitat von: Skusi am 18 November 2015, 18:27:04
als letzte Bedingung. Warum geht das an einem Tag und an einem anderen wieder nicht ?
Die beiden Bedingungen am Anfang:
([([AussenLux:sr_civil]+int(rand(300)))-10:00]
and [([05:50]+int(rand(900)))-10:00|8]
Zwei Intervalle, die mit AND verknüpft sind, machen eigentlich wenig Sinn. Die Bedingung ist nur dann wahr, wenn sie sich überschneiden. Normalerweise werden Intervalle mit OR verknüpft, um unterschiedliche Zeitintervalle, die sich normalerweise nicht überschneiden, anzugeben.
Gruß
Damian
Zitat von: Skusi am 18 November 2015, 18:27:04
Hab ich da was mit dem Triggern falsch verstanden ? Muß AussenLux:ss_civil auch in der ersten Bedingung stehen damit das DOIF überhaupt triggert ?
Nein. Wann immer das Device AussenLux ein Event generiert, wird jedes DOIF getriggert, wo [AussenLux...] als Bedingung aufgeführt wird. Es werden alle Bedingungen (und nur die), die dieses Device enthalten überprüft und die erste Bedingung gewählt, die zutrifft. Wenn eines der DOIF darauf nicht reagiert, obwohl eine Bedingungen erfüllt sein müsste, liegt es nahe, dass es sich bereits in diesem Zustand befand und deshalb nicht reagiert. Denn eine Aktion erfolgt nur bei einem Zustandswechsel des Moduls (es sei denn, Du hast do always gesetzt, was bei Deinem Szenario aber eher unwahrscheinlich ist).
Du solltest mal in dem Moment (bzw. unmittelbar nachdem) ein solches vermeintliches "Fehlverhalten" eines DOIF aufgetreten ist, ein list <Name des DOIFs> machen und das Ergebnis hier posten (bzw. Dir erstmal selbst anschauen). Das erklärt in den meisten Fällen, warum das Modul sich so verhält wie es das tut.
Hallo Brockmann,
ZitatWann immer das Device AussenLux ein Event generiert, wird jedes DOIF getriggert, wo [AussenLux...] als Bedingung aufgeführt wird.
Ich habe beim Twilight einige readings im event-on-change-reading eingetragen, weil es mir sonst zu geschwätzig ist. Die Zeiten fur ss_civil werden dann aber doch trotzdem bei jedem der zugelassenen readings Events aktualisiert an das DOIF übergeben - oder ? Muß das ss_civil reading auch mit in event-on-change-reading sethen ?
Die Timer im DOIF sind allerdings immer richtig gesetzt.
ZitatWenn eines der DOIF darauf nicht reagiert, obwohl eine Bedingungen erfüllt sein müsste, liegt es nahe, dass es sich bereits in diesem Zustand befand und deshalb nicht reagiert
Das DOIF befindet sich definitiv immer im Zustand cmd_1 also Rolladen morgens hoch, wenn es nicht zu ss_civil (cmd_3) runtergefahren ist.
@Damian
ZitatZwei Intervalle, die mit AND verknüpft sind, machen eigentlich wenig Sinn. Die Bedingung ist nur dann wahr, wenn sie sich überschneiden. Normalerweise werden Intervalle mit OR verknüpft, um unterschiedliche Zeitintervalle, die sich normalerweise nicht überschneiden, anzugeben.
Das ist ja auch so gewünscht. Erst wenn interval 2 in den Interval 1 fällt, sollen die Roladen hoch fahren. Ich weiß das ist eine ziehmlich hässliche Lösung, aber ich hatte keine Idee verhindern kann das im Sommer die Dinger schon um 4:00 hochfahren wenn ich noch schlafe.
---Skusi
Zitat von: Skusi am 19 November 2015, 19:02:01
Ich habe beim Twilight einige readings im event-on-change-reading eingetragen, weil es mir sonst zu geschwätzig ist. Die Zeiten fur ss_civil werden dann aber doch trotzdem bei jedem der zugelassenen readings Events aktualisiert an das DOIF übergeben - oder ? Muß das ss_civil reading auch mit in event-on-change-reading sethen ?
Die Timer im DOIF sind allerdings immer richtig gesetzt.
Im Grunde genommen ist es in Deinem Fall egal, weil Twilight ja gar nicht als Trigger verwendet wird. Es wird nur zum Bestimmen eines Zeitpunkts verwendet, der dann als Trigger dient. Da spielt es keine Rolle, welche Events Twilight generiert. Die Timer werden unabhängig davon berechnet, wann immer das DOIF getriggert (oder ausgeführt?) wird. Und soweit klappt es ja auch, wie Du schreibst.
Ansonsten wie schon gesagt: Mach ein list <Name des DOIFs>, nachdem es nicht wie gedacht funktioniert hat. Am Besten gleich noch ein list des anderen DOIFs, das wie gewünscht arbeitet. Dann hast Du den direkten Vergleich und erkennst vermutlich, warum das eine tut und das andere nicht. Oder Du postest die beiden lists hier, dann brauchen wir keinen Kaffeesatz mehr zu lesen. ;)
Zitat von: Toto1973 am 25 September 2015, 11:11:54
....
Im DOIF selbst bei den Uhrzeiten steht das hier: timer_1_c1 26.09.2015 11:05:00|[tag]
Sollte da nicht die Zahl aus dem Dummy angezeigt werden?
....
Hallo.
Ich habe heute meine Timer umgebaut und genau obiges zitiertes tritt bei mir auch auf. Konnte bisher keine Lösung finden.
Einziger Unterschied ist, das es bei mir nur einen Dummy gibt, in dem alle relevanten Daten (Schaltzeiten, Gerät, Wochentag) als reading vorliegen.
Folgend ist mein DOIF definiert:
( [zsu_01:state] eq "aktiviert" and [[zsu_01:on_time]|[zsu_01:on_day_nr]] )
(set ([zsu_01:device_name]) on)
DOELSEIF
( [zsu_01:state] eq "aktiviert" and [[zsu_01:off_time]|[zsu_01:off_day_nr]] )
(set ([zsu_01:device_name]) off)
und das sagt der timer:
timer_1_c1 22.02.2016 18:40:00|[zsu_01:on_day_nr]
timer_2_c2 22.02.2016 18:50:00|[zsu_01:off_day_nr]
Funktionieren tut es wunderbar nur sieht es unschön aus wenn man sich das timer-reading als Status anzeigen lassen möchte.
Wo liegt mein Fehler?
MfG
P.S. Sorry, sehe gerade das es hier um "sleep" geht aber bin durch die Suche genau hier gelandet.
Zitat von: spikeh1 am 22 Februar 2016, 18:52:45
Hallo.
Ich habe heute meine Timer umgebaut und genau obiges zitiertes tritt bei mir auch auf. Konnte bisher keine Lösung finden.
Einziger Unterschied ist, das es bei mir nur einen Dummy gibt, in dem alle relevanten Daten (Schaltzeiten, Gerät, Wochentag) als reading vorliegen.
Folgend ist mein DOIF definiert:
( [zsu_01:state] eq "aktiviert" and [[zsu_01:on_time]|[zsu_01:on_day_nr]] )
(set ([zsu_01:device_name]) on)
DOELSEIF
( [zsu_01:state] eq "aktiviert" and [[zsu_01:off_time]|[zsu_01:off_day_nr]] )
(set ([zsu_01:device_name]) off)
und das sagt der timer:
timer_1_c1 22.02.2016 18:40:00|[zsu_01:on_day_nr]
timer_2_c2 22.02.2016 18:50:00|[zsu_01:off_day_nr]
Funktionieren tut es wunderbar nur sieht es unschön aus wenn man sich das timer-reading als Status anzeigen lassen möchte.
Wo liegt mein Fehler?
MfG
P.S. Sorry, sehe gerade das es hier um "sleep" geht aber bin durch die Suche genau hier gelandet.
ja, es war programmtechnisch am einfachsten umzusetzen, denn getriggert wird jeden Tag und erst zum Triggerzeitpunkt wird das Reading ausgewertet. Andernfalls müsste ich auf Änderungen des Readings im Modul reagieren und jeweils die Anzeige anpassen und das wäre aufwändiger zu programmieren gewesen.
Gruß
Damian
Ok, also ist das so gewollt. War beim Umstellen schon am Verzweifeln, das dort nie der Wochentag angezeigt wurde, sondern immer nur der Name des Readings.
Das es funktionierte merkte ich nur durch Zufall. :)
Danke Dir für die schnelle Antwort.
MfG
Hallo Damian,
sorry dass ich diesen alten Thread hervorkrame aber er enthält ein Feature-Request, das ich auch gut fände.
Ich konnte weder in der Commandref noch in einem anderen Thread etwas aktuelles zur Datumssteuerung finden.
Zitat von: Damian am 15 Juli 2015, 08:46:39
3) Datumsangaben (aufwändig)
Datumsangaben mit Uhrzeit (mit Triggerung bzw. ohne Triggerung mit Fragezeichen wie bisher) [YYYY-MM-TT HH:MM[:SS]] oder [MM-TT HH:MM[:SS]] oder [TT HH:MM[:SS]]
Beispiel
[2015-10-30 10:00] oder [10-30 10:00] oder [30 10:00] oder Zeitintervalle [2015-10-30 10:00 - 2016-10-30 10:00] oder vom 1. September 10 Uhr bis zum ersten April 20:00 Uhr [09-01 10:00 - 04-01 20:00] oder vom ersten 10:00 Uhr bis 15. 20:00 Uhr [-01 10:00 - -15 20:00]
Datumsangaben ohne Zeitangabe: [YYYY-MM-TT] oder [MM-TT] oder [MM-] oder [-TT].
Bespiel: An meinem Geburtstag [02-26], nur im Februar [02-], immer am 15. des Monats [-15]
Beispiel mit Intervallen: Heizung soll laufen von September bis April [09- - 04-] oder vom 15.09 bis zum 30.04 [09-15 - 04-30]
(das "bis-Zeichen" muss dann mit Leerzeichen angegeben werden)
Gibt es schon pläne, ob solch eine Datumsfunktion kommt.
Die einfache Abfrage von Zeiträumen in DOIF ist es, was dieses Modul u.a. so genial macht - das war für mich immer viel Arbeit davor, zu prüfen, ob eine Aktion in einem gewünschten Zeitfenster liegt...
Mit Datum wäre das "Schweizer Taschenmesser DOIF" noch mächtiger - will z.B. immer in der Nacht auf den ersten Mai bestimmte Leuchten nicht schon um 01 Uhr nachts ausschalten, sondern erst um 05 Uhr.
Gelöst habe ich es basierend auf einem anderen Foreneintrag jetzt so - geht auch, aber mit Datumsfenster wäre das noch genialer.
([01:00|7] and ($month <> 5 and $mday <> 1))
(IF ([Bad1DaemmerungsgesteuertChkBox] eq "on") (set NAME=PollinZufall3Bad:FILTER=STATE=on off))
(IF ([Kind1DaemmerungsgesteuertChkBox] eq "on") (set NAME=PollinZufall2Kind:FILTER=STATE=on off))
({Log 3, "doif nicht am 01.05. um 01 Uhr ausgefuhert"})
DOELSEIF ([05:00|7] and ($month == 5 and $mday == 1))
(IF ([Bad1DaemmerungsgesteuertChkBox] eq "on") (set NAME=PollinZufall3Bad:FILTER=STATE=on off))
(IF ([Kind1DaemmerungsgesteuertChkBox] eq "on") (set NAME=PollinZufall2Kind:FILTER=STATE=on off))
({Log 3, "doif am 01.05. um 05 Uhr ausgefuhert"})
Viele Grüße,
Heiko
Zitat von: heikoh81 am 01 Mai 2016, 09:42:00
Hallo Damian,
sorry dass ich diesen alten Thread hervorkrame aber er enthält ein Feature-Request, das ich auch gut fände.
Ich konnte weder in der Commandref noch in einem anderen Thread etwas aktuelles zur Datumssteuerung finden.
Gibt es schon pläne, ob solch eine Datumsfunktion kommt.
Die einfache Abfrage von Zeiträumen in DOIF ist es, was dieses Modul u.a. so genial macht - das war für mich immer viel Arbeit davor, zu prüfen, ob eine Aktion in einem gewünschten Zeitfenster liegt...
Mit Datum wäre das "Schweizer Taschenmesser DOIF" noch mächtiger - will z.B. immer in der Nacht auf den ersten Mai bestimmte Leuchten nicht schon um 01 Uhr nachts ausschalten, sondern erst um 05 Uhr.
Gelöst habe ich es basierend auf einem anderen Foreneintrag jetzt so - geht auch, aber mit Datumsfenster wäre das noch genialer.
([01:00|7] and ($month <> 5 and $mday <> 1))
(IF ([Bad1DaemmerungsgesteuertChkBox] eq "on") (set NAME=PollinZufall3Bad:FILTER=STATE=on off))
(IF ([Kind1DaemmerungsgesteuertChkBox] eq "on") (set NAME=PollinZufall2Kind:FILTER=STATE=on off))
({Log 3, "doif nicht am 01.05. um 01 Uhr ausgefuhert"})
DOELSEIF ([05:00|7] and ($month == 5 and $mday == 1))
(IF ([Bad1DaemmerungsgesteuertChkBox] eq "on") (set NAME=PollinZufall3Bad:FILTER=STATE=on off))
(IF ([Kind1DaemmerungsgesteuertChkBox] eq "on") (set NAME=PollinZufall2Kind:FILTER=STATE=on off))
({Log 3, "doif am 01.05. um 05 Uhr ausgefuhert"})
Viele Grüße,
Heiko
Diese Features habe ich erst mal zurückgestellt, da der Aufwand für die Entwicklung eines dazugehörigen Parsers, wegen der zunehmender Komplexität in der Syntax, nicht unerheblich ist - alles Bisherige soll ja weiterhin fehlerfrei funktionieren. Da muss man sich erst mal mit $month und $mday behelfen, obwohl die Lesbarkeit der Definition durchaus vertretbar ist.
Gruß
Damian
Ok, danke, alles klar.
Hallo,
habe ein kleinen Problem mit wait
Wenn ich z.B. " attr Test_BEW wait 0,6 " in die Befehlsteile eingebe ist alles OK.
Test_Bew kriegt das Attribute wait 0,6
Will ich das Test_Bew wait durch einen Event ("Butt") in einem DOIF ändern
DEF:
([Butt])
(attr Test_BEW wait 0,6)
kommt nur
Test_Bew wait 0
raus.
(war am 9.März schon mal eine Thema, sollte aber mit dem neuen Update weg sein, "Komma als Trennzeichen")
Bin Update Aktuell(Heute Morgen)
Was mache ich falsch?
Viele Grüße und danke für das SUPER DOIF,
Rob
Zitat von: Robert1963 am 11 Mai 2016, 08:31:37
Hallo,
habe ein kleinen Problem mit wait
Wenn ich z.B. " attr Test_BEW wait 0,6 " in die Befehlsteile eingebe ist alles OK.
Test_Bew kriegt das Attribute wait 0,6
Will ich das Test_Bew wait durch einen Event ("Butt") in einem DOIF ändern
DEF:
([Butt])
(attr Test_BEW wait 0,6)
kommt nur
Test_Bew wait 0
raus.
(war am 9.März schon mal eine Thema, sollte aber mit dem neuen Update weg sein, "Komma als Trennzeichen")
Bin Update Aktuell(Heute Morgen)
Was mache ich falsch?
Viele Grüße und danke für das SUPER DOIF,
Rob
([Butt])
((attr Test_BEW wait 0,6))
Ein Komma ist nur dann geschützt, wenn es innerhalb von irgendwelchen Klammern vorkommt.
Du kannst ebenfalls die wait-Angabe in ein Reading oder Dummy ablegen und dieses in eckigen Klammern bei wait angeben.
Gruß
Damian
Perfekt!!! :)
Vielen Dank für die schnelle Hilfe
ich hoffe hier ist nix eingeschlafen. ich bräuchte mal eure hilfe. ich möchte gerne das der 2. befehl zeitverzögert schaltet und ich bekomme es einfach nicht hin. ist bestimmt ne klammerngeschichte.
([RF:"1"]) ({GetHttpFile ("192.168.178.21:8080","/raumserver/controller/leaveStandby?id=Wohnzimmer&scope=room")},({GetHttpFile ("192.168.178.21:8080","/raumserver/controller/loadPlaylist?id=Wohnzimmer&value=Line%20in")}))
danke für die hilfe
Die Ausführngsteile in eigene Klammern () und dann das Wait Attribut.
(Bedingung) (Ausführung 1) (Ausführung 2)
Attribut wait 0,5
Ausführung 1 sofort, Ausführung 2 nach 5 sek
Zitat von: Frank_Huber am 12 März 2018, 16:54:08
Die Ausführngsteile in eigene Klammern () und dann das Wait Attribut.
(Bedingung) (Ausführung 1) (Ausführung 2)
Attribut wait 0,5
Ausführung 1 sofort, Ausführung 2 nach 5 sek
hab jetzt überall nochmal ne klammer gesetzt, aber der zündet nur den ersten :-\
([RF:"1"]) (({GetHttpFile ("192.168.178.21:8080","/raumserver/controller/leaveStandby?id=Wohnzimmer&scope=room")}),(({GetHttpFile ("192.168.178.21:8080","/raumserver/controller/loadPlaylist?id=Wohnzimmer&value=Line%20in")})))edit:ich habs hinbekommen, das komma zwischen den befehlen kommt raus.
danke 8)