Plugin: Weather4Lox (ehemals Wunderground4Loxone)

[Gast]

Hallo zusammen,
ich habe ein Problem mit dem Weather4Lox-Plug-in und der DNS Auflösung. Nach einiger Zeit in Betrieb (noch unklar, wann, ein paar Tage, ich nehme an, bis Neustart von Loxberry oder evtl. FritzBox) funktioniert das Abrufen von Wetterdaten nicht mehr. Die Logfiles zeigen dann immer
RL: https://api.openweathermap.org/data/...=7237e3***&lat =*****&lon=11.6***&lang=de&units=metric
Status: 500 Can't connect to api.openweathermap.org:443 (Temporary failure in name resolution)
CRITICAL: Failed to fetch data for lat=48.072793&lon=11.673365. Status Code: 500

Auch ein wget api.openweathermap.org über SSH zeig dann einen DNS-Resolve-Fehler.
Sobald ich aber im Webbrowser am PC (also nicht über den Loxberry) api.openweathermap.org einmal eingebe (im Browser am PC kein Problem) geht es danach auch im Weather4Lox-Plugin wieder und läuft dann eine Zeit.

DNS-Einstellungen sind eigentlich richtig - ich habe DHCP und manuell probiert, macht keinen Unterschied. Andere Aufrufe von Loxberry funktionieren auch problemlos.

Hat jemand eine Idee, was hier falsch läuft?

Danke!

[svethi]

Naja, Deine DNS Einstellungen sind „eigentlich“ richtig? Irgendwie können die ja nicht richtig sein, sonst würde es ja auch eigentlich richtig funktionieren.

Naja, ein wget www.fbi.gov (eine Seite, die ich weder im Browser noch sonst wo verwendet habe) löst auf, auf api.openweathermap.org nicht. Übrigens sogar ohne Neustart nach ein paar Stunden nicht mehr...

[Prof.Mobilux]

Keine Ahnung was da bei Dir los ist. Du könntest probieren die IP-Einstellungen manuell zu setzen und als DNS-Server den von Google und nicht den von Deinem provider/Fritzbox zu verwenden. https://developers.google.com/speed/...dns/docs/using

Danke! Manuell hatte ich, aber anderer DNS ist eine gute Idee. Nach Neustart mit Google-DNS hat zumindest mal wget und Aktualisierung der Wetterdaten geklappt, ohne vorher im Browser aufgerufen zu werden. Das war bisher nicht der Fall. Ich beobachte weiter.

Bisher läuft es damit stabil - ist schon komisch, dass manche DNS-Anfragen vom Loxberry über den Router problemlos gingen, diese hier nicht.

[74homer]

Im Log sehe ich diese Fehlermeldung:
Weather4Lox GRABBER_WEATHERBIT
CRITICAL: Failed to fetch data for lat=49.225993&lon=8.526703. Status Code: 500
und
Weather4Lox GRABBER_OPENWEATHER
CRITICAL: Failed to fetch data for lat=49.225993&lon=8.526703. Status Code: 500

Weather4Lox GRABBER_WUNDERGROUND
CRITICAL: Failed to fetch data. Status Code: 500

Ich habe das Abfrage-Intervall auf 30 Minuten eingestellt.

Die Fehler treten bei 90% der Abfragen auf.
Das heißt, es gibt kein grundsätzliches Problem hinsichtlich der Einstellungen, weil sonst wären 100% der Abfragen fehlerhaft.

Was ist die Ursache für den Fehler Status Code: 500?

THX

[Christian Fenzl]

500 ist Server Fehler der entsprechenden Dienste. Sind deine API keys richtig?

[74homer]

Weil 10% der Anfrage lt. vorhandener Logs funktionieren gehe ich davon aus, dass API keys etc. korrekt sind.
Dies begründet auch meine Schlussfolgerung, dass die generellen Einstellungen korrekt sind, weil sonst alle Anfragen fehlerhaft sein müssten.

[Prof.Mobilux]

Scheint so als ob OpenWeatherMap damit öfters Probleme hat. Bitte stell mal das Logging auf Debug und hole manuell Wetterdaten ab. Dann bitte mit das gesamte (ungeschwärzte) Logfile per PM schicken.

[74homer]

Scheint so als ob OpenWeatherMap damit öfters Probleme hat. Bitte stell mal das Logging auf Debug und hole manuell Wetterdaten ab. Dann bitte mit das gesamte (ungeschwärzte) Logfile per PM schicken.

Meinst du das Logfile eines der konfigurierten Wetter-Services (Weatherbit oder OpenWeatherMap)?

In den Logfiles der fehlgeschlagenen Services steht praktisch der gleiche Fehler:
Status: 500 Can't connect to api.openweathermap.org:443 (Temporary failure in name resolution)
Status: 500 Can't connect to api.weatherbit.io:80 (Temporary failure in name resolution)
Status: 500 Can't connect to api.openweathermap.org:443 (Temporary failure in name resolution)

Diese Fehlermeldung ist eindeutig und wird auch auf der Konsole bestätigt (mit SERVFAIL):
root@pc5-loxberry:~# nslookup www.wunderground.com
Server: 127.0.0.1
Address: 127.0.0.1#53

** server can't find www.wunderground.com: SERVFAIL

root@pc5-loxberry:~# nslookup wunderground.com
Server: 127.0.0.1
Address: 127.0.0.1#53

Non-authoritative answer:
Name: wunderground.com
Address: 95.100.197.237

root@pc5-loxberry:~# nslookup api.weatherbit.io
Server: 127.0.0.1
Address: 127.0.0.1#53

** server can't find api.weatherbit.io: SERVFAIL

root@pc5-loxberry:~# nslookup weatherbit.io
Server: 127.0.0.1
Address: 127.0.0.1#53

Non-authoritative answer:
Name: weatherbit.io
Address: 45.33.67.222

root@pc5-loxberry:~# nslookup api.openweathermap.org
Server: 127.0.0.1
Address: 127.0.0.1#53

** server can't find api.openweathermap.org: SERVFAIL

root@pc5-loxberry:~# nslookup openweathermap.org
Server: 127.0.0.1
Address: 127.0.0.1#53

Non-authoritative answer:
Name: openweathermap.org
Address: 138.201.197.100

Somit ist die Ursache beim DNS zu suchen.

Und ich denke es liegt an der Verwendung der Sudomain
www.wunderground.com
api.weatherbit.io
api.openweathermap.org
weil diese vom Anbieter nicht als Canonical registriert ist.

Wenn man beispielsweise die Namensauflösung von www.zdf.de prüft, dann kommt das zurück:
root@pc5-loxberry:~# nslookup www.zdf.de
Server: 127.0.0.1
Address: 127.0.0.1#53

Non-authoritative answer:
www.zdf.de canonical name = ssl.zdf.de.edgekey.net.
ssl.zdf.de.edgekey.net canonical name = e8383.e6.akamaiedge.net.
Name: e8383.e6.akamaiedge.net
Address: 23.62.103.118


Das Problem ist nicht nur auf die Subdomains beschränkt, die von Weather4Lox verwendet werden.
Auch der Check nach Updates läuft in denselben Fehler:
Error: Abrufen der Release-Liste ist fehlgeschlagen: 500 Can't connect to api.github.com:443 (No address associated with hostname)

[Prof.Mobilux]

Ich meinte das Original Logfile, so wie ich geschrieben habe.... egal, brauche ich nicht mehr. Du hast ein Problem mit deinem Nameserver. Das ist weder ein Problem vom Loxberry, vom Plugin noch vom Server des Wetterdienstes.

Wieso nutzt dein LoxBerry überhaupt localhost als Nameserver?!

[74homer]

Wenn ich die Doku richtig verstanden habe, dann muss für die Verwendung der Wetterdaten im Loxone Miniserver die Funktion Weather Service Emulator aktiviert werden.
Dann wird auf dem Loxberry ein DNS betrieben, der alle Anfragen des Miniservers zu weather.loxone.com umleitet auf sich selbst (die IP von Loxberry).

Wenn ich ein Problem mit meinem DNS habe, warum werden dann die primären DNS-Suffix korrekt aufgelöst?


Update:
Ursache für das DNS Problem war eine falsche Subnetzmaske in der Konfiguration des Routers, der im Client-Mode läuft..

[svethi]

Siehst Du! Und da hast Du die ganze Zeit die Schuld bei anderen gesucht und wolltest auch nicht auf das hören was die anderen sagen.
Und dennoch ist es völlig sinnlos, wenn der Loxberry sich selbst als DNS befragt.
Ebenso hast Du das Thema DNS vor allem auch in Verbindung mit dem MS nicht richtig verstanden. Aber auch egal. Wenn es jetzt läuft ist alles gut.

[Gast]

Aus der Beschreibung des Weather4Loxone Plugins:

. Damit ist eine volle Integration des Wetters in die Loxone App möglich, z. B. die Anzeige im Raummodus. Allerdings müssen dazu die Netzwerkeinstellungen am Miniserver verändert werden.

Der Miniserver fragt das Wetter immer fest über die URL weather.loxone.com ab und authentifiziert sich dabei über seine Seriennummer. Die Emulation funktioniert wie folgt: Der LoxBerry wird mit der Software DNSMasq quasi als Nameserver konfiguriert. Er leitet alle DNS-Anfragen jedoch einfach weiter an den Nameserver Deines Providers - außer Anfragen an die Adresse weather.loxone.com. Diese leitet er auf seinen eigenen Webserver um und kann so die entsprechenden Wetterdaten an den Miniserver senden. In der Netzwerkkonfiguration des Miniservers muss daher als Nameserver zwingend die IP-Adresse des LoxBerry angegeben werden, damit der Miniserver alle DNS-Anfragen an den LoxBerry stellt.

[74homer]

Ich bin bisher davon ausgegangen, dass dieses Forum für die Klärung von Support-Anfragen ist und nicht von Fragen der Schuld (oder Unschuld).
Hierfür sind i.A. die Gerichte verantwortlich und man berät sich mit einem Anwalt; manche besonders eifrigen Bürger verlagern die Schuldfrage aber gerne in Telegram-Chats oder auf Facebook.
Finger-pointing und unsachliche Beiträge dürfen dort gerne gemacht werden, aber bitte nicht hier im Forum.

[svethi]

Siehst Du, da bist Du schon wieder falsch. Dies hier ist KEIN Support Forum.

[74homer]

Stimmt.
In den Forumsregeln steht: Kein Support Forum.

[wrack solutionist]

Hi,

seit kurzem bekomme ich von Openweather nur noch die Cur_Daten, die anderen z.B. dfc0_tt_h usw. fehlen. Hat jemand das selbe Problem?

VG
Michael

[wrack solutionist]

Problem gelöst, anscheinend wurde durch das letzte Loxberry Update die Einstellungen in den Tagesvorhersagen gelöscht.

[Prof.Mobilux]

Das kann nicht sein. LBUpdate macht nichts an den Plugin Einstellungen. Die Einstellungen müssen irgendwie anders geändert worden sein.

[Gast]

Ich habe es bei mir gerade geprüft. Bei mir kommen die Daten Cur und dfc0_tt_h.

Was ich nicht ganz verstehe, sind die angezeigten Tage auf der vom Plugin generierten Webseite.
- Tages-Vorhersage senden: 7 Tage (sollte mit free Openweather möglich sein, die Daten sind auf jeden Fall als dfc0 ... dfc7 vorhanden)
Auf der Webseite ist es der aktuelle Tag und weitere 3 Tage, also total 4 Tage. Der integrierte Service in der App zeigt natürlich nur 3 Tage.

Wie bekommt man alle 7 Tage angezeigt?

[Prof.Mobilux]

Dazu musst du die HTML Vorlagen erweitern. Die Webseite zeigt fest 4 Tage an. Steht glaube ich im Wiki wie das geht.

Vielen Dank, da werfe ich einen Blick drauf

[Gast]

Hallo,

ich habe das W4L Plugin installiert und soweit läuft es ganz Prima. Die Einbindung in den MS hat auch funktioniert und dazu habe ich den DNS im MS auf die Loxberry IP umgeschrieben. Jetzt zum Problem: Stelle ich im MS den DNS um, bekomme ich zwar das Wetter angezeigt, nur kann ich dann nicht mehr extern - von außerhalb meines lokalen Netzwerkes - auf den MS zugreifen?! Stelle ich den DNS im MS wieder auf z.B. 8.8.8.8 zurück funktioniert der externe Zugang aber der Zugriff auf das Wetter geht nicht mehr. Gibt es für dieses Problem eine Lösung?

VG
Thomas

Das Problem hat sich gerade von selbst erledigt, lag wohl an einem Problem mit der FritzBox. Jetzt funktioniert die DNS-Weiterleitung über den LoxBerry und die Wetterdaten werden auch angezeigt.

[Muck]

Hallo!

Ich habe gestern das Plugin installiert, alles meines Erachtens richtig konfiguriert, aber habe in der App immer noch keine Wetter sondern nur die Werbung.
Den DNS-Server hab ich auf die IP des Loxberry geändert! Die Adresse des alternativen DNS-Servers ist doch egal, oder?

Wetterserver verwenden ist aktiviert, und auch "Emulator aktivieren" im Plugin ist aktiviert. Trotzdem wird nichts angezeigt.

Was mache ich falsch?
Müssen in der Fritzbox noch irgendwelche Ports freigegeben werden? Da ist bis jetzt nur der Port für den MS eingerichtet.

Danke schon mal für eure Hilfe!

[Christian Fenzl]

Wenn der MS einmal den ersten DNS nicht erreicht, verwendet er nur noch den zweiten DNS.
Wenn im Plugin alles passt (Wetter wird angezeigt usw.), dann einfach den MS nochmal neu starten und eine Stunde warten.

[Muck]

Wenn ich im Plugin den Emulator starte, zeigt er mir die (Test-)Daten aus Dresden von 2018 an? Da kann doch was nicht stimmen!?