sunrise liefert falsches Datum

[Tungsten]

Hallo Zusammen,

hat sich kürzlich etwas bei der Berechnung von sunrise geändert?

Bis vor kurzem hat es wie in der Doku funktioniert, dass sunrise die Zeit vom nächsten Morgen ausgegeben hat.

Heute ist mir aufgefallen sunrise die Uhrzeit mit Datum vom heutigen Tag liefert, obwohl bereits in der Vergangenheit.
Habe vor 2 Tagen updates gemacht..

https://wiki.fhem.de/wiki/SUNRISE_EL

sunrise / sunset geben die absolute Zeit des nächsten Sonnenauf- bzw. -untergangs zurück, wobei 24 Stunden addiert werden, sofern das entsprechende Ereignis am nächsten Tag stattfindet

([{sunset()}] - [{sunrise()}]

liefert:

timer_01_c01    22.01.2021 17:43:08     2021-01-21 18:02:06
timer_02_c01    22.01.2021 07:46:41     2021-01-21 18:02:06

Das hat bis letzte Woche noch funktioniert. Ich schalte damit eine Lampe zwischen sunset und sunrise.
Geht nun aber nicht mehr da nicht mehr beim Timer2 das morgige Datum steht, sondern das heutige.

Was übersehe ich?

[Otto123]

Hi,

du solltest es nicht vermischen:
1. Was liefert {sunset()} und {sunrise()} (z.B. einfach in der FHEM Kommandozeile)?
2. Was macht DOIF daraus? DOIF zeigt den morgigen Tag - ist meines Wissens schon immer so?

Was meinst Du ist jetzt wirklich falsch? Morgen ist doch der 22. igste?

Gruß Otto

[Frank_Huber]

Ja, beim Post war SunSet schon rum, also ist die morgige Zeit drin.
Passt denke ich alles.

[Tungsten]

Mist ihr habt natürlich recht. Hatte einen anstrenden Tag und wollte kurz suchen weshalb die Beleuchtung draußen nicht mehr geht.
Bis Freitag lief es tadellos und Samstag habe ich seit einiger Zeit mal wieder FHEM aktualisiert. Seitdem funktioniert das DOIF nicht mehr.
Es sieht alles gut aus und es werden auch Bewegungen des PIR erkannt. Dann viel mir auch dass sunrise und sunset ja beide am nächsten Tag sind,
und somit die Bedingung nicht erfüllt sein kann, dass es nur in der Nacht laufen soll. Ging aber genau so bis Freitag.

Code Auswählen Erweitern


([{sunset()}] - [{sunrise()}]
and
[Schlechtwetter:state] eq "off"
and
([PIR.Bewegungsmelder1:state] eq "motion"
or
[PIR.Bewegungsmelder2:state] eq "motion"))

(set HUEGroup3SonoffBasiczbr3 on)

DOELSEIF

([PIR.Bewegungsmelder1:state] eq "nomotion"
and
[PIR.Bewegungsmelder2:state] eq "nomotion")

(set HUEGroup3SonoffBasiczbr3 off)

Stehe gerade auf dem Schlauch....

[xenos1984]

Zu viele eckige Klammern?

Code Auswählen Erweitern

[{sunset()} - {sunrise()}]
Oder isday().

Ansonsten: Ein komplettes List vom DOIF hilft mehr.

[Tungsten]

Die zusätzlichen eckigen Klammern hatte ich gemacht da ich Perl Warnings hatte.

isday() kenne ich noch nicht. Wie müsste ich das einbauen?

Oder gibt es eine andere Möglichkeit nur bei Dunkelheit/Nacht ein DOIF auszuführen?

[Frank_Huber]

Die zusätzlichen eckigen Klammern hatte ich gemacht da ich Perl Warnings hatte.

IMHO müssen die sein wegen der indirekten Zeitangabe.

[Otto123]

@Frank Nein, die Konstruktion von xenos1984 ist schon richtig - da müssen keine Klammern sein. Die braucht man wenn man die Werte aus Readings liest.
Interessanterweise werden die timer bei beiden Varianten  (mit und ohne) richtig gesetzt - was dann passiert weiß nur DOIF.

Ich würde das entweder konkreter fassen:

Code Auswählen Erweitern

DOIF ([{sunset()}-{sunrise()}] and (Bed1 or Bed2))(Schalte ein) DOELSEIF ([{sunrise()}] or (Bed1 and Bed2))(Schalte aus)
aber eigentlich reicht auch:

Code Auswählen Erweitern

DOIF ([{sunset()}-{sunrise()}] and (Bed1 or Bed2))(Schalte ein) DOELSE (Schalte aus)
Da beide Bedingungen in den einzelnen Zweigen aus meiner Sicht die exakte logische Umkehrung sind.

[bombardi]

Ich will das Thema mal wieder auffrischen, auch wenn bei mir nicht das Datum sondern die Uhrzeit falsch ist.
Ich nutze Sunrise_abs und das liefert z.B. heute (05.11.2021) für meine Koordinaten lat=52.3651974,lng=13.3088034 {sunrise_abs()}=06:33:24.
Richtig wäre aber für Großbeeren heute 07:08.

Hat jemand eine Idee woher der Unterschied kommt ?

Gruss
Bombardi

[Otto123]

Hi,

das liegt an deinem gewünschten (Höhen) Betrachtungswinkel
Mal {sunrise_abs("REAL")} probiert?
Zitat Doku / commandref

SUNRISE_EL geht von einem Höhenwinkel der Sonne bezogen zum Horizont, h, von -6° aus. Dieser Wert bedeutet, dass die Sonne 6° unter dem Horizont steht und Lesen im Freien ohne künstliche Beleuchtung nicht mehr möglich ist
...
altitude
Eine der folgenden Zeichenketten, die unterschiedliche Höhenwinkel h definieren und den Wert von $defaultaltit verändern.
Erlaubte Werte sind:
REAL, h = 0°,
CIVIL, h = -6°,
NAUTIC, h = -12°,
ASTRONOMIC, h = -18°,
oder HORIZON=, gefolgt von einer positiven oder negativen Zahl ohn Gradzeichen, die einen Höhenwinkel angibt.
...
Beispiele
sunrise("CIVIL");
Zeitpunkt des Sonnenaufgangs bei einem Höhenwinkel der Sonne von -6° unter dem Horizont (identisch zu sunrise()).

Gruß Otto

[rudolfkoenig]

Oder auch: wann ist jetzt aber "wirklich" hell?

[bombardi]

Hi,

das liegt an deinem gewünschten (Höhen) Betrachtungswinkel
Mal {sunrise_abs("REAL")} probiert?
Zitat Doku / commandref
Gruß Otto

Danke, genau das war mein Fehler

[hobu]

Für heute liefert mir ein
{sunrise()}
in der Eingabezeile als Ausgabe:
31:08:28

Das sieht weder nach Uhrzeit noch Stunden bis zum nächsten Sonnenaufgang aus.
sunrise_abs gibt 07:10 aus, was auch passt.

Wird mit sunrise() nicht die Uhrzeit des nächsten Sonnenaufgangs ausgegeben?

[Otto123]

es hängt davon ab ... 

Code Auswählen Erweitern

help sunrise_el
liefert die genaue Beschreibung 

sunrise() - absolute Zeit des nächsten Sonnenaufgangs (+ 24 h, wenn am nächsten Tag)

[hobu]

Das ist dann aber der übernächste Sonnenaufgang.
Die Abfrage war nach 08:00 und somit nach Sonnenaufgang.
Der *nächste* Sonnenaufgang ist somit in <24h.
Ich versteh nicht , warum da eine relative Zeit von >+30h berechnet wird.