[TWILIGHT] No Weather location found at yahoo weather for location ID

[Dietmar63]

Ich lebe auch im Norden, bei mir werden die Werte für die Astro-Ereignisse als undefined ausgegeben. Kann ich mit leben.

Das ist auch kein Fehler.
Sr- und Ss_astro sind die Tageszeiten, an denen die Sonne 18° unter dem Horizont steht. Das genau Passiert in den Sommermonaten nicht mehr. Im Norden früher als im Süden.

Sunrise_el liefert Werte, sie stimmen aber nicht.

[OiledAmoeba]

Klingt sinnvoll, die Änderung aufzunehmen. Bin gerade unterwegs, möchte nachher noch ein wenig probieren. Dann, denke ich, sollten wir den Autor kontaktieren.

[Dietmar63]

Das Modul wurde von unimatrix geschrieben. Die Fehler, die im letzten Sommer /Jahr aufgetreten sind, hat Rudi ausgebaut.

Rudi ist per Mail schlecht zu erreichen.

[rudolfkoenig]

>  Rudi ist per Mail schlecht zu erreichen.

Nicht wirklich, ich reagiere nur allergisch auf fhem-Support-Anfragen ueber email. Dafuer lese ich nebenbei auch diese Gruppe.

Da ich TWILIGHT nicht verwende bzw. teste, benoetige ich eine konkrete Ansage, was ich womit patchen soll, und welches Problem dadurch geloest wird.

Noch lieber waere es mir, wenn entweder unimatrix sich wieder meldet (klingt nicht so, sonst haette er sich hier schon eingemischt), oder jemand die Pflege dieses Moduls von mir uebernimmt.

[mcfly71]

Würde ich ja gerne machen, aber das traue ich mir nicht so ganz zu. Verstehe z.B.
schonmal nicht, warum meine Änderung bei mir absolut nötig ist, jedoch bei OiledAm...
nicht.
Ich hoffe es findet sich jemand anderes (vlcht OiledAm.. ??????)

VG
mcfly

[OiledAmoeba]

So, da bin ich wieder.

Ich habe mir die Funktion CustomGetFileFromURL nochmal angesehen.
Wichtig ist dabei, dass die Variable $data zwingend leer bleibt.

my $hdr = ($data ? "POST" : "GET")

heißt auf deutsch: Wenn $data gefüllt, sende POST sonst sende GET.
YahooWeather kann nach meinen Tests mit POST nix anfangen. Ist ja auch logisch: I want to GET the weather. ;-)

Deswegen schlage ich folgende Änderung an 59_Twilight.pm vor:

Code Auswählen Erweitern


diff U C:/Temp/59_Twilight.pm C:/Temp/59_Twilight.changed.pm
--- C:/Temp/59_Twilight.pm Fri Jun 07 10:43:00 2013
+++ C:/Temp/59_Twilight.changed.pm Fri Jun 07 13:30:59 2013
@@ -317,2 +317 @@
-  my $xml = GetFileFromURL("http://weather.yahooapis.com/forecastrss?w=".
-                            $location."&u=c",4.0);
+  my $xml = CustomGetFileFromURL(0, "http://weather.yahooapis.com/forecastrss?w=".$location."&u=c", 4, undef, 1);

Als Testumgebung kann ich nur Fritz!OS anbieten. Daher ist noshutdown=1 hier zwingend. Ich kann nicht sagen, wie sich dieser Schalter auf andere Umgebungen auswirkt.

@Rudi: Ist eine globale Variable verfügbar, mit der in HttpUtils der Einsatz von noshutdown steuerbar ist?

Damit ist mcfly's Problem noch nicht behoben. Leider kann ich genau das nicht testen. Bei mir zickt perl nicht rum, wenn die Daten -1 sind...

[Dietmar63]

Noch lieber waere es mir, wenn entweder unimatrix sich wieder meldet (klingt nicht so, sonst haette er sich hier schon eingemischt), oder jemand die Pflege dieses Moduls von mir uebernimmt.

@Rudi
Ich wuerde das Modul Twilight und die Änderung übernehmen.

Ich kenne mich in TW schon ganz gut aus.

[rudolfkoenig]

>  Ich wuerde das Modul Twilight und die Änderung übernehmen.

Gerne. Bitte MAINTAINER.txt anpassen.

[Dietmar63]

@OiledAmoeba
Ehrlich gesagt kann ich das Problem nicht wirklich nachvollziehen:

alt:

Code Auswählen Erweitern

 my $xml = GetFileFromURL("http://weather.yahooapis.com/forecastrss?w=".
                            $location."&u=c",4.0);

Bei diesem Aufruf wird data nicht übergeben und ist damit in GetFileFromUrl undefined. Das ist Standard in Perl.


 
Zwei Tests meinerseits mit dem Original und der Version:

Code Auswählen Erweitern

my $xml = GetFileFromURL($url, 4, undef, 1);

liefert immer einen get:

Code Auswählen Erweitern


Host: weather.yahooapis.com
2013.06.07 19:32:25 3: hdr------------>GET /forecastrss?w=12833457&u=c HTTP/1.0
Host: weather.yahooapis.com
2013.06.07 19:31:05 3: hdr------------>GET /forecastrss?w=12833457&u=c HTTP/1.0


Vielleicht ist der darauf folgende Parameter der Parameter, der das Problem löst.
Der Kommentar in HttpUtils:
(siehe Anhang / see attachement)
deutet irgendwie darauf hin, dass noshutdown bei Fritten manchmal notwendig ist.
Deine Fußnote deutet darauf hin, dass du eine fb7270v2 verwendest.
Sie könnte das Problem haben. Ich habe eine fb7270v3 - bei ihr tritt das Problem nicht auf.

kannst du vielleicht mal prüfen was passiert wenn du folgendes in TW änderst.

[code]  my $xml = GetFileFromURL("http://weather.yahooapis.com/forecastrss?w=".
                            $location."&u=c",4.0, undef);

Ich könnte mir vorstellen, dass dein Problem dann wieder zurückkommt.

[Puschel74]

Hallo,

da ich mit meinem RasPi auch davon betroffen bin -- habt ihr ne Idee was ich machen kann um euch zu helfen?

Grüße

[Dietmar63]

@alle:

ich habe eine Version angehängt, die die Probleme von OiledAmoeba, mcfly71 und von Puschel74 lösen könnte:
bitte mal testen.

Wenn es funzt, checke ist das Module ein.

[OiledAmoeba]

Hallo Dietmar,

das ist korrekt.
Eben weil noshutdown=undef ist, läuft Twilight fehlerhaft.
Bestätigen kann ich das aber ausschließlich auf der 7270v2.
Am Wochenende wollte ich verschiedene Linux-Systeme in eine VM packen und schauen, welches Linux mit welchen noshutdown-Werten arbeiten kann.

Interessanterweise arbeitet 59_Weather mit noshutdown=1. Logischerweise habe ich hier keine Probleme. Aber die, denen noshutdown Probleme bereitet, müssten dann auch mit 59_Weather Probleme haben, dagegen müsste 59_Twilight bei denen laufen... Da Du Probleme mit noshutdown hast: Kannst Du mal testen, ob Du mit 59_Weather Probleme bekommst?

Ich würde daher, sofern noch nicht verfügbar, eine Global-Variable Vorschlagen, mit der HttpUtils noshutdown selbst setzen kann. (Ich kann vom User eher verlangen, eine Global einzutragen, als dass sie ihre benutzten Module zu ihrem System kompatibel machen.)
So sollten, sauberes Coding vorausgesetzt, alle Module die auf http-Funktionen zugreifen, auf Besonderheiten verschiedener Systeme reagieren können.
Noch besser wäre natürlich, wenn HttpUtils selbstständig entscheiden könnte, ob noshutdown gebraucht wird, oder nicht.

Meine vorgeschlagene Änderung ist daher die Anpassung an die Besonderheit der Fritte und Umschreibung von GetFileFromURL zu CustomGetFileFromURL. Siehe HttpUtils.pm, hier wird GetFileFromURL als Kompatibilitätsmodus beschrieben, was meiner Meinung nach darauf hindeutet, das Rudi die Nutzung der HttpUtils ändern möchte. Deswegen ändere ich, da wo ich kann, den Aufruf auf die "neue" Schreibweise ab.

Das mit dem GET ist auch vollkommen korrekt. Ich wollte mit meinen Ausführungen nur aufzeigen, dass YahooWeather GET benötigt. Nicht, das jmd. auf die Idee kommt, weil CustomGetFileFromURL eine $data Variable hat, den Aufruf zu trennen. Weil die Funktion eben genau damit unterscheidet, ob sie GET oder POST sendet. Hab mich da vllt. ein wenig doof ausgedrückt.

[Puschel74]

Hallo,

21:35 reload 59_Twilight.pm durchgeführt nachdem ich die "alte" ersetzt habe.
Dann schauen wir mal.

Danke schonmal für dein Engagement.

Grüße

Edith:

Nachdem ich vorher dieses im Logfile hatte

2013.06.07 20:36:42 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 12836493
2013.06.07 20:51:42 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 12836493
2013.06.07 21:04:34 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 12836493
2013.06.07 21:10:59 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 12836493
2013.06.07 21:14:12 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 12836493
2013.06.07 21:17:35 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 12836493

ist vorerst mal Schluss damit.
Aber es ist erst eine knappe halbe Stunde rum.

[Dietmar63]

Interessanterweise arbeitet 59_Weather mit noshutdown=1. Logischerweise habe ich hier keine Probleme. Aber die, denen noshutdown Probleme bereitet, müssten dann auch mit 59_Weather Probleme haben, dagegen müsste 59_Twilight bei denen laufen... Da Du Probleme mit noshutdown hast: Kannst Du mal testen, ob Du mit 59_Weather Probleme bekommst?

Ich habe kein Problem mit noshutdown. Ich hatte vor Wochen das gleiche Problem mit TW - urplötzlich, und habe den Aufruf aus Weather kopiert - dann war alles gut. Verstanden hatte ich nicht, woher das Problem kam und wie ich es gelöst hatte.  Damals glaubte ich an ein Problem bei yahoo, das dann wieder verschwunden war.

Ich glaube übrigens, dass mit dem noshutdown in Weather niemand Probleme hat. Es gibt lt. Statistik 515(von 1600) registrierte Installationen mit Weather. Im Forum beklagt sich niemand über Probleme mit noshutdown.

Ich würde daher, sofern noch nicht verfügbar, eine Global-Variable Vorschlagen, mit der HttpUtils noshutdown selbst setzen kann. (Ich kann vom User eher verlangen, eine Global einzutragen, als dass sie ihre benutzten Module zu ihrem System kompatibel machen.)
 So sollten, sauberes Coding vorausgesetzt, alle Module die auf http-Funktionen zugreifen, auf Besonderheiten verschiedener Systeme reagieren können.
 Noch besser wäre natürlich, wenn HttpUtils selbstständig entscheiden könnte, ob noshutdown gebraucht wird, oder nicht.

Ich würde erstmal nichts dergleichen vorsehen: Nur Twilight anpassen und einchecken.
Dann beobachten wir was passiert. Falls wider erwarten doch jemand ein Problem hat, erweitere ich Twilight um ein Attribut, das dafür sorgt, dass noshutdown an GetFileFromUrl weitergegeben werden kann. Und nur wer Probleme hat, setzt es.

[Dietmar63]

An den vielen Einträgen kannst du sehen, wie oft das Wetter durch TW von yahoo geholt wird.

So oft ändert es sich bestimmt nicht und außerdem ist der weather_horizon schon vorbei. Das heißt, das die Wetterinformation jetzt vergeblich geholt werden.

Ich ärgere mich darüber, weil vor einem Jahr der kostenlose Google-Service zum Wetter abgeschaltet wurde.
Ab August hatte ich dann plötzlich keine Werte mehr.