Plugin: Weather4Lox Version 4 - neuer Fork

[Jan W.]

Hallo Zusammen,

eigentlich wollte ich nur ein paar Bugs im Plugin Weather4Lox beheben und kleine Anpassungen vornehmen. Mit Prof.Mobilux hatte ich dazu Ende Feb. gechattet und er hat mir eine neues Theme für Wetterdaten gezeigt, welches Str!ke1988 erstellt hatte. Str!ke1988 hatte die Idee, das Plugin zu erneuern. Nachdem ich etwas tiefer in das Thema und den Perl-Code eingestiegen bin, kamen noch einige Punkte hinzu und die KI hatte auch ein paar gute Vorschläge. Etliche Chats, Webmeetings und Anpassungen im Code später ist jetzt eine erneuerte Version fertig.

An dieser Stelle möchte ich Prof. Mobilux noch einmal für die Entwicklung und Support für über 10 Jahre danken! Nach über 1400 Beiträgen auf fast 100 Seiten zu dem Thema, habe ich ein neues Thema im Loxforum für diesen Fork erstellt. Mein Plan ist es, die Version 4 des Plugins weiterzuentwickeln und dabei den Wetter Service Emulator zu unterstützen, soweit der noch funktioniert.

Die wichtigsten Neuerungen:

• Alle Grabber liefern normalisierte Wetterdaten im JSON Format (current, daily und hourly)
• Der Grabber für WetterOnline, Weather Service Emulator und OSM Adresssuche sollten alle funktionieren
• Die Wettercodes in W4L (Symbole für die unterschiedliche Wettertypen) wurden deutlich erweitert
• Es gibt ein neues Set mit photorealistischen Wettersymbolen, mit Mondphasen und unterschiedlichen Symbolen für fast alle Wettercodes
• Es gibt eine Mapping-Datei mit der die Wettercodes den Symbolen zugeordnet werden
• Die Wettercodes in W4L werden auf einer Seite mit Erläuterung und Symbolen (Tag, Nacht) aufgelistet (Button im Plugin)
• Es gibt ein neues Theme (Deep Ocean), welches direkt die Wetterdaten im JSON Format liest
• Die Einstellungen des Plugins sind überarbeitet und etwas strukturierter

Die bisherigen Themes (Dark, Light, Custom) gibt es weiterhin, aber das neue Theme hat den großen Vorteil, dass aktuelle Wetterdaten von der eigenen Wetterstation oder einer in der Umgebung öfter abgefragt werden können und die angezeigten Werte automatisch aktualisiert werden. Mir gefällt das Theme besser, als die Anzeige im Wetter Service Emulator, insbesondere als Web-App auf iPad. Solange der Emulator noch läuft, werden wir den unterstützen, aber das eigentliche Ziel ist es, dass die Themes des Plugins mehr Wetterdaten anzeigen, schneller aktualisieren und besser aussehen. Wer Lust und Skills hat, kann gerne weitere Themes erstellen, die wir mit einbinden können. Hier ein paar Screenshots von einem iPad als Webapp:



Bisher haben Strike1988 und ich die Installation nur auf unseren Loxberrys getestet. Es kann noch der eine oder andere Fehler im Plugin enthalten sein. Daher empfehle ich die Installation zunächst nur denjenigen, die Probleme mit Ihrer vorhandenen Installation vom Weather4Lox Plugin haben oder für nicht-produktive Umgebungen.

Da es sich um einen Fork handelt, musst Du zur Installation die u.a. URL in der Plugin-Verwaltung einmalig eintragen:

• https://github.com/Jan21493/LoxBerry...V4.15.0.14.zip
• Release Notes findest Du hier: https://github.com/Jan21493/LoxBerry...r4Lox/releases

EDIT - eine neue Version 4.15.0.14 (Pre-Release) ist seit dem seit 03.06.2026 verfügbar!

Nach der ersten Installation funktioniert das automatische Update wie üblich. Die Konfiguration sollte eigentlich übernommen werden, aber sicher diese lieber vorher bzw. notiere Dir Deine API Keys.

Achtung: Eine Einstellung haben wir geändert, weil das '+' Zeichen bei MQTT nicht unterstützt wird und durch ein '_' ersetzt wird: calc_+X_... heißt jetzt nxhX, also statt z.B. calc_+12_prec bzw. calc__12_prec in MQTT für die erwartete Regenmenge innerhalb der nächsten 12h müsst Ihr jetzt nxh12_prec verwenden.

Falls Probleme auftreten, bitte ich Dich zuerst selbst die Ursache näher einzugrenzen: dafür kannst Du im Tab 'Logfiles' vom Plugin den Level auf 'Debug' stellen. Alle neuen Logs enthalten dann detaillierte Infos inkl. der URLs zum Abruf der Wetterdaten und den zugehörigen Antworten. Ich habe einen Schalter 'Mask keys in logs' in den 'Server Settings' ergänzt, mit dem die persönlichen API Keys maskiert werden können.

Falls Du das Problem nicht alleine lösen kannst oder etwas unklar ist, dann stellt gerne hier Fragen. Dabei möglichst konkret das Problem schildern und relevante Infos, wie verwendete(r) Wetterdienst(e), Konfiguration und evtl. Logs (mit maskierten Keys) gleich mitsenden. Alternativ kannst Du auch gerne ein Issue in Github erstellen oder direkt einen PR.

Wir haben bereits einige Ideen für die Zukunft:

• Theme für Pollenflugvorhersage (Settings und Abfragen gibt es bereits)
• Weitere Themes
• Vollständiges Set mit Wettersymbolen in modernem abstrakten Look, evtl. als SVG
• Weitere Wetterdienste einbinden, z.B. OpenMeteo, BrightSky / DWD
• Automatische Subscription bei MQTT

Wir freuen uns auf Feedback,
Strike1988 und Jan

[Prof.Mobilux]

Sehr cool - Danke euch für die Fortsetzung! Ich mache den alten Thread zu und aktualisiere noch das Wiki.

[BlackSoll]

Hi ! I installed it to my test rpi3 loxberry with fresh installation of Trixie. First time it messed up the dns and mqtt. Mosquito runs but
getaway not. I tried once more. Fresh install trixie, then loxbery. Everything ok until install the plugin. Again after install dnns changed to 127.0.0.1, no 8.8.8.8 and mqtt getaway stopped running. Can you take a look ?

[Jan W.]

Thank you for additional testing and narrowing the sources of the problem. You may report the issue to the loxberry core developers. I‘m really happy that they‘ve started to support Trixie recently.

[Juras]

i can confirm, that DNS after clean install of current versions loxberry and wather4lox is not working - even manual setup dont help. Its "hardcoded" to 127.0.0.1 - even dietpi-config is unable to change this.

[BlackSoll]

It has nothing to do with the plugin. Loxberry is the problem. See here https://www.loxforum.com/forum/proje...ietpi-loxberry

[lugg8]

Hallo zusammen, vielen vielen Dank für die super Erweiterung. ich wollte euch nur nochmal mitteilen, dass ich nach dem ersten Neustart nach der Installation den apache2 nicht mehr starten konnte.
Fehlermeldung war:
root@loxberry:/opt/loxberry# apache2ctl configtest AH00526: Syntax error on line 25 of /opt/loxberry/system/apache2/sites-enabled/001-weather4lox.conf: Invalid command 'Header', perhaps misspelled or defined by a module not included in the server configuration

The error Invalid command 'Header' means the Weather4Lox plugin is trying to use a feature that requires the Apache module headers, but that module is currently disabled.
To fix this, you need to enable the module and restart Apache. Run these commands:

1. Enable the headers module:
   bashsudo a2enmod headers

konnte ich das Problem dann lösen

[Jan W.]

Danke lugg8 für den genauen Hinweis auf das Problem. Ich hatte noch zwei Kleinigkeiten gefunden und alles in Version 4.15.0.10 behoben.

Falls noch jemand das Problem vor Update auf v4.15.0.10 hat, kann man alternativ zu dem Vorgehen im vorhergehenden Post nach Anmeldung via ssh mit user loxberry auch "su -", Root-Kennwort und dann "a2enmod headers" und "systemctl restart apache2" eingeben, falls der Befehl bashsudo nicht vorhanden ist.

[BlackSoll]

It's me again. All the above problems solved but weather don't update-change when i enter my latitude, longitude after Fetch data.

It stays at Schwarzenbek, Deutschland i use Visual Crossing .

[Jan W.]

weather don't update-change when i enter my latitude, longitude after Fetch data

If you‘ve entered lat/lon directly without using the osm address search, the city field is not updated and you need to enter a name manually. In the other case the city name should have been updated.

Did you save the settings? What name is displayed in your settings? Visualcrossing only uses lat/lon for fetching weather data, so the city name is just informational.

If it is still not working, please send me your logs.

EDIT: there is one browser based behavior that I can‘t change: If you use the osm address search it opens as a new tab. If you select a city the tab closes, but it moves to the next tab if it was not the last one. In this case you have to go back to the settings page manually and save the settings.

[BlackSoll]

Problem solved ! Uninstall the plugin and installed it again. Works lice a charm !

[challo]

Ist etwas OffTopic: Ich habe aktuell ein Nextion Display im Badezimmer um Uhrzeit, Wetter, Wettervorhersage und aktuelle Musik im Bad anzuzeigen. Die verschiedenen Bilder liegen auf dem Display und Daten werden über ein ESP8266 aktualisiert. Die Wetter seite mit dem neuen Theme gefällt mir schon sehr gut und könnte ich ja auch mit größerer Uhrzeit und Innentemperatur etc. anpassen. Hat jemand eine ähnliches Thema und ein Vorschlag für ein alternatives Display mit dem man die Webseite anzeigen kann? Eingabe wäre nicht notwendig, einfach nur anzeige.
So sieht es aktuell aus: Wetterbilder und Texte werden aktualisiert.

[Jan W.]

challo : mit der Umstellung auf JSON Format und Bereitstellung im "/plugins/weather4lox" Verzeichnis für den Client, wird die Erstellung eigener Themes stark vereinfacht und dynamischer, weil der Client (HTML5 und JS) regelmäßig Werte aus "current.json" nachladen kann, um z.B. die aktuelle Temperatur anzuzeigen.

Die Erstellung so eines Themes wäre für eine KI relativ leicht, wenn man das vorhandene Theme ocean.theme.html, ein Beispiel für current.json, dailyforecast.json und hourlyforecast.json neben ein paar Prompts mitgibt. Sprachspezifische Strings sind bereits in lang-de.json definiert, daher sollte man die Datei ebenfalls als Input zuliefern. Je nach KI muss man das Ergebnis mehr oder weniger genau beschreiben, evtl. kann die auch Dein Bild als Vorlage einlesen.

Ist das Bild im Hintergrund dynamisch, d.h. ändert es sich z.B. je nach Wettercode? Ein Parameter "image" habe ich bereits definiert (Idee kam von WetterOnline), aber bisher noch nicht nach lizenzfreien Wetterbildern gesucht. Mir gefällt auch die Integration mit dem MS (oder einem anderen Plugin), um Status- und Musikinfos anzuzeigen.

Für sehr einfache Clients, die nur ein Bild anzeigen können, könnte der Loxberry evtl. das Rendern von HTML5 mit JS übernehmen und als Bild ablegen.

[mno]

Leider gibt es ein Problem mit einem Wettercode.

Ich verwende Visual Crossing und habe heute über MQTT den Wettercode 17 erhalten. Diesen Code 17 gibt es aber laut der Auflistung im W4L Plugin "Webseite / WeatherService Emulator --> Wettercodes" nicht. Unter "Webseite / WeatherService Emulator --> Vorschau" wird aber "Regen, Teilweise bewölkt" angezeigt.
Im Loxwiki unter https://wiki.loxberry.de/plugins/weather4loxone/start ist der Wettercode 17 leider auch nicht dokumentiert.

Entweder stimmte der Wettercode 17 im MQTT oder die Dokumentation nicht.

[Jan W.]

mno : während der Überarbeitung fiel mir auf, dass es neben den Namen für Wettercodes wie 'partly_cloudy' noch eine weitere Nummer gibt, die nicht dem Loxone Wettercode entspricht. Ich habe den Code jetzt über ein Mapping wieder hergestellt, so dass die Variablen cur_we_code, dfc<X>_we_code und hfc<X>_we_code wieder die alten Werte aus der von Dir geposteten Tabelle liefern. Zusätzlich gibt es cur_we_code_lox, dfc<X>_we_code_lox und hfc<X>_we_code_lox, die den oben verlinkten Wettercode von Loxone liefern.

Da ich gestern noch ein paar andere Änderungen vorgenommen und die Änderungen noch nicht intensiv getestet habe, habe ich die neue Version v4.15.0.11 als Pre-Release gekennzeichnet. Bitte mal testen, ob der Fehler damit behoben ist.

[mno]

Der dfcX_we_code sollte jetzt passen, denn es wird jetzt der Code 11 angezeigt, aber der dfcX_we_code_lox ist immer noch falsch, denn es wird leider weiterhin der Code 17 angezeigt.

[Jan W.]

Hmm, einen Fehler in den Mappings kann ich nicht finden. Der Visual Crossing Weathercode "rain" sollte auf we_code 13 ("rain") und we_code_lox 11 ("rain") gemappt werden. "showers" auf we_code 11 ("showers") und we_code_lox 17 ("Heavy rain showers"). Loxone kennt bei "showers" nur "light" oder "heavy" und ich finde, dass heavy besser passt.

Wenn es bei Dir anders ist, dann schick mir bitte die Logs vom Grabber im Debug-Level, current.json, dailyforecast.json und hourlyforecast.json und vielleicht ein Screeshot vom MQTT Gateway mit dem we_code, wo es nicht passt.

[mno]

Wenn es den we_code_lox 17 gibt ist alles richtig. Ich dachte nur, dass beide den selben Code haben sollten. Ich verwende sowieso nur den we_code.
Ich möchte mich bei dir noch für das W4L Plugin und für deine Bemühungen bedanken. Schöne Grüße vom Bodensee.

[Stefan_L]

Jan W.
gibt es die möglichkeit das plugin auch direkt alternativ zum loxberry als schlanken docker container oder als lxc laufen zu lassen/zur verfügung zu stellen?
weather4lox ist das letzte plugin das ich noch auf loxberry habe - und der overhead für eine eigene vm dafür ist eigentlich nicht mehr sinnvoll.

auch updates, ssl-zertifikate mit traeffic, backups usw. würde ich mir mit docker deutlich leichter tun. ist dazu was geplant/möglich?

[Jan W.]

Hallo Stefan_L, nein das plane ich nicht. Mit Docker habe ich keine Erfahrung, aber der Source-Code liegt offen in GitHub, so dass es ein anderer User gerne machen kann.

[challo]

Hi Jan W. wäre es möglich bei den "Kalkulatorische Werte (calc)" die wärmste bzw. kälteste Stunde des Tages mit Temperatur und Stunde zu ermitteln?
Bei dem neuen solcast NG Pluging gibt es etwas ähnliches:

• Top-4-Peaks des Tages (höchste Erzeugungsstunden inkl. Uhrzeit)

  Heute Top-4-Peaks

  today_peak_1_kwh / today_peak_1_hour (1..4)

[Jan W.]

Hi challo, die kalkulatorischen Werte heissen jetzt nxh (für next X hours), siehe Post 1 und enthalten bereits Minimum und Maximum für die Temperatur. Insgesamt gibt es die folgenden Parameter:

Parameter	Einheit	Wert
nxh<X>_prec	mm	Summe der erwarteten Regenmenge für die nächsten <X> Stunden
nxh<X>_snow	cm	Summe der erwarteten Schneemenge für die nächsten <X> Stunden
nxh$<X>_sr	W/m²	Summe der erwarteten Sonneneinstrahlung für die nächsten <X> Stunden
nxh$<X>_ttmin	°C	Minimale Temperatür für die nächsten <X> Stunden
nxh$<X>_ttmax	°C	Maximale Temperatür für die nächsten <X> Stunden
nxh$<X>_ttmean	°C	Durchschnittliche Temperatür für die nächsten <X> Stunden
nxh$<X>_popmin	%	Minimale Regenwahrscheinlichkeit für die nächsten <X> Stunden
nxh$<X>_popmax	%	Maximale Regenwahrscheinlichkeit für die nächsten <X> Stunden

Dabei werden bei z.B. <X>=4 die Werte für die nächsten 4 Stunden (1, 2, 3 und 4) betrachtet, also entweder addiert, das Minimum, Maximum oder der Durchschnitt berechnet. Die Berechnung erfolgt rollierend, d.h. die Tage werden nicht betrachtet.

Sinnvolle Anwendungsfälle wären z.B.:

• Starte die Bewässerung, wenn die erwartete Regenmenge für die nächsten 8 Stunden unter 5mm liegt
• Bewässere mehr, wenn zusätzlich die maximale Temperatur oder Sonneneinstahlung größer als X ist
• Warne, wenn es in den nächsten X Stunden Frost gibt
• Schließe die Dachfenster, wenn die maximale Regenwahrscheinlichkeit für die nächsten 4 Stunden > 20% ist (und kein Regensensor vorhanden ist)
• Starte die automatische Beschattung, wenn die erwartete maximale Temperatur über X und Sonneneinstrahlung über Y liegt

Tageswerte gibt es bereits in den dailyforecast.json und dfc<X>_tt_l (temp low) für die niedrigste und dfc<X>_tt_h für die höchste Temperatur (<X> = 0 bedeutet heute). Die Wetterdienste liefer zu den täglichen Daten allerdings keine Zeitpunkte mit.

Verbundene Werte, d.h. z.B wärmste Stunde des Tages mit Temperatur und Stunde können zumindest über MQTT nicht als ein Wert übermittelt werden, sondern müssten als zwei einzelne Parameter übergeben. Bisher kann man im Plugin verschiedene Wetterdienste für tägliche und stündliche Vorhersagen wählen. In diesem Fall sind die Zeitpunkte der niedrigsten und höchsten Temperatur aus den stündlichen Vorhersagen nicht 100%ig deckungsgleich mit den täglichen, aber das lässt sich nicht ändern. Je nach Wetterdienst sind die stündlichen Vorhersagen nach z.B. 32 oder 48h ungenauer, d.h. werden nur im 3h oder 6h Intervall zur Verfügung gestellt, so dass die Genauigkeit nicht so gut ist.

Was würdest Du Dir denn wünschen? dfc<X>_tt_lh (temp low hour) und dfc<X>_tt_hh (temp high hour), die aus stündlichen Werte berechnet werden und zumindest bei einigen Wetterdiensten für ein paar Tage einigermaßen passen würden? Oder lieber neue Parameter ndh<X>_tt_l (next day from hourly data) für die Temperatur und ndh<X>_tt_lh für die zugehörige Stunde?

Ein konkreter Anwendungsfall wäre auch gut und vielleicht bekommen andere User dadurch ebenfalls Interesse an solchen Berechnungen. Der Aufwand wäre überschaubar, so dass ich dass dann gerne machen kann.

[challo]

Hi Jan, vielen Dank für die ausführliche Rückmeldung. Ich habe folgende Idee zur Optimierung der Warmwasserbereitung der Wärmepumpe. Ich starte diese in der Stunde mit dem höchsten PV (laut Vorhersage). Sollte der PV Ertrag in dieser Stunde unter dem Schwellwert X liegen, starte ich die Warmwasser aufbereitung in der Wärmsten Stunde des Tages (höchste Effizient der Wärmepumpe). Wie groß der energetische Nutzen ist weiß ich noch nicht genau oder ob der höchste PV Ertrag auch immer in die wärmste Stunde fällt. Aber es ist eine Überlegung. Daher wäre es interessant nicht nur die maximale Temperatur dfc<X>_tt_h zu erhalten, sondern auch in welcher Stunde (wie von dir Vorgeschlagen dfc<X>_tt_hh) diese sein wird. Also z.b. 13 oder 11 etc. für 13Uhr oder 11 Uhr.

[Jan W.]

Was ist Dein eigentliches Ziel: den PV-Überschuss möglichst effektiv zu nutzen und dafür die WW-Bereitung der WP auf Zeiten mit viel PV-Überschuss zu legen und/oder die WW-Temperatur zu erhöhen? Warum möchtest Du dafür in die Zukunft schauen? Wäre SR > X für die nächste Stunde ausreichend?

Die Temperatur ist dafür aus meiner Sicht weniger gut geeignet, als „sr“ (Solar Radiation), den einige Wetterdienste (als hfc und nxh) mitliefern. Logiken im MS, die etwas in der Zukunft auslösen, können ziemlich kompliziert werden. Mir ist noch nicht klar, wofür die Stunde benötigt wird und wie die Logik funktioniert.