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

[HarryT]

Hello

Since a few days I get a lot off "[TWILIGHT] No Weather location found at yahoo weather for location ID" errors. Have other people the same experience?

I changed a lot on my fhem.cfg and 99_mutils.pm  the last days so I am not sure what is happening.
It seems to me there is are no Twilight events triggered when it can't find the weather.

What are your observations?

{HT}

[Jojoe]

push - same here

[JustMe]

kann ich bestätigen.
warum  geht das nicht ? der link in dem modul kann ich aufrufen, allerdings wird wohl nicht mehr richtig geparst??

kann das jemand berichtigen ?

[Puschel74]

Hallo,

sorry aber mein Englisch lässt schwer zu wünschen übrig ...
Wenn es aber um Twilight und die Abfrage in FHEM geht habe ich am 27.05.2013 20:41:05 die letzten Daten bekommen.

Grüße

[JustMe]

dann funktioniert das modul bei dir ?

wenn ich ss_weather und ss vergleiche, sehen die beide identisch aus. heute ist es auch bewölkt.
und im log steht [TWILIGHT] No Weather location found at yahoo weather for location ID:

das sollte heißen das auch die daten für ss_weather deswegen gleich aussehen, weil er ja den normal berechneten wert nimmt.

steht bei dir in der log nicht der Eintrag ?

define myTwilight Twilight 49.962529  10.324845 3 676757

wie in der doku beschrien bring KEINEN wert. dafür allerdings den log eintrat.


vorschläge dafür ?

[Puschel74]

Hallo,

mein Log ist seit April leer und ich weiß nicht warum.
Das einzige was ich dir anbieten kann ist das:

(siehe Anhang / see attachement)

Grüße

[JustMe]

Hallo, und danke für die vielen Infos die du zuspielst !

Irgendwo ist der Wurm drin.
ich versuche gleiche daten wie du auch

define myTwilight Twilight 47.644 7.734 4 12836493

allerdings zeigt er mir nicht die Daten wie bei dir an.

er zeigt mir nur die angehängten Ergebnisse an:


Die Datei 59_Twilight.pm ist vom 08.04.13 um 12:06. ist das bei dir auch so ?
Aber danke für diesen Screen.

[Puschel74]

Hallo,

Die Datei 59_Twilight.pm ist vom 08.04.13 um 12:06. ist das bei dir auch so ?

Wenn du mir sagst wie ich das abrufen oder nachschauen kann kann ich dir das gerne beantworten.

Ich bin leider (oder zum Glück ;-) ) etwas update-faul und warte gerne mal bis nach einem neuen update im Forum

gefixed und eingecheckd

steht
bevor ich ein update mach.
Fehler können sich immer mal einschleichen und je komplexer die Software (und die Module die zusammenspielen sollen) desto schneller klappt was nicht.

Grüße

P.S.: Ich will mit diesem <klappt was nicht> niemanden angreifen. FHEM ist genial dafür das es ein Freizeit-Projekt ist (kann man doch so sagen Rudi oder? )

[JustMe]

Fhem ist " Perfekt " !

Ich "liebe" es. ENDLICH was auch offen erweitert werden kann usw.

Großes Lob an Rudolf Koenig und ALLE anderen die sich die ganze Arbeit machen.

Ich bin absolut begeistert !


Aber das check ich nicht, warum es bei dir geht, und hier eben nicht.
Die Datei liegt im Fhem verzeichniss wo es installiert ist.
Du müsstest dich dort mit einem FTP Programm oder dergleichen einloggen und in den Pfad Fhem sehen. Dort ist die beschriebene Datei.
Unter Datei-Info oder wie es auch immer in den verschiedenen Programmen heist steht das datum und die Grösse usw.

Wenn du damit aber sonst nie was machen solltest, lass es. Ich möchte nicht das du dein System vielleicht jetzt dadurch beschädigst, weil du eine Datei ausversehen veränderst.


Aber Danke soweit, das hilft schon.


Grüsse
Christian

[Puschel74]

Hallo,

ich greife auf meine RasPi grundsätzlich per Putty über die Kommandozeile zu - ich kenn nur nicht alle Pfade und Wege (und Befehle) ;-)
Verändern könnte ich sowieso nur mit sudo irgendwas - und da werd ich vorher gefragt ob ich die Änderung speichern möchte (was ich erstmal verneine - es sei den ich will das auch ändern).
Wenn du mir also den Pfad und den Namen der Datei sagen kannst kann ich gern per Putty nachschauen was drinnen steht.
Wenn du weiterführende Linuxbefehle inkl. evtl. Pfadangaben (auf einer 0815 Linux(Wheezy)Installation) hast - dann nur her damit.
Ich entlocke meinem System gern (fast) alles was du wissen willst - musst um einen Unterschied zu finden.

Grüße

[Dietmar63]

Twiglight hat sich seit ewigen Zeiten nicht geändert:

(siehe Anhang / see attachement)

Diese Fm hatte ich vor zwei Monaten auch schon einmal - war dann aber ganz schnell behoben - irgendwie von allein.
Sendet mir mal eure Einstellung, die zum Fehler führt, dann prüfe ich warum das parsen nicht funktioniert.

Diese Werte funktionieren bei mir:

Code Auswählen Erweitern

define myTwilight Twilight 47.644 7.734 4 12836493
(siehe Anhang / see attachement)

[Puschel74]

Hallo,

das einzige was ich anbieten kann (mangels meines Linuxwissens) ist das:
(siehe Anhang / see attachement)

Ein Scrennshot der 59_Twilight.pm.

Sorry das ich (noch) nicht mehr bieten kann.

Grüße

[Dietmar63]

In der ersten Zeile seht ihr, dass das Modul zuletzt Anfang Januar geändert wurde.
Und die Änderung bezog sich auf "update-change-on-reading" ... die Logik wurde nicht geändert.

[JustMe]

hallo !

äpfel und birnen hab ich verglichen. und wie du siehst hab ich auch nicht sonderlich viel ahnung von dem linux zeugs.
ich hab fhem noch gar nicht lang. das wird hier warscheinlich mein installations-datum sein.
in der datei hab ich dann natürlich das gleich wie du auch stehen.
vielleicht kann er GetFileFromURL oder so nicht ausführen.

ich hab derzeit auch keine ahnung wie ich das prüfen kann.

ja blöd gelaufen, dann werd ich nichts dran ändern können.


ich werd das was du hier alles von deiner laufenden version gepostet hast, später noch vergleichen.
zur zeit bastel ich aber noch an was anderem rum. irgendwie ist hier grad die lust weg...


wünsch dir noch einen erholsamen Abend, bei dem schönen wetter was heute war.


grüsse
Christian

[Puschel74]

Hallo,

so, nun Reihe ich mich auch bei Euch ein.

2013.06.03 11:38:20 1: [TWILIGHT] No Weather location found at yahoo weather for location ID:

Seit heute bekomme ich auch keine Werte mehr geliefert.

Grüße

[Dietmar63]

schick mir deine Definition - dann prüfe ich, ob ich etwas herausfinde.

[Puschel74]

Hallo,

um 16:24 wurden wieder Werte übertragen *grübel*

schick mir deine Definition - dann prüfe ich, ob ich etwas herausfinde.

Danke aber ich vermute das es an Yahoo liegen könnte.
Aber das ist jetzt nur mal so spekuliert von mir.

Grüße

Edith: Kommando zurück. Ich bekomme nach wie vor die fehlermeldung im Logfile

2013.06.03 16:39:57 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 12836493

Allerdings wurden die Werte in den Readings auch um 16:39:57 aktualisiert.
Hier mal meine Definition für myTwilight:

Code Auswählen Erweitern

define myTwilight Twilight 47.644 7.734 4 12836493

[JustMe]

Hallo,

ich glaube in keinem fall das es an Yahoo gelegen hat.
Die Datei kann wunderbar geladen werden. Ich hab mir die Datei angesehen, und die Werte die geparst werden sollen ( Der Identcode für das Wetter ) taucht in der Datei auch auf.

So und hier hört es dann aber auf.

Ich versteh nicht warum er mich nicht die Wetterdaten umschlüsselt und den rest anzeigen kann.


Aber ich bastle nach wie vor an was anderem rum.


Grüsse
Christian

[Dietmar63]

Ich glaube, dass yahoo manchmal einen xml String sendet, der von TW nicht geparst werden kann.
Es wäre schön ihn zu Gesicht zu bekommen, wenn es mal wieder passiert.

Dann könnte man sich eine Lösung einfallen lassen.

Zeile 320 ist die entscheidende Stelle:
(siehe Anhang / see attachement)

[Dragonfly]

Selbiges bei mir - FHEM auf FB7390

Hat heute um 11:41 begonnen, um 12:11 hats geklappt, dann 26x nicht und jetzt um 19:37 ging es wieder.

Internet neu verbinden, FHEM Neustart, FB Neustart hat nichts gebracht.
Parallel zu TWILIGHT läuft bei mir WEATHER - dies hat, so wie es aussieht, funktioniert - läuft aber nur alle 60 Minuten.

Wie kann ich helfen, um den xml-String "sichtbar" zu machen?

LG - Tom

[JustMe]

ich hab die datei geladen, und der string wird korekt erkannt.

aber es erscheinen trotzdem keine werte in fhem.

woher das kommt kann ich nicht sagen.
wenn er die datei nicht bekommt erschein ein fehler im fhem.

die datei ist wohl generell in xml:

Code Auswählen Erweitern


<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<rss version="2.0" xmlns:yweather="http://xml.weather.yahoo.com/ns/rss/1.0" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#">
<channel>

<title>Yahoo! Weather - Munich, DE</title>
<link>http://us.rd.yahoo.com/dailynews/rss/weather/Munich__DE/*http://weather.yahoo.com/forecast/GMXX0087_c.html</link>
<description>Yahoo! Weather for Munich, DE</description>
<language>en-us</language>
<lastBuildDate>Mon, 27 May 2013 8:00 pm CEST</lastBuildDate>
<ttl>60</ttl>
<yweather:location city="Munich" region="BY"   country="Germany"/>
<yweather:units temperature="C" distance="km" pressure="mb" speed="km/h"/>
<yweather:wind chill="10"   direction="30"   speed="3.22" />
<yweather:atmosphere humidity="87"  visibility=""  pressure="1011"  rising="0" />
<yweather:astronomy sunrise="5:18 am"   sunset="8:59 pm"/>
<image>
<title>Yahoo! Weather</title>
<width>142</width>
<height>18</height>
<link>http://weather.yahoo.com</link>
<url>http://l.yimg.com/a/i/brand/purplelogo//uh/us/news-wea.gif</url>
</image>
<item>
<title>Conditions for Munich, DE at 8:00 pm CEST</title>
<geo:lat>48.14</geo:lat>
<geo:long>11.58</geo:long>
<link>http://us.rd.yahoo.com/dailynews/rss/weather/Munich__DE/*http://weather.yahoo.com/forecast/GMXX0087_c.html</link>
<pubDate>Mon, 27 May 2013 8:00 pm CEST</pubDate>
<yweather:condition  text="Drizzle"  code="9"  temp="10"  date="Mon, 27 May 2013 8:00 pm CEST" />
<description><![CDATA[
<img src="http://l.yimg.com/a/i/us/we/52/9.gif"/><br />
<b>Current Conditions:</b><br />
Drizzle, 10 C<BR />
<BR /><b>Forecast:</b><BR />
Mon - Showers Early. High: 14 Low: 4<br />
Tue - PM Showers. High: 19 Low: 9<br />
<br />
<a href="http://us.rd.yahoo.com/dailynews/rss/weather/Munich__DE/*http://weather.yahoo.com/forecast/GMXX0087_c.html">Full Forecast at Yahoo! Weather</a><BR/><BR/>
(provided by <a href="http://www.weather.com" >The Weather Channel</a>)<br/>
]]></description>
<yweather:forecast day="Mon" date="27 May 2013" low="4" high="14" text="Showers Early" code="45" />
<yweather:forecast day="Tue" date="28 May 2013" low="9" high="19" text="PM Showers" code="39" />
<guid isPermaLink="false">GMXX0087_2013_05_28_7_00_CEST</guid>
</item>
</channel>
</rss>

<!-- api29.weather.bf1.yahoo.com Mon May 27 19:13:20 PST 2013 -->


[Dietmar63]

wenn du kannst, ändere in der Datei 59_Twilight.pm

Code Auswählen Erweitern

 Log 1, "[TWILIGHT] No Weather location found at yahoo weather ".
        "for location ID: $location";
in

Code Auswählen Erweitern

 Log 1, "[TWILIGHT] No Weather location found at yahoo weather for location ID: $location\nxml:\n$xml";

Wenn dann der Fehler auftritt, bekommmen wir den passenden xml-String ins Log geschrieben, und wir können prüfen was die Ursache sein könnte.

[Dragonfly]

Geändert und folgendes kommt raus:

Code Auswählen Erweitern

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

In meinen Augen nicht viel?!

Nachtrag:
Über Nacht hat es 2x geklappt, 17x nicht - ich lass mir das in einem Dummy loggen der hochzählt.
Hatte ich mal gebaut, da die Internetverbindung 1x im Monat "träge" ist und ich ab einem Wert von "4" einen automatischen Reconnect veranlasse - das hat dann geholfen (als PING-Ersatz sozusagen).

[Puschel74]

Hallo,

hier mal die Fehlermeldung aus dem FHEM-Logfile:

2013.06.04 09:37:52 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 12836493

aber die Daten wurden in FHEM aktualisiert (siehe Datum / Uhrzeit):
(siehe Anhang / see attachement)

[Steffen]

Hallo!

So ist es bei mir aucu schon seit ca.2Tagen:

2013.06.04 09:56:42 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 686627

Mfg Steffen

[Puschel74]

Hallo,

werden die Daten in fhem dennoch aktualisiert?
Bei mir ist es so (s.o.).

Grüße

[mcfly71]

Guten Tag liebe Gemeinde,

also bei mir ist das auch so.
Der Fehler erscheint im log, dass die Werte dennoch gemacht werden, liegt daran,
dass in der Funktion, wo die Fehlermeldung ausgegeben wird, NUR !!!
der WEATHER_HORIZON berechnet wird, alle anderen Daten sind zur Verfuegung.
D.h.: Immer wenn der Fehler auftritt, sind danach die Werte von
[ss] und [ss_weather] gleich (Die ursprüngliche Idee ist ja, dass wenn es verdammt dunkel ist wegen der Wolken, die Werte auch was dunkler zu machen, respektive wenn Gewitterwolken über einem hängen,
soll es sozusagen früher dunkel werden.

Die Logbuch Änderung habe ich gemacht, und ich sehe dasselbe wie ein Vorchreiber von mir:
Die Variable $xml ist leer!!!!, somit schmeisst er dann korrekterweise die Fehlermeldung raus.
Ich weiss allerdings wirklich nicht, warum die leer ist. Die einzige Erklärung die ich habe, ist die Response Zeit von 4.0 (die könnte dann immer zuwenig sein).
Ich stelle die mal hoch und werde wieder berichten.....

MfG
mcfly

[Mark]

Hallo zusammen,

ich lese mit, da ich auf meinem Windows System auch Probleme mit twilight habe.
Unter Linux scheint es allerdings nicht solche fatalen Auswirkungen zu
haben wie auf meinem Windows System.

Hier meine Erfahrungen:
Das erste Mal ist FHEM durch twilight am 28.05.2013 01:17:47 "eingefroren".
Dies war der Zeitpunkt als twilight das letzte mal versucht hat Daten zu holen.
Ein Neustart war nicht möglich, da FHEM immer wieder beim "define twilight"
eingefroren ist.

Durch herumprobieren konnte ich herausfinden, dass das define von twilight wieder
funktionierte, wenn der <latitude> Wert kleiner 50 ist.

Beispiel:
define mytwilight twilight 47.644 7.734 4 12836493
- funktioniert einwandfrei.

define mytwilight twilight 50.644 7.734 4 12836493
- sofort Ende ! FHEM friert ein.

Für mich als Laie lief mein System erst einmal wieder.

Allerdings nur bis heute Nacht. Dies ist der letzte Logeintrag:
2013.06.04 01:21:30 1: [TWILIGHT] No Weather location found...

Damit mein FHEM wieder zu starten war, musste ich zuerst den twilight Eintrag in meiner fhem.cfg löschen.

Mann beachte den Zeitabstand. Ziemlich genau eine Woche 28.05.2013 01:17:47 -> 2013.06.04 01:21:30

Vielleicht hilft einem von Euch die Information bei der Fehlereingrenzung.

Der Ansatz, dass Yahoo hin und wieder (Einmal die Woche?) einen anderen Datensatz sendet,
würde erklären warum FHEM/perl sich auf einem Windows System "zerlegt".

Ubuntu zeigt sich übrigens von <latitude> Werten kleiner 50 unbeeindruckt und läuft einfach weiter.

Gruß Mark

[mcfly71]

Hallo Marc,

dein Einfrieren hatte ich auch, ebenfalls unter Windows-System.
Liegt an einer Zeile  script. ich zeige dir mal mein script.
Da ist auch ein Kommentar, der erklärt warum es passiert, und vor
allen Dingen, warum der Typ im Norddeutschen das früher hatte als wir,
und auch warum es mit anderen Koordinaten bei dir wieder fummt:

2) Modul 59_Twilight.pm

  for(my $i=0; $i<6; $i++) {
    ($sunrise_set[$i]{RISE}, $sunrise_set[$i]{SET})=
       Twilight_calc($latitude, $longitude, $sunrise_set[$i]{DEGREE},
                     $declination, $timezone, $midseconds, $timediff);
      # MCFLY GEAENDERT:
      # twilight ermittelt ³brigens hier in Norddeutschland im Moment keine Werte f³r sr-/ss_astro (-18¦).
      # Die Sonne sinkt nicht mehr so tief unter den Horizont.
      # Der Wert f³r light erreicht somit auch nicht den Wert 0.
      # ABER sobald mit -1 localtime aufgerufen wird, st³rzt perl ab
      # orig.: statt =~ "-1" stand ein eq "nan"
    readingsBulkUpdate($hash, $sunrise_set[$i]{SR_NAME},
        $sunrise_set[$i]{RISE} !!!!!=~ "-1"!!!!! ? "undefined" :
        strftime("%H:%M:%S",localtime($sunrise_set[$i]{RISE})));
    readingsBulkUpdate($hash, $sunrise_set[$i]{SS_NAME},
        $sunrise_set[$i]{SET} !!!!!=~ "-1"!!!!! ? "undefined" :
        strftime("%H:%M:%S",localtime($sunrise_set[$i]{SET})));
  }

Das behebt wenigstens dein erstes Problem, warum das sonst niemandem aufgefallen ist ... man weiss es nicht....
Vielleicht kann rudolf was dazu sagen ????? und es könnte eingecheckt werden, oder wie das heisst..
Bei mir blieb Perl übrigens nicht hängen, sondern startete immer wieder nach einem Absturz neu.

Leider ändert sich das andere Problem dadurch nicht.... ich bleibe aber auch dran....

P.S. Für mich gilt auch: Egal was ich schreibe, dass Rudolf König und andere soviel Zeit da reinstecken, finde ich mehr als spitze. Die Fehler, die auftauchen muessen halt ausgemerzt werden....

[Mark]

Hallo mcfly71,

danke für Deinen Hinweis. Bisher läuft mein FHEM mit Deinen Änderungen.

Gruß Mark

[Steffen]

Hallo!

Bei mir immer noch das gleiche:

Code Auswählen Erweitern

2013.06.05 09:03:17 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 686627
2013.06.05 09:18:17 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 686627
2013.06.05 09:18:18 3: Notify gesendet
2013.06.05 09:33:17 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 686627
2013.06.05 09:48:17 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 686627
2013.06.05 10:03:17 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 686627
2013.06.05 10:18:17 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 686627
2013.06.05 10:18:18 3: Notify gesendet
2013.06.05 10:33:17 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 686627
2013.06.05 10:48:17 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 686627
2013.06.05 10:56:43 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 686627
2013.06.05 11:03:17 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 686627
2013.06.05 11:03:39 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 686627

Code Auswählen Erweitern

CONDITION
-1
DEF
52.286117 13.539019 3 686627
INDOOR_HORIZON
3
LATITUDE
52.286117
LONGITUDE
13.539019
NAME
myTwilight
NR
169
NTFY_TRIGGERTIME
2013-06-05 11:11:43
STATE
6
TYPE
Twilight
WEATHER
686627
WEATHER_HORIZON
0

Readings
condition
-1
2013-06-05 11:11:43
light
6
2013-06-05 11:11:43
nextEvent
ss_weather
2013-06-05 11:11:43
nextEventTime
21:14:10
2013-06-05 11:11:43
nextUpdate
11:26:43
2013-06-05 11:11:43
sr
04:54:29
2013-06-05 11:11:43
sr_astro
01:00:00
2013-06-05 11:11:43
sr_civil
03:59:32
2013-06-05 11:11:43
sr_indoor
05:18:52
2013-06-05 11:11:43
sr_naut
02:45:11
2013-06-05 11:11:43
sr_weather
04:54:29
2013-06-05 11:11:43
ss
21:14:10
2013-06-05 11:11:43
ss_astro
undefined
2013-06-05 11:11:43
ss_civil
22:09:07
2013-06-05 11:11:43
ss_indoor
20:49:47
2013-06-05 11:11:43
ss_naut
23:23:28
2013-06-05 11:11:43
ss_weather
21:14:10
2013-06-05 11:11:43


gibt es dafür schon eine Lösung??

[Puschel74]

Hallo,

der Beitrag von mcfly71 drüber hilft dir nicht?

Grüße

[Mark]

Hallo,

mein FHEM läuft mit den Änderungen ohne abzustürzen.
Die Yahoo Fehlermeldung bekomme ich auch.

Gruß Mark

[Dietmar63]

bei mir laüft TW mit deinen Werten:

Code Auswählen Erweitern

define tw1 52.286117 13.539019 3 686627
ich denke es liegt wirklich daran, dass die Antwort zu spät geliefert wird.

[Dietmar63]

Hast du vielleicht auch eine langsame Internetverbindung?

Wenn das zutrifft, dann liefert deine FB wahrscheinlich auch die Wetterdaten von yahoo langsam aus und die 4 Sekunden timeout reichen nicht und der xml-String ist leer.

Du könntest dich auch einmal per telnet auf der Fb anmelden und mit top die Performance prüfen.
Bei mir ist die Hardware nur schwach ausgelastet - unter 5%.

[Steffen]

Hallo!

Also auch mit dem Tip von mcfly71 klappt es leider auch nicht(mache aber da noch irgendwas selber Falsch), könnte jemand die jetzt geänderte Version hier online stellen?
Wollte nur hinzufügen, das ich sonst nie Fehlermeldung hatte zu Twilight erst seit ca.3 Tagen ist das erst jetzt so.

Mfg Steffen

[Dragonfly]

Da ich ja auch ein "Opfer" bin - Internet Verbindung (gerade getestet): 21 Mbps down / 4 Mbps up

Richtig begonnen hat es am 2013-06-03_11:41:04 - sonst Sporadisch, wenn die Internetverbindung schlecht war. Das hat man aber dann auch beim Surfen gemerkt.

Heute konnte ich 6x über den Tag verteilt die korrekten Daten erhalten, habe FHEM 1x gestartet wegen update.

[Dietmar63]

was helfen könnte, die fb komplett neu booten.

bzw. im Modul Twilight Zeile 317:

Code Auswählen Erweitern

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


Code Auswählen Erweitern



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


Dann wartet fhem bis zu 6 Sekunden auf eine Antwort von yahoo.
Wenn's immer noch nicht klappt, dann vielleicht auf 8.0 setzen.

[Steffen]

was helfen könnte, die fb komplett neu booten.

bzw. im Modul Twilight Zeile 317:

Code Auswählen Erweitern

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


Code Auswählen Erweitern



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


Dann wartet fhem bis zu 6 Sekunden auf eine Antwort von yahoo.
Wenn's immer noch nicht klappt, dann vielleicht auf 8.0 setzen.

Guten Morgen!

Auch das bringt keine besserung:

Code Auswählen Erweitern

2013.06.06 04:33:18 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 686627

Ich glaube das es wenig mit der eigenen Internetverbindung zu tun hat, den der Fehler trat fast gleichzeitig bei mehreren auf wenn ich mich nicht irre?!

Mfg Steffen

[Dragonfly]

FB reboot bringt nichts, Timeout auf 8 sec auch nicht.
Änderung der DNS-Server in der FB - kein Erfolgt.
Vorübergehender Wechsel von Cable auf UMTS - die Fehlerrate scheint geringer zu sein, aber nach 1 h testen ist dies nicht aussagekräftig.

Das Modul weather.pm bezieht ja die Daten von der gleichen Stelle - ich habe die Aktuallisierung von 3600 auf 36 gesetzt - funktioniert.
Auszug aus weather.pm

Code Auswählen Erweitern

 my $xml = GetFileFromURL("http://weather.yahooapis.com/forecastrss?w=" . $location . "&u=" . $units, 3, undef, 1);
  return 0 if( ! defined $xml || $xml eq "");
Vielleicht kann man ja von "weather" ableiten, was in "twilight" anders gemacht wird?
Leider überschreitet dies wieder einmal meine Fähigkeiten :-((

[mcfly71]

Hallo DragonFly,

ja du hast recht, bei weather ""funktioniert"" das besser... aber nicht wirklich - jedenfalls sagen wir mal keine Aussage -, da weather mit der Zeile
 return 0 if( ! defined $xml || $xml eq "");
Genau dann abbricht, wenn die Rückgabe leer ist und einfach ohne Fehlermeldung rausgeht.
Das macht Twilight nicht, geht weiter, stellt indirekt fest, dass $xml leer ist - nämlich dadurch, dass der reguläre Ausdruck nicht passt - und gibt dann die uns bekannte Fehlermeldung aus.
Sprich es kann sein, dass das alles auch bei weather passiert, aber wir es nicht mitkriegen, da kein logbuch Eintrag erzeugt wird.

MfG
mcfly

[OiledAmoeba]

Mich hat's auch getroffen, ebenfalls seit 3.6.:

2013.06.03 11:43:32 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 657169

[OiledAmoeba]

So, hab jetzt einen  Treffer.

Die Anpassung von mcfly71 brauchts bei mir nicht.
Bei mir war der Trick: Anpassung an Fritte mit folgender Änderung des Code in 59_Twilight.pm

Code Auswählen Erweitern

317  my $xml = GetFileFromURL("http://weather.yahooapis.com/forecastrss?w=".
318                            $location."&u=c",4.0, undef, 1);
wobei die Änderung ist: "[...],4.0, undef, 1);

Erklärung: Die Funktion GetFileFromURL wird intern durch HttpUtils.pm in die Funktion CustomGetFileFromURL umgewandelt. Die von mir angehängten Parameter erklären Data=undef (der Data-String wird bereits mit der URL übergeben) und noshutdown=1, für die Fritten notwendig, da sie Rückgaben der Server sonst meist nicht verarbeiten.

Seit dieser Änderung tritt der Fehler bei mir nicht mehr auf.

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

[mcfly71]

Hey mann für ne ölige Amöbe biste gut drauf :;-)

Bei mir funktionierten die ersten Test ebenfalls.
Der Punkt ist ja wohl - glaube ich - das der shutdown = 1 jetzt ist, da data vorher bei leer ja auch undef war, und somit ein POST gemacht wurde.
Wat is dat eigentlich mit der Fritte (hier in Aachen nennen wir die Belgier so, aber ich schätze du meinst was anderes... :-) ) ?


Allerdings muss ich meine Änderung nach wie vor beibehalten, sonst startet perl immer wieder neu, da es vorher abstürzt.

Aber auf jedenfall: Gute Verbesserung....

mcfly

[Dragonfly]

Vielen Dank von mir und meiner Fritz!

Soweit einwandfrei!

Wie geht´s jetzt weiter?
Sollte weather.pm dann auch gleich überarbeitet werden?

Nicht daß bei irgendeinem Update oder einer Neuinstallation das ganze Theater wieder von vorne beginnt!

LG Tom

[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.

[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?

[OiledAmoeba]

Nicht wirklich. Weather läuft von Haus aus mit noshutdown=1, Twilight jetzt ja auch.
Das Webinterface der FHZ spreche ich mit einem watchdog an und den Drucker über at/notify.
Notifymyandroid wird über meine Eigenkonstruktion angesprochen.

[Steffen]

Hallo!

Kurze Info von mir, auf meinem "Pi" mit HMLAN habe ich seit der Änderung der von Dietmar63 bereitgestellten Twilight.pm keine Fehler mehr im Log und scheint erstmal alles Korrekt zu sein.


Mfg Steffen

[OiledAmoeba]

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

Könnte man den Fehler über unterschiedliche Berechnungen mit Hilfe von

Code Auswählen Erweitern

if($^O =~ m/Win/) {
} else {
}
abfangen?
Nur als möglicher Denkanstoß. Muss gleich weg, mir kam diese if/else gerade nur so in den Sinn...

[Dietmar63]

Es ist einfach nur notwendig nach der Berechnung, die  verschiedenen Fehlersituationen abzufragen und immer -1 oder immer 'nan' zurück zu geben. Die Formel bleibt auf allen Plattformen gleich.

Dann ist der Code Plattform unabhängig.

[Puschel74]

Hallo,

Nachtrag von mir.

Auf meinem RasPi ist mit der geänderten 59_Twilight.pm auch Ruhe und keine Fehlermeldungen mehr im Log.
Die Daten werden brav aktualisiert.

Grüße

[egi01]

Hallo Dietmar,

auf dem Tux läuft ein Debian Linux und der Perlinterpreter ist da einfach dabei. Die Dateien kann ich einfach mit dem vi editieren, oder auf meinem Rechner und werden nach Veränderung wieder zurückkopiert.

Ich möcht aber nochmals darauf hinweisen, in meinem Log steht nach wie vor das, in genau dieser Reihenfolge:
2013.06.08 16:57:36 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 12838518
localtime(-nan) too large at ./FHEM/59_Twilight.pm line 225.
2013.06.08 16:58: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.
2013.06.08 16:59:21 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 12838518
localtime(-nan) too large at ./FHEM/59_Twilight.pm line 225.
2013.06.08 17:12:36 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 12838518
localtime(-nan) too large at ./FHEM/59_Twilight.pm line 225.
2013.06.08 17:13: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.
2013.06.08 17:14:21 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 12838518
localtime(-nan) too large at ./FHEM/59_Twilight.pm line 225.
2013.06.08 17:27:36 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: 12838518
localtime(-nan) too large at ./FHEM/59_Twilight.pm line 225.
2013.06.08 17:28: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.
localtime(-nan) too large at ./FHEM/59_Twilight.pm line 225.

Hier der Logauszug wo die Meldungen das erste mal aufgtrten sind.

2013.06.03 10:45:47 3: Watchdog wd_FHT_Bad_3 triggered
2013.06.03 10:45:47 2: FHT set FHT_232d hour 10 minute 45
localtime(-nan) too large at ./FHEM/59_Twilight.pm line 225.
localtime(-nan) too large at ./FHEM/59_Twilight.pm line 225.
localtime(-nan) too large at ./FHEM/59_Twilight.pm line 225.
localtime(-nan) too large at ./FHEM/59_Twilight.pm line 225.
localtime(-nan) too large at ./FHEM/59_Twilight.pm line 225.
localtime(-nan) too large at ./FHEM/59_Twilight.pm line 225.
localtime(-nan) too large at ./FHEM/59_Twilight.pm line 225.
localtime(-nan) too large at ./FHEM/59_Twilight.pm line 225.
2013.06.03 11:27:59 1: [TWILIGHT] No Weather location found at yahoo weather for location ID:
localtime(-nan) too large at ./FHEM/59_Twilight.pm line 225.
2013.06.03 11:31:25 1: [TWILIGHT] No Weather location found at yahoo weather for location ID:

[Dietmar63]

probier mal diese Version:

ich habe die Berechnungsmethode geändert!
Im Modul wurde eine arcuscosinisFunktion verwendet.
Diese Funktion ist für Agumente < -1 bzw. > +1 nicht definiert.

Das fange ich jetzt anders ab, so dass auf allen Rechnertypen und Perlversionen "nan" zurückgeliefert wird - hoffentlich.

Je nach Installation können sogar Complexe Zahlen herauskommen! Windowsversionen liefern so etwas scheinbar.
Deine Verision hat offensichtich ein  -nan erzeugt (nan steht für not a number).

[egi01]

Hallo Dietmar,

sieht momentan gut aus, keine Meldung mehr.
Muß jetzt nochmal weg. Mal sehen was das  Log später sagt, wenn ich iweder da bin.

Erst mal ein Danke an Dich

[JustMe]

Vielen Dank Dietmar63 !!

Bei mir geht es jetzt auch, hab es gerade probiert.


Grüsse
Christian

[mcfly71]

Hallo Diemtmar,

es funktioniert leider nicht

Das liegt daran, dass in Twilight_calc($$$$$$$) die $sunset und $sunrise Vars nicht
-1 sind, sondern: -1.#IND
also garkeine Zahl.... deshalb hatte ich =~ m/-1/ in meiner Version getestet....
ich habe =~ m/-1/ nun in Twilight_calc($$$$$$$) eingebaut, und es klappt wieder....

Vielleicht änderst du es auch so ??

VG
mcfly

[Dietmar63]

Hast du die Version von gestern 17:57 probiert?
Poste bitte deine Twilight_calc.

Sie sollte so aussehen:

Code Auswählen Erweitern


sub Twilight_calc($$$$$$$)
{
  my ($latitude, $longitude, $horizon, $declination, $timezone, $midseconds, $timediff) = @_;

  my $s1 = sin($horizon /57.29578);
  my $s2 = sin($latitude/57.29578) * sin($declination);
  my $s3 = cos($latitude/57.29578) * cos($declination);

  my ($suntime, $sunrise, $sunset);
  my $acosArg = ($s1 - $s2) / $s3;
  if (abs($acosArg) < 1.0) {   # ok
     $suntime = 12*acos($acosArg)/pi;
     $sunrise = $midseconds + (12-$timediff -$suntime -$longitude/15+$timezone) * 3600;
     $sunset  = $midseconds + (12-$timediff +$suntime -$longitude/15+$timezone) * 3600;
  } else {
     $sunrise = $sunset = "nan";
  }

  return $sunrise, $sunset;
}

Die Ursache liegt in der Berechnung von suntime. Gib diesen Inhalt aus.

[mcfly71]

Hallo Dietmar,

mein Fehler, habe die neueste Version eingesetzt... diese funktioniert jetzt...

übrigens bislang auch das gethttpfile.....

spitze

vg
mcfly

[Dietmar63]

Dann werde ich es heute Abend einchecken.
Nach meinem Urlaub wird es dann eine neuer Version geben, die intern komplett anders läuft - natürlich nicht ohne vorher einen Betatest durchführen zu lassen.

[Markus Bloch]

Hi Dietmar,

find ich super, dass du dich um das Modul kümmerst. Ich wollte fragen, ob du eine Möglichkeit siehst, die Kalkulation so laufen zu lassen, dass auch Lichtwertänderungen die zwischen den verschiedenen Sunset/Sunrises stattfinden erfassen.

Mein Problem ist, dass ich vor allem beim Sonnenuntergang aktuell mehrere Werte übersprungen werden. Also z.B.

6
3
2
1
0

oder

6
5
3
2
1
0

Aktuell wird ja der Lichtwert immer beim nächsten Sunset/Sunrise-Step neu berechnet. Es währe aber toll, wenn gerade während eines Sonnenuntergangs und -aufgangs der Lichtwert kontinuierlich berechnet wird, da es gerade hier spannend wird, wann die Rollos runterfahren sollen.

Aktuell fahre ich die Rollos bei erreichen des Wertes 4 herunter/herauf, sofern man sich im Sonnenaufgang/-untergang befindet.

Es währe daher sehr cool, wenn du das in deiner neuen Version mit einbeziehen könntest.

Vielen Dank

Gruß
Markus

[Dietmar63]

Fehlerbereinigte Version eingecheckt.

@Markus:
Ich habe mit mit den Innereien des Moduls schon länger beschäftigt.

Es ordnet jedem ss/sr (-18, -12, -6, 0, indoor_horizon, indoor_horizon+weather_horizon) einen Lichtwert von (0-6) zu.
Tagsüber ist 6(hellichter Tag) der Lichtwert, wenn die Sonne unter dem Horizont von -18° gesunken ist, liefert es 0(stockdunkel).

Es ermittelt alle 900 Sekunden alle ss/sr des Tages neu und holt sich das Wetter von yahoo um die aktuelle Wetterbedingung in die Berechnung einzubeziehen. Wenn das Wetter schlecht ist, wird einfach ein anderer Weather_horion angenommen: +15° könnte das zum Beispiel sein, wenn es stark bewölkt ist. Das führt dann dazu, das der indoor_horizon+weather_horizon ca. 15*7 Minuten früher "stattfindet". Die restlichen ss/sr sind davon nicht beeinflußt.

Ich habe eine Version im Einsatz, die die Berechnung der horizon, die sich am Tag nicht ändern, nur einmal, so gegen Mitternacht berechnet. Die ermittelten Werte für den indoor_horizon+weather_horizon werden dann nochmals jeweils eine Stunde vor dem jeweiligen Ereignis nachberechnet.

Bei mir wird dann zum Zeitpunkt indoor_horizon+weather_horizon das Licht angeschaltet - passt ganz gut.

Das Überspringen der Lichtwerte kommt daher, dass du vermutlich keinen indoor_horizon angegeben hast. In der Übersicht fallen dann wahrscheinlich viele ss oder sr vom Zeitpunkt her zusammen:

ss               0°
ss_indoor        ss+indoor_horizon                   (Parameter bei der Definition)
ss_weather       ss+indoor_horizon+weather_horizon   (yahoo-Wettercode->Horizont)  

Zwischen 6 und 4 ist dann keine detailierte Steuerung möglich. Es gibt einfach nur diese wenigen Werte.
Mal sehen was uns noch so einfällt - Ich komme sowiso erst nach meinem Urlaub Anfang Juli dazu, etwas zu ändern.

[Puschel74]

Hallo,

OT

Ich komme sowiso erst nach meinem Urlaub Anfang Juli dazu, etwas zu ändern.

Hast du es gut ;-)
Geniess deinen Urlaub und mach mal den PC aus ^^

OT-Ende

Grüße

[Dietmar63]

Hallo Markus,

Twilight detaillierter zu machen mit dem Ansatz, der zur Zeit implementiert ist, dürfte schwierig sein.

Es gibt aber einen Ansatz von Loredo aus der Sonnenposition die Himmelsrichtung zu ermitteln, aus der die Sonne scheint. Aus seiner Idee, hat er ein Modul erstellt, das alle n Minuten die Himmelsrichtung und die Höhe der Sonne am Himmel ermitteln kann.

Ich habe ihm ein wenig unter die Arme gegriffen und zur Zeit kommt folgender Output heraus:

Code Auswählen Erweitern


2013.06.10 22:17:24 3: compassPoint------------>north-northwest
2013.06.10 22:17:24 3: dElevation------------>-4.4
2013.06.10 22:17:24 3: dAzimuth-------------->318.5
2013.06.10 22:16:24 3: compassPoint------------>north-northwest
2013.06.10 22:16:24 3: dElevation------------>-4.3
2013.06.10 22:16:24 3: dAzimuth-------------->318.3
2013.06.10 22:15:24 3: compassPoint------------>north-northwest
2013.06.10 22:15:24 3: dElevation------------>-4.2
2013.06.10 22:15:24 3: dAzimuth-------------->318.1
2013.06.10 22:14:24 3: compassPoint------------>north-northwest
2013.06.10 22:14:24 3: dElevation------------>-4
2013.06.10 22:14:24 3: dAzimuth-------------->317.9
2013.06.10 22:13:24 3: compassPoint------------>north-northwest
2013.06.10 22:13:24 3: dElevation------------>-3.9
2013.06.10 22:13:24 3: dAzimuth-------------->317.7
2013.06.10 22:12:24 3: compassPoint------------>north-northwest
2013.06.10 22:12:24 3: dElevation------------>-3.8
2013.06.10 22:12:24 3: dAzimuth-------------->317.5
2013.06.10 22:11:24 3: compassPoint------------>north-northwest
2013.06.10 22:11:24 3: dElevation------------>-3.7
2013.06.10 22:11:24 3: dAzimuth-------------->317.3
2013.06.10 22:10:24 3: compassPoint------------>north-northwest
2013.06.10 22:10:24 3: dElevation------------>-3.6
2013.06.10 22:10:24 3: dAzimuth-------------->317.1
2013.06.10 22:09:24 3: compassPoint------------>north-northwest
2013.06.10 22:09:24 3: dElevation------------>-3.5
2013.06.10 22:09:24 3: dAzimuth-------------->316.9
2013.06.10 22:08:24 3: compassPoint------------>north-northwest
2013.06.10 22:08:24 3: dElevation------------>-3.4
2013.06.10 22:08:24 3: dAzimuth-------------->316.6
2013.06.10 22:07:24 3: compassPoint------------>north-northwest
2013.06.10 22:07:24 3: dElevation------------>-3.3
2013.06.10 22:07:24 3: dAzimuth-------------->316.4


Mit dieser Funktion sollte man eigentlich in der Lage sein deinen Anspruch, eine detaillierte Helligkeitssteuerung aufzubauen, realisieren können. Was hälst du davon?
Im Beispiel erfolgt die Aktualisierung der Readings jede Minute.  Wenn das Modul fertig ist, sollte es reichen alle 5 Minuten die Readings zu aktualisieren.

Ich bleibe dran.

[JustMe]

Hallo Dietmar63,

ich wünsche dir einen schönen Urlaub.

Nach wie vor funktioniert es ohne Probleme .



Grüsse
Chris

[TeeVau]

Bei mir ist der Fehler auch verschwunden!
Besten Dank!

[Rosco]

Hallo ins Forum,

seit dem 03.06.13, 12:03 werden auch keiner Daten mehr für das Twilight Modul verarbeitet.

Zunächst wurden diese Fehler im Log beschrieben:

2013.06.03 22:30:21 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: xxxxxx
Argument "" isn't numeric in addition (+) at ./FHEM/59_Weather.pm line 317.
Argument "" isn't numeric in addition (+) at ./FHEM/59_Weather.pm line 159.
2013.06.03 23:55:52 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: xxxxx

Am 07.06.2013 habe ich dann ein Update auf fhem 5.4 installiert. Doch leider wurde weiter ´No Weather location found at yahoo weather for location ID: xxxxxx´

Am 12.06.2013 habe ich nun erstmalig eine weitere Meldung im Log stehen:

2013.06.12 20:21:19 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: xxxxxx
2013.06.12 20:35:42 1: CustomGetFileFromURL http://weather.yahooapis.com/forecastrss?w=xxxxxx&u=c: Can't connect to http://weather.yahooapis.com:80

Use of uninitialized value $xml in pattern match (m//) at ./FHEM/59_Twilight.pm line 320.
2013.06.12 20:35:42 1: [TWILIGHT] No Weather location found at yahoo weather for location ID: xxxxxx

Leider kann ich die Dateiinhalte in den Zeilen nicht interpretieren, besser gesagt: ich traue mich da auch nicht in den Code zu sehen.

Ach ja, ich habe mal den Wert für <indoor_horizon> geändert. Ob´s damit zusammenhängt?!?

Ich freue mich auf eure Rückantworten.
Bis dahin, beste Grüße ins Forum
Rosco

[Dietmar63]

Wie hast du auf 5.4 umgestellt?
Auf Welcher Hardware ist fhem installiert?

Hast du die Version hier aus dem Thread eingespielt? Anhang!

Die neueste Version ist erst seit dem 10.7. Abends Zum update für alle eingestellt worden

[Rosco]

Hallo Dietmar,

vielen Dank für deine schnelle Rückantwort.
 
Fhem läuft bei mir auf einer Fb 7390. Ich hatte über die update Funktion aktualisiert. Ich ging davon aus, dass die bereinigte Version bereits eingecheckt wäre. Wenn diese jedoch erst nach dem 10.06. für alle verfügbar war, müsste ich dann wohl jetzt erneut ein Update durchführen?

Beste Grüße
Rosco

[Dietmar63]

Du meinst sicherlich die Update Funktion von fhem?
Dann ja! Probier es danach nochmals aus.
Ich drück dir die Daumen!

[Rosco]

Hallo Dietmar,

nach neuerlichen Update scheint nun wieder alles im Lot zu sein. Keine Fehler mehr im Log und die Aktoren werden auch wieder angesprochen.

Ein feines Modul, vielen Dank für deinen Support.

Beste Grüße
Rosco