Plugin: Weather4Lox (ehemals Wunderground4Loxone)

**Muck** · 06.02.2026, 18:02

Du hast Recht, der DNS war auf den Router und nicht mehr auf den Loxberry gesetzt - warum auch immer.
Jetzt keine Werbung mehr, aber dfür wieder schwarzer Bildschirm

Die Werte gehen irgendwann auf 0, das stimmt. Aber woran liegt das?

**Jan W.** · 07.02.2026, 08:12

Wenn der Picto-Code bei den interpolierten Werten, die mehr als 48h in der Zukunft liegen, immer 0 ist, dann hast Du ein Fehler beim Patchen gemacht. Ich gehe davon aus, dass Du OpenWeatherMap verwendest, weil der Patch sich darauf bezieht.

**Muck** · 12.02.2026, 06:14

Zitat von Jan W.

Wenn der Picto-Code bei den interpolierten Werten, die mehr als 48h in der Zukunft liegen, immer 0 ist, dann hast Du ein Fehler beim Patchen gemacht. Ich gehe davon aus, dass Du OpenWeatherMap verwendest, weil der Patch sich darauf bezieht.

Ja, ich verwende OpenWeatherMap. Irgendwas muss tatsächlich schief gelaufen sein, ich bekomme beim Test nur alte Daten "ab 05.02.2026".
Was kann da passiert sein??

**Jan W.** · 12.02.2026, 20:54

Hallo Muck,
möglicherweise hast Du beim Bearbeiten der Datei ein Fehler gemacht, so dass das Programm nicht mehr läuft. Es reicht, wenn 1 Zeichen im Code nicht korrekt ist. Hier sind die Änderungen von mir sichtbar. Rot ist der alte Code, grün der neue.

Die erste Änderung in Zeile 505-509 tritt möglicherweise nur in bestimmten Zeitzonen auf und Einstellungen vom MS als auch Loxberry können relevant sein. Evtl. hängt es auch davon ab, wann genau die Wetterdaten abgerufen werden. Die Änderung bewirkt, dass die erste Wertereihe der Vorhersage nicht mehr übersprungen wird.
Bei Deinen Wetterdaten sind die Uhrzeiten in der 3. Spalte fortlaufen, d.h. sie passen bei Dir. Bei mir war zwischen der ersten und zweiten Zeile mit den Wetterdaten ein Versatz von 2h und dann wurden die aktuellen Werte interpoliert. Die "aktuellen" Werte waren bei mir leider nicht aktuell, sondern bezogen sich auf die bereits abgelaufene Stunde. Eine Diskussion findest Du hier.

Die Zeilen 860ff sind entscheidend für die interpolierten Werte. Nach dem Hinweis von Prof.Mobilux in #1414, insbesondere den Kommentar 3 hatte ich keinen PR mehr gestellt. Die Anpassung vertauscht die vorvorletzte und vorletzte Spalte in den interpolierten Werten. Da OpenWeatherMap nur stündliche Vorhersagen für die nächsten 48h (2 Tage) liefert, der Emulator aber 3 Tage benötigt, werden die fehlenden Daten aus den 3-stündigen Vorhersagen interpoliert. Erst mit neueren Versionen der App auf dem Smartphone tritt das Problem auf, dass falsche Symbole nicht einfach ignoriert werden wie vorher, sondern die ganze Seite mit dem Emulator schwarz wird.

Wenn Du kein Syntaxfehler finden kannst, dann am besten das aktuelle Plugin von Prof. Mobilux nochmal drüber installieren und danach die Zeilen ändern. Python ist sehr empfindlich bei Einrückungen - die müssen zum restlichen Code genau passen.
Testen kannst Du es über den "Teste Emulator" Button im Loxberry Plugin, den Du wahrscheinlich für den Screenshot verwendet hast. Wenn die Seite nicht in der letzten Stunde neu aufgebaut wurde, dann läuft der Code nicht richtig. Neben den Werten in der vorletzten Spalte solltest Du auf die Uhrzeiten in der dritten Spalte achten. Die Uhrzeiten müssen fortlaufend sein und der Picto-Code zwischen 1 = wolkenlos bis 29 = kräftiger Schneeregenschauer liegen - siehe hier.

**Jan W.** · 14.02.2026, 16:44

Hallo Muck,
ja, es gab schon immer den Bug, dass das Icon für die interpolierten Werte fehlte, aber die alte App hat das ignoriert. Der Bug ist daher nicht aufgefallen. Für alle 3 vorhergesagten Tage sehe ich für alle Stunden das passende Symbol in der Loxone App.

Da ich nicht der Autor des Plugins bin, kenne ich nicht den besten Weg, um Dein Problem zu finden oder habe Erfahrung mit typischen Fehlern. Hier daher eine (etwas komplizierte) Anleitung, um den Weg von OpenWeatherMap zum Emulator nachzuvollziehen.

Im Plugin im Tab 'Logfiles' den Log-Level für das Plugin auf Debug stellen, 1h warten. Der Level gilt für alle neuen Meldungen, daher musst Du warten.
Das aktuelle Logfile für die Gruppe 'Grabber_openweather' öffnen. Das steht als erstes in der Gruppe und an der Uhrzeit kannst Du es einfach erkennen
Dort findest Du den Inhalt der in Schritt 8 erzeugten Datei (hier hourlyforecast.dat.tmp) mit dem Database Content, der Schritt 9 entspricht.
Im Log findest Du ziemlich am Anfang ein Eintrag nach 'INFO: Fetching additional 3-Hourly Forecat Data for Location lat=xxxx&lon=yyyy to interpolite hourly data' mit einer URL
Öffne die URL im Browser. Achtung: die URL enthält Deinen API Key, d.h. die solltest Du nicht teilen. Das sind die Rohdaten, die das Plugin verarbeitet.
Den Dump im JSON Format kopieren und in ein Online JSON Decoder wie z.B. https://onlinephp.io/json-decode geben, damit Du ihn einfach lesen kannst. Es sind nur Deine Wetterdaten, d.h. der Inhalt enthält keine sensitiven Daten
Gehe zum Ende und dann rückwärts zum letzten Eintrag mit Wetterdaten. Dort solltest Du eine 'id' und 'description' finden, z.B. 'id' => 803, 'description' => 'Überwiegend bewölkt',
Der Code in grabber_openweather.pl ab Zeile 800 wandelt die 'id' in 'code' (Picto-Code) und 'icon' und fügt diese Daten vor der 'description' in die Datei /opt/loxberry/log/plugins/weather4lox/hourlyforecast.dat ein
Prüfe, ob im Code alle Deine Wettercodes, die Du über den API Call erhalten hast, enthalten sind. Beispiel: die id' => 803 ist enthalten. Die von OpenWeatherMap verwendeten id's haben eine Nummer von 200 bis 804 (nicht fortlaufend) und können vom Grabber verarbeitet werden.
Lasse Dir die Datei hourlyforecast.dat z.B. mit 'cat' anzeigen
Prüfe für die letzten Einträge, ob diese passen: die Datei sieht wg. der Spaltentrennung '|' etwas unübersichtlich aus, aber anhand der Description und der beiden Spalten davon ist das nicht so schwierig, z.B. |4|cloudy|Überwiegend bewölkt
Prüfe, ob das Format dieser Spalten für alle Zeilen in der gleichen Form ist, d.h. zuerst der Code kommt, dann die englische Name und dann die Beschreibung. Mit Excel kann man die Spalten gut über Import sehen. Du kannst auch mit vs-code bzw. Notepad++ und dem regulären Suchausdruck ([^|]+\|){27} über Suchen und Ersetzen durch 'nichts' ersetzen. Dann sollte der linke Teil jeder Zeile bis zum Code gelöscht sein.
Prüfe die Werte der Codes. Im Code von datatoloxone.pl steht in Zeile 1797, dass die Loxone Wettercodes zwischen 1 und 35 liegen müssen, lt. Loxone zwischen 1 und 29. Ich weiß nicht, was richtig ist. Eine 0 ist nicht zulässig.
Das Skript 'datatoloxone.pl' nimmt diese Daten und erzeugt 1x pro Stunde die Datei 'index.txt' für den Wetter Emulator. In dieser Datei ist von den o.a. 3 Werten nur noch der sogenannte Picto-Code als Zahl in der vorletzten Spalte enthalten. Die Datei kann man sich über den "Test" Button im Plugin anzeigen lassen. Dort sollte kein Fehler vorliegen, wenn das Problem nur mit den interpolierten Werten auftritt.

Ich hoffe, Du kannst mit der Anleitung zur Selbsthilfe etwas anfangen. Für mich sieht es so aus, als ob Du die 3-stündigen Vorhersagen abrufen kannst, aber für diese Daten der Wettercode nicht richtig verarbeitet wird. In der Datei "hourlyforecast.dat" werden die stündlichen Vorhersagen für die nächsten 48h mit interpolierten Werten ergänzt. Das das Parsen von JSON ziemlich robust ist und bei mir funktioniert, kann ich mir Deinen Fehler noch nicht erklären.

**Stefan_L** · 24.02.2026, 17:40

gibt es irgendwo eine übersicht, welche wetterservices und features momentan funktionieren?
sich durch 96 seiten forum zu wühlen ist sehr unübersichtlich - ich hab ein paar seiten durchgeklickt - aber jetzt aufgegeben. OpenWeatherMap mit api key hat nicht geklappt.

**<Andreas>** · 10.03.2026, 06:30

Ich bin jetzt schon einige Zeit auf Open-Meteo umgestiegen
- besonders das icon-d2 Modell des DWD liefert bei mir sehr gute Ergebnisse und eine direkte Abfrage beim DWD ist sehr umständlich
- Kein API Key
- einfache json API

Wohmöglich auch für Weather4lox eine Überlegung wert

**rett_de** · In den letzten 3 Wochen

ich hab einiges gefixed und einen Pull-Req. gestellt:
Summary

This PR fixes multiple bugs in the weather4lox-version4 branch, including three open GitHub issues (#122, #119, #40) and several additional problems found during testing. All changes have been tested on a live LoxBerry system with OpenWeatherMap and Cloud Weather Emulator enabled.

Bug Fix: Ramdisk fills up (#122)

Problem: Every Perl script creates its LoxBerry::Log instance with the logdir parameter. This causes LoxBerry::Log to create a new timestamped log file on every invocation (e.g. grabber_openweather-2026-03-19_12-00-00.log). Since the cronjob runs every few minutes, hundreds of log files accumulate in the ramdisk (/dev/shm), eventually filling it up completely and causing the system to malfunction.

Fix: Changed all 12 Perl scripts from logdir => "$lbplogdir" to filename => "$lbplogdir/weather4lox.log" with append => 1. This writes all log output to a single shared log file that is appended to, preventing unbounded file creation.

Affected files (12):
cronjob.pl, fetch.pl, datatoloxone.pl, grabber_openweather.pl, grabber_visualcrossing.pl, grabber_weatherflow.pl, grabber_wttrin.pl, grabber_wetteronline.pl, grabber_loxone.pl, grabber_foshk.pl, grabber_wu.pl, grabber_pwscatchupload.pl

Bug Fix: Icon/Code swap in hourly forecast (#119)

Problem: In grabber_openweather.pl, the regular hourly forecast data writes fields in the order code|icon|description, but the interpolated hourly data (used to fill gaps between API data points) writes them as icon|code|description. This causes Loxone to display wrong weather icons for interpolated hours.

Fix: Swapped the order in the interpolated section (around line 860) from:
$newline .= $icon; $newline .= "|"; $newline .= $code;

to:
$newline .= $code; $newline .= "|"; $newline .= $icon;

Affected file: bin/grabber_openweather.pl

Bug Fix: Deprecated readlanguage call (#40)

Problem: index.cgi and geolocation.cgi use LoxBerry::Web::readlanguage() which is deprecated and triggers warnings in newer LoxBerry versions.

Fix: Replaced with LoxBerry::System::readlanguage() in both files.

Affected files: webfrontend/htmlauth/index.cgi, webfrontend/htmlauth/geolocation.cgi

Fix: Cloud Weather Emulator returns "Data currently not available"

Problem: The emulator CGI at webfrontend/html/emu/forecast/index.cgi checks for index.txt using a relative path (-e "index.txt"). This depends on Apache's current working directory being the same as the script directory, which is not guaranteed. When Apache sets a different working directory, the file is not found and the Miniserver receives "Data currently not available" instead of weather data.

Fix (two-part):

index.cgi: Changed to use the absolute path REPLACELBPLOGDIR/index.txt (the placeholder is resolved during plugin installation). The CGI now reads index.txt directly from the ramdisk where datatoloxone.pl writes it, eliminating the dependency on Apache's working directory.
datatoloxone.pl: Additionally copies index.txt to the emulator forecast directory ($lbphtmldir/emu/forecast/) after creation as a fallback.

Affected files: webfrontend/html/emu/forecast/index.cgi, bin/datatoloxone.pl

Fix: show.cgi crashes on fresh install or empty ramdisk

Problem: show.cgi uses die() when it cannot open .dat files (current.dat, dailyforecast.dat, hourlyforecast.dat). On a fresh install or after a reboot before the first weather fetch, these files may not exist, causing the CGI to crash with an Internal Server Error instead of showing a helpful message.

Fix: Replaced all four die() calls with graceful error handling that prints a user-friendly HTML message ("No weather data available yet. Please fetch weather data first.") and exits cleanly.

Affected file: webfrontend/htmlauth/show.cgi

Fix: Generated HTML files and index.txt not web-accessible

Problem: datatoloxone.pl generates webpage HTML files (webpage.html, webpage.dfc.html, webpage.hfc.html, webpage.map.html, weatherdata.html) in the ramdisk log directory ($lbplogdir), but the web server serves files from $lbphtmldir. Without copying them, the weather pages are not accessible via the browser at /plugins/weather4lox/.

Fix:

datatoloxone.pl: After creating the HTML files, copies them to $lbphtmldir (the web-accessible plugin directory). Added use File::Copy for this purpose.
daemon: At boot, after restoring .dat and HTML files from persistent storage to ramdisk, copies them to the web-accessible directory ($LBHOMEDIR/webfrontend/html/plugins/$pluginname/). Also copies index.txt to the emulator forecast directory.

Affected files: bin/datatoloxone.pl, daemon/daemon

Fix: MQTT password logged in cleartext

Problem: datatoloxone.pl logs the MQTT password in a debug message: LOGDEB "MQTT Login with Username and Password: Sending $mqtt_username $mqtt_password". This exposes credentials in log files.

Fix: Replaced $mqtt_password with ******** in the log message.

Affected file: bin/datatoloxone.pl

Minor Fixes

bin/grabber_openweather.pl	Wrong variable $lbpconfigdir in error message → corrected to $lbplogdir
bin/grabber_openweather.pl	Double semicolon ;; → ;
bin/datatoloxone.pl	Double semicolon ;; → ;
webfrontend/htmlauth/index.cgi	Duplicate $cfg->param("SERVER.WUGRABBER", ...) line removed

**edipseamm** · In den letzten 3 Wochen

rett_de

Amazing. Especially the MQTT password logged in cleartext this should be basic security in any app. Hopefully gets merged soon

**SergeantX** · In den letzten 3 Wochen

Großartiges Plugin - ich liebe es! Sehr nett, dass es so liebevoll gepflegt wird.

Nicht wichtig, aber die "OSM Search" scheint einen Hacer zu haben. Ein- und dieselbe Abfrage funktioniert auf nominatim.openstreetmap.org, wirft im Plugin aber einen Fehler:

Software error:

malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "Access denied. See h...") at /opt/loxberry/webfrontend/htmlauth/plugins/weather4lox/geolocation.cgi line 121.

Depending of what you have done, report this error to the plugin developer or the LoxBerry-Core team.
Further information you may find in the error logs.

Wie gesagt, nicht wichtig, ich melde es nur.

LG

**schildkroete** · In den letzten 2 Wochen

Ich würde gerne den Loxone Wetterservice durch das Plugin ablösen. Bevor ich anfange und unnötig viel Zeit investiere - gibts ein Template, welches die Werte enthält, die sonst vom Wetterservice kommen? :-)

**Lightpicture** · In den letzten 2 Wochen

Hallo schildkroete

Verwendest du Config Version größer 15, wird nichts mehr vom Plugin in der App angezeigt.
Bitte das Bedenken.

Wetter Anzeige in der App funktioniert ab V16 nicht mehr.

**schildkroete** · In den letzten 2 Wochen

Danke für den Hinweis. Ich bin auf der aktuellen Config 17. Mir gehts allerdings auch nicht um die Anzeige in der App, die habe ich eh nie genutzt. Mir gehts um die Daten zum Steuern der Logik im Hintergrund (z.B. Außentemperatur für Frostschutz, Sonnenauf/untergang für Automatikbeschattung usw). Das sollte doch gehen, oder ist das auch Wetterservice-Only?

**Lightpicture** · In den letzten 2 Wochen

Das funktioniert und du kannst die Werte vom Plugin abrufen, per UDP oder MQTT.
Bei MQTT bin ich mir nicht 100% sicher, verwende ich nicht.

**schildkroete** · In den letzten 2 Wochen

Ich bekomme die calc-Werte irgendwie nicht per MQTT (über Loxberry und HTTP Input) in den Miniserver. Liegt das an dem doppelten Unterstrich? Hat jemand eine Idee?
Die Werte sind in Loxone immer 0, obwohl im MQTT konkrete Werte drin stehen.