Twilight Steuerung schaltet doppelt

Begonnen von SofB, 11 Dezember 2016, 13:07:21

Vorheriges Thema - Nächstes Thema

SofB

Hallo,

fuer meine Aussenlampe nutze ich Twilight zum Ausschalten morgens.
Leider schaltet Twilight zweimal.
*{twilight("TwilightHome","sr","2:00","9:30")} set Taster_Haustuer_Licht off
Und zwar um 2:00 und um viertel nach acht. Der Zweite Wert waere der zu erwartende. Leider ist die Lampe dann schon aus.
Ich hatte den Wert 2:00 vorher auf 4:00. Um zu pruefen, ob es an Twilight liegt habe ich diesen auf 2:00 geaendert.
Angezeigt wird stets die korrekte "Ausgehzeit", aber um 2:00 steht im Log, dass das Licht ausgeschaltet worden ist.

Jemand eine Idee?
FHEM auf Debian Jessie VM - ESXi 6.0 Intel Nuc i5 4th Gen
HM-CFG-LAN | HM-CFG-USB | nanoCUL868 | nanoCUL433 | JeeLink868

Dietmar63

Dass liegt daran dass die Tage kürzer werden
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

SofB

Hi Dietmar,

sorry, aber die Aussage verstehe ich nicht ganz...
Ich habe ja zwei Timer. Einer zum Anschalten, der natuerlich immer eher anschaltet und eben diesen zweiten hier zum Ausschalten.
Letzterer will ja auch erst nach acht schalten (die Nacht wird laenger - der Tag kuerzer), schaltet aber bereits am Min. Zeitpunkt ZUSAETZLICH.
FHEM auf Debian Jessie VM - ESXi 6.0 Intel Nuc i5 4th Gen
HM-CFG-LAN | HM-CFG-USB | nanoCUL868 | nanoCUL433 | JeeLink868

Dietmar63

Ich nehme an du nutzt at

AT stellt nach einer Schaltung sofort die neue Zeit ein, und die ist immer Winter immer einige Minuten später
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

SofB

Richtig, ich nutze AT.
Danke nochmal fuer Deine Erlaeuterung. Dennoch verstehe ich nicht, was die kuerzeren Tage damit zu tun haben, dass das Licht statt ca. 8:15 (Parameter SR) um 2:00 ausgeht. Und dann NOCHMAL um 8:15 geschaltet wird.
So kurz ist der Tag nun auch nicht ;)
FHEM auf Debian Jessie VM - ESXi 6.0 Intel Nuc i5 4th Gen
HM-CFG-LAN | HM-CFG-USB | nanoCUL868 | nanoCUL433 | JeeLink868

Dietmar63

Schwer zu sagen woran es liegt, dass um 2 geschalt wird.
Du kannst ja mal bei Twilight verbose 5 setzen und dir sr ansehen. Das Element  muss dem Format HH:MM:TT Entsprechen.
Tritt das Phänomen immer auf?
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

Dietmar63

Du könntest zum Beispiel ein at anlegen dass regelmäßig das Ergebnis von
twilight("TwilightHome","sr","2:00","9:30")

Ins Log schreibt. Vielleicht lässt sich daran erkennen was nicht stimmt.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

SofB

das mit dem Log probiere ich mal aus. interessiert mich sehr.

ich habe es so lösen können indem ich den ersten "nicht vor" Parameter durch "" ersetzt habe.
FHEM auf Debian Jessie VM - ESXi 6.0 Intel Nuc i5 4th Gen
HM-CFG-LAN | HM-CFG-USB | nanoCUL868 | nanoCUL433 | JeeLink868

Dietmar63

Meine Analysen haben ergeben, dass es nur an SR liegen kann.
Die Parameter "2:00" und "9:30" werdn sauber in die Zahlenwerten 2 und 9.5 verwandelt.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

SofB

Warum der "erstmoegliche" Schalttermin verwendet wird, konnte ich nun herausfinden.
Der Fehler kommt immer beim Restart von FHEM. Obwohl Twilight sehr weit oben in der fhem.cfg definiert ist, scheint bei der AT Definition noch keine Daten im Modul vorzuliegen.
Wie kann man da Abhilfe schaffen...?
Zusaetzlich gibt es noch das Phaenomen, dass der Befehl 2x innerhalb ca. 1Minute ausgefuehrt wird. Damit kann ich aber leben..
FHEM auf Debian Jessie VM - ESXi 6.0 Intel Nuc i5 4th Gen
HM-CFG-LAN | HM-CFG-USB | nanoCUL868 | nanoCUL433 | JeeLink868

Dietmar63

vielleicht liegt es daran, dass die Daten in TW per BlockingCall asynchron geholt werden.
Das soll verhindern, dass die Oberfläche einfriert, wenn die Daten extern(yahoo) besorgt werden müssen.

Wenn du den Namen deines TWs mit tst beginnen lässt, wird automatisch ein verobose 5 eingeschaltet und du kannst erkennen wann was in TW ausgeführt wird.
Mit passendem Logging auf dem at, kannst du die zeitliche Reihenfolge genau prüfen.

Ich glaube es gibt ein Ereignis auf das man ein notify legen kann, das feuert, wenn die Startphase abgeschlossen ist.

Beispiel:

define FHEM_init notify global:INITIALIZED { \
        $defs{Stromzaehler}{READINGS}{basis}{VAL}= 7825387;; \
}


Vielleicht kannst du erst nach dem Eintreten des INITIALIZED-Ereignisses das at auf twilight(...) definieren.
Vielleicht musst du sogar auf die Initialisierung der Readings in Twilight warten. Dann ist ein notify auf Twilght:sr oder Twilight:twilight einzurichten

Wenn du noch Fragen hast - immer her damit!!!
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

FHEMGerd

Hallo, ich habe glaube ich genau das gleiche Problem.

Mein at sieht so aus:
define z_Jal_Buero_ab_sr at *{ReadingsVal("Sonnenstand","ss_civil","22:45:00")} set Buero_Jal_Taster_ab_kurz ab

Ich möchte damit eigentlich erreichen, dass eine Jalousie bei Sonnenuntergang runtergefahren wird. Das hat auch eine Zeitlang wunderbar geklappt. Das Problem dabei: das at schaltet 2mal, laut log so ca. im Abstand von 1 Minute. Der Runterfahrbefehl geht an eine Siemens Logo. Dort wiederrum ist im Programm eine Zeit für das Runterfahren hinterlegt, die so gewählt ist, dass die Jalousie noch ca. 5cm über der Fensterbank steht. Das soll verhindern, dass sie bei Frost anfriert. Die Lamellen sind dann noch offen. Irgendwann hab ich bemerkt, dass die Lamellen zu sind, so bin ich drauf gekommen, dass das at zweimal schaltet.

Ich denke das paßt zu diesem Thema, allerdings habe ich die Lösung noch nicht so ganz verstanden ...

Danke schonmal, Gerd

CoolTux

Hallo Gerd,

Ich denke es hat etwas damit zu tun das die Tage wieder länger und somit der Sonnenuntergang immer später kommt.

Heute sagen wir mal 17:04 wenn das at um 17:04 aus löst wird automatisch der nächste Sonnenuntergang berechnet. Der ist 17:05 und eigentlich am Folgetag. Aber ich denke das mit dem Folgetag bekommt er nicht hin. Sondern schaltet am selben Tag nochmal und dann erst berechnet er für den Folgetag. Das Problem an sich kennt man.

Vorschlag. Kannst Du für Deine Jalousien das AutoShuttersControl Modul nehmen? Wäre aber denke ich erstmal ohne Lamellensteuerung.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Damian

Wenn du sunset() nimmst, sollte er nur einmal schalten, wenn du bei ss_civil bleiben willst, dann kannst du auch definieren:

DOIF ([[Sonnenstand:ss_civil]]) (set Buero_Jal_Taster_ab_kurz ab)

attr do always


hier wird auch nur einmal geschaltet, auch wenn die Tage länger werden.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

FHEMGerd

Hallo  CoolTux und Damian,

danke für Eure Tips und Erklärungen. Ich glaube ich habs jetzt kapiert.
Ich probiers jetzt mal so:

define z_Jal_Buero_ab_sr at *{sunset_abs("CIVIL",0)} set Buero_Jal_Taster_ab_kurz ab

Ich hab natürlich im Global Device latidude und longitude gesetzt. Das Twilight Device hab ich gelöscht.
Falls es nicht funzt gehe ich Euch wieder auf den Keks  ;)

Gerd