Twilight vs. sunrise/sunset

Begonnen von Spartacus, 15 Dezember 2014, 20:56:18

Vorheriges Thema - Nächstes Thema

Spartacus

Hallo,
ich habe eine Steuerung mit twilight gebaut und nutze die Readings "ss_civil", "sr_civil" und "twilight".

in einem DOIF nutze ich das so:
(([16:30-22:30|56] or
  [16:30-22:30] or
  [16:30-21:30|01234]) and [Daemmerung:twilight] < 25) (set Licht on)

Funktioniert auch gut.

mit
define SA at *{sunrise("HORIZON=-6")} set Tageslicht hell
define SU at *{sunset("HORIZON=-6")} set Tageslicht dunkel

schalte ich Dummy Tageslicht zwischen "hell" und "dunkel"

wenn ich nun mein DOIF so umbaue, funktioniert das nicht mehr!
(([16:30-22:30|56] or
  [16:30-22:30] or
  [16:30-21:30|01234]) and [Tageslicht] eq "dunkel") (set Licht on)


im zweiten Fall muss Tageslicht vor 16:00 bzw 16:30 "dunkel" sein, damit geschaltet wird, im ersten Fall schaltet das Licht auch, wenn es nach 16:00 bzw 16:30 dunkel wird und das ist auch korrekt.

im Prinzip wäre das ja alles egal. Ich könnte für den DOIF Fall einfach mein Twilight nehmen, und für den anderen Anwendungsfall (da brauche ich in sunrise und sunset ein offset von 60sec) das andere Modul. Problem ist nur, dass Twilight und Sunrise bei gleichen Geo-Koordinaten unterschiedliche Zeiten berechnet. Irgendwie sind da 5 min Differenz bei sunrise. Für meinen Anwendungsfall darf es aber keinen Unterschied geben, da der Aktor 2 60sec vor/nach Aktor 1 geschaltet haben muss. Aktor 1 ist  genau zwischen Sonnenuntergang und Aufgang aktiv (das soll DOIF gemacht werden), Aktor 2 60sec vor Untergang bis 60sec. nach Aufgang.

Frage:
Wieso  wird das DOIF im 2. Fall nicht nach der Zeit getriggert?
Gibt es eine Möglichkeit bei Twilight auch einen offset hinzu-, bzw abzuziehen?
Spartacus
Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

Dietmar63

ZitatGibt es eine Möglichkeit bei Twilight auch einen offset hinzu-, bzw abzuziehen?
nein
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

Spartacus

Hallo,
bleibt wohl nur der Weg über sunset/sunrise. Hat jemand eine Idee, warum die beiden Funktionen unterschiedliche Werte berechnen? Ist das ein Bedienungsfehler, oder liegt das an unterschiedlichen Ansätzen bei der Programmierung der Module!

Christian
Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

Dietmar63

Unterschiedliche Ansätze in der Berechnung
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

juppzupp

Über einen kleinen Umweg geht das mit dem offset schon. hab ich irgendwo hier im forum geklaut :
sub TimeOffset($;$)

  {
    my $PtimeOrg = shift;
    my $Poffset = shift;

    $PtimeOrg = "" unless(defined($PtimeOrg));
    $Poffset  = 0  unless(defined($Poffset));
    my ($sec,$min,$hour,$mday,$month,$year,$wday,$yday,$isdst) = localtime;

    if ($PtimeOrg !~ /[0-2][0-9]:[0-5][0-9]/ or substr($PtimeOrg,0,2) >= 24) {$PtimeOrg = $hour.":".$min;}

    my $TimeP     = mktime(0,substr($PtimeOrg,3,2),substr($PtimeOrg,0,2),$mday,$month,$year,$wday,$yday,$isdst);
    my $TimePM    = $TimeP + $Poffset * 60;
    my ($Psec,$Pmin,$Phour,$Pmday,$Pmonth,$Pyear,$Pwday,$Pyday,$Pisdst) = localtime($TimePM);
    my $ReturnText = sprintf("%02d:%02d:%02d", $Phour, $Pmin, $Psec);


in die 99_myutils
und dann wie folgt aufrufen :

define dimflurabendson at *{TimeOffset(ReadingsVal("myTwilight","ss_weather","19:00:00"),-30)} set structure_Flur_Kuche on 1800

Spartacus

Hallo,
Puuh!
Viel Aufwand für das Berechnen des offsets. Aber das werde ich mal testen. Vielen Dank dafür.

Eine Frage noch:
Im Prinzip kann ich für mein DOIF oben auch Sunset und Sunrise nehmen. Dann wird das halt mehrfach in den Konditionen berechnet, Quasi pro Kondition ein Mal. Kann jemand abschätzen, wie viel Rechenzeit das kostet, wenn man das bspw. in 5 Bedingungen jedes Mal berechnet? Oder ist es in diesem Fall empfehlenswert die SUB zu nutzen...
(([1sunset...-22:30|56] or
  [Sunset,,,-22:30] or
  [Sunset,...-21:30|01234
...........])) (set Licht on)

Christian
Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

Dietmar63

Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

Spartacus

Hallo Dietmar,
vielen Dank für die Einschätzung! Meine C-Control, die mehr als 10 Jahre lang meine Beleuchtung steuerte, brauchte für eine dieser Berechnungen schon ein paar ms. Nanosekunden, das  ist ja um den Faktor 1 Mio schneller und sollte wirklich nicht ins Gewicht fallen!

Schönen Gruß,
Christian
Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

Dietmar63

Nanosekunden sind vielleicht übertrieben.
Es sollte dir nur verdeutlichen, dass der Aufwand für die Berechnung zu vernachlässigen ist.

Aufwendig sind eher:
SVG Grafiken erstellen, die WEB-Oberfläche berechnen, notify, Zugriffe aufs WEB ,oder in Internet  ... , wobei bei den beiden letzteren die Rechenzeit auch nicht hoch ist, aber die Latenzen zu berücksichtigen sind.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

Spartacus

Hallo,
Auch OK! Ich gucke mal,welches Modul am Ende das Beste für mich ist...aber über kurz oder lang kommt man um einen Dämmerungsschalter nicht herum.

Danke und Gruß,
Christian
Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

chq

Was ist das Ergebnis, knapp vier Jahre später?

Gruß Chris
So einfach wie möglich, so kompliziert wie nötig