Hallo,
ich möchte gerne folgendes Szenario abbilden:
Die Lampe in der Küche soll angehen und auch anbleiben, wenn das Radio an ist (STATE:ON).
Wenn das Radio nicht an ist, soll das Licht nur angehen, wenn der Bewegungsmelder (Homematic) Bewegung erkennt.
Das Licht soll dann ausgehen, wenn der Bewegungsmelder seit 5 Minuten keine Bewegung erkannt hat.
Ich hatte das mal mit einem Watchdog versucht - klappte aber nicht wirklich zufriedenstellend.
Das sollte doch auch mit einem DOIF möglich sein? - ODer?
Hier mal mein aktuelles DOIF:
([SB_Kueche] eq "on") (set eg.ku.fs.lampe_fenster on) DOELSEIF
([HM_BWGM_KUECHE:state] eq "motion") (set eg.ku.fs.lampe_fenster on) DOELSE
(set eg.ku.fs.lampe_fenster off)
Danke.
Gruß
Hermann
Zitat von: hermann1514 am 21 November 2016, 10:50:31
Das sollte doch auch mit einem DOIF möglich sein? - ODer?
Ja. Hast Du es denn schon ausprobiert ?
Syntax selbst sie ok aus.
Zitat von: kumue am 21 November 2016, 12:55:31Syntax selbst sie ok aus.
Wobei sich die beiden ersten Fälle zusammenfassen ließen.
Ansonsten sind die HM-Bewegungsmelder ausreichend oft Thema bei DOIF gewesen, um zu sehen, wie mit deren Events umgegangen werden muss.
Danke,
im Moment ist es so dass das Licht angeht wenn das Radio an ist.
Soweit so gut. Wenn jedoch jetzt eine Bedingung "Bewegung erkannt" wird und nach 4 Minuten keine weitere Bewegung, dann schaltet sich das Licht ab obwohl das Radio angeschaltet ist.
Das sollte doch nicht sein - oder?
Gruß
Hermann
Warum eigentlich kein simples notify auf den Bewegungsmelder?
Dann ein IF: Ist das Radio an -> Licht einschalten, ELSE per defmod ein at mit +4 Minuten zum ausmachen.
Wird dazwischen weiter getriggert, verschiebt sich das at wieder usw.. Man müßte nur das at wieder löschen für den Fall, dass in den 4 Minuten jemand das Radio anmacht. Aber auch das könnte man abfangen, wenn man das notify auch mit einer 2. Bedingung (Radio geht an) triggert und evtl. mehr Abragezweige in den Ausführungsteil einbaut.
Oder ist das zu einfach gedacht?
Gruß, Beta-User
Es gibt sicherlich mehrere Wege. Aber ich möchte gerne DOIF nutzen, da ich dies als ein mächtiges Tools sehe. Um dann später mal alles einheitlich zu haben würde ich wenn es geht alles über DOIF's steuern.
Absolut richtig: DOIF ist sehr mächtig.
Es hat nur den Nachteil, dass die Zahl der Optionen und vor allem der Kombinationsmöglichkeiten der Optionen sehr groß ist.
Daher wollte ich nur darauf hinweisen, dass es auch andere Möglichkeiten gibt, Dein Problem zu lösen. Aber da Du das offenslichtlich weißt, bitte ich um Verzeihung für den freundlich gemeinten Hinweis.
Gruß,
Beta-User
hi,
ich würde es so machen:
([SB_Kueche] eq "on" or [HM_BWGM_KUECHE:state] eq "motion") (set eg.ku.fs.lampe_fenster on)
DOELSE (set eg.ku.fs.lampe_fenster off)
dein Problem sind die Trigger.
SB_Kueche triggert das "on" einmal. Dann schaltet sich das Licht ein. Triggert dann der Bewegungsmelder gehts bei deinem DOIF in den DOELSEIF-Fall. nach 4 Minuten triggert der Bewegungsmelder, dass er keine Bewegung erkannt hat. Der DOELSEIF-Fall ist also nicht mehr wahr. Da SB_Kueche aber nicht nochmal. Somit wird in den DOELSE-Fall gegangen.
Fragst du alles in einer Bedingung ab, so wird die gesamte Bedingung gecheckt, wenn eines der Devices triggert.
Alternativ kannst du das Attribut checkall setzen. Ich glaub das ist aber noch nicht offiziell.
Gruß Michael
Zitat von: hermann1514 am 21 November 2016, 10:50:31
([SB_Kueche] eq "on") (set eg.ku.fs.lampe_fenster on) DOELSEIF
([HM_BWGM_KUECHE:state] eq "motion") (set eg.ku.fs.lampe_fenster on) DOELSE
(set eg.ku.fs.lampe_fenster off)
Es sollte am Ende nicht DOELSE heißen, sondern da gehört noch eine doppelte Abfrage hin: Radio ist aus ohne Trigger "[?...]" und Bewegungsmelder auch "off", ggf. noch in Verbindung mit einem Wait-Attribut, je nachdem wie lange der Bewegungsmelder braucht, um ein off zu senden. DOELSE dann wieder ohne Ausführungscode ans Ende.
Zitat von: l2r am 21 November 2016, 14:57:41
([SB_Kueche] eq "on" or [HM_BWGM_KUECHE:state] eq "motion") (set eg.ku.fs.lampe_fenster on)
DOELSE (set eg.ku.fs.lampe_fenster off)
So geht das Licht aber auch an, wenn man das Radio anmacht, oder ;). Wird wohl eher nicht gewünscht sein....
ähm doch?? ist doch die erste Bedingung?
Zitat von: l2r am 21 November 2016, 15:15:39
ähm doch?? ist doch die erste Bedingung?
Ganz am Anfang schrieb der TE: "wenn das Radio an ist (STATE:ON)." Dein Vorschlag fragt aber doch ab, ob das Radio in den Zustand "on"
wechselt und triggert damit genauso wie der Bewegungsmelder. Triggern sollte aber doch nur letzterer, oder habe ich das falsch verstanden?
Na ja, DOIF ist wirklich einfach ;D, wenn man weiß, was man eigentlich machen will und in welcher Reihenfolge welche Bedingungen zuschlagen sollen bzw. abgefragt werden.
ja ok, kann man so interpretieren. Ich hab mich da vllt. ein bisschen zu nah an dem Code gehalten, weil er da ja abfragt ob das Radio in den State on wechselt und er mit diesem Teil keine Probleme hatte...
[?SB_Kueche] eq "on" or [HM_BWGM_KUECHE:state] eq "motion") (set eg.ku.fs.lampe_fenster on)
DOELSE (set eg.ku.fs.lampe_fenster off)
So wäre es dann nicht triggernd...;)
Andererseits weiß ich nicht wie er das Radio anschaltet, falls manuell, dann sollte zwangsläufig auch ne Bewegung erkannt worden sein ;-)
Stimmt irgendwie auch, die Eingangsbedingung mit dem Radio war ja erst drin.
Also munteres Weiterraten, es müßte also insgesamt so aussehen:
([HM_BWGM_KUECHE:state] eq "motion") (set eg.ku.fs.lampe_fenster on) DOELSEIF ([HM_BWGM_KUECHE:state] ne "motion" and
[?SB_Kueche] ne "on") (set eg.ku.fs.lampe_fenster off) DOELSE
Evtl. kann man den SB_Kueche auch triggernd nach "off" abfragen, dann geht das Licht (vielleicht besser nach einem wait) aus, wenn man das Radio ausmacht. Aber fragt mich nicht nach den waits, do always etc.
DOELSE kannst du auch weglassen und wenn du schon nach ne "on" fragst, dann würde ich das auch triggernd machen...
mit wait wäre es dann
attr XXX wait 0:120 für 2 min wait.
DO always wird nicht benötigt.
Zitat von: l2r am 21 November 2016, 16:12:05
DOELSE kannst du auch weglassen
Irgendwie habe ich mir das angewöhnt, DOIF grundsätzlich immer in einen definierten Zustand (hier: cmd_3) zu schicken, wenn irgendwann zwischenzeitlich keiner der definierten Zustände eintreten kann. Das macht es m.E. leichter, wenn man später irgendwelche Änderungen macht, von denen man eigentlich annimmt, dass sie problemlos wären, die aber halt doch das Triggerverhalten ändern. Und: schaden tut es selten, fehlt es, ist man versucht, evtl. ein "do always" zu setzen.
Und übrigens: Es ist nicht mein DOIF, ich brauche nichts wegzulassen ;). Ich werde eher zukünftig mal die paar DOIF, die ich definiert habe, in andere Syntax umwandeln. Das verstehe ich so langsam aber sicher besser, jedenfalls dann, wenn ich mir Gedanken gemacht habe, was ich eigentlich in welcher Abhängigkeit schalten will...
mit dem leeren DOELSE wird aber zum Beispiel jedes mal der set-Befehl ausgeführt, wenn der Bewegungsmeldet motion triggert. Ist dann halt ein bisschen zusätzliche Last. Im Einzelfall zu vernachlässigen, aber Kleinvieh macht bekanntlich ja auch mist. Ein Fall wo es zu unschönem Verhalten führen kann ist, wenn man im Set-Befehl zb. eine Playlist startet. Diese würde dann jedes mal geladen und gestartet werden. Führt dann zu unschönen rucklern... ;)
DOELSE und attr do always machen in den meisten Fällen das gleiche...
Zitat von: l2r am 21 November 2016, 16:46:02
mit dem leeren DOELSE wird aber zum Beispiel jedes mal der set-Befehl ausgeführt, wenn der Bewegungsmeldet motion triggert. Ist dann halt ein bisschen zusätzliche Last. Im Einzelfall zu vernachlässigen, aber Kleinvieh macht bekanntlich ja auch mist. Ein Fall wo es zu unschönem Verhalten führen kann ist, wenn man im Set-Befehl zb. eine Playlist startet. Diese würde dann jedes mal geladen und gestartet werden. Führt dann zu unschönen rucklern... ;)
DOELSE und attr do always machen in den meisten Fällen das gleiche...
Es ist schon gut sich vorher Gedanken zu machen ob ein leeres DOELSE angegeben wird oder nicht. Denn durch die Angabe des DOELSE wird ein Zustandwechsel provoziert, der manchmal aber nicht immer erwünscht ist.
Oha....ist ja ne ganz schöne Diskussion geworden. :o :o
Nun,
erstmal zu Beta USer:
ZitatDaher wollte ich nur darauf hinweisen, dass es auch andere Möglichkeiten gibt, Dein Problem zu lösen. Aber da Du das offenslichtlich weißt, bitte ich um Verzeihung für den freundlich gemeinten Hinweis.
Danke für den Hinweis....sollte nicht als meckern verstanden werden ;)
Und ja - wenn ich das Radio einschalte wird ja eine Bewegung erzeugt.
Ich werde mal die diversen Vorschläge testen.
Vielen Dank für Eure Hilfe.
Gruß
Hermann
Zitat von: hermann1514 am 22 November 2016, 08:53:36
Danke für den Hinweis....sollte nicht als meckern verstanden werden ;)
Kein Problem ;). Dein Ansatz, die Funktionalität erst mal komplett verstehen zu wollen, ist auf alle Fälle gut!!!
Hier im Forum gibt es nach meinem persönlichen Empfinden zu viele Beiträge von Leuten, die sich unbedacht auf DOIF stürzen und dann völlig erschlagen sind von den vielen Möglichkeiten. Bei meinem Start mit FHEM hab' ich's genauso gemacht und empfinde das heute als Fehler: Die DOIF's haben nach einem kurzen Test funktioniert und ich habe mich dann lange nicht mehr damit beschäfitgt, ob sie wirklich tun, was ich eigentlich möchte. Jezt gehe ich das alles nochmal durch und stelle fest: Das funktioniert meistens, aber leider nicht immer...
Na jedenfalls habe ich gestern abend mal ein paar DOIF's durch einfache norify's ersetzt (in Verbindung mit IF ... ELSE ..., das liest sich einfacher als perl-if-Code) und das ganze dabei noch verdichtet. Also vorher: 2 notify + 4 DOIF für bestimmte Funktionalitäten
Jetzt: 3 notify und ich habe auch noch einen Fehler eleminiert ;D (den will ich aber nicht dem Modul anlasten :D)
Verbleiben noch 18 DOIF... Nochmal 4 dürften einfach sein, dann muß ich mich mal an Stichworte wie defmod und evtl. weekdaytimer ranwagen, um das in den Griff zu kriegen, was mit Wiederholungen zu tun hat oder Zeiträumen, innerhalb derer bestimmte Schaltvorgänge stattfinden sollen. Da ist DOIF wirklich komfortabel!
Gruß,
Beta-User
Zitat von: Beta-User am 22 November 2016, 09:31:53
Kein Problem ;). Dein Ansatz, die Funktionalität erst mal komplett verstehen zu wollen, ist auf alle Fälle gut!!!
Hier im Forum gibt es nach meinem persönlichen Empfinden zu viele Beiträge von Leuten, die sich unbedacht auf DOIF stürzen und dann völlig erschlagen sind von den vielen Möglichkeiten. Bei meinem Start mit FHEM hab' ich's genauso gemacht und empfinde das heute als Fehler: Die DOIF's haben nach einem kurzen Test funktioniert und ich habe mich dann lange nicht mehr damit beschäfitgt, ob sie wirklich tun, was ich eigentlich möchte. Jezt gehe ich das alles nochmal durch und stelle fest: Das funktioniert meistens, aber leider nicht immer...
Na jedenfalls habe ich gestern abend mal ein paar DOIF's durch einfache norify's ersetzt (in Verbindung mit IF ... ELSE ..., das liest sich einfacher als perl-if-Code) und das ganze dabei noch verdichtet. Also vorher: 2 notify + 4 DOIF für bestimmte Funktionalitäten
Jetzt: 3 notify und ich habe auch noch einen Fehler eleminiert ;D (den will ich aber nicht dem Modul anlasten :D)
Verbleiben noch 18 DOIF... Nochmal 4 dürften einfach sein, dann muß ich mich mal an Stichworte wie defmod und evtl. weekdaytimer ranwagen, um das in den Griff zu kriegen, was mit Wiederholungen zu tun hat oder Zeiträumen, innerhalb derer bestimmte Schaltvorgänge stattfinden sollen. Da ist DOIF wirklich komfortabel!
Gruß,
Beta-User
Ich würde dir an einer Stelle Recht geben, viele wollen komplexe Probleme schnell gelöst haben. Zudem besitzen sie keine Programmiererfahrung und können oft logische zusammenhänge mathematisch nicht richtig erfassen. Zusätzlich kommt noch die Ereignissteuerung hinzu, die dies Sache komplizierter macht. Da kann auch ein DOIF nicht helfen.
Da jeder notify-Befehl in DOIF-Befehl umgewandelt werden kann, aber nicht umgekehrt, kann man sagen, wenn man ein Problem mit drei notify lösen kann dann kann man es auch mit drei DOIFs lösen, meistens aber kürzer.
Wenn du schon zu den Grundlagen zurück möchtest, dann solltest du vielleicht gleich auf Perl-if setzen, da du auch bei IF an bestimmten Stellen Einschränkungen in Kauf nehmen musst.
Gruß
Damian
Zitat von: Damian am 22 November 2016, 11:30:10
Wenn du schon zu den Grundlagen zurück möchtest, dann solltest du vielleicht gleich auf Perl-if setzen, da du auch bei IF an bestimmten Stellen Einschränkungen in Kauf nehmen musst.
Das führt jetzt zwar weit weg von der urspünglichen Frage, aber:
- sobald meine C-Programme auf den Arduinos soweit passen, werde ich das mit Perl versuchen zu vertiefen.
- Dass IF auch "bestimmte Einschränkungen" hat, habe ich gelesen, allerdings bislang keine konkrete Vorstellung, worum es sich handeln soll (ok, ich habe zum einen nicht besonders lange gesucht und könnte das Modul zum anderen zum Üben für perl nehmen und versuchen, das durch Analyse des Quellcodes selbst herauszufinden ::)). Bei den "beseitigten" DOIF's ging es "nur" um die Kombination eines (eher seltenen) Ereignisses mit in der Regel einer weiteren Abfrage, also:
--Licht im Bad wird angeschaltet oder ein Taster gedrückt: Umwälzpumpe für Warmwasser anschalten, wenn dort die Wassertemp. unter einem bestimmten Wert ist, oder
--Tür öffnen iVm. einem Höchst-Helligkeitswert=Außenlicht einschalten.
Dafür ist IF nach meinem Eindruck ok und verhindert, dass man sich beim "Klammern" usw. vertippt; diese einfachen Dinge werden dadurch auch nicht viel länger als mit DOIF. Das ist vermutlich bei komplexeren Dingen anders, mal sehen.
- Was mich noch interessieren würde: Hat DOIF eigentlich Vorteile bei der Systemlast, wenn man häufige Events auswerten will (Helligkeitswerte), vor allem, wenn es mit Zeiträumen gekoppelt ist? Werden also bestimmte Abfragen nur durchgeführt, wenn sie Sinn machen, oder wird sowieso immer alles ausgewertet? (Da die Readings aller Elemente in FHEMWEB aktualisiert werden, würde ich auf letzteres tippen).
Ansonsten: An sich hat mir DOIF auch als Anfänger erst mal sehr gut gefallen und sicher manches möglich gemacht, was ich sonst nie oder jedenfalls nicht in der Zeit hinbekommen hätte. Für diesen Ansatz daher auch mal ein ausdrückliches
DANKE! Und ich sehe auch, dass DOIF in den guten zwei Jahren, in denen ich es im Einsatz hatte, sehr gewachsen ist und unglaubliche Funktionalitäten ermöglicht, das
ist und bleibt eine Riesenleistung und sicher für viele Neulinge auch eine große Hilfe.
Auch die Tutorials, Fehlersuchhilfen usw., die in letzter Zeit dazugekommen sind, sind ein großer Fortschritt!
Thx,
Beta-User
wenn du es noch nicht gemacht hast, kann ich dir folgendes ans Herz legen:
http://www.fhemwiki.de/wiki/DOIF/Tipps_zur_leichteren_Bedienung#Einschalten_von_Syntaxhervorhebung.2C_Zeilenumbruch.2C_Suchen_und_Ersetzen.2C_Klammerpr.C3.BCfung_uvm. (http://www.fhemwiki.de/wiki/DOIF/Tipps_zur_leichteren_Bedienung#Einschalten_von_Syntaxhervorhebung.2C_Zeilenumbruch.2C_Suchen_und_Ersetzen.2C_Klammerpr.C3.BCfung_uvm.)
Hilft ungemein beim "Klammern"
Gruß Michael
Codemirror kenne ich, vermutlich habe ich vor einiger Zeit mal mit einer doofen Frage verursacht, dass dieses Stichwort (und die Funktionalität) plötzlich bei vielen Leuten präsent ist ;D.
Aber mit perl direkt werden die Kommandos wirklich deutlich länger und damit schlechter zu lesen (und damit für echte Anfänger im Zweifel abschreckend!). Einen echten Nachteil konnte ich bei (einfachen) IF bislang nicht erkennen, lerne da aber gerne dazu...
Gruß,
Beta-User