neues Modul Astro.pm

Begonnen von Prof. Dr. Peter Henning, 05 Juli 2017, 21:39:21

Vorheriges Thema - Nächstes Thema

Bäschdler

Zitat von: Frank_Huber am 20 Januar 2019, 14:45:23
schonmal mit {twilight("myLocation","CivilTwilightMorning","04:00","09:30")} versucht?
myLocation sollte dein Astro device sein.

Ähm - twilight ist doch das alte Modul das ich los werden will weil es nicht mehr mit Daten von Yahoo versorgt wird...

Ich brauche die Definition von Astro

Frank_Huber

{twilight.....} ist eine Perl Funktion und hat mit dem Modul nichts zu tun.
versuchs einfach...

CoolTux

Zitat von: Frank_Huber am 20 Januar 2019, 17:44:13
{twilight.....} ist eine Perl Funktion und hat mit dem Modul nichts zu tun.
versuchs einfach...

Halb und halb. Die Funktion kommt aus dem Modul Twilight.
Aber davon mal ab funktioniert das Modul auch ohne Yahoo eins a. Man muss sich nur kurz damit beschäftigen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

AnBad

#318
Ich wollte ein weblink mit dem Pfad zum Mondbild "befüllen". Leider klappt es nicht. Kann mir jemand helfen?


sub MondbildAsHtml()
{
my $link = sprintf('<img src="');
$link .= sprintf(ReadingsVal('Astrodaten', 'Mondbild', ""));
$link .= sprintf('">');
return $link;
}
1;


define Mondbildlink weblink htmlCode MondbildAsHtml()}

khk123

Ich zeige das Bild auf der FHEM Weboberfläche an:


devStateIcon { '<div><img src='.ReadingsVal($name,"Mondbild","0").' height="100" width="100">' }
FHEM6.2, RasPi4, RasPi Zero W,
CUL V3, HM, ZWave, IT, vcontrol, owntracks, alexa

AnBad

Ja,
das ist Cool.
Vielen Dank!!

Prof. Dr. Peter Henning

Das geht auch einfacher, nämlich ohne zusätzlichen Perl-Aufruf mit einem einfachen
<embed ...>
im stateFormat. Oder über einen weblink

define Moon weblink image http://192.168.0.193:8083/fhem/Astro_moonwidget?name='Astronomie'

LG

pah

mi.ke

@pah
Sehr detailiertes und für mich, sehr wertvolles Modul.
Vielen Dank, dass Du es mit uns teilst.

Cheers
mi.ke

FHEM 5.9 | RPi4 + 5 x RPi(Z) + FB7590 + FB 6890 LTE via LAN und WAN (VPN) verbunden.
2 x CUL868 + 3 x RFXTRX(e) + 6 x HMwLanGW + 4 x z2tGw + 5 x LGW + 2 x IRBlast + CO2 +++
FS20, FHT, FMS, Elro(mod), CM160, Revolt, LGTV, STV, AVR, withings, HM-sec-*, HM-CC-RT-DN, AMAD, PCA301, arlo, Aqara

Ellert

Ich erhalte hier im Norden seit einer Woche alle 5 Minuten eine Mitteilung im Log, das Werte nicht berechnet werden können.

Wäre es möglich den Loglevel von 3 auf 4 zu ändern, da bei dem Befehl Log das Modulattribut verbose nicht greift und ich den globalen Attributwert nicht auf 2 ändern möchte.

Es Betrifft die Zeilen 941, 955, 969, 983



Loredo

Wäre es möglich die Abhängigkeit zur Systemsprache zu lösen?


Wenn man Automationen schreibt, dann möchte man dies nicht in einer Vermischung aus Englisch und Deutsch tun. Es wäre daher gut, wenn die Standard Readings immer in einer verlässlichen Sprache wären (=Englisch) und man zusätzlich eine weitere Sprache zur Darstellung definieren könnte, für die dann zusätzliche Readings erzeugt werden.
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

Prof. Dr. Peter Henning

ZitatIch erhalte hier im Norden seit einer Woche alle 5 Minuten eine Mitteilung im Log, das Werte nicht berechnet werden können.

Es wäre ja sehr nett zu wissen, welche Meldungen das sind. Ich vermute mal, dass es wegen der jahreszeitlichen Nähe zum Mittsommer die astronomischen Dämmerungswerte sind - aber bitt emal die Meldungen posten.

ZitatWäre es möglich die Abhängigkeit zur Systemsprache zu lösen?
Nein, denn das habe ich in anderen Modulen auch so umgesetzt und will diese Konsistenz nicht aufgeben. Tipp: alles auf Englisch machen, und selbst userReadings generieren, welche die entsprechenden Daten dann auf Deutsch präsentieren. Mache ich sowieso, die Vielzahl der Readings von Astro lasse ich mir nie anzeigen.

LG

pah

Ellert

#326
Zitat von: Prof. Dr. Peter Henning am 18 Mai 2019, 19:55:13
Es wäre ja sehr nett zu wissen, welche Meldungen das sind. Ich vermute mal, dass es wegen der jahreszeitlichen Nähe zum Mittsommer die astronomischen Dämmerungswerte sind - aber bitt emal die Meldungen posten.
Nein, denn das habe ich in anderen Modulen auch so umgesetzt und will diese Konsistenz nicht aufgeben. Tipp: alles auf Englisch machen, und selbst userReadings generieren, welche die entsprechenden Daten dann auf Deutsch präsentieren. Mache ich sowieso, die Vielzahl der Readings von Astro lasse ich mir nie anzeigen.

LG

pah
Ich ging davon aus, dass die Zeilennummern reichen, dort werden die Meldungen generiert.

Dann hier auch die erzeugten Meldungen, ein Auszug hoffe ich reicht
Zitat2019.05.18 02:01:16.295 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 02:06:16.478 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 02:11:16.661 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 02:16:16.874 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 02:21:17.085 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 02:26:17.299 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 02:31:17.479 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 02:36:17.702 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 02:41:17.918 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 02:46:18.106 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 02:51:18.296 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 02:56:18.477 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 03:01:18.695 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 03:06:18.878 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 03:11:19.060 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 03:16:19.242 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 03:21:19.427 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 03:26:19.644 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 03:31:19.856 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 03:36:20.037 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 03:41:20.221 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 03:46:20.439 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 03:51:20.656 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 03:56:20.870 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 04:01:21.045 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 04:06:21.237 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 04:11:21.418 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 04:16:21.604 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 04:21:21.814 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 04:26:22.028 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 04:31:22.239 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 04:36:22.420 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 04:41:22.636 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 04:46:22.856 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 04:51:23.069 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
2019.05.18 04:56:23.295 3: [Astro_SunRise] no solution possible for astronomical twilight - maybe the sun never sets below -18 degrees?
Die Logeinträge werden mit meinem Vorschlag verhindert, nicht nur für astronomical und meinem Standort.

Anbei die Datei mit meinem eingearbeiteten Vorschlag, als schnelle Lösung.

Prof. Dr. Peter Henning

Habe die kleine Änderung eingecheckt.

LG

pah

Loredo

Zitat von: Prof. Dr. Peter Henning am 18 Mai 2019, 19:55:13
Nein, denn das habe ich in anderen Modulen auch so umgesetzt und will diese Konsistenz nicht aufgeben. Tipp: alles auf Englisch machen, und selbst userReadings generieren, welche die entsprechenden Daten dann auf Deutsch präsentieren. Mache ich sowieso, die Vielzahl der Readings von Astro lasse ich mir nie anzeigen.

Verstehe ich und kann man so machen, ja.
Allerdings muss dann wieder jeder User selbst ran, um im Grunde das gleiche zu erreichen wie viele andere vor ihm.

Die Locale richtig zu setzen hat in der Tat seinen Charme, aber ich verstehe ich verstehe noch nicht so ganz den Zusammenhang zum globalen FHEM Attribut "language". Muss ich dann quasi selbst sicherstellen, dass das globale Attribut zur Locale passt?

Du könntest natürlich die LANG/LC_* Umgebungsvariablen auch im lokalen Perl Kontext deines Moduls so setzen, wie es sich der Benutzer über das globale Attribut "language" gewünscht hat (ja, das Format passt nicht direkt). Vorausgesetzt die Locale steht beim System auch zur Verfügung, braucht der Benutzer dann zumindest nicht mehr über sein System eingreifen, sondern hat seine FHEM Konfiguration transportabel.

Ich habe gerade für das Docker Image einmal geschaut und dort folgende Standardwerte hinterlegt, mit denen man zwar die grundsätzliche Systemsprache in Englisch hält, die Werte jedoch in europäischem Format erhält:


LANG=en_US.UTF-8}
LANGUAGE=en_US:en
LC_MEASUREMENT=de_DE.UTF-8
LC_MESSAGES=en_DK.UTF-8
LC_MONETARY=de_DE.UTF-8
LC_NUMERIC=de_DE.UTF-8
LC_PAPER=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8
LC_TIME=en_DK.UTF-8


Das ergibt bereits einen ziemlich guten paneuropäischen Standard. Für das Astro Modul ist LC_TIME entscheidend, mit en_DK bekommt man ein etwas europäisch angehauchtes Format. Setzt man es auch noch auf de_DE.UTF-8, sind alle Datums und Zeitangaben in deutscher Sprache, Systemausgaben bleiben jedoch in Englisch und somit kompatibel.

Im Astro Modul könntest du also mittels folgender Zeile vor dem jeweiligen System(nahen) Aufruf die Sprache über Perl festlegen:


local $ENV{LC_TIME} = 'de_DE.UTF-8';


Das local sorgt dafür, dass andere Perl Module nicht beeinflusst werden.
Wahrscheinlich könntest du so relativ einfach auf die Systemfunktionen für die Formatierung zurückgreifen und trotzdem eine brauchbare Flexibilität für die Sprache einbauen, auch mehrere Sprachen parallel gingen damit.






<OT>

Je nachdem wer hier noch so mitliest: Nutzt man Systemaufrufe aus FHEM/Perl heraus, bei denen eine konsistente Rückgabe von Werten unabhängig der Sprache notwendig ist, dann setzt man direkt vor dem Systembefehl ein LC_ALL=C und überlagert somit alle anderen Sprachvorgaben. Somit muss man sich bei der Auswertung des Rückgabewertes nur um eine Sprache bemühen. Bei SSH Verbindungen erhält man keine Warnungen mehr, wenn die für den FHEM Benutzer gesetzte Sprache auf dem entfernten System nicht zur Verfügung steht.

</OT>
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

the ratman

servus,

nur ne info:
krieg seit heute bei neustarts von fhem folgendes warning2019.05.20 08:54:15 1: PERL WARNING: Argument "[Astro_Get] astro has improper time specification MoonAg..." isn't numeric in addition (+) at ./FHEM/95_Astro.pm line 1289.
2019.05.20 08:54:15 1: stacktrace:
2019.05.20 08:54:15 1:     main::__ANON__                      called by ./FHEM/95_Astro.pm (1289)
2019.05.20 08:54:15 1:     main::Astro_moonwidget              called by ./FHEM/01_FHEMWEB.pm (926)
2019.05.20 08:54:15 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (567)
2019.05.20 08:54:15 1:     main::FW_Read                       called by fhem.pl (3749)
2019.05.20 08:54:15 1:     main::CallFn                        called by fhem.pl (748)
→do↑p!dnʇs↓shit←