Plugin: Weather4Lox Version 4 - neuer Fork

[svethi]

Jan W. Hi Jan, ich habe mir einen neuen Loxberry aufgesetzt mit DietPi. Nach der ersten Installation des Plugin hatte ich genau das gleiche Problem wie bereits mindestens ein Vorredner. Das Plugin hat keinerlei Fehler oder dergleichen angezeigt und auch gesagt, dass es Daten geholt hat. Allerdings sind in allen Dateien weiterhin alte Daten verblieben. Genau wie der Vorredner habe ich das Plugin dann einmal de- und wieder installiert. Danach lief es gleich von Anfang an.
Kannst ja vielleicht bei Gelegenheit die Installationsroutinen prüfen.
Gefühlt wurden beim 2. Versuch weitere Dinge nachinstalliert. Kann es vielleicht sein, dass hier eventuelle Abhängigkeiten erst nach der ersten Installation erkannt werden?

Gruß Sven

DietPi Trixie auf einer VM X64

[Jan W.]

Hi Sven,

hast Du vielleicht noch das Install-Log des Plugins? Gab es nach der ersten Installation CRITICAL Meldungen in einem der Logs, die zum Plugin gehören?

Eigentlich laufen bei jedem Install die gleichen Schritte ab, aber vielleicht gibt es ein Problem bei der ersten Installation, welches beim 2. Mal nicht mehr auftritt.

In dpkg/apt werden über apt install folgende Module installiert:
libjson-perl
libdatetime-format-iso8601-perl


in POSTROOT.sh:
cpanm Math::Function::Interpolator
cpanm Astro::MoonPhase
dpkg-reconfigure -f noninteractive tzdata
a2enmod headers

Es ist immer schwierig, ohne nähere Informationen und Logs ein Fehler einzugrenzen, aber ich werde in den nächsten Tagen mein Loxberry mal neu aufsetzen und sehen, ob ich Deinen Fehler reproduzieren kann.

[svethi]

Hi Jan,

leider wurde das alte Log überschrieben. Was mir aber bei der 2. Installation aufgefallen ist, ist, dass er sehr lang an den Perl Modulen installiert hat. Beim apt ist es ja so, dass ein bereits installiertes Paket nicht noch einmal installiert wird. Wenn das bei cpanm eigentlich auch so ist, dann fehlten die Module.

[Jan W.]

Das ist bei cpanm auch so. Die erste Installation dauert länger, weil abhängige Module installiert und teilweise kompiliert werden. Bei Fehlern bricht die Installation ab. Ursache steht eigentlich in den Logs.

[svethi]

Ich habe mir das Log nicht im Detail angeschaut, aber bin mir sehr sicher, dass am Ende alles als erfolgreich angegeben war.
Was aber dann auch doof ist. Sollten jetzt tatsächlich Sachen fehlen, müsste dann nicht auch im Log ein Fehler auftauchen, dass er irgendwas nicht laden konnte?
Macht die Fehlersuche natürlich schwierig.

[Jan W.]

Für alle Anwender des Plugins: ich habe gerade eine neue Pre-Release Version v4.15.0.15 veröffentlicht. Um Allen eine bessere Übersicht zum aktuellen Fehlerstatus zu geben, hier die wichtigsten Fixes und Änderungen der letzten beiden Versionen:

1. DNS Probleme nach Installation des Plugins
   Die Installation des Standard-Paketes dnsmasq, welches bisher immer während der Installation des Plugins ausgeführt wurde, hat ein massives Problem mit der DNS Namensauflösung bei Trixie verursacht.
   Die Installation von dnsmasq habe ich daher aus dem Plugin-Installer entfernt und in den cloudemu-Prozess verschoben. dnsmasq wird nur noch installiert, wenn der Emulator tatsächlich verwendet wird. Das cloudemu-Skript wurde zusätzlich für die Kompatibilität mit Trixie aktualisiert. DNS Probleme nach der Installation des Plugins sind hoffentlich behoben, aber im Detail muss die Verwendung von dnsmasq in Verbindung mit dem Emulator noch in unterschiedlichen Varianten getestet werden.
2. Probleme bei Installation von Perl Modulen
   Der User cris.s hatte ein Problem mit der Installation des Math::Function::Interpolator Moduls, aber dies in einem anderen Beitrag geschrieben. Bei ihm schlug die Installation eines abhängiges Modul (Number::Closest::XS) fehl und erst nach einer manuellen Installation konnte das Problem beseitigt werden.
   Die eigentliche Ursache ist für mich noch etwas diffus, aber in der aktuellen Version habe ich die Installationsroutine in postroot.sh überarbeitet, so dass Fehlermeldungen von abhängigen Modulen in den Status der Installation des Plugins übernommen werden. Alle Grabber enthalten jetzt einen Test, ob die installierten Perl-Module, die vom Grabber benötigt werden, vorhanden sind. Im Log wird jetzt ein CRITICAL Error angezeigt und der Grabber ordentlich beendet. Vorher gab es ein Absturz des Grabbers und dann sah man gar kein Log vom Grabber für die betreffende Uhrzeit. Neben dem Interpolator, der von einigen Grabbern benötigt wird, wird das Astro Modul zur Berechnung von Mondphasen in fast allen Grabbern benötigt. Die wenigsten User werden sich die die 650KB des Installationsskriptes durchgelesen haben. Jetzt erscheint eine Fehlermeldung im Installation Log des Plugins und das Log ist mit ERROR statt OK gekennzeichnet. Die tieferen Gründe des Problems müssen noch analysisiert werden.
3. Änderung an API für wttr.in
   Der Wetterdienst wttr.in hat den Parameter 'localObsDateTime' aus der Anwort im JSON Format in seiner API entfernt. Durch diese nicht dokumentierte Anpassung (ich konnte zumindest nichts finden) wurde ein Zeitstempel ungültig und das Modul datatoloxone.pl ist dadurch abgestürzt und hat keine Wetterdaten mehr per MQTT oder UDP an den MS gesendet. Die Webseite mit Wetterdaten (weatherdata.html) für die Abfrage per HTTP vom MS wurde ebenfalls nicht mehr erstellt.
   Für dieses Problem habe ich im Grabber für wttr.in ein Workaround erstellt, der die Uhrzeit aus anderen Parametern ermittelt und eine Info in das Log schreibt. Außerdem habe ich das Modul datatoloxone.pl robuster gestaltet, so dass der Fehler abgefangen wird und nicht zum Beenden des Moduls führt.
4. Verbesserung: rainToday aka cur_prec_today wird im Grabber für Visual Crossing berechnet
   Bisher enthielt der Grabber für Visual Crossing keinen Wert für rainToday / cur_prec_today bzw. null / -9999, da dieser nicht direkt geliefert wurde. Visual Crossing stellt jedoch stündliche Niederschlagsmengen aus Beobachtungen für den heutigen Tag bereit. Die Niederschlagsmengen aller vergangenen Stunden werden nun aufsummiert und auf diese Weise die bisher angefallene Niederschlagsmenge für heute berechnet. Der Feature-Request kam von Str!ke1988.
5. Verbesserung: Geo-Koordinaten aus MS auslesen
   Der Vorschlag kam von Prof.Mobilux. Mit Loxberry v4 können die Geo-Koordinaten und der Standort (Location) aus dem Miniserver ausgelesen werden. Wer bereits mit Loxberry v4 testet, findet in den Einstellungen zum Plugin neben dem Button 'OSM Addresssuche' jetzt den Button 'Adresse aus MS'. Hinweis: für produktive Systeme ist v4 derzeit noch nicht empfohlen.

Warnungen, die durch ein älteres OS Release wie Bookworm, Bullseye, Buster oder noch älter bei der Installation angezeigt werden, weil die APT database nicht aktualisiert werden konnte oder es Probleme mit abgelaufenen Schlüsseln gibt, werden weiterhin bei der Installation des Plugins angezeigt. Dies ist das Standardverhalten beim Loxberry. Lösungsmöglichkeiten hatte ich in Post #26 dargestellt.

Wer Probleme mit dem Plugin hat, möchte bitte zuerst in das Installation Log des Plugins nach möglichen Fehlern schauen (erreichbar z.B. über das Menü 'Plugin-Verwaltung'). Außerdem stellt bitte in den Einstellungen des Plugins im Tab 'Logfiles' den Log-Level auf 'Debug' ein. Mit diesem Level werden detaillierte Informationen in neue Logs geschrieben. Die Logs zum Plugin sind nach Gruppen sortiert und die neusten Logs jeder Gruppe stehen immer oben. Bei Problemen zuerst in der Übersicht prüfen, ob aktuelle Logs in den jeweiligen Gruppen mit passender Uhrzeit erstellt worden sind und der Status der Logs 'OK' ist.

[Gargamel]

Hallo Jan W. ,
ich habe auch das Problem. Wusste erst nicht das es am Weather4Lox Problem liegt und habe deshalb ein neuen Thread aufgemacht.

https://www.loxforum.com/forum/germa...ung#post485874

Wird der Fehler automatisch behoben wenn ich die aktuelle Version vom Weather Plugin installiere oder muss ich vorab noch was beachten?

Vielen dank für deine Mühe.

[Jan W.]

Nachdem mehrere Anwender von Problemen mit der DNS Namensauflösung berichtet hatten, habe ich ein rPI 5 mit DietPI v10.4.(DietPi_RPi5-ARMv8-Trixie.img.xz, vom 18. Mai 2026) neu aufgesetzt, Loxberry v3.0.1.3 und anschließend das Weather4lox Plugin installiert. Ich hatte keine Probleme mit fehlenden oder unvollständigen Paketen, keine Fehler im Log.

Ich habe danach noch das DNSmasq Plugin installiert, um die verschiedenen Kombinationen beim Emulator tiefer zu testen. Das DNSmasq Plugin hatte bei mir das Problem, dass die Konfiguration ignoriert wurde. Erste nach den dem folgenden Befehl wurde die Konfiguration gelesen:

su -
<root password>
ln -s /opt/loxberry/config/plugins/dnsmasq/DNSmasq_dnsmasq.cfg /etc/dnsmasq.d/dnsmasq_plugin.conf

außerdem hatte ich in der DNSmasq Konfiguration folgende Einstellungen gesetzt

addn-hosts=/opt/loxberry/config/plugins/dnsmasq/DNSmasq_hosts.cfg
no-resolv
no-poll
bogus-priv
domain-needed
domain=home.local
server=1.1.1.1
server=1.0.0.1
local=/.local/

Nach dem An- und Abschalten des Emulators hatte ich das Problem, dass die DNS Namensauflösung nicht mehr funktionierte. Daher habe ich das Skript, um den Emulator zu starten und zu beenden komplett überarbeitet. Es werden jetzt Log-Meldungen (in der Gruppe 'Emulator') erzeugt und getestet, ob die DNS-Namenslauflösung am Ende funktioniert. Dies betrifft nur die Anwender, die den Emulator aktiv nutzen. Wenn ein DNSmasq Plugin gefunden wird, dann werden nur die Einträge für weather.loxone.com gesetzt bzw. gelöscht. Wird dieses Plugin nicht gefunden, dann wird das Paket dnsmasq installiert bzw. deinstalliert und alle benötigten Einträge für den Emulator erstellt.

Ich habe außerdem die Einstellungen in der GUI erweitert, so dass man jetzt neben dfcX_... und hfcX_... auch auf nxhX_... filtern kann und nur die ausgewählten Stunden bzw. Tage oder Aggregationen an den MS per MQTT oder UDP gesendet werden. Die aktuellen Einstellungen dafür werden in einer Liste angezeigt, so dass man die einfacher erkennen kann, ohne die Auswahlfelder aufzuklappen.

Getestet habe ich die Installation auch auf einem etwas älteren Loxberry mit Bookwork OS und auf einem OrangePI zero 3 mit Trixie. Auf beiden Systemen konnte ich keine Fehler feststellen.

Das Logging von Perl Modulen, die während der Installation des Plugins über cpanm installiert werden, habe ich noch etwas verbessert und alles in der neuen Version v4.15.0.17 veröffentlicht:

https://github.com/Jan21493/LoxBerry...V4.15.0.17.zip

[SehlingS]

Kurze Frage, ich habe aktuelle die letzte Version vom org. Plugin installiert unter Loxberry v3.0.1.3 unter Bockworm.
Jetzt würd ich gerne auf neues Plugin updaten.
Alter vorher deinstallieren? Oder einfach die URL oben einfügen und installieren klicken?
Oder habe ich dann am Ende beide Versionen drauf?

Grüße und Danke
Sascha

[Jan W.]

Du kannst einfach updaten, da ich den Autor, Name vom Plugin etc. bisher nicht verändert habe. Alle Einstellungen bleiben erhalten. Es wird in den nächsten Monaten ein Major Upgrade kommen, wo sich der Autor ändert und dann leider kein Update funktioniert. Dafür gibt es aber eine Info und Anleitung.

[christian288]

Hi,

could someone share a screenshot of how MQTT is configured in Loxone?

I tried to follow the manual, but I couldn't quite figure it out.

I haven't been able to get it working, and I need to get some data into Loxone.

Any help or example configuration would be greatly appreciated. 🙂

Thanks in advance!

[Jan W.]

see Post #20 together with Google translator. If you got stuck, post detailed infos.

[christian288]

could someone share a screenshot of how MQTT is configured in Loxone?

I tried to follow the manual, but I couldn't quite figure it out.

I haven't been able to get it working, and I need to get some data into Loxone.

Any help or example configuration would be greatly appreciated. 🙂

Thanks in advance!
[/QUOTE]

According to the recommendations, this should work via MQTT. I'm still using a Loxone Gen.1 Miniserver.

In LoxBerry, MQTT is configured with the following connection details:

• Host: 192.168.20.162
• Port: 1883
• Username: loxberry
• Password: XXXXXXXXXXXXX

The LoxBerry IP address is 192.168.20.162:8084.

I'm trying to follow the guide, but I can't get any values into Loxone. See the attached screenshot.

[Jan W.]

Hmm, what parameter(s) do you like to get? The name of the parameter in Loxone config needs to be exactly from the list in the wiki, e.g. w4l_cur_tt for current real temperature. I also have a MS Gen. 1, so the hardware is not the issue. Try Google translate, maybe Google lens to translate the bubbles in the screenshots from the guide.

Try the following:

1. Configure your MS in the Loxberry as a miniserver with credentials and do a test. If this is working fine, IP addresses and credentials should be O.K.
2. Create a subscription on the Loxberry in MQTT under the MQTT gateway, subscriptions tab and name it to the the topic that you've configured in the weather4lox plugin in the 'send to miniserver' tab, e.g. subscription name w4l/# if your topic is w4l
3. Use the MQTT Incoming Overview in the MQTT gateway on the Loxberry and filter on your topic, e.g. w4l (first screenshot in post #20), w4l_cur or w4l_cur_tt to see the current temperature only. It's a regular expression match that allows you to restrict the output. All parameters that you see here, are forwarded from the plugin to the MQTT Gateway. If you don't see any parameters from weather4lox, the subscription may be missing (problem in step 2). If a specific parameter is missing, the name may be wrong wrong.
4. Attention: values for a parameter are submitted to the MS only if the value has changed, so either do a restart of the mqtt gateway.

Look into the log of the MQTT Gateway, but also Weather4Lox plugin. Which guide did you follow? This one here? Don't miss any step!!

[christian288]

Hmm, what parameter(s) do you like to get? The name of the parameter in Loxone config needs to be exactly from the list in the wiki, e.g. w4l_cur_tt for current real temperature. I also have a MS Gen. 1, so the hardware is not the issue. Try Google translate, maybe Google lens to translate the bubbles in the screenshots from the guide.

Try the following:

1. Configure your MS in the Loxberry as a miniserver with credentials and do a test. If this is working fine, IP addresses and credentials should be O.K.
2. Create a subscription on the Loxberry in MQTT under the MQTT gateway, subscriptions tab and name it to the the topic that you've configured in the weather4lox plugin in the 'send to miniserver' tab, e.g. subscription name w4l/# if your topic is w4l
3. Use the MQTT Incoming Overview in the MQTT gateway on the Loxberry and filter on your topic, e.g. w4l (first screenshot in post #20), w4l_cur or w4l_cur_tt to see the current temperature only. It's a regular expression match that allows you to restrict the output. All parameters that you see here, are forwarded from the plugin to the MQTT Gateway. If you don't see any parameters from weather4lox, the subscription may be missing (problem in step 2). If a specific parameter is missing, the name may be wrong wrong.
4. Attention: values for a parameter are submitted to the MS only if the value has changed, so either do a restart of the mqtt gateway.

Look into the log of the MQTT Gateway, but also Weather4Lox plugin. Which guide did you follow? This one here? Don't miss any step!!

Thanks for the detailed explanation.

I think I need some advice on the Loxone side. What values exactly should I enter in the Virtual HTTP Input?

I may be using the wrong IP address or configuring it incorrectly. See the attached screenshot.

I never had any problems getting data into Loxone via UDP, but I have never managed to get MQTT working properly. I can see data arriving in the MQTT Gateway on LoxBerry, but I'm probably missing something in the Loxone configuration.

[Jan W.]

What values exactly should I enter in the Virtual HTTP Input?

The short answer is: nothing. This object only needs to exist to be able to configure virtual http input commands.

The longer answer may help you to understand how the MQTT gateway of the loxberry communicates with the miniserver. So if you had asked this question to Loxone, your answer would be like "this is not supported, the MS gen. 1 does not have virtual MQTT input. The answer here in the Loxforum is different: if you have a Loxberry, you can 'misuse' virtual http input commands for MQTT. Technically they are not used as HTTP inputs and you could also use other types of inputs, because the MQTT gateway is using websockets to communicate with the MS. The MQTT gateway is using a push method to send the new value via websocket to a specific parameter, so only the name of the parameter needs to match.

I may be using the wrong IP address or configuring it incorrectly. See the attached screenshot.

These IP addresses can't be wrong, because they are not used if a value is pushed to the MS over websockets. However, if you leave the IP address empty, Loxone config complains that the input is not configured completely. I recommend to put in just a dot as the URL in the virtual http input as a dummy and a very high refresh interval. Also in the virtual http input command you can configure a backslash dot as a dummy in the detection to avoid complaints from Loxone config.

What is the advantage to use MQTT over normal HTTP inputs? Normal http inputs poll a website every few seconds or minutes, parse each parameter by virtual http input commands. The polling and parsing puts load on the MS. With MQTT and websockets, the MQTT gateway is pushing a value to the ms. This pushing is much more efficient and a parsing can be avoided. You even get a changed value much faster without a need to poll every second.

[christian288]

The short answer is: nothing. This object only needs to exist to be able to configure virtual http input commands.

The longer answer may help you to understand how the MQTT gateway of the loxberry communicates with the miniserver. So if you had asked this question to Loxone, your answer would be like "this is not supported, the MS gen. 1 does not have virtual MQTT input. The answer here in the Loxforum is different: if you have a Loxberry, you can 'misuse' virtual http input commands for MQTT. Technically they are not used as HTTP inputs and you could also use other types of inputs, because the MQTT gateway is using websockets to communicate with the MS. The MQTT gateway is using a push method to send the new value via websocket to a specific parameter, so only the name of the parameter needs to match.


These IP addresses can't be wrong, because they are not used if a value is pushed to the MS over websockets. However, if you leave the IP address empty, Loxone config complains that the input is not configured completely. I recommend to put in just a dot as the URL in the virtual http input as a dummy and a very high refresh interval. Also in the virtual http input command you can configure a backslash dot as a dummy in the detection to avoid complaints from Loxone config.

What is the advantage to use MQTT over normal HTTP inputs? Normal http inputs poll a website every few seconds or minutes, parse each parameter by virtual http input commands. The polling and parsing puts load on the MS. With MQTT and websockets, the MQTT gateway is pushing a value to the ms. This pushing is much more efficient and a parsing can be avoided. You even get a changed value much faster without a need to poll every second.

It seems that I don't have something configured correctly in LoxBerry because I'm not receiving any data, even though I've already followed the guide.

I tried to follow the instructions step by step, but I'm still unable to get any values into Loxone. It's possible that I'm missing something or have configured something incorrectly.

I'm attaching screenshots for reference.


It's solved now. I finally managed to get MQTT working, and the data is now being transferred to Loxone correctly. 🙂

[christian288]

It's solved now. I finally managed to get MQTT working, and the data is now being transferred to Loxone correctly. 🙂

[Jan W.]

Just changed the name? Other users might be interested.

BTW: please use quotes only if required. Otherwise it‘s hard to read and filling up space in this thread.