Hallo, hat dieses Problem noch jemand, oder habe ich einen Fehler verbaut.
define Wohnzrolloreab DOIF ([{twilight("TC_TWILIGHT","sr_indoor","06:00","10:00")}] and [Balkontuer] eq "off" ) (set Wohnzrollolre on,set pushmsg message Die Rolläden wurden heraufgefahren,set Wohnzrolloreab_ initialize) DOELSE ()
attr Wohnzrolloreab do always
Es wird zwar ausgeführt, aber zweimal. :-\
2016.07.20 06:16:29 1: IT set Wohnzrollolre on
2016.07.20 06:17:39 1: IT set Wohnzrollolre on
Vermutung:
Wenn das DOIF getriggert wird, wird auch die Zeitberechnung neu durchgeführt. Der alte Zeitpunkt ist der gestern berechnete sunrise. Nun wird aber der sunrise für heute berechnet. Da die Tage kürzer werden, liegt der etwas später als gestern. Der interne Timer wird entsprechend gesetzt und das DOIF kurze Zeit später erneut getriggert. Wenn Du bis zur Wintersonnenwende warten kannst, würde sich das Problem von alleine erledigen. ;)
hm.......abends arbeite ich auch mit twilight, müsste beim herunterfahren dann nciht auch der berfehl doppelt ausgeführt werden. abends ist alles gut ?!
Zitat von: rr725 am 20 Juli 2016, 16:37:44
hm.......abends arbeite ich auch mit twilight, müsste beim herunterfahren dann nciht auch der berfehl doppelt ausgeführt werden. abends ist alles gut ?!
Abends geht es ja sicher um sunset und der ist bei abnehmender Tageslänge jeden Tag etwas früher. Beim Ausführen des DOIFs wird der Timer dann auf einen Zeitpunkt gesetzt, der bereits vergangen ist bzw. erst am nächsten Tag wieder erreicht wird. Deshalb würde der Effekt da eben nicht auftreten (zu dieser Jahreszeit).
Aber wenn Du Gewissheit willst, müsstest Du Dich mal zur fraglichen Zeit vor den Event monitor setzen oder das DOIF (bzw. die DOIFs) mal komplett loggen lassen. Dann kann man genau nachvollziehen, was passiert.
Tipp: ohne do always mit Zeitintervallen arbeiten. Bei Zeitintervallen wird die Berechnung (beim aktuellen DOIF-Modul) des Zeitbeginns erst mit der Endzeit berechnet, damit werden solche Probleme umgangen.
Gruß
Damian
ok....werd´ich mal testen. Vielen DANK !!!!!!
Zitat von: Damian am 20 Juli 2016, 18:53:50
Tipp: ohne do always mit Zeitintervallen arbeiten. Bei Zeitintervallen wird die Berechnung (beim aktuellen DOIF-Modul) des Zeitbeginns erst mit der Endzeit berechnet, damit werden solche Probleme umgangen.
Moin,
wie stelle ich das denn an mit den Zeitbereichen?
Stand jetzt ist das mein Code:
define DOIF_ROLLADEN_UP DOIF ([{twilight("Sonnenstand","sr_civil","06:30","08:00")}]) (set PI_EG cmd set Rollos_EG offen ;;set PI_OG cmd set Rollos_OG offen ;;set PI_DG cmd set Rollos_DG offen)
attr DOIF_ROLLADEN_UP do alwaysgenerell stört mich das doppelte Ausführen in diesem Fall nicht, aber wer weiß was ich in Zukunft noch reinbastle. ;-)
Das ist übrigens mein erster Kontakt mit DOIF.
Grüße
Frank
Moin,
Bei mir führten die Sunrise-Werte nicht zu einem hinreichenden WAF, wobei ich ursprünglich auch mit dem light-Wert des Twilight-Moduls gearbeitet hatte. Nun habe ich das einstellbar auf die prozentualen Werte gebaut nachdem ich hier im Forum mal so nebenbei gelernt hatte, wie ich das do always umgehen kann. WAF ist nun > 90%.
Diese Ergebnisse habe ich als Beispiel für das Arbeiten ohne do always mal in's Wiki geschrieben. Vielleicht ist das ja auch für Dich ein Ansatz, etwas anders an die Sache heran zu gehen. Inzwischen könnte man das unter Ausnutzung der neuen tollen Features vom DOIF sicher noch etwas schlanker halten, aber an dieser Stelle mag ich im Moment nicht schrauben.
http://www.fhemwiki.de/wiki/DOIF/do_always_Alternative_am_Beispiel_einer_Rollladenautomatik
beispielhafte Grüße
Niels
Zitat von: Frank_Huber am 02 Dezember 2016, 08:53:14(set PI_EG cmd set Rollos_EG offen ;;set PI_OG cmd set Rollos_OG offen ;;set PI_DG cmd set Rollos_DG offen)
Sollte bei DOIF nicht Komma statt doppelt Semikolon stehen?
Und Leerzeichen hinter den Befehlen können (müssen aber nicht) das Ergebnis verfälschen.
genau, mit Komma und hintereinander weg...
so liest man es auch im commandref
OK, das hab ich dann übersehen. Aber: es funktioniert.
morgens sogar doppelt. ;)
Werds mal mit Komma testen. wird aber am eigentlichen Thema nix ändern.
Kann es sein, dass es wetterbedingt den Helligkeitswert auch zweimal gibt? Du kannst ja eine zusätzliche Bedingung einbauen: wenn Rollo unten.
wie gesagt, stört mich im Rollo Fall die doppelte Befehlsabsetzung nicht. ich seh nur im Log für jeden Rollo "Start und Ziel gleich"
"Wenn Rollo unten" geht eh nicht da ich per Structure alle Rollos fahren lassen will (ausser den Schlafräumen)
deswegen setzt der Keller PI den Befehl an die anderen Drei ab.
oben war etwas von Zeiten anstatt dem do always Attribut geschrieben.
Hier paar Details wären gut. ;)
Zitat von: Frank_Huber am 02 Dezember 2016, 13:43:54oben war etwas von Zeiten anstatt dem do always Attribut geschrieben.
Hier paar Details wären gut. ;)
Einfach dem Link folgen:
Statt DOELSE ein DOELSEIF ([0:00]) nehmen, dann wird um Mitternacht (in der Regel also weit weg von der gewünschten Helligkeit zum Öffnen dein DOIF auf cmd2 gesetzt und kann wieder reagieren. Solange bleit es in cmd1 stehen. Also nur einmal pro Tag.
danke, geht ein DOELSEIF auch ohne Befahl dahinter?
mein DOIF ist ja weit weniger Komplex als das verlinkte Beispiel.
da war mir das DOELSEIF mit Zeit nicht ins Auge gefallen.
EDIT: wer den ganzen Text im Link lies tist klar im Vorteil. :-)
werd ich testen. danke für den Schubs nochmal den Link anzuschauen.
Moin Frank_Huber,
bist Du sicher, daß durch FHEM2FHEM keine Events "verdoppelt" werden?
Gruß
Sunny
Hi Sunny.
Ja,
zum einen ist es RFHEM,
zum anderen sehe ich an den ausführungszeiten genau dass es die "alte" und "neue" Uhrzeit vom sunrise ist.
Grüße
Frank
Zitat von: Frank_Huber am 02 Dezember 2016, 14:09:30danke, geht ein DOELSEIF auch ohne Befahl dahinter?
Ja (http://fhem.de/commandref_DE.html#DOIF_Reine_Statusanzeige_ohne_Ausfuehrung_von_Befehlen)
Zitat von: Per am 02 Dezember 2016, 15:24:34
Ja (http://fhem.de/commandref_DE.html#DOIF_Reine_Statusanzeige_ohne_Ausfuehrung_von_Befehlen)
Danke,
hatte ich beim genauen lesen des Textes im Link dann auch entdeckt.
im Link sah anfangs alles so komplex aus dass ich das übersehen hatte. :-)
Grüße
Frank
Zitat von: Frank_Huber am 02 Dezember 2016, 15:34:34alles so komplex
Ja, das Beispiel hätte einfacher sein können, nach ein paar Jahren Fhem versteht man das schon. Aber es richtet sich ja eigentlich an die Anfänger...
In der Tat habe ich mich schwer damit getan, die Balance zwischen einem realen Anwendungsfall und dem was ich darlegen wollte zu schaffen. An einem konkreten Fall erklärt es sich leichter, warum es so ist, aber es verwischt immer etwas das Wesentliche. Und zugegeben, ich war etwas faul - ich habe mein praktisches Beispiel nur verschlankt eingestellt. Warum ich nicht auch noch die abweichende Steuerung am Wochenende raus genommen habe verstehe ich auch gerade nicht :-\
Werde ich noch machen. Aber zum Glück ist das ein Wik und alle können mithelfen das zu optimieren ;)
Interessant ist im DOIF-Wiki auf jeden Fall das DOIF-Labor mit den kompletten Daten zum RAW-Import. Hier macht es wirklich Sinn die Beispiele zu importieren und mit ihnen zu spielen. Allerdings muss man dazu schon wieder den RAW-Import kennen...
dokumentierte Grüße
Niels
Moin Moin,
do always raus und DOELSEIF rein hat das "problem" gelöst.
Danke nochmal für den richtigen Schubbs.
/Frank
Zitat von: Frank_Huber am 05 Dezember 2016, 09:42:07do always raus und DOELSEIF rein hat das "problem" gelöst.
Jo, die Idee ist richtig gut!
Ich habe noch mal einen 2. Anlauf zu der Lösung im Wiki gestartet: https://wiki.fhem.de/wiki/DOIF/do_always_Alternative_am_Beispiel_einer_Batteriewarung_via_Telegram
Ist das einfacher? Ja, ich weiß, wieder blöde reguläre Ausdrücke und wegen der Abhängigkeiten zu den verwendeten Geräten auch kein Labor-Import...
Aber er war stets bemüht 8)
dokumentierte Grüße
Niels