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

[Dietmar63]

shutdown auf IO::Socket::INET scheint nicht schädlich zu sein.
http://www.perlmonks.org/?node=108244

Im Gegenteil, es gehört zum zivilisierten Netzwerkverkehr - habe ich jedenfalls so verstanden.  

[OiledAmoeba]

@OiledAmoeba
Ehrlich gesagt kann ich das Problem nicht wirklich nachvollziehen:
[...]
Ich habe eine fb7270v3 - bei ihr tritt das Problem nicht auf.

Dann habe ich dich hier falsch verstanden. Also sollte noshutdown=1 bei niemandem Probleme machen, korrekt?

und habe den Aufruf aus Weather kopiert

Damit hast Du damals ja schon die jetzt vorgeschlagene Änderung eingebaut. Wie schon geschrieben, 59_Weather übergibt noshutdown=1.

OK, warten wir erstmal ab, ob es Probleme mit der neuen Version gibt. Wenn ich jetzt gerade keinen Gedankenfehler habe, dürfte es aber keine Probleme geben...

[OiledAmoeba]

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

Ich meine mich an eine Diskussion zu erinnern, dass Google vermutlich wegen den häufigen Anfragen den Service beendet hat.

Nun, ich habe zum Beispiel Twilight und Weather laufen. Beide fragen ständig bei Yahoo nach. Und sicherlich bin ich nicht der Einzige, der beide Module nutzt.
Bei mir sind das in nur einer Installation zwei regelmäßig wiederkehrende Abfragen. Vllt. macht Yahoo irgendwann das selbe wie Google.
Aber das ist ein anderes Thema.

Danke für deinen Shutdown Hinweis. Da kann ich mir die VMs am Wochenende sparen ;-)
Aber das zeigt dann ja, dass die Fritte nicht so auf zivilisierten Netzwerkverkehr steht. Denn dass die Verbindung geschlossen wird, ist ja genau unser Problem...

[Dietmar63]

genau
ich vermute, dass es keine Probleme geben wird.

[Dietmar63]

Ich habe den englichen text so verstanden, dass es sinnvoll ist beides zum machen:

shutdown
close

shutdown seint aber ein normales Commando im Zusammenhang mit IO::Socket::INET zu sein, teilt dem Gegenüber mit, dass jetzt das Ende der Nachricht erreicht ist(EOF).

Das Close schließt dann die Filehandle. IO::Socket::INET scheint so etwas wie Datei-IO (über das Netzwerk) zu sein.

[Dietmar63]

Nun, ich habe zum Beispiel Twilight und Weather laufen. Beide fragen ständig bei Yahoo nach. Und sicherlich bin ich nicht der Einzige, der beide Module nutzt.
 Bei mir sind das in nur einer Installation zwei regelmäßig wiederkehrende Abfragen. Vllt. macht Yahoo irgendwann das selbe wie Google.
 Aber das ist ein anderes Thema.

Deshalb sollte man vielleicht sparsam mit dem Service von yahoo umgehen:
Weather: Abfragen einmal die Stunde.
Twilight: es reicht morgens und abends eine Stunde vor dem sr/ss, um den weather_horizon zu justieren.

[Puschel74]

Hallo,

nächstes "Zwischenfazit" - erstmal.

Twilight seit dem ersetzen der 59_Twilight.pm Ruhe im Logfile.
Letzte Aktualisierung:
(siehe Anhang / see attachement)
ohne Fehlermeldung (und auch davor seit dem Austausch keine mehr).

Wetter wird bei mir alle 1800 Sekunden (30 Minuten) aktualisiert - kann ich aber gern auch höher setzen.
Nur für Twilight habe ich leider keinen Zeitparameter drin wie oft das aktualisiert werden soll.
Kann ich aber gerne auch nachholen und z.B. per at mit sunrise und sunset aktualisieren lassen (oder um 2 Uhr und um 14 Uhr).

Grüße

Edith: Um 22:58:30 wurde wieder aktualisiert

[OiledAmoeba]

Hey puschel, das freut mich!
Bei mir ebenfalls alles i.O.

In Ermangelung einer Wetterstation hole ich alle 60 Minuten das Wetter, weil bei mir einige Steuerungen vom Wetter abhängen.
Twilight hole ich nur einmal am Tag, bei ss_weather-120. Ich nehme dabei einfach an, dass sich weder Wetter noch Erdneigung täglich soweit verändern, das 2 Stunden vor dem Schaltpunkt der Punkt verpasst sein könnte. Zudem benötige ich nur ss_weather und ss_indoor.
Ich habe aber nach der Diskussion um die vielen Abfragen (war das schon hier oder noch in der Google-Group? Egal...) schonmal darüber nachgedacht, Weather zwischenzuspeichern und Twilight darauf zugreifen zu lassen. Nur sind bei meiner Config die Anfragen von Twilight vernachlässigbar.

EDIT: Ich schieß mich selbst in aus, cool ;-)
Natürlich habe ich das Standardmodul laufen, in dem nur die hier beschriebenen Änderungen drin sind. Damit werden ja trotzdem viertelstündlich Updates gezogen... Ich greife diese Daten nur für meine Zwecke 2 Stunden vor ss_weather ab.

[Dietmar63]

Weather: Ich denke, einmal pro Stunde ist ok.
TW:      holt sich die Daten alle 15 Minunten und braucht sie nicht.

für TW habe ich eine komplett überarbeitete Version des Moduls im Einsatz, das tatsächlich nur dreimal am Tag die weather_horizon holt - wie schon hier geschrieben etwa eine Stunde vor der zuletzt ermittelten Zeitpunkt.

Das Wetter von yahoo läßt sowieso manchmal zu wünschen übrig.

Mit folgendem kleinen Befehl könnt ihr testen wie oft TW die Sonnenaufgänge und Sonnenuntergänge neu berechnet:

Code Auswählen Erweitern

define lichtwechsel           notify Twilight:(.*) {Log 3, "Nachricht von @: %" }

[Dietmar63]

@mcfly71:

jetzt must du uns noch sagen, ob die neue Version des Moduls, hier im Forum veröffentlicht, auch dein Problem löst.
Ich habe folgendes geädert:

(siehe Anhang / see attachement)

ich vermute, dass bei der Berechung der suntime auf Windof -1 herauskommmt. Bei der Masse der Perlinstallationen aber ist das Ergebnis "nan". "nan" steht wohl für "not a Number" !!!! Habe ich durch etwas Suchen auf Google herausgefunden.

Wenn als -1 als Ergebnis herauskommt, ändere ich diesen Wert auch in "nan" und damit sollte der Rest des Moduls wieder funktionieren.

[rudolfkoenig]

Zu noshutdown hatten wir schon eine Diskussion, hier eine detailliertere Erklaerung:
- ein TCP Scoket besteht aus 2 unabhaengigen Kanaelen, eins zum Schreiben, eins zum Lesen
- close() macht beide auf einmal zu, mit shutdown() kann man aussuchen welchen man zumacht.
- falls man mit shutdown(1) den Schreibkanal zumacht, dann signalisiert ein Client damit, dass jetzt keine Daten mehr kommen, der Server kann mit dem Antwort anfangen. Soz. ein eingebautes "quit".
- Leider interpretieren mancher SERVER diesen Signal falsch, und glauben, dass der Client weg ist, und antworten gar nicht. Z.Bsp. auf dem FritzBox befinden sich solche kaputten Server.

Eine globale Variable ist nicht sinnvoll, da dieser Flag nur im Zusammenhang mit dem angesprochenen Server sinnvoll ist, und FHEM spricht gleichzeitig unterschiedliche an.

CustomGetHttpFile sollte man von aussen nicht verwenden, da alle Parameter bis auf dem ersten (quiet) durch GetHttpFile oder GetHttpFileQuiet weitergereicht werden.

[OiledAmoeba]

Moin Rudi,

danke für die Erklärung.

Bei mir ist es wurscht, ob ich GET oder POST einsetzen muss, ohne noshutdown=1 läuft hier nix. Egal, ob notifymyandroid, Webinterface Drucker (Brother), Weather, Twilight oder Webinterface der FHZ.
Deswegen dachte ich, dass eine globale Variable Sinn machen würde.

Irritiert wurde ich durch diesen Kommentar in HttpUtils.pm

Code Auswählen Erweitern

150  # Compatibility modeIch interpretierte das so, dass Du eigentlich auf Custom... umschwenken wolltest.

[egi01]

Hallo an alle,

ich habe das gleiche Problem und zwischenzeitlich alle Beiträge zu diesem Thema gelesen. Auch habe ich die Änderungsvorschläge alle porbiert. Nichts hat geholfen. Bei mir kommt immer noch folgender Eintrag im Log:

2013.06.08 12:43:40 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 12838518
localtime(-nan) too large at ./FHEM/59_Twilight.pm line 225.

Wobei diese Meldung: localtime(-nan) too large at ./FHEM/59_Twilight.pm line 225.
kommt bei mir seit dem 02.06.2013 nachdem ich das zu dieser Zeit aktuelle update installiert habe.

Bei mir läuft fhem auf einem Tuxradio V2.

Für Anregungen, dieses Problem zu beseitigen bin ich dankbar. Leider kenne ich mich mit Perl zu wenig aus, als das ich hier konstruktiv mitreden könnte. Meine Stärken sind Linux als Betriebssystem und Netzwerktechnik

Grüße an alle

[Dietmar63]

Mußtet du überall eigene Verbesserungen in die Module einbauen?
Wenn dem so wäre, sollten dann nicht alle Module angepasst werden?

[Dietmar63]

Dieser Fehler hat nichts mit dem noshudown Thema hier zu tun.

Es rührt daher, dass die Berechnung des sunrise sunset mathematisch manchmal keine Lösung mehr ergibt, und meist 'nan'(Fritz Box )  herauskommt.

Manchmal kommt -1(Windof) heraus, und manchmal -nan(Tuxradio) , so wie bei dir. Könnte an unterschiedlichen Perl-Installationen liegen.

Auf welcher Hardware läuft bei dir fhem - äh jetzt habe ich es gesehen - tuxtadio?

Wie kommst du an ein Perl für tux heran?