neues Modul Astro.pm

[Prof. Dr. Peter Henning]

Für mein in Arbeit befindliches Hausautomatisierungsmodul habe ich etwas mehr Daten über Sonne und Mond benötigt.
Ich habe mir daher erlaubt, die Routinen von dieser Seite hier: http://lexikon.astronomie.info/java/sunmoon/ von ein paar kleineren Fehlern zu befreien und nach Perl zu migrieren.

Resultat ist das angehängte Modul. Dazu sollten für den eigenen Standort die globalen Attribute
(Edit: Modul ist eingecheckt und wird per Update verteilt)

Code Auswählen Erweitern

attr global longitude <wert>
attr global latitude <wert>
attr global altitude <wert>

gesetzt werden. Mit

Code Auswählen Erweitern

define IRGENDEINNAME Astro
wird dann ein Astro-Device angelegt, dessen Readings periodisch upgedated werden (default 1 Stunde), das aber auch mit Parametern aufgerufen werden kann.

Der Nutzen liegt z.B. darin, dass man sich für einen Tag in der Zukunft den Sonnenaufgang anzeigen lassen kann.

LG

pah

[betateilchen]

Falls es erlaubt ist, ohne dass mir wieder irgendeine Geflügelverschlepperei nach Südosteuropa vorgeworfen wird, hier (m)ein Tipp zum einfachen automatischen Laden des Moduls in FHEM:

• die Moduldatei habe ich umbenannt in AstroUtils.pm (ohne Zahl davor)
• am Anfang meiner 99_myUtils.pm habe ich ein "require AstroUtils;" eingefügt

Da die 99_myUtils.pm beim FHEM-Start vor allen anderen Moduldateien geladen wird, ist somit sichergestellt, dass die Funktionen aus dem Modul sehr frühzeitig verfügbar sind und es keine Probleme gibt, falls irgendein Device darauf zugreifen möchte.

[Prof. Dr. Peter Henning]

Udo, ich baue noch ziemlich viel an diesen Dingen herum - eventuell wird daraus sogar ein Astro"-Device.

LG

pah

[betateilchen]

Wenn das mein Modul wäre, würde ich die Werte einfach als JSON zurückliefern, fhem.pl stellt dazu seit einiger Zeit eine eigene Funktion toJSON() bereit, mit der man beliebige Datentypen (scalar, array, hash) auf simpelste Weise in json konvertieren kann.

eventuell wird daraus sogar ein Astro"-Device.

Dann hättest Du aber immer noch das "Reihenfolge-Problem" beim Start von FHEM, sofern andere devices auf readings dieses Astro-devices zugreifen wollen, bevor es definiert ist.

[Prof. Dr. Peter Henning]

Wieso ich ?

LG

pah

[betateilchen]

Weil Du als Maintainer eines solchen zukünftig vielleicht existierenden Moduls den Anwendern das Verhalten im "Fehlerfall" erklären müsstest 

[justme1968]

es gibt irgendwo einen thread bei dem es um die abhäbgigkeit von devices untereinander ging und die probleme die es beim start machen kann.

diese probleme kann man vermeiden in dem man nicht in der DefineFn versucht aufs andere device zuzugreifen sondern erst verzögert nach dem fhem komplett läuft. die verzögerungen bekommt man entweder durch eine NotifyFn auf global:INITIALIZED oder durch einen InternalTimer mit verzögerung 0.

d.h. es ist aufgabe des benutzenden moduls und nicht des bereitstellenden moduls das 'richtig' zu machen.

gruss
  andre

[Prof. Dr. Peter Henning]

@betateilchen: "Müsste", soso. Wie gesagt:

Wurks.

Sehe ich nicht so.

@justme1968: Das geht noch viel einfacher. Selbstrverständlich 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.

LG

pah

[justme1968]

das oben bezog sich auf den zugriff auf readings.

klar geht der aufruf einer routine auch direkt. jedenfalls so lange das andere modul damit klar kommt das es eventuell noch kein eigenes device und irgendwelche initialisierungen noch nicht gelaufen sind die z.b. eigene attribute benötigen.

gruss
  andre

[betateilchen]

@justme1968: Das geht noch viel einfacher. Selbstrverständlich 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
um den Sonnenaufgang an Heiligabend 2019 zu bekommen.

Das ist doch genau das,

was ich in meinem Beitrag https://forum.fhem.de/index.php/topic,73951.msg656393.html#msg656393

vorgeschlagen habe? Wenn man das require in die 99_myUtils.pm packt,

• muss man das nur einmal tun
• KANN das auch jeder Anwender tun, weil es "seine" Datei ist
• hat man die Funktionen aus einem so geladenen Modul zum frühestmöglichen Zeitpunkt zur Verfügung und muss sich über Reihenfolgen keine Gedanken mehr machen. Warum nicht einfach die Mechanismen nutzen, die FHEM bereits bietet?

[Prof. Dr. Peter Henning]

Leute, worüber diskutieren wir hier eigentlich ?

Udo wollte mir ausreden, daraus ein Device zu machen. Wollte ich aber. Ich habe gepostet, dass man _seinen_ Vorschlag auch mit einem Device-Modul umsetzen kann.

Also herrscht doch Mir, Druschba, Blini.

LG

pah

[Morgennebel]

Also herrscht doch Mir, Druschba, Blini.

Klär mich auf, bitte...

Ciao, -MN

[CoolTux]

Hi KugelblitzIn, sollte Tevje der MiLchmann die Milch der frommen Denkungsart hier ausgegossen haben ? Dann würden ja Mir, Druschba, Blini herrschen und alle Kratzbäume wären mehr als flüssig... Und wo bleibt unser geliebter Zoo aus den diversen (Un) Tierchen ?

[justme1968]

zum eigentlichen thema:

wie wäre es pro device den globalen standort mit instanz attributen überschreiben zu können um sich ein device mit den readings für einen anderen ort anzulegen?

gruss
  andre

[Prof. Dr. Peter Henning]

André: Gute Idee. Ich schau mal auf mein Zeitbudget.

Morgennebel: Friede, Freundschaft, Eierkuchen (nicht ganz, aber die sind dort unbekannt).

LG

pah