Zuerst: Danke für die Überarbeitung an alle Beteiligten.
Heute habe ich umgestellt auf das neue Modul + DarkSkyApi, funktioniert soweit auch ganz gut. Zwei Dinge hätte ich für die Wunschliste.
- Luftdruckangabe in hPa fände ich zeitgemäßer als mbar (im Reading state)
- ein Attribut "expert" (analog zu HomeMatic) mit dem man den Umfang der dargestellten Readings einstellen kann. In manchen Fällen brauche ich gar keine forecast, in anderen Fällen nur die nächsten zwei Tage. Gab es nicht früher ein solches Attribut in dem Modul?
wie umgestellt?
dachte erst morgen?
Per FHEM Update ab morgen. Im SVN wird es schon liegen.
Hallo Udo,
Ein expert Mode finde ich gut. Das deaktivieren des Forcast ist ohne weiteres Möglich, wenn man den Code entsprechend an passt.
Ein beschränken des Forcast nur bedingt. Der Forcast kann Stunden sein (wie bei OpenWeatherMap) oder eben Tage. Müsste man mal schauen. Im Grunde würde man nur sagen wie viel Forecast Datensätze geschrieben werden sollen. Egal ob Tage oder Stunden gemeint sind.
Das von Dir gemeinte Attribut ist bestimmt das welches Du beim erstellen des Weblinks als 2 Parameter an die Funktion mit übergibst.
Grüße
Ja, kann sein, dass ich das mit dem weblink verwechsle.
Ob forecast sich auf Stunden oder Tage bezieht, ist mir eigentlich wurscht. Wenn ich expert = 3 setze, möchte ich gern drei Datensätze haben. Wenn ich expert = 0 setze, gar keine. Wenn das Attribut fehlt = alle anzeigen.
Zwei Dinge sind mir in der commandref aufgefallen
- bei den readings steht .locense statt .license
- die Tabellen zu den API sind sehr unübersichtlich, insbesondere weil bei openweathermap plötzlich darkskyapi drinsteht
Zitat von: betateilchen am 12 Januar 2019, 20:52:35
Ja, kann sein, dass ich das mit dem weblink verwechsle.
Ob forecast sich auf Stunden oder Tage bezieht, ist mir eigentlich wurscht. Wenn ich expert = 3 setze, möchte ich gern drei Datensätze haben. Wenn ich expert = 0 setze, gar keine. Wenn das Attribut fehlt = alle anzeigen.
Zwei Dinge sind mir in der commandref aufgefallen
- bei den readings steht .locense statt .license
- die Tabellen zu den API sind sehr unübersichtlich, insbesondere weil bei openweathermap plötzlich darkskyapi drinsteht
Vielen Dank für die Bug Meldung.
Bei Deinem Beispiel würde ich nicht auf das Attribut expert kommen sondern eher als Attribut forecast nehmen.
forecast 3
Drei Datensätze für Forecast. Bei Null keine und wenn kein Attribut alle.
Was hälst davon? Oder verstehe ich Dich da nicht richtig?
Grüße
Vielleicht wäre es besser, das Attribut eher forecast oder forecastCount oder noch besser forecastLimit zu nennen, statt expert. Es handelt sich ja nicht um einen Expertenmodus im eigentlichen Sinn.
gb#
Edit: 2 Dumme ein Gedanke ;D
forecastLimit gefällt mir!
nenne es, wie Du willst :)
Es geht wieder um das unlösbare Thema "Standardisierung" in FHEM, darüber will ich nicht schon wieder diskutieren.
Zitat von: betateilchen am 12 Januar 2019, 21:07:56
nenne es, wie Du willst :)
Es geht wieder um das unlösbare Thema "Standardisierung" in FHEM, darüber will ich nicht schon wieder diskutieren.
Gerade bei Standardisierung bin ich voll bei Dir.
Expert ist schön und gut, sagt aber erstmal nur aus das man mehr Möglichkeiten hat. Entweder mehr setter oder mehr getter, oder mehr Attribute die Sichtbar werden. So wäre zu mindest meine Auffassung.
Ich werde morgen mal was vorbereiten mit forecastLimit und es in mein Git schupsen. Würde mich freuen wenn Du es dann testen magst. Ich gebe Bescheid wenn es soweit ist.
Tschuldigung, wenn ich da kurz einhake (bitte ignorieren wenn ich falsch liege) - ich bin mir nicht ganz sicher, ob das selbe Verständnis bezüglich forecastLimit besteht
* Udo hätte gerne die Möglichkeit "den Umfang der dargestellten Readings " einzustellen - bei gleichbleibender Funktionalität (kompletter Forecast wird geladen)
* Unter forecastLimit würde ich verstehen, dass nur n Datensätze geladen werden (Proplanta kann das)
Ich fände beide Funktionalitäten gut, wobei ich - ehrlich gesagt - sehr selten in das Modul reinschaue, außer ich will irgendwas basteln - meistens bekomme ich alles was ich häufig brauche über readingsgroup/weblink...
Zitat von: KernSani am 12 Januar 2019, 21:36:54
Tschuldigung, wenn ich da kurz einhake (bitte ignorieren wenn ich falsch liege) - ich bin mir nicht ganz sicher, ob das selbe Verständnis bezüglich forecastLimit besteht
* Udo hätte gerne die Möglichkeit "den Umfang der dargestellten Readings " einzustellen - bei gleichbleibender Funktionalität (kompletter Forecast wird geladen)
* Unter forecastLimit würde ich verstehen, dass nur n Datensätze geladen werden (Proplanta kann das)
Ich fände beide Funktionalitäten gut, wobei ich - ehrlich gesagt - sehr selten in das Modul reinschaue, außer ich will irgendwas basteln - meistens bekomme ich alles was ich häufig brauche über readingsgroup/weblink...
Da stehe ich gerade auf dem Schlauch.
Wo ist da jetzt der Unterschied? Aber um es mal kurz zu sagen. Es werden immer alle Forecastdaten vom Anbieter geladen und auch im erstellten API Object als Cache vorgehalten. Nur das scheiben der Readings wird begrenzt auf die Anzahl welche angegeben ist. So wäre meine Idee.
Bei den jetzigen API's ginge das noch nicht mal das nur n Forcast Datensätze geladen werden.
Proplantana
Zitat von: CoolTux am 12 Januar 2019, 21:49:49
Da stehe ich gerade auf dem Schlauch.
Wo ist da jetzt der Unterschied? Aber um es mal kurz zu sagen. Es werden immer alle Forecastdaten vom Anbieter geladen und auch im erstellten API Object als Cache vorgehalten. Nur das scheiben der Readings wird begrenzt auf die Anzahl welche angegeben ist. So wäre meine Idee.
Bei den jetzigen API's ginge das noch nicht mal das nur n Forcast Datensätze geladen werden.
Ok, dann bitte ignorieren ;-) Ich habe dein Forecast-Limit so verstanden, wie das bei Proplanta der Fall ist - dass einfach weniger Daten geladen werden. Einen "expert" level dagegen so, dass nicht nur die Anzahl der angezeigten FC-days, sondern möglicherweise auch die Art der readings in der Anzeige eingeschränkt wird.
Mir geht es darum, dass nur eine bestimmte Anzahl von readings aus den vom Wetterdienst geladenen Daten erzeugt wird.
Welchen Sinn es hat, den gesamten Datenbestand im Cache vorzuhalten, verstehe ich nicht. Muss ich aber auch nicht.
Ich hätte gerne (Wünschdirwas!) einen Filter, z.B. per Regex oder so, mit dem ich sagen kann: Bitte erzeuge nur die Readings für die Bewölkung / den UV-Index / whatever, gerne kombiniert mit einem Limit auf die vorhergesagten Tage. Proplanta z.B. erzeugt Myriaden an Readings, die bestimmt irgendwie interessant sind, die ich aber aktuell nicht brauche - aber vielleicht in Zukunft und deshalb sollte das konfigurierbar sein. Proplanta erzeugt aktuell rund 720 Readings, von denen ich maximal 10 oder so benutze.
Auch ich habe heute umgestellt. Vielen Dank für eure Arbeit!
Eine Frage habe ich, die mir die (neue) CommandRef nicht beantwortet. Wie im alten Modul gibt es "Code" als Reading für die aktuellen Wetterverhältnisse. Bislang habe ich diesen Yahoo-Code als einen Baustein meiner Beschattung ausgewertet. Im überarbeiteten Modul gibt es den Code weiterhin als Reading. In der DarkSkyAPI-Beschreibung taucht "code" nicht auf. Übersetzt das neue Modul verschiedene Informationen von DarkSky in die alten Yahoo-Codes? Dann wäre ein Hinweis irgendwo darauf ganz nützlich.
Ob ich den Code noch länger verwenden muss, prüfe ich gerade, da das neue Modul ja eine Reihe Readings liefert, die Yahoo nicht hatte (oder ich dort zumindest nie wahrgenommen habe, als ich danach gesucht habe im letzten Sommer).
Gruß
Christian
Zitat von: cbl am 13 Januar 2019, 11:58:21
Auch ich habe heute umgestellt. Vielen Dank für eure Arbeit!
Eine Frage habe ich, die mir die (neue) CommandRef nicht beantwortet. Wie im alten Modul gibt es "Code" als Reading für die aktuellen Wetterverhältnisse. Bislang habe ich diesen Yahoo-Code als einen Baustein meiner Beschattung ausgewertet. Im überarbeiteten Modul gibt es den Code weiterhin als Reading. In der DarkSkyAPI-Beschreibung taucht "code" nicht auf. Übersetzt das neue Modul verschiedene Informationen von DarkSky in die alten Yahoo-Codes? Dann wäre ein Hinweis irgendwo darauf ganz nützlich.
Ob ich den Code noch länger verwenden muss, prüfe ich gerade, da das neue Modul ja eine Reihe Readings liefert, die Yahoo nicht hatte (oder ich dort zumindest nie wahrgenommen habe, als ich danach gesucht habe im letzten Sommer).
Gruß
Christian
Hallo Chris,
Wir haben versucht so weit wie möglich kompatibel zu Yahoo zu bleiben, daher werden die Informationen der API versucht in Yahoo Codes zu übersetzen.
Grüße
ich habe auf OpenWeatherMapAPI umgestellt.
ich bekomme jetzt 3-stundenreadings (hfc1_.. - hfc40_..)
kann ich irgendwie die alten Tages-readings (fc1_.. - fc10_..) bekommen?
Aktuell nur mit der DarkSky API
Ich habe sowohl die DarkSkyAPI als auch die OpenWeatherMapAPI in Benutzung.
Ich erhalte folgende codes und conditions:
Bei OpenWeatherMap:
code
35
2019-01-13 13:50:42
condition
Mäßiger Regen
2019-01-13 13:50:42
Bei DarkSky:
code
11
2019-01-13 13:40:40
condition
Leichter Regen und Wind
2019-01-13 13:40:40
Das ist inhaltlich sicher ähnlich, aber nicht identisch. Da ich die Yahoo-Wettercodes für einen Schutz einer Verschattungsanlage gegen "Schlechtwetter" eingesetzt habe, ist mir dran gelegen, zuverlässige und verbindliche codes und/oder conditions zu bekommen.
Gibt es eine Liste oder ist eine geplant dieser codes oder conditions? Kann ich unterstützend tätig werden?
Viele Grüße Gisbert
and (([?weatherStahnsdorfYahoo:code] >= 0 and [?weatherStahnsdorfYahoo:code] < 5) or ([?weatherStahnsdorfYahoo:code] > 22 and [?weatherStahnsdorfYahoo:code] < 25)
So habe ich das bei mir als Beispiel seit Jahren in Verwendung. Für Regen!
Aktuell kann ich nichts anderes anbieten. Unterschiedliche Meldungen ergeben unterschiedliche Mappings.
Ok verstehe.
Im Moment habe ich bei OpenWeatherMap:
code 9 2019-01-13 15:23:22
condition Nieselregen 2019-01-13 15:23:22
d.h. dann müsstest du deine Bedingungen ändern, falls du Regen feststellen möchtest (ich nehme mal an, dass Nieselregen auch unter Regen fällt).
So, hab auch problemlos (vielen Dank) umgestellt
Zitat von: betateilchen am 12 Januar 2019, 20:34:24
- Luftdruckangabe in hPa fände ich zeitgemäßer als mbar (im Reading state)
Fände ich auch besser.
Ich weiss, ich bin jetzt bestimmt pingelig. :-\
Und bitte wie bei den anderen Wettermodulen auch verwendet 'H' und nicht 'F' für Luftfeuchtigkeit
Cheers
mi.ke
1. Dank an die "Macher"; ich bin gerade dabei es einzurichten.
2. Zwei ganz kleine Hinweise zur deutschen Dokumentation:
Define
define <name> Weather [API=<API>[,<apiotions>]] [apikey=<apikey>] [location=<location>] [interval=<interval>] [lang=<lang>]
Die Parameter haben die folgende Bedeutung:
. . . .
Bei "apiotions' fehlt das 'p'.
Ein kleines Stück darunter zu 'API-spezifischen Dokumentation':
OpenWeatherMap
API DarkSkyAPI
Müsste dort dann nicht statt 'DarkSkyAPI' 'OpenWeatherMapAPI' stehen ?
Schönen Abend
Peter
Ich habe das neue Wetter-Modul nun doch mit OpenWeather zum Laufen gebracht.
Wäre es möglich im State zwischen dem Typ und dem Wert ein Leerzeichen zu setzen?
Also anstatt:
T:8°C F:87% W:11km/h P:1002mbar
eher
T: 8°C F: 87% W: 11km/h P: 1002mbar
Das wäre in meinen Augen besser lesbar und würde in einem Plot die Regexp erleichtern (dort heißt die Regexp nun nämlich "Wetter.T:8°C" und lässt sich nicht darstellen).
Die Yahoo API hat seinerzeit keinen Maßeinheit aufgeführt, wäre für mich und den Plot auch ok
T: 0 H: 92 W: 8 P: 992
Zitat von: PNinBB am 13 Januar 2019, 17:05:25
1. Dank an die "Macher"; ich bin gerade dabei es einzurichten.
2. Zwei ganz kleine Hinweise zur deutschen Dokumentation:
Define
define <name> Weather [API=<API>[,<apiotions>]] [apikey=<apikey>] [location=<location>] [interval=<interval>] [lang=<lang>]
Die Parameter haben die folgende Bedeutung:
. . . .
Bei "apiotions' fehlt das 'p'.
Ein kleines Stück darunter zu 'API-spezifischen Dokumentation':
OpenWeatherMap
API DarkSkyAPI
Müsste dort dann nicht statt 'DarkSkyAPI' 'OpenWeatherMapAPI' stehen ?
Schönen Abend
Peter
Danke Dir. Das werde ich noch korrigieren.
Zitat von: Felix_86 am 13 Januar 2019, 17:22:06
Ich habe das neue Wetter-Modul nun doch mit OpenWeather zum Laufen gebracht.
Wäre es möglich im State zwischen dem Typ und dem Wert ein Leerzeichen zu setzen?
Also anstatt:
T:8°C F:87% W:11km/h P:1002mbar
eher
T: 8°C F: 87% W: 11km/h P: 1002mbar
Das wäre in meinen Augen besser lesbar und würde in einem Plot die Regexp erleichtern (dort heißt die Regexp nun nämlich "Wetter.T:8°C" und lässt sich nicht darstellen).
Die Yahoo API hat seinerzeit keinen Maßeinheit aufgeführt, wäre für mich und den Plot auch ok
T: 0 H: 92 W: 8 P: 992
Ich denke darüber lässt sich reden. Also das mit dem Leerzeichen.
Mir ist was aufgefallen bei der Windgeschwindigkeit: Anstatt km/h müssten es m/s sein. Ich habe es mit der Webseite verglichen. Immerhin ein Faktor 3,6 Unterschied ;-)
Zitat von: macs am 13 Januar 2019, 18:06:27
Mir ist was aufgefallen bei der Windgeschwindigkeit: Anstatt km/h müssten es m/s sein. Ich habe es mit der Webseite verglichen. Immerhin ein Faktor 3,6 Unterschied ;-)
Cool hatte mich schon gewundert das das so gering ist, aber bei mir war das immer recht Windstill. Bei ich heute Abend um, oder besser erweitere ich.
Danke
Ich habe eben noch mal geschaut. Zu mindest für DarkSky sind es km/h
Zitat
except that windSpeed and windGust are in kilometers per hour
bei OpenWeatherMap sind es m/s
Zitat von: CoolTux am 13 Januar 2019, 18:28:47
Ich habe eben noch mal geschaut. Zu mindest für DarkSky sind es km/h
Bei mir liefern aber beide APIs nahezu gleiche Werte.
Diese kommen mir aber in der Tat etwas klein vor.
hmmm....
Zitat von: CoolTux am 13 Januar 2019, 18:28:47
Ich habe eben noch mal geschaut. Zu mindest für DarkSky sind es km/h
Aktuell über DarkSkyApi zeigt es "wind_speed 12" und
condition "Frische Brise und überwiegend bewölkt" an.
Laut Definition:
Starker Wind 10,8 - 13,8 m/s | 39 - 49 Km/h | 22 - 27 Knt | 6 Bft
scheinen es doch m/s zu sein.
Cheers
mi.ke
Also ich kann gerne pro forma ein 3.6 Faktor einbauen. Alternativ kann bitte jemand mit der Webansicht vergleichen?
Moin,
es sind tatsächlich m/s in den Readings. In Wilhelmshaven lt. Reading 11, lt. Website 39.
LG
Andreas
Zitat von: rischbiter123 am 13 Januar 2019, 19:11:29
Moin,
es sind tatsächlich m/s in den Readings. In Wilhelmshaven lt. Reading 11, lt. Website 39.
LG
Andreas
Danke Dir. Ich habe auch gerade mal geschaut und kann das bestätigen.
Wie ist das weitere Vorgehen bei den Windgeschwindigkeiten bei DarkSky und bei OpenWeatherMap? Ich wäre für km/h in Fhem.
Ich auch. Vorerst werde ich es auch so einsetzen.
Müssen schauen wie es mit Leuten ist die in Gegenden leben wo milen eine Rolle spielt.
Zitat von: CoolTux am 13 Januar 2019, 19:41:26
Ich auch. Vorerst werde ich es auch so einsetzen.
Müssen schauen wie es mit Leuten ist die in Gegenden leben wo milen eine Rolle spielt.
könnte man nicht über die System locale prüfen welche Einheiten ein System verwendet?
Nein. Entscheidend ist wie der Lieferant die Daten liefert. Aktuell ist bei beiden APIs auto aktiv, es wird also anhand der Location entsprechend geliefert.
Grüße
Hallo,
erst einmal vielen Dank für dei schnelle Änderung des Moduls.
Mit DarkSky, einer Wegwerf-Mailadresse und 10 Minuten frickeln, konnte alles anpassen.
Eine kleine Anmerkung meinerseits: Die Wochentage werden leider trotz Spracheinstellung lang=de gekürzt auf Englisch übergeben.
Wenn ich mir die Vorhersage anschaue, bin ich auch nicht sonderlich glücklich:
Condition= Vormittag frische Brise und Nachmittag Nebel.
precipProbability=0.91
Also für mich eigentlich Regenwetter.
Kann man daran noch was machen oder ist man auf die Daten von DarkSky angewiesen?
Ich bin gerade beim Einrichten von OpenWeatherMap und wundere mich über Details des eingerichteten Gerätes.
define WetterOpenWetter Weather api=OpenWeatherMapAPI,cachemaxage:600 apikey=xxxxxxxxxxxxxxxxxxx interval=3600 language=de
In der eingerichteten Instanz wird als API allerdings DarkSkyAPI ausgewiesen.
Internals:
API DarkSkyAPI
APIKEY xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
APIOPTIONS cachemaxage:600
DEF api=OpenWeatherMapAPI,cachemaxage:600 apikey=xxxxxxxxxxxxxxxxxxxxx interval=3600 language=de
INTERVAL 3600
LANG de
LOCATION xx.yyyyyy,xx.yyyyyyyy
NAME WetterOpenWetter
NOTIFYDEV global
NR 524
NTFY_ORDER 50-WetterOpenWetter
STATE API Maintainer: Leon Gaultier (<a href=https://forum.fhem.de/index.php?action=profile;u=13684>CoolTux</a>) ErrorMsg: DarkSky Weather decode JSON err malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "permission denied\n") at FHEM/DarkSkyAPI.pm line 192.
TYPE Weather
Ist das so in Ordnung ??
Danke für einen Hinweis.
Peter
Wie vielerorts beschrieben, muss API groß geschrieben werden.
Hallo,
für die WebLink-Anzeige der stündlichen Vorhersage habe ich folgenden Änderungsvorschlag sub WeatherAsHtmlH ( ab Zeile 549 ):
my $ret = '<table class="weather">';
my $fc = ( (defined($h->{READINGS}->{fc1_day_of_week}) and $h->{READINGS}->{fc1_day_of_week}) ? 'fc' : 'hfc' );
my $DayHour = ($fc eq 'fc' ? '_day_of_week' : '_pubDate' );
# icons
$ret .= sprintf('<tr><td class="weatherIcon" width=%d>%s</td>', $width, WeatherIconIMGTag(ReadingsVal($d, "icon", "")));
for(my $i=1; $i<$items; $i++) {
$ret .= sprintf('<td class="weatherIcon" width=%d>%s</td>', $width, WeatherIconIMGTag(ReadingsVal($d, "${fc}${i}_icon", "")));
}
$ret .= '</tr>';
# condition
$ret .= sprintf('<tr><td class="weatherDay">%s</td>', ReadingsVal($d, "condition", ""));
for(my $i=1; $i<$items; $i++) {
$ret .= sprintf('<td class="weatherDay">%s: %s</td>', ReadingsVal($d, "${fc}${i}$DayHour", ""),
ReadingsVal($d, "${fc}${i}_condition", ""));
}
$ret .= '</tr>';
Damit wird nicht nur der Tag angezeigt.
gleiches für WeatherAsHtmlV (ab Zeile 513):
my $fc = ( (defined($h->{READINGS}->{fc1_day_of_week}) and $h->{READINGS}->{fc1_day_of_week}) ? 'fc' : 'hfc' );
my $DayHour = ($fc eq 'fc' ? '_day_of_week' : '_pubDate' );
for(my $i=1; $i<$items; $i++) {
$ret .= sprintf('<tr><td class="weatherIcon" width=%d>%s</td><td class="weatherValue"><span class="weatherDay">%s: %s</span><br><span class="weatherMin">min %s°C</span> <span class="weatherMax">max %s°C</span></td></tr>',
$width,
WeatherIconIMGTag(ReadingsVal($d, "${fc}${i}_icon", "")),
ReadingsVal($d, "${fc}${i}$DayHour", ""),
ReadingsVal($d, "${fc}${i}_condition", ""),
ReadingsVal($d, "${fc}${i}_low_c", ""), ReadingsVal($d, "${fc}${i}_high_c", ""));
}
Beste Grüße
Lippie
Wie vielerorts beschrieben, muss API groß geschrieben werden.
Danke für den Tipp; gleich ging es !
Noch ein Fehler in der deutschen Dokumentation: dort ist 'api' in den Beispielen klein geschrieben. Von dort hatte ich es kopiert und angepasst !
Schönen Abend.
Peter
Zitat von: bastelfeak am 13 Januar 2019, 20:07:32
Hallo,
erst einmal vielen Dank für dei schnelle Änderung des Moduls.
Mit DarkSky, einer Wegwerf-Mailadresse und 10 Minuten frickeln, konnte alles anpassen.
Eine kleine Anmerkung meinerseits: Die Wochentage werden leider trotz Spracheinstellung lang=de gekürzt auf Englisch übergeben.
Wenn ich mir die Vorhersage anschaue, bin ich auch nicht sonderlich glücklich:
Condition= Vormittag frische Brise und Nachmittag Nebel.
precipProbability=0.91
Also für mich eigentlich Regenwetter.
Kann man daran noch was machen oder ist man auf die Daten von DarkSky angewiesen?
Das liegt an Deiner locale Einstellung von der linux distrie wo das FHEM drauf läuft. Die ist bei Dir englisch.
in der DarkSkyAPI werden für die daily-forecasts werte wie partly-cloudy-night und clear-night ausgegeben. Das sieht etwas unschön aus bei der täglichen Wettervorhersage.
ich habe die Zuordnung bei mir folgendermaßen geändert:
my %codes_day = (
'clear-day' => 32,
'clear-night' => 32,
'rain' => 11,
'snow' => 16,
'sleet' => 18,
'wind' => 24,
'fog' => 20,
'cloudy' => 26,
'partly-cloudy-day' => 30,
'partly-cloudy-night' => 30,
'hail' => 17,
'thunderstorm' => 4,
'tornado' => 0,
);
Dazu noch zu Lookup-Funktion für daily-Abfragen:
'code' => $codes_day{ $data->{daily}->{data}->[$i]->{icon} }
Grüße
Lippie
Da ich nach der Umstellung auf OpenWeatherMapAPI jetzt nur 3-stundenreadings (hfc1_.. - hfc40_..) bekomme, hab ich mir eine function in 99_myUtils gebaut, die die alten Tages-readings (fc1_.. - fc10_..) und den pressure_trend_txt so gut wie möglich nachbaut...
sub calcWeather
{
my ($w, $rest) = @_;
Log 2, "calcWeather(\"$w\")";
my $hfcCnt=0;
my $fcCnt=0;
my $Dday="";
my $Ddate="";
my $Dcode="";
my $Dcondition="";
my $Dpressure="";
my $Dhigh_c=0;
my $Dlow_c=0;
my $Dicon="";
my $p1=0;
my $p2=0;
#my $pubDate=ReadingsVal($w, "hfc${hfcCnt}_pubDate",0);
#my $d=substr($pubDate,0,3);
for ($hfcCnt=1; $hfcCnt<=40; $hfcCnt++)
{
my $pubDate =ReadingsVal($w, "hfc${hfcCnt}_pubDate",0);
my $code =ReadingsVal($w, "hfc${hfcCnt}_code",0);
my $condition=ReadingsVal($w, "hfc${hfcCnt}_condition",0);
my $pressure =ReadingsVal($w, "hfc${hfcCnt}_pressure",0);
my $icon =ReadingsVal($w, "hfc${hfcCnt}_icon",0);
my $high_c =ReadingsVal($w, "hfc${hfcCnt}_high_c",0);
my $low_c =ReadingsVal($w, "hfc${hfcCnt}_low_c",0);
my $day =substr($pubDate,0,3);
my $date=substr($pubDate,5);
if ( $day ne $Dday )
{
if ($fcCnt > 0)
{
fhem( "setreading $w fc${fcCnt}_high_c $Dhigh_c; setreading $w fc${fcCnt}_low_c $Dlow_c; setreading $w fc${fcCnt}_icon $Dicon; setreading $w fc${fcCnt}_code $Dcode; setreading $w fc${fcCnt}_condition $Dcondition; setreading $w fc${fcCnt}_date $Ddate; setreading $w fc${fcCnt}_day_of_week $Dday; setreading $w fc${fcCnt}_pressure $Dpressure; ");
}
$fcCnt++;
$Dday =$day ;
$Ddate =$date;
$Dcode =$code;
$Dcondition=$condition;
$Dpressure =$pressure;
$Dicon =$icon;
$Dhigh_c =$high_c;
$Dlow_c =$low_c;
$p1=$pressure if ($fcCnt==1);
$p2=$pressure if ($fcCnt==2);
}else{
$Dhigh_c = $high_c if ( $high_c > $Dhigh_c );
$Dlow_c = $low_c if ( $low_c < $Dlow_c );
if ( $date =~ /12:00/ )
{
$Ddate =$date;
$Dcode =$code;
$Dcondition=$condition;
$Dpressure =$pressure;
$Dicon =$icon;
$p1=$pressure if ($fcCnt==1);
$p2=$pressure if ($fcCnt==2);
}
}
}
my $fcCntNext=$fcCnt+1;
fhem( "setreading $w fc${fcCnt}_high_c $Dhigh_c; setreading $w fc${fcCnt}_low_c $Dlow_c; setreading $w fc${fcCnt}_icon $Dicon; setreading $w fc${fcCnt}_code $Dcode; setreading $w fc${fcCnt}_condition $Dcondition; setreading $w fc${fcCnt}_date $Ddate; setreading $w fc${fcCnt}_day_of_week $Dday; setreading $w fc${fcCnt}_pressure $Dpressure; deletereading $w fc${fcCntNext}_.*; ");
my $Dp= $p2 - $p1;
my $pTxt="";
if ( $Dp > 24 )
{ $pTxt="stark steigend"; }
elsif ( $Dp > 6 )
{ $pTxt="steigend"; }
elsif ( $Dp > -6 )
{ $pTxt="gleichbleibend"; }
elsif ( $Dp > -24 )
{ $pTxt="fallend"; }
else
{ $pTxt="stark fallend"; }
fhem( "setreading $w pressure_trend_txt $pTxt ");
}
ich triggere diese function mit einem notify.
def n_WetterVorschau notify WetterVorschau:current_date_time.* { calcWeather($NAME) }
könnt ihr diese function in die OpenWeatherMapAPI übernehmen?
danke
didi
Noch eine kleine Frage zum 'update'.
Werden diese Abfragen 'non-blocking' ausgeführt? Ich vermute doch: ja. Ich habe aber weder in den Einstellungen noch in den Attributen etwas zum Einstellen gefunden.
Wenn ich 'update' anstosse, sieht man auch keinen weiteren Prozess.
Nochmals besten Dank
Peter
Zitat von: didi-fritz am 14 Januar 2019, 07:22:25
Da ich nach der Umstellung auf OpenWeatherMapAPI jetzt nur 3-stundenreadings (hfc1_.. - hfc40_..) bekomme, hab ich mir eine function in 99_myUtils gebaut, die die alten Tages-readings (fc1_.. - fc10_..) und den pressure_trend_txt so gut wie möglich nachbaut...
sub calcWeather
{
my ($w, $rest) = @_;
Log 2, "calcWeather(\"$w\")";
my $hfcCnt=0;
my $fcCnt=0;
my $Dday="";
my $Ddate="";
my $Dcode="";
my $Dcondition="";
my $Dpressure="";
my $Dhigh_c=0;
my $Dlow_c=0;
my $Dicon="";
my $p1=0;
my $p2=0;
#my $pubDate=ReadingsVal($w, "hfc${hfcCnt}_pubDate",0);
#my $d=substr($pubDate,0,3);
for ($hfcCnt=1; $hfcCnt<=40; $hfcCnt++)
{
my $pubDate =ReadingsVal($w, "hfc${hfcCnt}_pubDate",0);
my $code =ReadingsVal($w, "hfc${hfcCnt}_code",0);
my $condition=ReadingsVal($w, "hfc${hfcCnt}_condition",0);
my $pressure =ReadingsVal($w, "hfc${hfcCnt}_pressure",0);
my $icon =ReadingsVal($w, "hfc${hfcCnt}_icon",0);
my $high_c =ReadingsVal($w, "hfc${hfcCnt}_high_c",0);
my $low_c =ReadingsVal($w, "hfc${hfcCnt}_low_c",0);
my $day =substr($pubDate,0,3);
my $date=substr($pubDate,5);
if ( $day ne $Dday )
{
if ($fcCnt > 0)
{
fhem( "setreading $w fc${fcCnt}_high_c $Dhigh_c; setreading $w fc${fcCnt}_low_c $Dlow_c; setreading $w fc${fcCnt}_icon $Dicon; setreading $w fc${fcCnt}_code $Dcode; setreading $w fc${fcCnt}_condition $Dcondition; setreading $w fc${fcCnt}_date $Ddate; setreading $w fc${fcCnt}_day_of_week $Dday; setreading $w fc${fcCnt}_pressure $Dpressure; ");
}
$fcCnt++;
$Dday =$day ;
$Ddate =$date;
$Dcode =$code;
$Dcondition=$condition;
$Dpressure =$pressure;
$Dicon =$icon;
$Dhigh_c =$high_c;
$Dlow_c =$low_c;
$p1=$pressure if ($fcCnt==1);
}else{
$Dhigh_c = $high_c if ( $high_c > $Dhigh_c );
$Dlow_c = $low_c if ( $low_c < $Dlow_c );
if ( $date =~ /12:00 pm/ )
{
$Ddate =$date;
$Dcode =$code;
$Dcondition=$condition;
$Dpressure =$pressure;
$Dicon =$icon;
$p1=$pressure if ($fcCnt==1);
$p2=$pressure if ($fcCnt==2);
}
}
}
fhem( "setreading $w fc${fcCnt}_high_c $Dhigh_c; setreading $w fc${fcCnt}_low_c $Dlow_c; setreading $w fc${fcCnt}_icon $Dicon; setreading $w fc${fcCnt}_code $Dcode; setreading $w fc${fcCnt}_condition $Dcondition; setreading $w fc${fcCnt}_date $Ddate; setreading $w fc${fcCnt}_day_of_week $Dday; setreading $w fc${fcCnt}_pressure $Dpressure; ");
my $Dp= $p2 - $p1;
my $pTxt="";
if ( $Dp > 24 )
{ $pTxt="stark steigend"; }
elsif ( $Dp > 6 )
{ $pTxt="steigend"; }
elsif ( $Dp > -6 )
{ $pTxt="gleichbleibend"; }
elsif ( $Dp > -24 )
{ $pTxt="fallend"; }
else
{ $pTxt="stark fallend"; }
fhem( "setreading $w pressure_trend_txt $pTxt ");
}
ich triggere diese function mit einem notify.
def n_WetterVorschau notify WetterVorschau:current_date_time.* { calcWeather($NAME) }
könnt ihr diese function in die OpenWeatherMapAPI übernehmen?
danke
didi
Hallo,
Deine Funktion kann ich so nicht übernehmen. Sie ist inkompatibel.
Grüße
Zitat von: PNinBB am 14 Januar 2019, 07:35:31
Noch eine kleine Frage zum 'update'.
Werden diese Abfragen 'non-blocking' ausgeführt? Ich vermute doch: ja. Ich habe aber weder in den Einstellungen noch in den Attributen etwas zum Einstellen gefunden.
Wenn ich 'update' anstosse, sieht man auch keinen weiteren Prozess.
Nochmals besten Dank
Peter
Werden non-blocking ausgeführt.
Grüße
Zitat von: CoolTux am 13 Januar 2019, 17:36:03
Ich denke darüber lässt sich reden. Also das mit dem Leerzeichen.
Danke, das Leerzeichen zwischen dem Typ und dem Wert ist nun mit dem heutigen Update drin. Da die Maßeinheit allerdings nicht vom Wert getrennt ist (state T: 3°C F: 93% W: 13km/h P: 1010hPa), findet der Plot keine Werte.
Ich habe mir nun ein userReading gebaut, dass mir das gewünschte Logging-Format erzeugt und schiebe dieses Reading ins Log, anstatt dem echten state-Reading (wie zuvor mit der Yahoo API):
attr WetterAtHome userReadings state4Log {"T: ". ReadingsVal($name,"temperature","")." H: ". ReadingsVal($name,"humidity","")." W: ". ReadingsVal($name,"wind","")." P: ". ReadingsVal($name,"pressure","")}state4Log T: 3 H: 93 W: 13 P: 1010
Zitat von: Felix_86 am 14 Januar 2019, 10:50:35
Danke, das Leerzeichen zwischen dem Typ und dem Wert ist nun mit dem heutigen Update drin. Da die Maßeinheit allerdings nicht vom Wert getrennt ist (state T: 3°C F: 93% W: 13km/h P: 1010hPa), findet der Plot keine Werte.
Ich habe mir nun ein userReading gebaut, dass mir das gewünschte Logging-Format erzeugt und schiebe dieses Reading ins Log, anstatt dem echten state-Reading (wie zuvor mit der Yahoo API):
attr WetterAtHome userReadings state4Log {"T: ". ReadingsVal($name,"temperature","")." H: ". ReadingsVal($name,"humidity","")." W: ". ReadingsVal($name,"wind","")." P: ". ReadingsVal($name,"pressure","")}
state4Log T: 3 H: 93 W: 13 P: 1010
Also wenn das beim alten Weather so war kann ich das sehr gerne auch noch so umbauen. Ist ja nun kein Hexending :-)
Ich hoffe, hier bin ich jetzt richtig. CoolTux hat mich zu 59_Weather weiterverwiesen.
In Verbindung mit Open Weather liefert WeatherAsHtmlH bzw. WeatherAsHtmlHV Stundenwerte. Das ist ganz interessant aber man möchte ja auch die tägliche Vorschau verfolgen können. Könnte man das nicht so machen, dass es zwei Spalten, bzw. Zeilen gibt? Eine wäre dann für die Stundenwerte und die andere für die tägliche Vorschau für z.B. die nächsten 7 Tage.
Zitat von: Felix_86 am 14 Januar 2019, 10:50:35
Danke, das Leerzeichen zwischen dem Typ und dem Wert ist nun mit dem heutigen Update drin. Da die Maßeinheit allerdings nicht vom Wert getrennt ist (state T: 3°C F: 93% W: 13km/h P: 1010hPa), findet der Plot keine Werte.
Ich habe mir nun ein userReading gebaut, dass mir das gewünschte Logging-Format erzeugt und schiebe dieses Reading ins Log, anstatt dem echten state-Reading (wie zuvor mit der Yahoo API):
attr WetterAtHome userReadings state4Log {"T: ". ReadingsVal($name,"temperature","")." H: ". ReadingsVal($name,"humidity","")." W: ". ReadingsVal($name,"wind","")." P: ". ReadingsVal($name,"pressure","")}
state4Log T: 3 H: 93 W: 13 P: 1010
Ich habe das state nun entsprechend formatiert.
Grüße
Hallo,
habe noch eine Änderungsanregung:
Ich habe die WeatherAsHtml... erweitert um einen weiteren Eingangsparameter: (daily | hourly) um die bevorzugte Anzeige der Vorhersage der Funktion übergeben zu können.
Außerdem habe ich für die Anzahl der Vorhersagen abgesichert, so dass die for-Schleife abgebrochen wird, wenn es keine Vorhersage mehr gibt.
Mögliche Weblink-Aufrufe sind damit:
htmlCode { WeatherAsHtmlD("Wetter_UF",["daily"|"hourly"],[Items]) }
hier nun der Quellcode:
sub WeatherAsHtmlV($;$;$)
{
my ($d,$f,$items) = @_;
$d = "<none>" if(!$d);
$f = "daily" if(!$f);
$items = 9 if( !$items );
return "$d is not a Weather instance<br>"
if(!$defs{$d} || $defs{$d}->{TYPE} ne "Weather");
my $h = $defs{$d};
my $width= int(ICONSCALE*ICONWIDTH);
my $test_reading = ($f eq "daily" ? "fc1_day_of_week" : "hfc1_day_of_week");
my $fc1 = ($f eq "daily" ? "fc" : "hfc");
my $fc2 = ($f eq "daily" ? "hfc" : "fc");
my $ret = '<table class="weather">';
$ret .= sprintf('<tr><td class="weatherIcon" width=%d>%s</td><td class="weatherValue">%s<br>%s°C %s%%<br>%s</td></tr>',
$width,
WeatherIconIMGTag(ReadingsVal($d, "icon", "")),
ReadingsVal($d, "condition", ""),
ReadingsVal($d, "temp_c", ""), ReadingsVal($d, "humidity", ""),
ReadingsVal($d, "wind_condition", ""));
my $fc = ( (defined($h->{READINGS}->{$test_reading}) and $h->{READINGS}->{$test_reading}) ? $fc1 : $fc2 );
my $DayHour = ($fc eq 'fc' ? '_day_of_week' : '_pubDate' );
for(my $i=1; $i<$items; $i++) {
if(defined($h->{READINGS}->{"${fc}${i}_icon"}) and $h->{READINGS}->{"${fc}${i}_icon"}){
$ret .= sprintf('<tr><td class="weatherIcon" width=%d>%s</td><td class="weatherValue"><span class="weatherDay">%s: %s</span><br><span class="weatherMin">min %s°C</span> <span class="weatherMax">max %s°C</span></td></tr>',
$width,
WeatherIconIMGTag(ReadingsVal($d, "${fc}${i}_icon", "")),
ReadingsVal($d, "${fc}${i}$DayHour", ""),
ReadingsVal($d, "${fc}${i}_condition", ""),
ReadingsVal($d, "${fc}${i}_low_c", ""), ReadingsVal($d, "${fc}${i}_high_c", ""));
}
}
$ret .= "</table>";
return $ret;
}
sub WeatherAsHtml($;$;$)
{
my ($d,$f,$i) = @_;
$f = "daily" if(!$f);
WeatherAsHtmlV($d,$f,$i);
}
sub WeatherAsHtmlH($;$;$)
{
my ($d,$f,$items) = @_;
$d = "<none>" if(!$d);
$f = "daily" if(!$f);
$items = 9 if( !$items );
return "$d is not a Weather instance<br>"
if(!$defs{$d} || $defs{$d}->{TYPE} ne "Weather");
my $h = $defs{$d};
my $width= int(ICONSCALE*ICONWIDTH);
my $test_reading = ($f eq "daily" ? "fc1_day_of_week" : "hfc1_day_of_week");
my $fc1 = ($f eq "daily" ? "fc" : "hfc");
my $fc2 = ($f eq "daily" ? "hfc" : "fc");
my $format= '<td><table border=1><tr><td class="weatherIcon" width=%d>%s</td></tr><tr><td class="weatherValue">%s</td></tr><tr><td class="weatherValue">%s°C %s%%</td></tr><tr><td class="weatherValue">%s</td></tr></table></td>';
my $ret = '<table class="weather">';
my $fc = ( (defined($h->{READINGS}->{$test_reading}) and $h->{READINGS}->{$test_reading}) ? $fc1 : $fc2 );
my $DayHour = ($fc eq 'fc' ? '_day_of_week' : '_pubDate' );
# icons
$ret .= sprintf('<tr><td class="weatherIcon" width=%d>%s</td>', $width, WeatherIconIMGTag(ReadingsVal($d, "icon", "")));
for(my $i=1; $i<$items; $i++) {
if(defined($h->{READINGS}->{"${fc}${i}_icon"}) and $h->{READINGS}->{"${fc}${i}_icon"}){
$ret .= sprintf('<td class="weatherIcon" width=%d>%s</td>', $width, WeatherIconIMGTag(ReadingsVal($d, "${fc}${i}_icon", "")));
}else{
$items = $i;
}
}
$ret .= '</tr>';
# condition
$ret .= sprintf('<tr><td class="weatherDay">%s</td>', ReadingsVal($d, "condition", ""));
for(my $i=1; $i<$items; $i++) {
$ret .= sprintf('<td class="weatherDay">%s: %s</td>', ReadingsVal($d, "${fc}${i}$DayHour", ""),
ReadingsVal($d, "${fc}${i}_condition", ""));
}
$ret .= '</tr>';
# temp/hum | min
$ret .= sprintf('<tr><td class="weatherMin">%s°C %s%%</td>', ReadingsVal($d, "temp_c", ""), ReadingsVal($d, "humidity", ""));
for(my $i=1; $i<$items; $i++) {
$ret .= sprintf('<td class="weatherMin">min %s°C</td>', ReadingsVal($d, "${fc}${i}_low_c", ""));
}
$ret .= '</tr>';
# wind | max
$ret .= sprintf('<tr><td class="weatherMax">%s</td>', ReadingsVal($d, "wind_condition", ""));
for(my $i=1; $i<$items; $i++) {
$ret .= sprintf('<td class="weatherMax">max %s°C</td>', ReadingsVal($d, "${fc}${i}_high_c", ""));
}
$ret .= "</tr></table>";
return $ret;
}
sub WeatherAsHtmlD($;$;$)
{
my ($d,$f,$i) = @_;
$f = "daily" if(!$f);
if($FW_ss) {
WeatherAsHtmlV($d,$f,$i);
} else {
WeatherAsHtmlH($d,$f,$i);
}
}
viele Grüße
Lippie
Hallo Lippie,
Das ist Recht umfangreich. Kannst Du das bitte als Patch oder als Pull Request auf GitHub geben? Was wäre super.
Grüße
hab mit GIT noch nicht gearbeitet, muss ich mich dazu irgendwo anmelden oder freischalten lassen?
Nur bei GitHub. Es reicht aber auch wenn Du hier einfach einen Patch oder diff postest.
Grüße
Es gibt Arbeit im fhem-mirror :-)
Hab alles fleißig übertragen.
Zitat von: Lippie am 16 Januar 2019, 23:11:05
Es gibt Arbeit im fhem-mirror :-)
Hab alles fleißig übertragen.
Hallo,
Leider gehört der mir nicht. Du musst das wenn an mein Git schicken.
https://github.com/LeonGaultier/fhem-weather
Grüße
OK, dort habe ich schon mal die APIs bearbeitet. Das andere kommt noch
Zitat von: Lippie am 16 Januar 2019, 23:23:09
OK, dort habe ich schon mal die APIs bearbeitet. Das andere kommt noch
Habe ich gesehen. Und Dir auch schon Kommentare hinterlassen.
Wenn Du Fragen hast dann einfach Fragen.
Grüße
Zitat von: CoolTux am 14 Januar 2019, 18:22:40
Ich habe das state nun entsprechend formatiert.
Besten Dank.
Habe gestern geupdated und wieder auf den Ursprungszustand zurück gebaut. Funktioniert weiterhin alles bestens :daumenhoch:
Hallo Leon,
So, ich habe nun auch endlich die Aktualisierung über die Bühne gebracht, war ja einfach ;D!
So weit läuft alles einwandfrei, allerdings sind mir auch noch ein paar Kleinigkeiten aufgefallen.
Zum einen eben das Sprach-Problem bei den Wochentagen, zu dem du folgendes geschrieben hast:
Zitat von: CoolTux am 13 Januar 2019, 20:53:32
Das liegt an Deiner locale Einstellung von der linux distrie wo das FHEM drauf läuft. Die ist bei Dir englisch.
Da habe ich jetzt aber irgendwie so meine Zweifel und zwar aus folgendem Grund.
Meine aktuellen locale-Einstellungen sind auf dem FHEM-Rechner nämlich auf Deutsch eingestellt:
LANG=de_DE.UTF-8
LANGUAGE=
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=
LC_TIME und/oder LC_LANG dürften die relevanten Einstellungen sein.
Nichts desto trotz sieht mein Weather Device wie folgt aus:
Internals:
API DarkSkyAPI
APIKEY *****d5039
APIOPTIONS
DEF API=DarkSkyAPI apikey=******d5039 lang=de
INTERVAL 3600
LANG de
LOCATION 48.557,9.199
NAME yaw
NOTIFYDEV global
NR 1159
NTFY_ORDER 50-yaw
STATE T: 5 °C F: 68 % W: 18 km/h P: 1010 hPa
TYPE Weather
.attraggr:
.attreocr:
.*
.attrminint:
Helper:
DBLOG:
state:
logdb:
TIME 1547743341.92971
VALUE Initialized
READINGS:
2019-01-17 17:42:22 .license Based on data from EUMETNET - MeteoAlarm [https://www.meteoalarm.eu/]. Time delays between this website and the MeteoAlarm website are possible; for the most up to date information about alert levels as published by the participating National Meteorological Services please use the MeteoAlarm website.
2019-01-17 17:42:22 apiMaintainer Leon Gaultier (<a href=https://forum.fhem.de/index.php?action=profile;u=13684>CoolTux</a>)
2019-01-17 17:42:22 apparentTemperature 2
2019-01-17 17:42:22 cloudCover 52
2019-01-17 17:42:22 code 29
2019-01-17 17:42:22 condition Leicht bewölkt
2019-01-17 17:42:22 current_date_time Thu, 17 Jan 2019 17:42
2019-01-17 17:42:22 dewPoint 0
2019-01-17 17:42:22 fc1_apparentTempHigh 6
2019-01-17 17:42:22 fc1_apparentTempHighTime Thu, 17 Jan 2019 09:00
2019-01-17 17:42:22 fc1_apparentTempLow -4
2019-01-17 17:42:22 fc1_apparentTempLowTime Fri, 18 Jan 2019 04:00
2019-01-17 17:42:22 fc1_cloudCover 62
2019-01-17 17:42:22 fc1_code 29
2019-01-17 17:42:22 fc1_condition Nachmittags überwiegend bewölkt.
2019-01-17 17:42:22 fc1_day_of_week Thu
2019-01-17 17:42:22 fc1_dewPoint 1
2019-01-17 17:42:22 fc1_high_c 8
2019-01-17 17:42:22 fc1_humidity 71
2019-01-17 17:42:22 fc1_icon partly_cloudy_night
2019-01-17 17:42:22 fc1_iconAPI partly-cloudy-night
2019-01-17 17:42:22 fc1_low_c 0
2019-01-17 17:42:22 fc1_moonPhase 0.36
2019-01-17 17:42:22 fc1_ozone 305.76
2019-01-17 17:42:22 fc1_precipIntensity 0.0559
2019-01-17 17:42:22 fc1_precipIntensityMax 0.1676
2019-01-17 17:42:22 fc1_precipIntensityMaxTime Thu, 17 Jan 2019 22:00
2019-01-17 17:42:22 fc1_precipProbability 0.48
2019-01-17 17:42:22 fc1_precipType rain
2019-01-17 17:42:22 fc1_pressure 1010
2019-01-17 17:42:22 fc1_pubDate Thu, 17 Jan 2019 00:00
2019-01-17 17:42:22 fc1_sunriseTime Thu, 17 Jan 2019 08:10
2019-01-17 17:42:22 fc1_sunsetTime Thu, 17 Jan 2019 16:58
2019-01-17 17:42:22 fc1_tempHigh 8
2019-01-17 17:42:22 fc1_tempHighTime Thu, 17 Jan 2019 08:00
2019-01-17 17:42:22 fc1_tempLow 0
2019-01-17 17:42:22 fc1_tempLowTime Fri, 18 Jan 2019 06:00
2019-01-17 17:42:22 fc1_uvIndex 1
2019-01-17 17:42:22 fc1_uvIndexTime Thu, 17 Jan 2019 11:00
2019-01-17 17:42:22 fc1_visibility 10
2019-01-17 17:42:22 fc1_wind 12
2019-01-17 17:42:22 fc1_windGust 61
2019-01-17 17:42:22 fc1_windGustTime Thu, 17 Jan 2019 07:00
2019-01-17 17:42:22 fc1_wind_condition Wind: SW 12 km/h
2019-01-17 17:42:22 fc1_wind_direction 233
2019-01-17 17:42:22 fc1_wind_speed 12
<... Restliche fc_ und hfc_ gekürzt ...>
2019-01-17 17:42:22 humidity 68
2019-01-17 17:42:22 icon partly_cloudy_night
2019-01-17 17:42:22 iconAPI partly-cloudy-night
2019-01-17 17:42:22 lastError
2019-01-17 17:42:22 lat **.***
2019-01-17 17:42:22 long *.***
2019-01-17 17:42:22 ozone 318.78
2019-01-17 17:42:22 precipIntensity 0.0305
2019-01-17 17:42:22 precipProbability 0.16
2019-01-17 17:42:22 pressure 1010
2019-01-17 17:42:22 pubDate Thu, 17 Jan 2019 17:42
2019-01-17 17:42:22 state T: 5 °C F: 68 % W: 18 km/h P: 1010 hPa
2019-01-17 17:42:22 status ok
2019-01-17 17:42:22 temp_c 5
2019-01-17 17:42:22 temperature 5
2019-01-17 17:42:22 timezone Europe/Berlin
2019-01-17 17:42:22 uvIndex 0
2019-01-17 17:42:22 validity up-to-date
2019-01-17 17:42:22 visibility 15
2019-01-17 17:42:22 wind 18
2019-01-17 17:42:22 windGust 46
2019-01-17 17:42:22 wind_condition Wind: WSW 18 km/h
2019-01-17 17:42:22 wind_direction 256
2019-01-17 17:42:22 wind_speed 18
fhem:
allowCache 1
interfaces temperature;humidity;wind
Attributes:
DbLogExclude .*
event-on-change-reading .*
room Umwelt
Das ist übrigens auch bei OpenWeatherMapAPI so.
Btw.: Mein altes Yahoo-Weather-Device hatte die Tage korrekt angezeigt:
Internals:
API YahooWeatherAPI
APIOPTIONS transport:https,cachemaxage:600
DEF ****** 3600 de
INTERVAL 3600
LANG de
LOCATION ********
NAME yaw
NOTIFYDEV global
NR 240
NTFY_ORDER 50-yaw
STATE T: 0 H: 88 W: 7 P: 986
TYPE Weather
UNITS c
.attraggr:
.attrminint:
READINGS:
2019-01-03 23:06:29 city P***n
2019-01-03 23:06:29 code 14
2019-01-03 23:06:29 condition leichte Schneeschauer
2019-01-03 23:06:29 country Germany
2019-01-03 23:06:29 current_date_time Thu, 03 Jan 2019 10:00 PM CET
2019-01-03 23:06:29 day_of_week Do
2019-01-03 23:06:29 description Yahoo! Weather for P***n, BW, DE
2019-01-03 23:06:29 fc10_code 28
2019-01-03 23:06:29 fc10_condition überwiegend wolkig
2019-01-03 23:06:29 fc10_date 12 Jan 2019
2019-01-03 23:06:29 fc10_day_of_week Sa
2019-01-03 23:06:29 fc10_high_c 0
2019-01-03 23:06:29 fc10_icon mostlycloudy
2019-01-03 23:06:29 fc10_low_c -2
2019-01-03 23:06:29 fc1_code 16
2019-01-03 23:06:29 fc1_condition Schnee
2019-01-03 23:06:29 fc1_date 03 Jan 2019
2019-01-03 23:06:29 fc1_day_of_week Do
2019-01-03 23:06:29 fc1_high_c 1
2019-01-03 23:06:29 fc1_icon snow
2019-01-03 23:06:29 fc1_low_c -5
2019-01-03 23:06:29 fc2_code 26
2019-01-03 23:06:29 fc2_condition wolkig
2019-01-03 23:06:29 fc2_date 04 Jan 2019
2019-01-03 23:06:29 fc2_day_of_week Fr
2019-01-03 23:06:29 fc2_high_c 2
2019-01-03 23:06:29 fc2_icon cloudy
2019-01-03 23:06:29 fc2_low_c 0
2019-01-03 23:06:29 fc3_code 5
2019-01-03 23:06:29 fc3_condition Regen und Schnee
2019-01-03 23:06:29 fc3_date 05 Jan 2019
2019-01-03 23:06:29 fc3_day_of_week Sa
2019-01-03 23:06:29 fc3_high_c 3
2019-01-03 23:06:29 fc3_icon rainsnow
2019-01-03 23:06:29 fc3_low_c 1
2019-01-03 23:06:29 fc4_code 5
2019-01-03 23:06:29 fc4_condition Regen und Schnee
2019-01-03 23:06:29 fc4_date 06 Jan 2019
2019-01-03 23:06:29 fc4_day_of_week So
2019-01-03 23:06:29 fc4_high_c 3
2019-01-03 23:06:29 fc4_icon rainsnow
2019-01-03 23:06:29 fc4_low_c 1
2019-01-03 23:06:29 fc5_code 26
2019-01-03 23:06:29 fc5_condition wolkig
2019-01-03 23:06:29 fc5_date 07 Jan 2019
2019-01-03 23:06:29 fc5_day_of_week Mo
2019-01-03 23:06:29 fc5_high_c 2
2019-01-03 23:06:29 fc5_icon cloudy
2019-01-03 23:06:29 fc5_low_c 0
2019-01-03 23:06:29 fc6_code 5
2019-01-03 23:06:29 fc6_condition Regen und Schnee
2019-01-03 23:06:29 fc6_date 08 Jan 2019
2019-01-03 23:06:29 fc6_day_of_week Di
2019-01-03 23:06:29 fc6_high_c 1
2019-01-03 23:06:29 fc6_icon rainsnow
2019-01-03 23:06:29 fc6_low_c -1
2019-01-03 23:06:29 fc7_code 5
2019-01-03 23:06:29 fc7_condition Regen und Schnee
2019-01-03 23:06:29 fc7_date 09 Jan 2019
2019-01-03 23:06:29 fc7_day_of_week Mi
2019-01-03 23:06:29 fc7_high_c 1
2019-01-03 23:06:29 fc7_icon rainsnow
2019-01-03 23:06:29 fc7_low_c 0
2019-01-03 23:06:29 fc8_code 14
2019-01-03 23:06:29 fc8_condition leichte Schneeschauer
2019-01-03 23:06:29 fc8_date 10 Jan 2019
2019-01-03 23:06:29 fc8_day_of_week Do
2019-01-03 23:06:29 fc8_high_c 0
2019-01-03 23:06:29 fc8_icon chance_of_snow
2019-01-03 23:06:29 fc8_low_c -1
2019-01-03 23:06:29 fc9_code 28
2019-01-03 23:06:29 fc9_condition überwiegend wolkig
2019-01-03 23:06:29 fc9_date 11 Jan 2019
2019-01-03 23:06:29 fc9_day_of_week Fr
2019-01-03 23:06:29 fc9_high_c -1
2019-01-03 23:06:29 fc9_icon mostlycloudy
2019-01-03 23:06:29 fc9_low_c -3
2019-01-03 23:06:29 humidity 88
2019-01-03 23:06:29 icon chance_of_snow
2019-01-03 23:06:29 isConverted 0
2019-01-04 13:04:11 lastError DNS: Cant find host
2019-01-03 23:06:29 lat **.******
2019-01-03 23:06:29 long *.******
2019-01-03 23:06:29 pressure 986
2019-01-03 23:06:29 pressure_trend 0
2019-01-03 23:06:29 pressure_trend_sym =
2019-01-03 23:06:29 pressure_trend_txt gleichbleibend
2019-01-03 23:06:29 pubDate Thu, 03 Jan 2019 10:00 PM CET
2019-01-13 08:05:14 pubDateComment disabled by attribute
2019-01-03 23:06:29 pubDateRemote Thu, 03 Jan 2019 10:00 PM CET
2019-01-03 23:06:29 pubDateTs 1546549200
2019-01-03 23:06:29 region BW
2019-01-03 23:06:29 state T: 0 H: 88 W: 7 P: 986
2019-01-03 23:06:29 temp_c 0
2019-01-03 23:06:29 temperature 0
2019-01-13 08:05:14 validity stale
2019-01-03 23:06:29 visibility 16
2019-01-03 23:06:29 wind 7
2019-01-03 23:06:29 wind_chill -1
2019-01-03 23:06:29 wind_condition Wind: NW 7 km/h
2019-01-03 23:06:29 wind_direction 305
2019-01-03 23:06:29 wind_speed 7
fhem:
allowCache 0
interfaces temperature;humidity;wind
Attributes:
DbLogExclude .*
alias Yahoo Wather
disable 1
room Umwelt
verbose 2
Desweiteren noch die Frage, ob der API-Key nicht als "sensibles" Datum (ähnlich wie Login-Credentials) aus dem Device herausgehalten werden sollte?
Sprich Verwaltung mittels
setKeyValue und
getKeyValue im Key-File?
Ansonsten: Wirklich Top Arbeit! 8)
Danke!
gb#
Hallo Benni,
Das mit der locale schaue ich mir gerne noch mal an. Kann ich morgen in Ruhe testen.
Was den API Key an geht gebe ich Dir Recht und es existiert auch schon ein entsprechendes Designkonzept. Vorrang hatte aber erstmal das weiter laufen des Modules und neue Quellen ;D
Habe heute die Freigabe von Boris bekommen an Weather einige Umsetzungen durch zu führen. Es wird also im Laufe der Tage das ein oder andere an Betatester raus gehen.
Grüße
Zitat von: CoolTux am 17 Januar 2019, 18:53:09
Das mit der locale schaue ich mir gerne noch mal an. Kann ich morgen in Ruhe testen.
Keine Eile, es pressiert nicht! ;)
Bevor übrigens die Frage kommt ....
linux liefert mir in der shell mit date das erwartete Ergebnis:
$date
Do 17. Jan 19:28:29 CET 2019
Kannst Du das bitte einmal auf dem FHEM Server ausführen
usr/bin/perl -e "use POSIX; print strftime(\"%a\",localtime(time)) . \"\\n\";"
Also bitte in der Shell.
Grüße
Zitat von: CoolTux am 17 Januar 2019, 19:41:46
Kannst Du das bitte einmal auf dem FHEM Server ausführen
usr/bin/perl -e "use POSIX; print strftime(\"%a\",localtime(time)) . \"\\n\";"
$ perl -e "use POSIX; print strftime(\"%a\",localtime(time)) . \"\\n\";"
Do
Hmmm ....
in FHEM bekomme ich auf der Commandline folgendes Ergebnis
{strftime("%a",localtime(time))}
Thu
language - Attribut im
global device steht auf
DE
Kannst Du den bash Befehl bitte einmal als User fhem ausführen. Eventuell ist da was anders.
:-\ Passt auch:
$sudo -u fhem perl -e "use POSIX; print strftime(\"%a\",localtime(time)) . \"\\n\";"
Do
Locales sind auch i.O.:
$ sudo -u fhem locale
LANG=de_DE.UTF-8
LANGUAGE=
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=
Zitat von: Benni am 17 Januar 2019, 20:49:17
:-\ Passt auch:
$sudo -u fhem perl -e "use POSIX; print strftime(\"%a\",localtime(time)) . \"\\n\";"
Do
Locales sind auch i.O.:
$ sudo -u fhem locale
LANG=de_DE.UTF-8
LANGUAGE=
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=
Sehr seltsam. Ich schaue morgen noch mal genauer.
Folgendes in der Commandref beim DWD-Modul (https://commandref.fhem.de/#DWD_OpenData)
in den Installationsanweisungen gefunden:
Zitat
The weekday of the forecast will be in the language of your FHEM system. Enter {$ENV{LANG}} into the FHEM command line to verify. If nothing is displayed or you see an unexpected language setting, add export LANG=de_DE.UTF-8 or something similar to your FHEM start script, restart FHEM and check again. If you get a locale warning when starting FHEM the required language pack might be missing. It can be installed depending on your OS and your preferences (e.g. dpkg-reconfigure locales, apt-get install language-pack-de or something similar).
habe den entsprechenden Varaiblen-export im Startskript von FHEM hinzugefügt, nachdem bei mir bei Ausführung von {$ENV{LANG}} nichts angezeigt wurde.
Jetzt bekomme ich nach einem Neustart folgendes Ergebnis:
{$ENV{LANG}}
de_DE.UTF-8
Jetzt liefert mir auch folgendes den korrekten Wert:
{strftime("%a",localtime(time))}
Do
Und siehe da, im Weather-Device sind die Daten nun korrekt in Deutsch:
Internals:
API DarkSkyAPI
APIKEY ***d5039
APIOPTIONS
DEF API=DarkSkyAPI apikey=***d5039 lang=de
INTERVAL 3600
LANG de
LOCATION ***
NAME yaw
NOTIFYDEV global
NR 927
NTFY_ORDER 50-yaw
STATE T: 2 °C F: 89 % W: 34 km/h P: 1014 hPa
TYPE Weather
.attraggr:
.attreocr:
.*
.attrminint:
READINGS:
2019-01-17 21:10:10 .license Based on data from EUMETNET - MeteoAlarm [https://www.meteoalarm.eu/]. Time delays between this website and the MeteoAlarm website are possible; for the most up to date information about alert levels as published by the participating National Meteorological Services please use the MeteoAlarm website.
2019-01-17 21:10:10 apiMaintainer Leon Gaultier (<a href=https://forum.fhem.de/index.php?action=profile;u=13684>CoolTux</a>)
2019-01-17 21:10:10 apparentTemperature -3
2019-01-17 21:10:10 cloudCover 71
2019-01-17 21:10:10 code 24
2019-01-17 21:10:10 condition Leichter Wind und überwiegend bewölkt
2019-01-17 21:10:10 current_date_time Do, 17 Jan 2019 21:10
2019-01-17 21:10:10 dewPoint 1
2019-01-17 21:10:10 fc1_apparentTempHigh 6
2019-01-17 21:10:10 fc1_apparentTempHighTime Do, 17 Jan 2019 09:00
2019-01-17 21:10:10 fc1_apparentTempLow -4
2019-01-17 21:10:10 fc1_apparentTempLowTime Fr, 18 Jan 2019 05:00
2019-01-17 21:10:10 fc1_cloudCover 62
2019-01-17 21:10:10 fc1_code 24
2019-01-17 21:10:10 fc1_condition Nachmittag leicht bewölkt und Abend leichter Wind.
2019-01-17 21:10:10 fc1_day_of_week Do
2019-01-17 21:10:10 fc1_dewPoint 1
2019-01-17 21:10:10 fc1_high_c 8
2019-01-17 21:10:10 fc1_humidity 73
2019-01-17 21:10:10 fc1_icon windy
2019-01-17 21:10:10 fc1_iconAPI wind
2019-01-17 21:10:10 fc1_low_c 0
2019-01-17 21:10:10 fc1_moonPhase 0.36
2019-01-17 21:10:10 fc1_ozone 302.36
2019-01-17 21:10:10 fc1_precipIntensity 0.0584
2019-01-17 21:10:10 fc1_precipIntensityMax 0.1397
2019-01-17 21:10:10 fc1_precipIntensityMaxTime Do, 17 Jan 2019 13:00
2019-01-17 21:10:10 fc1_precipProbability 0.48
2019-01-17 21:10:10 fc1_precipType rain
2019-01-17 21:10:10 fc1_pressure 1010
2019-01-17 21:10:10 fc1_pubDate Do, 17 Jan 2019 00:00
2019-01-17 21:10:10 fc1_sunriseTime Do, 17 Jan 2019 08:10
2019-01-17 21:10:10 fc1_sunsetTime Do, 17 Jan 2019 16:58
2019-01-17 21:10:10 fc1_tempHigh 8
2019-01-17 21:10:10 fc1_tempHighTime Do, 17 Jan 2019 08:00
2019-01-17 21:10:10 fc1_tempLow 0
2019-01-17 21:10:10 fc1_tempLowTime Fr, 18 Jan 2019 07:00
2019-01-17 21:10:10 fc1_uvIndex 1
2019-01-17 21:10:10 fc1_uvIndexTime Do, 17 Jan 2019 11:00
2019-01-17 21:10:10 fc1_visibility 9
2019-01-17 21:10:10 fc1_wind 13
2019-01-17 21:10:10 fc1_windGust 61
2019-01-17 21:10:10 fc1_windGustTime Do, 17 Jan 2019 07:00
2019-01-17 21:10:10 fc1_wind_condition Wind: WSW 13 km/h
2019-01-17 21:10:10 fc1_wind_direction 245
2019-01-17 21:10:10 fc1_wind_speed 13
< .... und so weiter und so fort ... >
Danke Dir Benni,
Das werde ich mal ausleihen für die Commandref von 59_Weather
das Thema mit den englischen und deutschen Tagen hatte ich ja gestern auch schon angeschnitten. Heute habe ich es genauso, dass einige Tage in Deutsch sind und einige in englisch also alles gemischt.
Ein "{strftime("%a",localtime(time))}" in der Konsole fhem ergibt bei mir ein "Fri"
Zitat von: moonsorrox am 18 Januar 2019, 12:58:26
das Thema mit den englischen und deutschen Tagen hatte ich ja gestern auch schon angeschnitten. Heute habe ich es genauso, dass einige Tage in Deutsch sind und einige in englisch also alles gemischt.
Ein "{strftime("%a",localtime(time))}" in der Konsole fhem ergibt bei mir ein "Fri"
Und das da (https://forum.fhem.de/index.php/topic,95746.msg890080.html#msg890080) hast du schon geprüft und versucht?
https://forum.fhem.de/index.php/topic,95746.msg890080.html#msg890080
Gruß Benni.
Zitat von: moonsorrox am 18 Januar 2019, 12:58:26
das Thema mit den englischen und deutschen Tagen hatte ich ja gestern auch schon angeschnitten. Heute habe ich es genauso, dass einige Tage in Deutsch sind und einige in englisch also alles gemischt.
Ein "{strftime("%a",localtime(time))}" in der Konsole fhem ergibt bei mir ein "Fri"
Probiere mal bitte Benni sein Lösungsvorschlag aus.
:)
Dieser fix hat auch auf meiner Synology die Lösung für die englischen Bezeichnungen gebracht.
Dort gibt es kein "export LANG=de_DE.utf8" im startscript.
Habe ich in der Commandref mal so festgehalten.
Zitat von: Benni am 18 Januar 2019, 13:05:08
Und das da (https://forum.fhem.de/index.php/topic,95746.msg890080.html#msg890080) hast du schon geprüft und versucht?
https://forum.fhem.de/index.php/topic,95746.msg890080.html#msg890080
Gruß Benni.
Es hatte mich in der Vergangenheit nicht gestört ob die Anzeige Deutsch oder Englisch war. Aber mit diesem Lösungsansatz ist jetzt bei mir auch alles in Deutsch. Komisch ist aber trotzdem, dass auf der Shell locale ein richtiges Ergebnis liefert und in FHEM die Sprache verloren geht.
EDIT:// ich habe es am Anfang eingefügt und nun geht es in deutsch..!!! ;)
Danke
An welcher Stelle muss ich im Startscript was eingeben..? wollte da nicht sinnlos rum pfuschen ;)
Hier mein Startscript:
# if you need to start hmland for use with
# Homematic, please start the hmland daemon
# like this (please use correct path and port,
# depending on your installation!)
#
/opt/hmcfgusb/hmland -d -p 1234 -r 0
#
perl fhem.pl fhem.cfg
# if you want to use configDB for configuration,
# use this command to start fhem:
#
# perl fhem.pl configDB
#
# and remove/comment the above line including fhem.cfg
RETVAL=$?
;;
'stop')
echo "Stopping fhem..."
# if you want to stop hmland during fhem stop:
pkill hmland
pkill -U fhem perl
RETVAL=$?
;;
'status')
cnt=`ps -ef | grep "fhem.pl" | grep -v grep | wc -l`
if [ "$cnt" -eq "0" ] ; then
echo "fhem is not running"
else
echo "fhem is running"
fi
;;
*)
echo "Usage: $0 { start | stop | status }"
RETVAL=1
;;
esac
exit $RETVAL
Zitat von: moonsorrox am 18 Januar 2019, 14:33:04
An welcher Stelle muss ich im Startscript was eingeben..? wollte da nicht sinnlos rum pfuschen ;)
Auch wenn du's schon selbst gefunden hast ...
Es muss auf jeden fall vor dem eigentlichen Start von FHEM mit perl sein.
Beispiel:
export LANG=de_DE.UTF-8
perl fhem.pl fhem.cfg
Zitat von: Benni am 18 Januar 2019, 16:43:06
Auch wenn du's schon selbst gefunden hast ...
Es muss auf jeden fall vor dem eigentlichen Start von FHEM mit perl sein.
Jou Benni, ich hatte es nämlich einmal am Ende eingefügt und es ging natürlich nicht :-\
Aber vielen Dank für den Hinweis...! ;)
Wann werden denn die Icons wieder so eingepflegt, dass diese im FTUI wieder funktionieren wie vorher ?
Das solltest Du die FTUI Leute fragen.
Zitat von: cotecmania am 27 Januar 2019, 12:07:17
Wann werden denn die Icons wieder so eingepflegt, dass diese im FTUI wieder funktionieren wie vorher ?
Bin gerade dran, das Weather_Widget für FTUI komplett zu überarbeiten. Erstelle, wenn eine erste Testversion fertig ist, einen neuen Thread im FTUI Forum.
VG
Andreas
Hallo, hab gestern das Webinar verfolgt. Danke für die Vorbereitung und Durchführung. Nächstes Mal bin ich wieder dabei.
Mein Mikrophon war leider defekt und deshalb konnte ich meine Fragen nicht stellen.
1. Ich hatte weather in der Vergangenheit gelöscht und Anfang Januar gelöscht.
Jetzt ist da noch ein Rest übrig geblieben, der mir sporadisch mehrmals am Tag eine Fehlermeldung bringt:
ERROR evaluating {WeatherAsHtml("SIMMERATH_WETTER",7)}: Undefined subroutine &main::WeatherAsHtml called at (eval 56343) line 1
Wie bekomme ich dies weg. 2. Und mein zweites Anliegen: Ich möchte weather wieder installieren, finde aber keine Doku. Gilt immer noch die alte Wiki https://wiki.fhem.de/wiki/Weather oder wie muss ich vorangehen? Hab schon den Blog durchgeschaut, ohne Erfolg.
Hallo Uwe2,
man konnte sich beim Webinar per Telefon einwählen, habe ich so gemacht, denn ich habe kar kein Auto, äh Mikrofon.
Schau bitte in die commandref zum Modul 59_Weather, da ist eigentlich alles erklärt, was man für die Definition des eigenen Devices benötigt. Ansonsten forste das Forum bei den Wettermodulen mal durch, auch da ist es (auch) haarklein erklärt.
Viele Grüße Gisbert
Zitat von: cotecmania am 27 Januar 2019, 12:07:17
Wann werden denn die Icons wieder so eingepflegt, dass diese im FTUI wieder funktionieren wie vorher ?
Ich habe eine neue Version des "Weather_Widgets" zur Darstellung der Icons in FTUI zum Testen bereitgestellt. Diese Version unterstützt DarkSky, OpenWeather, ProPlanta und DWD https://forum.fhem.de/index.php/topic,96954.0.html
Viele Grüße
Andreas
Zitat von: UweUwe am 02 Februar 2019, 09:56:44
Gilt immer noch die alte Wiki https://wiki.fhem.de/wiki/Weather oder wie muss ich vorangehen? Hab schon den Blog durchgeschaut, ohne Erfolg.
Es gibt inzwischen mehrere Einträge im Wiki, die sich mit dem Wetter beschäftigen und zum Teil veraltet und nicht untereinander vernetzt sind. Wie geht man am besten vor, wenn man da aufräumen und gleichzeitig niemandem auf die Füße treten will?
Eine Frage von hier: https://forum.fhem.de/index.php/topic,95823.msg918120.html#msg918120 (https://forum.fhem.de/index.php/topic,95823.msg918120.html#msg918120)
Ich hätte eine Bitte. Irgendwo wird das von DarkSky gelieferte "_time" in "_pubDate" (mit den lustigen Umlautproblemen die trotz aller aufgezeigten Fixversuche bei mir immer noch bestehen) gewandelt und ausgeliefert. Damit ich meinen Plot fertig bekomme, und Perl eher Codekopieren statt verstehen bei mir ist, die Frage, wie ich _pubDate in ein logProxy verständliches Format bekomme. Zb -> 2010-05-22 13:43:17
Ich suche seit Stunden/Tagen, aber genau dieses Format wie im Moment _pubDate wird scheinbar internetweit recht selten verwandt.
_pubDate bekomme ich mit meinem Wissensstand nicht formatiert. Bei original DarkSky hatte ich bisher $timestamp mit _time generiert:
($hdmsec, $hdmmin, $hdmhour, $hdmmday, $hdmmon, $hdmyear, $hdmwday, $hdmyday, $hdmisdst) = localtime(ReadingsVal($device, "hfc".$h."_time",undef));
# necessary conversion of $mon and $year
$hdmmon += 1;
$hdmyear += 1900;
$timestamp = sprintf("%04d-%02d-%02d_%02d:%02d:%02d", $hdmyear, $hdmmon, $hdmmday, $hdmhour, $hdmmin, $hdmsec);
oder ihr liefert als ExtraWert _time wieder mit? Wobei ich nicht weiß, ob andere etwas davon hätten.
Danke und Gruß
H.
Zitat von: holle75 am 14 März 2019, 11:40:55
Ich hätte eine Bitte. Irgendwo wird das von DarkSky gelieferte "_time" in "_pubDate" (mit den lustigen Umlautproblemen die trotz aller aufgezeigten Fixversuche bei mir immer noch bestehen) gewandelt und ausgeliefert.
Es scheint aber anders zu sein, denn "pubDate" wird nicht von der API geliefert, sondern ist lediglich die Zeit, wann "set $NAME update" readings bekommt. Ich hab mir einfach ein
userreading pubDateTs {time()} gemacht, dass exakt identisch ist. Dies verwende ich dann in diversen notifys.
Im "alten" Weathermodul war, sowit ich weiss, das "pubDate" die Zeit, wann die Info vom Dienst bereitgestellt wurde.
Das wäre mir ehrlich gesagt auch lieber.
Die "lustigen Umlautproblemen" waren doch eigentlich gefixt, oder? (zumindst ist es mir eben erst wieder aufgefallen)
Cheers
mi.ke
Moinsen Mi.ke, ich kenne die Wertbenennungen nur von der DarkSky API direkt über HTTPMOD und weiß nicht genau wie was in WEATHER benannt oder konvertiert wird. Wenn ich die Readings vergleiche, kam ich auf _time als Equivalent zu konvertiertem _pubDate. Das kann auch falsch sein.
Was ich eigentlich suche, ist die Zeit für die das entsprechende Hourly-Reading gilt :) ... hfcxx_pubDate .... und das im logproxy verständlichem Format.
Und ich glaube, auch bei fcxx_pubDate ist es das, nicht die Update-Zeit
Bei mir mit vorgestrigem Update hat es die Umlautprobleme. Ein locale (und die anderen checks) gibt mir aber de zurück.
GET https://api.darksky.net/forecast/0123456789abcdef9876543210fedcba/42.3601,-71.0589
{
"latitude": 42.3601,
"longitude": -71.0589,
"timezone": "America/New_York",
"currently": {
"time": 1509993277,
"summary": "Drizzle",
"icon": "rain",
"nearestStormDistance": 0,
"precipIntensity": 0.0089,
"precipIntensityError": 0.0046,
"precipProbability": 0.9,
"precipType": "rain",
"temperature": 66.1,
"apparentTemperature": 66.31,
"dewPoint": 60.77,
"humidity": 0.83,
"pressure": 1010.34,
"windSpeed": 5.59,
"windGust": 12.03,
"windBearing": 246,
"cloudCover": 0.7,
"uvIndex": 1,
"visibility": 9.84,
"ozone": 267.44
},
pubDate ist nichts weiter wie "currently": { "time": 1509993277, halt in ein humanreadable format gebracht.
Über HTTPMOD als JSON abgeftragt liefert die DarkSky API
2019-03-14 13:17:27 hourly_data_01_apparentTemperature 12.79
2019-03-14 13:17:27 hourly_data_01_cloudCover 0.01
2019-03-14 13:17:27 hourly_data_01_dewPoint -5.12
2019-03-14 13:17:27 hourly_data_01_humidity 0.28
2019-03-14 13:17:27 hourly_data_01_icon clear-day
2019-03-14 13:17:27 hourly_data_01_ozone 385.6
2019-03-14 13:17:27 hourly_data_01_precipIntensity 0
2019-03-14 13:17:27 hourly_data_01_precipProbability 0
2019-03-14 01:17:27 hourly_data_01_precipType rain
2019-03-14 13:17:27 hourly_data_01_pressure 1015.02
2019-03-14 13:17:27 hourly_data_01_summary Clear
2019-03-14 13:17:27 hourly_data_01_temperature 12.79
2019-03-14 13:17:27 hourly_data_01_time 1552564800
2019-03-14 13:17:27 hourly_data_01_uvIndex 4
2019-03-14 13:17:27 hourly_data_01_visibility 9.88
2019-03-14 13:17:27 hourly_data_01_windBearing 335
2019-03-14 13:17:27 hourly_data_01_windGust 15.13
2019-03-14 13:17:27 hourly_data_01_windSpeed 9.06
Das meine ich. _time/pubDate ist die Zeit für die die entsprechenden Day/Hourly-Readings gelten.... ist auch fortlaufend hochzählend passen zur hourly_data_xx.
.... und wie bekomme ich den Wert jetzt aus dem humanreadable Reading pubDate von WEATHER wieder in so ein Format ... 2010-05-22 13:43:17 .... gewandelt?
Zitat von: CoolTux am 14 März 2019, 13:50:29
pubDate ist nichts weiter wie "currently": { "time": 1509993277, halt in ein humanreadable format gebracht.
Wäre es vielleicht eine Idee, es zu lösen, wie Du es beim UWZ-Modul gemacht hast?
Dort ist die Zeitangabe als Reading in time() und per Attribut humanreadable=1 werden zusätzliche Readings erzeugt (_Date _Time).
Hätte den Vorteil, dass die Zeit in "epoch" vorliegt und der User es sich formatieren kann wie er will.
Wer möchte kann sich auch ohne Kenntnis die "humanreadable" anzeigen lassen.
Das kann man machen wenn es sich um ein Frontend Modul handeln würde. Aber DarkSkyAPI ist ein Backend Modul mit einer festen API Beschreibung. Man kann mit Boris mal darüber reden wie man sowas am besten ändern kann. Dann muß die Darstellung aber eben vom Weather Modul geregelt werden. Zu mindest was pubDate an geht.
Hallo zusammen,
letztens habe ich auf DarkSky umgestellt, allerdings fehlte mir dann ein LogProxy für das Chart-Widget.
Da ich nirgends eine fertige LogProxy-Funktion finden konnte, habe ich mich mal ans Werk gemacht und was gebastelt.
Meine Lösung ist nicht so universell wie die für ProPlanta, aber sie tut was ich wollte: Sie liefert die 49 Stundenwerte des angegebenen Readings, die unter hcf1 bis hfc49 zu finden sind.
Aufruf:
Func:logProxy_darkskyHours(\\x22<device>\\x22,\\x22<reading>\\x22)
wobei <device> halt der Name des device ist und <reading> der Namensteil des Readings hinter dem ,,hfc_". Z.B.:
Func:logProxy_darkskyHours(\\x22wetter\\x22,\\x22temperature\\x22)
Die Funktion kann beim Chart-Widget direkt in die Definition von data-columnspec eingesetzt werden.
WICHTIG:
die Datum/Zeit-Angaben, die das DarkSkyApi unter PubDate liefert, konnte ich so nicht verarbeiten. Wer dieses LogProxy verwenden will, muss das Modul DarkSkyApi.pm deshalb leider folgendermassen patchen:
An drei Stellen ist der Anfang der jeweiligen Zeile
'pubDate' => strftimeWrapper("%a, %e %b %Y %H:%M", .....
zu ersetzen durch:
'pubDate' => strftimeWrapper("%d.%m.%Y %H:%M", .....
Mir ist klar, dass das Patchen nicht optimal ist, aber vielleicht fällt ja jemandem etwas besseres hierzu ein.
Noch ein paar Worte zum Code:
Ich benutze Perl nur, wenn ich muss. Ich freue mich also über Anmerkungen oder Korrekturen zum Code.
sub logProxy_darkskyHours($$) {
my ($device, $hfcName) = @_;
return undef if(!$device);
my ($h,$fcDay,$mday,$mon,$year);
my $timestamp;
my $reading;
my $value;
my $ret = "";
for (my $hfc=0;$hfc<=49;$hfc++){
$reading="hfc".$hfc."_".$hfcName;
$value = ReadingsVal($device,$reading,undef);
$reading="hfc".$hfc."_pubDate";
($mday,$mon,$year,$h) = split('\.| |:',ReadingsVal($device,$reading,undef));
$timestamp = sprintf("%04d-%02d-%02d_%02d:%02d:%02d", $year, $mon, $mday, $h, 0, 0);
$ret .= "$timestamp $value\n";
}
return ($ret);
}
Bei mir sieht das für einen svg-Plot so aus:
############## hdm WetterDarkSkyModule Wetter Plot funktion ##################################
sub logProxy_WetterDarkSkyModule2Plot($$$$;$$) {
my ($device, $fcValue, $from, $to, $fcHour, $expMode) = @_;
my $regex;
my @rl;
my $hdmreading;
my $hdmtime;
return undef if(!$device);
if ($fcValue =~ s/_$//)
{
$regex = "^hfc[\\d]+_".$fcValue."\$";
}
$fcHour = 12 if(!defined $fcHour);
$expMode = "point" if(!defined $expMode);
#Log3 undef,2, "regex: ".$regex;
if( defined($defs{$device}) ) {
if( $defs{$device}{TYPE} eq "Weather" ) {
@rl = sort{
my ($an) = ($a =~ m/hfc(\d+)_.*/);
my ($bn) = ($b =~ m/hfc(\d+)_.*/);
$an <=> $bn or $a cmp $b;
}( grep /${regex}/,keys %{$defs{$device}{READINGS}} );
return undef if( !@rl );
} else {
Log3 undef, 2, "logProxy_WetterDarkSkyModule2Plot: $device is not a Weather device";
return undef;
}
}
#Log3 undef,2, Dumper(@rl);
my $fromsec = SVG_time_to_sec($from);
my $tosec = SVG_time_to_sec($to);
my $sec = $fromsec;
my ($h,$hdmsec,$hdmmin,$hdmhour,$hdmmday,$hdmmon,$hdmyear,$hdmwday,$hdmyday,$hdmisdst);
my $timestamp;
my $reading;
my $value;
my $prev_value;
my $min = 999999;
my $max = -999999;
my $ret = "";
# while not end of plot range reached
while(($sec < $tosec) && @rl) {
#remember previous value for start of plot range
$prev_value = $value;
$reading = shift @rl;
($h) = $reading =~ m/^hfc(\d+).*/;
$value = ReadingsVal($device,$reading,undef);
use Date::Parse;
$hdmreading = ReadingsVal($device, "hfc".$h."_pubDate",undef);
$hdmreading =~ s/^....//; #Wochentag weg
$hdmreading =~ s/ä/a/; #März
$hdmreading =~ s/i/y/; #Mai
$hdmreading =~ s/k/c/; #Oktober
$hdmreading =~ s/z/c/; #Dezember
$hdmtime = str2time($hdmreading);
#Log3 undef,2, "hdmreading: ".$hdmreading;
#Log3 undef,2, "hdmtime: ".$hdmtime;
#($hdmsec, $hdmmin, $hdmhour, $hdmmday, $hdmmon, $hdmyear, $hdmwday, $hdmyday, $hdmisdst) = localtime(ReadingsVal($device, "hfc".$h."_time",undef));
($hdmsec, $hdmmin, $hdmhour, $hdmmday, $hdmmon, $hdmyear, $hdmwday, $hdmyday, $hdmisdst) = localtime($hdmtime);
# necessary conversion of $mon and $year
$hdmmon += 1;
$hdmyear += 1900;
$timestamp = sprintf("%04d-%02d-%02d_%02d:%02d:%02d", $hdmyear, $hdmmon, $hdmmday, $hdmhour, $hdmmin, $hdmsec);
#Log3 undef,2, "timestamp: ".$timestamp;
$sec = SVG_time_to_sec($timestamp);
# skip all values before start of plot range
next if( SVG_time_to_sec($timestamp) < $fromsec );
# add first value at start of plot range
if( !$ret && $prev_value ) {
$min = $prev_value if( $prev_value < $min );
$max = $prev_value if( $prev_value > $max );
$ret .= "$from $prev_value\n";
}
# done if after end of plot range
last if($sec > $tosec);
$min = $value if( $value < $min );
$max = $value if( $value > $max );
# add actual controll point
$ret .= "$timestamp $value\n";
#Log 3, "$timestamp $value -0- $reading";
}
if(($sec < $tosec) && !@rl && ($expMode eq "day")) {
$timestamp = sprintf("%04d-%02d-%02d_%02d:%02d:%02d", $hdmyear, $hdmmon, $hdmmday, 23, 59, 59);
if(SVG_time_to_sec($timestamp) < $tosec) {
$ret .= "$timestamp $value\n";
}
else {
$ret .= "$to $value\n";
}
}
elsif(($sec > $tosec) && ($expMode eq "day")) {
$value = $prev_value + ($value - $prev_value)*(86400 + ($tosec - $sec))/86400;
$ret .= "$to $value\n";
}
return ($ret,$min,$max,$prev_value);
}
############## end hdm WetterDarkSkyModule Wetter Plot funktion ##################################
aber auch nur zusamengeschustert und mit viel Hilfe hier aus dem Forum umgesetzt.
Spannend der Part:
use Date::Parse;
$hdmreading = ReadingsVal($device, "hfc".$h."_pubDate",undef);
$hdmreading =~ s/^....//; #Wochentag weg
$hdmreading =~ s/ä/a/; #März
$hdmreading =~ s/i/y/; #Mai
$hdmreading =~ s/k/c/; #Oktober
$hdmreading =~ s/z/c/; #Dezember
$hdmtime = str2time($hdmreading);
das modifiziert den Timestamp in nutzbar ohne in der Modul.pm was basteln zu müssen.