neues Modul Astro.pm

[andies]

Da ist ein Unterschied. Ich habe Berlin eingegeben, also

Code Auswählen Erweitern

Latitude: 52.520008
Longitude: 13.404954

In der javascript-Rechnung von Barmettler komme ich auf einen Sonnenuntergang von 20:10 = 20.175. FHEM zeigt mir aber an
20:07:09.

Ich hoffe mal, ich habe keine falschen Parameter gesetzt, aber entscheidend sind doch nur Längen- und Breitengrade?


Gesendet von iPad mit Tapatalk Pro

[andies]

Wieder mal sitzt das Problem vor'm Bildschirm (da gab es doch ein Kürzel dazu?). Also ich habe den Sonnenuntergang aus einer uralt-Installation genommen und mW wird das mit sunset/sunrise("REAL") ausgelöst (siehe unten) und zeigt heute 20:07 an. Wenn ich dagegen das Astro-Modul nehme  ("get Astro text"), wird mir die richtige Sonnenuntergangszeit von 20:10 gezeigt.

Jetzt muss ich nur noch herausbekommen, wie der falsche Wert in meine Installation gelangt ist.

Code Auswählen Erweitern

Internals:
   COMMAND    { my $s = sunrise("REAL"); fhem("set Sonnenaufgang $s"); $s = sunset("REAL"); fhem("set Sonnenuntergang $s"); }
   DEF        *03:00:00 { my $s = sunrise("REAL"); fhem("set Sonnenaufgang $s"); $s = sunset("REAL"); fhem("set Sonnenuntergang $s"); }
   NAME       sun_riseSet_timer
   NR         40
   PERIODIC   yes
   RELATIVE   no
   REP        -1
   STATE      Next: 03:00:00
   TIMESPEC   03:00:00
   TRIGGERTIME 1535245200
   TRIGGERTIME_FMT 2018-08-26 03:00:00
   TYPE       at
   READINGS:
     2018-08-25 13:06:04   state           Next: 03:00:00
Attributes:

[Prof. Dr. Peter Henning]

Wieso denn eigentlich "FHEM" ? Das Astro-Modul berechnet mit den entsprechenden Geodaten ganz korrekt

SunSet = 20:10

mit minutengenauer Angabe (keine Sekunden).


Edit: Hat sich überschnitten...


LG

pah

[andies]

Wieso denn eigentlich "FHEM" ?

Mit FHEM meine ich, dass der oben zitierte Befehl bzw. mein ,,Gerät" [dummy] aus FHEM falsche Angaben zum Sonnenuntergang liefert. Ich verstehe nicht, wie es zu den falschen Angaben kommt.

Astro liefert korrekte Zeiten - Danke!


Gesendet von iPhone mit Tapatalk Pro

[andies]

Könnte es sein, dass die Funktion Sunset von rudolfkoenig fehlerhaft ist?


Gesendet von iPhone mit Tapatalk Pro

[Prof. Dr. Peter Henning]

k.A.

LG

pah

[andies]

Hallo pah, es scheint in der Tat ein Fehler in sunset (99_SUNSET_EL.pm) zu sein. Nun meine Frage, da ich Perl-Laie bin. Vielleicht kann man diesen Fehler leicht beheben, da ja meines Wissens 50_Astro.pm in der Distribution enthalten ist.

Kann man nicht den Aufruf

Code Auswählen Erweitern


Astro_Compute($hash);
$Astro{SunRise}
"irgendwie" (ich sagte: ich bin Laie) nutzen, so dass beim Aufruf von sunset nicht die rudolfkoenig-Routinen, sondern eben die Routinen von Astro benutzt werden können? Das würde das Problem am einfachsten lösen, weil sicherlich viele Leute sunset verwenden und ein Umbau im Zweifel eine Menge Ärger verursacht.

Andererseits muss ich zugeben, dass die Fehler anscheinend +/- 5 Minuten betragen und wer nicht gerade religiös unterwegs ist, wird das sicher entspannt sehen können.

[andies]

Eine Möglichkeit besteht in folgendem. Man definiert Astro

Code Auswählen Erweitern

define Astro Astro
und nutzt dann statt "sunset()" einfach

Code Auswählen Erweitern

{ReadingsVal("Astro","SunSet","")}
Mir ist nur nicht klar, ob man das auch in DOIF und diesen Spielzeugen verwenden kann. Es fehlen ja die Sekundenangaben.

[Ellert]

Mir ist nur nicht klar, ob man das auch in DOIF und diesen Spielzeugen verwenden kann. Es fehlen ja die Sekundenangaben.

In DOIF kann man es verwenden, auch ohne Sekundenangaben. Man kann es auch ausprobieren.

[andies]

... kann man in jedem eigenen Modul auch ein

Code Auswählen Erweitern

require "95_Astro.pm";
an den Anfang setzen. Und sogar ohne Definition eines Astro-Devices auf die somit bekannten Routinen zugreifen. Etwa per

Code Auswählen Erweitern

Astro_Get( IRGENDEINE HASH REFERENZ,"dummy","text", "SunRise","2019-12-24");
um den Sonnenaufgang an Heiligabend 2019 zu bekommen.

Man muss nur noch den aktuellen Tag einsetzen und hat alles für ein korrektes sunset().

Ich bin ja Programmierlaie: Schlägt man das jetzt als Lösung für korrekte Befehle in SUNRISE vor? Gibt es hier einen Ablauf, was ich wann zu tun habe? Wird das noch diskutiert?

[Prof. Dr. Peter Henning]

Nö, kein Ablauf und keine Diskussion. Kann jeder verwenden, wie er will - ob die alten Funktionen von Rudi, oder die Werte aus Astro.

LG

pah

[Morgennebel]

Moin,


ich habe testweise ASTRO für meine Außenbeleuchtung konfiguriert, in der Kombination mit DOIF:

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF        ((([[AS_MyPlace:CustomTwilightEvening]-22:30|Fr Sa]          or
   [[AS_MyPlace:CustomTwilightEvening]-21:45|So Mo Di Mi Do] or
   [05:30-[AS_MyPlace:CustomTwilightMorning]|Mo Di Mi Do Fr] or
   [06:30-[AS_MyPlace:CustomTwilightMorning]|Sa So])         and [?D_ArrivalExpected] eq "off") or
([DI_NightAndDay:IsDaylight] eq "off" and [D_ArrivalExpected] eq "on"))
(setreading $SELF OutDoorLight on)
DOELSE
(setreading $SELF OutDoorLight off)
   NAME       DI_OutdoorLightsTimer
   NR         246497
   NTFY_ORDER 50-DI_OutdoorLightsTimer
   STATE      cmd_2
   TYPE       DOIF
   READINGS:
     2018-09-30 06:31:00   Device          DI_NightAndDay
     2018-09-30 06:31:00   OutDoorLight    off
     2018-09-30 06:31:00   cmd             2
     2018-09-30 06:31:00   cmd_event       timer_8
     2018-09-30 06:31:00   cmd_nr          2
     2018-09-30 06:31:00   e_DI_NightAndDay_IsDaylight on
     2018-09-29 14:47:03   mode            enabled
     2018-09-30 06:31:00   state           cmd_2
     2018-09-30 08:13:55   timer_01_c01    30.09.2018 17:54:00|FrSa
     2018-09-29 22:30:00   timer_02_c01    30.09.2018 22:30:00|FrSa
     2018-09-30 08:13:55   timer_03_c01    30.09.2018 17:54:00|SoMoDiMiDo
     2018-09-29 21:45:00   timer_04_c01    30.09.2018 21:45:00|SoMoDiMiDo
     2018-09-30 06:31:00   timer_05_c01    01.10.2018 05:30:00|MoDiMiDoFr
     2018-09-30 08:13:55   timer_06_c01    01.10.2018 06:31:00|MoDiMiDoFr
     2018-09-30 06:31:00   timer_07_c01    01.10.2018 06:30:00|SaSo
     2018-09-30 08:13:55   timer_08_c01    01.10.2018 06:31:00|SaSo
   Regex:
   condition:
     0          ((DOIF_time($hash,0,1,$wday,$hms,"FrSa")          or    DOIF_time($hash,2,3,$wday,$hms,"SoMoDiMiDo") or    DOIF_time($hash,4,5,$wday,$hms,"MoDiMiDoFr") or    DOIF_time($hash,6,7,$wday,$hms,"SaSo"))         and InternalDoIf($hash,'D_ArrivalExpected','STATE') eq "off") or  (ReadingValDoIf($hash,'DI_NightAndDay','IsDaylight') eq "off" and InternalDoIf($hash,'D_ArrivalExpected','STATE') eq "on")
   days:
     0          FrSa
     1          FrSa
     2          SoMoDiMiDo
     3          SoMoDiMiDo
     4          MoDiMiDoFr
     5          MoDiMiDoFr
     6          SaSo
     7          SaSo
   devices:
     0           DI_NightAndDay D_ArrivalExpected
     all         DI_NightAndDay D_ArrivalExpected
   do:
     0:
       0          setreading DI_OutdoorLightsTimer OutDoorLight on
     1:
       0          setreading DI_OutdoorLightsTimer OutDoorLight off
   helper:
     DOIF_Readings_events
     DOIF_eventas
     event      cmd_nr: 1,cmd: 1,cmd_event: timer_1,cmd_1
     globalinit 1
     last_timer 8
     sleeptimer -1
     timerdev   DI_NightAndDay
     timerevent cmd_nr: 1,cmd: 1,cmd_event: timer_1,cmd_1
     triggerDev DI_NightAndDay
     timerevents:
       cmd_nr: 1
       cmd: 1
       cmd_event: timer_1
       cmd_1
     timereventsState:
       cmd_nr: 1
       cmd: 1
       cmd_event: timer_1
       state: cmd_1
     triggerEvents:
       cmd_nr: 1
       cmd: 1
       cmd_event: timer_1
       cmd_1
     triggerEventsState:
       cmd_nr: 1
       cmd: 1
       cmd_event: timer_1
       state: cmd_1
   internals:
     0           D_ArrivalExpected:STATE
     all         D_ArrivalExpected:STATE
   interval:
     0          -1
     1          0
     2          -1
     3          2
     4          -1
     5          4
     6          -1
     7          6
   itimer:
     all         AS_MyPlace
   localtime:
     0          1538322840
     1          1538339400
     2          1538322840
     3          1538336700
     4          1538364600
     5          1538368260
     6          1538368200
     7          1538368260
   readings:
     0           DI_NightAndDay:IsDaylight
     all         DI_NightAndDay:IsDaylight
   realtime:
     0          17:54:00
     1          22:30:00
     2          17:54:00
     3          21:45:00
     4          05:30:00
     5          06:31:00
     6          06:30:00
     7          06:31:00
   time:
     0          [AS_MyPlace:CustomTwilightEvening]
     1          22:30:00
     2          [AS_MyPlace:CustomTwilightEvening]
     3          21:45:00
     4          05:30:00
     5          [AS_MyPlace:CustomTwilightMorning]
     6          06:30:00
     7          [AS_MyPlace:CustomTwilightMorning]
   timeCond:
     0          0
     1          0
     2          0
     3          0
     4          0
     5          0
     6          0
     7          0
   timer:
     0          0
     1          0
     2          0
     3          0
     4          0
     5          0
     6          0
     7          0
   timers:
     0           0  1  2  3  4  5  6  7
   trigger:
   triggertime:
     1538322840:
       localtime  1538322840
       hash:
     1538336700:
       localtime  1538336700
       hash:
     1538339400:
       localtime  1538339400
       hash:
     1538364600:
       localtime  1538364600
       hash:
     1538368200:
       localtime  1538368200
       hash:
     1538368260:
       localtime  1538368260
       hash:
   uiState:
   uiTable:
Attributes:
   room       Aussen


Problem dabei ist die stündliche Neuberechnung der SunSet und SunRise Werte. Die Außenbeleuchtung springt morgens korrekt an, geht aber niemals aus - da inzwischen ASTRO den Wert CustomTwilightMorning auf den nächsten Tag verschoben hat.

Selbst wenn ich die Neuberechnung von ASTRO auf 12 oder 24h erhöhe, kann ich immer noch genau dieses Fenster der Beleuchtung morgens erwischen...

D_ArrivalExpected ist ein Dummy, der signalisiert ob jemand aus der Familie spät nachts nach Hause kommt. Dann soll die Beleuchtung an bleiben. DI_NightAndDay ist ein DOIF, welches Tag/Nacht signalisiert - spart wiederholende Berechnungen in diesem DOIF.

Mache ich hier was falsch und/oder gibt es hierfür eine Lösung?

Danke, -MN

[throbin]

Hi,

war schon mal aufgetreten, danach erfolgreich gefixt (siehe Beiträge auf Seite 18), Nun tritt die Warnung wieder auf:

Code Auswählen Erweitern


2018.10.04 07:34:32.467 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4584.
2018.10.04 07:34:32.468 1: stacktrace:
2018.10.04 07:34:32.468 1:     main::__ANON__                      called by fhem.pl (4584)
2018.10.04 07:34:32.468 1:     main::readingsBulkUpdateIfChanged   called by ./FHEM/95_Astro.pm (1354)
2018.10.04 07:34:32.469 1:     main::Astro_Update                  called by fhem.pl (3140)
2018.10.04 07:34:32.469 1:     main::HandleTimeout                 called by fhem.pl (649)


LG

[frank]

feines modul.
läuft scheinbar alles prächtig. denn ich konnte heute die schmale, blasse mondsichel tagsüber trotz sonnenschein relativ schnell finden.

gibt es eventuell die absicht das modul um weitere planeten zu erweitern? der modulname klingt zumindestens schon mal vielversprechend. 

[Prof. Dr. Peter Henning]

scheinbar

Wieso scheinbar ?

Der Mond ist ja kein Planet ...
Und auf Gezeiten haben nur Mond und Sonne im Rahmen privater Genauigkeit messbaren Einfluss.

LG

pah