neues Modul Astro.pm

[Loredo]

Hallo pah,

ich habe hier einen Patch für Astro geschrieben:

1. weitere Sprachen hinzugefügt (ES,FR,IT,NL,PL)
2. Sprachen jetzt auch über Device Attribut konfigurierbar
3. Meteorologische Jahreszeit hinzugefügt (ObsMeteoSeason)
4. Phänologische Jahreszeit hinzugefügt (ObsPhenoSeason) - nur für Standorte in Mitteleuropa
5. Schaltjahr hinzugefügt (ObsIsLeapyear, ObsYearRemainD, ObsYearProgress, ObsMonthRemainD, ObsMonthProgress) / neue Funktion IsLeapyear()
6. Analog zu Dayofyear wurde die Woche hinzugefügt (ObsWeekofyear)
7. Dauer für Tag (SunHrsVisible) und Nacht (SunHrsInvisible) hinzugefügt; analog dazu gibt es auch MoonHrsVisible und MoonHrsInvisible
8. Saisonale und temporale Stunden hinzugefügt (ObsSeasonalHr, ObsSeasonalHrR, ObsSeasonalHrs, ObsSeasonalHrLenDay, ObsSeasonalHrLenNight, ObsSeasonalHrTNext, ObsSeasonalHrT[<ObsSeasonalHr>])
9. Relative Tageszeit (also sowas wie Morgen/Mittag/Abend/Nacht, jedoch basierend auf den 12 temporalen Stunden und somit viel feiner) (ObsDaytime, ObsDaytimeN); Unterstützung für römische Stunden.
10. Neuer Setter "update", um ein manuelles Update zu triggern
11. Neues Attribut "disable", mit dem man das Device komplett deaktivieren/sperren kann.
12. Neues Attribut "recomputeAt", um zusätzlich zum Interval auch eine Neuberechnung um 00:00:00 Uhr und/oder zum Beginn der nächsten saisonalen/temporalen Stunde auszulösen.
13. "get json" enthält jetzt auch ungerundete Werte, die relevanten Readingnamen sind dafür unter gleichem Namen mit vorangestelltem Punkt enthalten (werden daher nicht als Readings in FHEMWEB angezeigt, stehen aber grundsätzlich bereit)
14. neues Internal NEXTUPDATE zur Anzeige des nächsten Updates
15. Unterschiedliche Horizonte für Twilight morgens/abends möglich
16. Azimuth als Kompassangabe (SunCompass, SunCompassI, SunCompassS, MoonCompass, MoonCompassI, MoonCompassS) / neue Funktion Deg2CP()
17. Vorbelegte Widgets für set, get, attr
18. HTML Anker Namen korrigiert
19. Attribute können als Kommando Parameter an den Getter übergeben werden, beispielsweise language=XX, um eine andere Sprache zu erhalten
20. Flexiblere Datum/Zeitangabe bei get json/text: Uhrzeit ohne Datum
21. Änderungsindikatoren für den Tag bevor ein Ereignis eintritt und am Ereignistag (aktuell beim Wechsel der Jahreszeiten, beim Wechsel Normalzeit<>Sommerzeit, Tierkreiszeichen Sonne/Mond, Mondphase)
22. Zeitplaner mit allen für den Tag berechneten Ereignissen (ObsSched*). Außerdem Anzeige welches Ereignis als nächstes eintreten wird bzw. welches zuletzt eingetreten ist.
23. CommandRef um entsprechende Punkte erweitert
25. Nummernformat für Textausgabe basierend auf LC_NUMERIC (auch abhängig von language Attribut, dadurch unabhängig von Systemvorgaben)
26. Änderung der Zeitzone über timezone Attribut (unabhängig der Systemvorgaben)
27. Darstellung Rektaszension in HHMM korrigiert (in Übereinstimmung mit CommanRef)

Strukturelle Änderungen am Code:
1. Umgestellt von "package main" auf "package FHEM::Astro" (damit Entfernung des Präfix "Astro_" in vielen Bereichen; Funktionen Astro_Initialize() und Astro_Get() werden nach main:: exportiert)
2. Export von Transtable und anderen Hash Tabellen zur Nutzung in anderen Modulen
3. Rudimentäre Unterstützung für Meta.pm
4. Neue Funktion DistOnEarth() (habe keine existierende Funktion dafür ausfindig machen können)
5. Neue Funktion DaysOfMonth()
6. Neue Funktion Arabic2Roman()
7. FHEMWEB FORKABLE=0 Tippfehler gefixt
8. INTERVAL Internal wird immer angezeigt, auch wenn Attribut nicht gesetzt ist
9. Attribut Liste wird aus Hash generiert
10. Verbesserte Reading Aktualisierung über Notify() Funktion
11. Verbesserte Eingabeprüfung für Attribute
12. HHMM[SS]() Umgang mit Integer Werten verbessert
13. Mond Transit und Untergang: Tippfehler in Variablenname korrigiert
14. Generierung der Datum/Zeit Basisdaten in eigene Funktion SetTime() ausgelagert
15. Verwendung von JSON::XS zur besseren Performance und "beautify" Output bei verbose>3, toJSON() als Fallback
16. %Astro und %Date beinhalten in {1} und {2} die Werte der Nachfolgetage (wird derzeit für die vorausschauende Berechnung der Zeiten für den Wechsel der saisonalen/temporalen Stunden verwendet)
17. %Astro und %Date beinhalten in {-1} und {-2} die Werte der Vorgängertage (wird derzeit für die vorausschauende Berechnung für den Wechsel der Jahreszeiten verwendet)
18. Aktivierung von parseParams, um über Astro_Get() auch andere Attributwerte übergeben zu können, wenn kein Astro Device definiert wurde. Erübrigt das temporäre Anlegen eines echten Devices unter $attr{<name>}

Habe versucht mir dabei Mühe zu geben und hoffe der Patch sagt dir zu, so dass er übernommen werden kann.
Ich würde gerne anschließend einiges aus UConv.pm entfernen.


Natürlich hätte ich die Jahreszeiten auch wieder in ein extra Modul packen können, schicker fände ich es jedoch, wenn es gleich in Astro mitkäme.




Viele Grüße
Julian




EDIT: Patch entfernt und per PM geschickt

[Prof. Dr. Peter Henning]

Schau ich mir an, dauert aber bis zu 2 Wochen, da ich gerade im Antragsstress bin.

LG

pah

[Loredo]

Um diese Uhrzeit [bist du wach]? 😟


Exzellent [, dann warte ich - vielen Dank!] 😆






* Edit: Nachricht durch kursiven Text zur Verdeutlichung ergänzt.

[Loredo]

Nur weil sich ja wohl einige den Patch runtergeladen haben:
Ich habe noch einige Änderungen vorgenommen.


Edit: Saisonale/temporale Stunden hinzugefügt.

[flummy1978]

Nur weil sich ja wohl einige den Patch runtergeladen haben:

Sorry, für die unwissende Anfängerfrage:
Aber wie spiele ich den Patch denn korrekterweise ein? Bisher habe ich nur die Updates normal bezogen und nicht manuell etwas gemacht 

Grüße
Andreas

[Loredo]

Du musst die heruntergeladene Datei nach /opt/fhem/FHEM kopieren und dann über die Kommandozeile den Patch einspielen:

Code Auswählen Erweitern


patch 95_Astro.pm 95_Astro.pm.patch


Schau auch mal hier für mehr Details.

Die Datei 95_Astro.pm.patch kannst du anschließend löschen. Wenn die gepatchte Version nicht überschrieben werden soll, dann musst du noch exclude_from_update beim global Device anpassen.

[flummy1978]

DANKEschön ... schon erledigt 

Komisch dass ich das sonst nicht gefunden hab ... aber wohl weil es über die Kommandozeile gemacht wird und somit nichts mit FHEM ansich, sondern mit der Systemoberfläche

Danke nochmal

Grüße
Andreas

[Prof. Dr. Peter Henning]

Leute, ich weise auf Eines hin:

"gepatchte" Dateien unterliegen keinem Support durch mich, außerdem ist die Verwendung ohne entsprechenden Vermerk "gepatchte Version, basiert auf der Software xyz" eine klare Verletzung der GPL.

Wir haben auch bei FHEM klare Regeln, wie Software entwickelt wird. Und dazu gehört auch, dass man dem Maintainer ausreichend Zeit einräumt, Änderungswünsche zu realisieren.

Etwas säuerlich

pah

[CoolTux]

Ich stimme pah da zu. Sowas sollte wirklich vom Modulauthor eingepflegt werden.
Auf der anderen Seite fehlt uns aber auch eine Möglichkeit vernünftig solche Patche entgegen zu nehmen. Über das Forum finde ich es suboptimal. So ein pull Request wäre da schön 

[Loredo]

Und wo genau liegt jetzt mein Fehler? [emoji47]

[nils_]

außerdem ist die Verwendung ohne entsprechenden Vermerk "gepatchte Version, basiert auf der Software xyz" eine klare Verletzung der GPL.

ist das echt so?? ich dachte immer - achtung, gefährliches halbwissen - das eine veröffentlichung ausreicht?!

Ich stimme pah da zu. Sowas sollte wirklich vom Modulauthor eingepflegt werden.
Auf der anderen Seite fehlt uns aber auch eine Möglichkeit vernünftig solche Patche entgegen zu nehmen. Über das Forum finde ich es suboptimal.

patche(s) geht ja noch. komplette module finde ich noch kritischer. dann wird es komplett undurchschaubar, was die korrekte version ist und wer dafür verantwortlich ist / sich verantwortlich fühlt.

So ein pull Request wäre da schön 

da hat wohl jemand gefallen an git(hub) gefunden

[Prof. Dr. Peter Henning]

Hmmm. Nicht in der Arbeit, die Du da hineingesteckt hast.

Den Patch aber hier zu veröffentlichen, war nicht so klug - denn jetzt muss ich bis auf Weiteres bei jeder Frage erst herausfinden, ob es sich um die gepatchte Version handelt.

Außerdem finde ich Patches sowieso nicht gut, den ich habe hervorragende Werkzeuge, um zwei Dateiversionen zu vergleichen und sie abschnittsweise aneinander anzugleichen.

Vorschlag also: Den Patch hier löschen, und mir Deine per PM geänderte Gesamtdatei zukommen lassen. Vor dem 4.6. komme ich aber nicht mehr dazu.

LG

pah

[CoolTux]

Und wo genau liegt jetzt mein Fehler? [emoji47]

Bei dem was aktuell offiziell gegeben ist um Patches zu verwalten, würde ich sagen hast Du keinen Fehler gemacht.

außerdem ist die Verwendung ohne entsprechenden Vermerk "gepatchte Version, basiert auf der Software xyz" eine klare Verletzung der GPL.

Einzig das hier wäre eventuell etwas wo man in Zukunft drauf achtet das man das mit gibt.

Aber darum ging es pah bestimmt nicht, er war halt gerade nur etwas säuerlich.
Aber wie gesagt, im Prinzip stimme ich pah zu. Das Problem ist uns fehlt ein Patchmanagement und so lange wir das nicht haben fehlt ein Hinweis an die User das vom Modulauthor ungeprüfte Patches vom Support ausgeschlossen sind.
Gerade die Entwickler welche wenig Zeit für Support haben wollen den Helfen der mit einer offiziellen Version unterwegs ist.


Grüße

[nils_]

vielleicht solltet ihr das mal mit den anderen Devs diskutieren.

pah zB mag patches nicht gerne und möchte lieber die gesamtmodule
jemand anderes will lieber patches
der nächste will pull requests
usw....

und natürlich auch das "wie und wo stelle ich einen patch zur verfügung".


ich persönlich finde den austausch über das forum auch eher suboptimal, da gibt es in manchen threads verschiedene modulversionen und dann patches zwischendurch, und dann auch noch über manchmal 100 seiten. da dann die richtige version zu finden  ist schwierig, und konkrete hilfestellung geben genauso, da nie klar ist wer was benutzt.

aber nu genug OT hier

[Prof. Dr. Peter Henning]

Viele Individualisten in FHEM es gibt!

pah