Autor Thema: neues Modul Astro.pm  (Gelesen 60785 mal)

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3656
  • ~ Challenging Innovation ~
Antw:neues Modul Astro.pm
« Antwort #360 am: 04 Juli 2019, 17:45:48 »
Alles außer englisch ist optional. Daher wird in FHEM auch automatisch auf die englische Hilfe umgeleitet, wenn die commandref in der über "language" gesetzten Sprache nicht verfügbar ist.


Man kann ein Modul nicht ohne einen deutschen Abschnitt ins SVN einchecken, soweit ich weiß. Es sei denn daran hat sich etwas geändert.
Egal - es war und ist pah's Entscheidung den deutschen Abschnitt drin zu haben. Deal with it ;)
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Offline mahowi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1086
Antw:neues Modul Astro.pm
« Antwort #361 am: 04 Juli 2019, 20:24:41 »

Man kann ein Modul nicht ohne einen deutschen Abschnitt ins SVN einchecken, soweit ich weiß. Es sei denn daran hat sich etwas geändert.
Egal - es war und ist pah's Entscheidung den deutschen Abschnitt drin zu haben. Deal with it ;)

Es ist natürlich nicht so, daß ich nicht damit klar komme.  ;)

Ich finde es halt nur intuitiver, wenn mir eine englische Hilfe angezeigt wird anstatt einem nicht so hilfreichen Text, das es keine deutsche Hilfe gibt.

Das ist eigentlich auch von Rudi so angedacht:
Falls man keine deutsche Hilfe anbietet, dann sollte man bitte nichts hinschreiben und auch keinen Abschnitt dafuer anlegen.
Leider ist eine automatische Pruefung auf eine explizit formulierte "keine Hilfe" nicht so einfach, das sollte also bitte der Modulautor entfernen.

Aber ich will da niemanden reinreden, war nur ein Vorschlag.  8) Das hier ist ja nicht das einzige Modul, bei dem es so ist.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

Offline Prof. Dr. Peter Henning

  • Developer
  • Hero Member
  • ****
  • Beiträge: 6814
Antw:neues Modul Astro.pm
« Antwort #362 am: 05 Juli 2019, 11:06:09 »
Eben.

LG

pah

Offline Ellert

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3605
Antw:neues Modul Astro.pm
« Antwort #363 am: 05 Juli 2019, 19:17:42 »
Eben.

LG

pah

Dann gibt es ja keinen Grund mehr, es zu ändern.
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3656
  • ~ Challenging Innovation ~
Antw:neues Modul Astro.pm
« Antwort #364 am: 07 Juli 2019, 12:12:33 »
Ich habe gerade experimentell in Astro einen Kompatibilitätsmodus für SUNRISE_EL eingebaut.


Zur Info: Das Experiment wurde beendet. Es wird keine Möglichkeit geben Astro Daten über die von SUNRISE_EL bekannten Funktionen zu verwenden. Eigene Funktionen braucht es IMHO nicht, denn Astro liefert entsprechende Readings, mit denen man arbeiten kann.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3656
  • ~ Challenging Innovation ~
Antw:neues Modul Astro.pm
« Antwort #365 am: 10 Juli 2019, 11:18:58 »
Als Kompromiss gibt es ab morgen jetzt Funktionen von Astro, die sich genauso wie die von SUNRISE_EL verhalten, jedoch unter einem leicht anderen Namen zu verwenden sind:



asunrise, asunset,
asunrise_rel, asunset_rel
asunrise_abs, asunset_abs
asunrise_abs_dat, asunrise_abs_dat
aisday


Wie man sieht heißen die Funktionen genauso und man muss lediglich ein "a" voranstellen.
Natürlich muss man entweder ein Astro Device definiert haben oder zumindest ein


LoadModule('Astro');


in die eigene 99_myUtils.pm eintragen, damit die Funktionen auch geladen werden.


Entscheidet man sich für ein eigenes Astro Device, dann werden dessen Einstellungen berücksichtigt, wenn man es beim define mit dem Zusatz "global" versieht. Ein solches Astro Device kann es nur einmal pro FHEM Instanz geben. Als Einstellungsmöglichkeit ist dabei insbesondere das Attribut "horizon" interessant, ebenfalls in Verbindung mit unterschiedlichen Werten für "morgens" und "abends". aisday() liefert deshalb keinen Wert nur basierend auf HORIZON=-6 wie isday() zurück, sondern eben aufgrund des Attributs des globalen Astro Device. Dadurch muss man nicht bei jeder Verwendung von isday() den eigenen Wert für HORIZON wiederholen bzw. mehrfach angeben.


Damit gibt es nun ein Werkzeug, um SUNRISE_EL mit Astro zu ersetzen. Allerdings obliegt es dem Benutzer bzw. den Modulautoren, die alternativen Funktionen zu verwenden bzw. anzubieten und auch konsequent an allen Stellen anzuwenden, um eine Datenkonsistenz zu gewährleisten.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline andies

  • Hero Member
  • *****
  • Beiträge: 2261
Antw:neues Modul Astro.pm
« Antwort #366 am: 11 Oktober 2019, 18:28:34 »
pah, ich habe eine Frage zu Deinem Modul. Ich lasse mir Sunrise und Sunset ausgeben und die Werte sind ja genauer als die "klassischen" Funktionen in FHEM:
sub ZeitenSetzen(){
my $timestamp = POSIX::strftime("%Y-%m-%dT", localtime).ReadingsVal("Astro", "SunSet", "").":00";
my $seconds = time_str2num($timestamp)-18*60;
my $result = POSIX::strftime("%H:%M",localtime($seconds));
fhem("setreading Sonne ShbtStart ".$result);
$result = ReadingsVal("Astro", "CustomTwilightEvening", "");
fhem("setreading Sonne ShbtEnde ".$result);
fhem("save");
}
Astro selbst ist so definiert, dass dort alle 8h ein Neuberechnung folgt, also
Internals:
   FUUID      5c782b59-f33f-1115-26ab-8a735ed2122df348
   FVERSION   95_Astro.pm:v2.0.0-s19656/2019-06-19
   INTERVAL   28800
   NAME       Astro
   NEXTUPDATE 2019-10-11 22:40:47
   NOTIFYDEV  global
   NR         142
   NTFY_ORDER 50-Astro
   STATE      Updated
   TYPE       Astro
   READINGS:
     2019-10-11 06:40:47   AstroTwilightEvening 20:15
     2019-10-11 06:40:47   AstroTwilightMorning 05:31
     2019-10-11 06:40:47   CivilTwilightEvening 18:56
     2019-10-11 06:40:47   CivilTwilightMorning 06:50
     2019-10-11 06:40:47   CustomTwilightEvening 19:13
     2019-10-11 06:40:47   CustomTwilightMorning 06:34
     2019-10-11 14:40:47   MoonAge         154.1
     2019-10-11 14:40:47   MoonAlt         -31
     2019-10-11 14:40:47   MoonAz          59.5
     2019-10-11 14:40:47   MoonDec         -8.2
     2019-10-09 22:40:47   MoonDiameter    29.5
     2019-10-11 14:40:47   MoonDistance    405422
     2019-10-11 14:40:47   MoonDistanceObserver 408750
     2019-10-11 06:40:47   MoonHrsInvisible 13:51
     2019-10-11 06:40:47   MoonHrsVisible  10:08
     2019-10-11 14:40:47   MoonLat         -4.7
     2019-10-11 14:40:47   MoonLon         351.9
     2019-10-06 22:40:44   MoonPhaseI      3
     2019-10-11 14:40:47   MoonPhaseN      0.95
     2019-10-06 22:40:44   MoonPhaseS      Zunehmender Mond
     2019-10-11 14:40:47   MoonRa          23:41
     2019-10-11 06:40:47   MoonRise        18:09
     2019-10-11 06:40:47   MoonSet         04:17
     2019-10-09 22:40:47   MoonSign        Fische
     2019-10-11 06:40:47   MoonTransit     23:41
     2019-10-11 06:40:47   NauticTwilightEvening 19:36
     2019-10-11 06:40:47   NauticTwilightMorning 06:11
     2018-08-27 22:39:01   ObsAlt          10
     2019-10-11 06:40:47   ObsDate         11.10.2019
     2019-10-11 06:40:47   ObsDayofyear    284
     2019-10-11 14:40:47   ObsGMST         14:00:03
     2018-09-08 21:51:44   ObsHor          -8.5
     2019-06-20 22:33:01   ObsHorEvening   -8.5
     2019-06-20 22:33:01   ObsHorMorning   -8.5
     2019-03-31 08:24:06   ObsIsDST        1
     2019-10-11 14:40:47   ObsJD           2458768.03
     2019-10-11 14:40:47   ObsLMST         14:52:32
     2018-08-25 14:02:59   ObsLat          52.4596
     2018-08-25 14:02:59   ObsLon          13.1187513
     2019-09-23 06:40:43   ObsSeason       Herbst
     2019-09-23 06:40:43   ObsSeasonN      3
     2019-10-11 14:40:47   ObsTime         14:40:47
     2019-03-31 08:24:06   ObsTimezone     2
     2019-06-20 22:33:01   ObsTimezoneS    CEST
     2019-10-11 14:40:47   SunAlt          26.4
     2019-10-11 14:40:47   SunAz           209.7
     2019-10-11 14:40:47   SunDec          -6.9
     2019-10-01 14:40:44   SunDiameter     32
     2019-10-11 14:40:47   SunDistance     149332407
     2019-10-11 14:40:47   SunDistanceObserver 149329567
     2019-10-11 06:40:47   SunHrsInvisible 13:02
     2019-10-11 06:40:47   SunHrsVisible   10:57
     2019-10-11 14:40:47   SunLon          197.9
     2019-10-10 22:40:47   SunRa           13:05
     2019-10-11 06:40:47   SunRise         07:25
     2019-10-11 06:40:47   SunSet          18:22
     2019-09-23 14:40:43   SunSign         Waage
     2019-10-09 06:40:44   SunTransit      12:54
     2019-10-11 14:40:47   state           Updated
Attributes:
   group      intern
   horizon    -8.5
   interval   28800
Nun bilde ich mir ein, dass sich der Zeitpunkt des Sonnenuntergangs zwischen verschiedenen Abrufen (leicht) verschiebt. Heute früh war das mW 18:09, jetzt ist es wenige Minuten später. Ist das der Fall oder mache ich da was falsch? Und wenn sich das verschiebt, weißt Du zufällig, wie man formal dann den "richtigen" Sonnenuntergangszeitpunkt definiert?
FHEM 5.9 auf RaspPi3 (Raspbian:  4.14.34-v7+ ); Perl: v5.20.2
SIGNALduino (433 MHz) und HM-UART (868 MHz)
wenige Brennenstuhl-IT, Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Offline Prof. Dr. Peter Henning

  • Developer
  • Hero Member
  • ****
  • Beiträge: 6814
Antw:neues Modul Astro.pm
« Antwort #367 am: 12 Oktober 2019, 07:02:02 »
Wundert mich ...

Das wird iterativ berechnet, ich muss mal überprüfen, was da los ist.

"Formal": klar, Sonnenrand am Horizont.

LG

pah

 

decade-submarginal