Plugin: Weather4Lox (ehemals Wunderground4Loxone)

[SeLoxone]

meinst du das Logfile von einem Critical?

[Prof.Mobilux]

Ja, das logfile von fetch und das vom grabber. Logging vorher auf debug stellen und das Logfile hier anhängen. Nicht als Screenshot sondern das File. Sonst sehen wir nix und können nicht helfen.

[SeLoxone]

Habe die Logfiles oben mit angehängt.

[menK0]

Moin,
ich bin mir nicht sicher ob es mit der neuen Loxberry Version zu tun hat, aber seit dem Update werde die Daten vom Grabber_Loxone nicht mehr richtig übernommen.
Und selbst die Werte die übernommen werden sollen passen nicht zusammen. Beispiel im Anhang und z.b. Temp vom Sensor 11.9, Temp vom Grabber 12.3.

[Christian Fenzl]

Bitte melde dich am LoxBerry mit Putty an (https://www.loxwiki.eu/pages/viewpag...ageId=12091660) und mach folgenden Befehl:

curl http://user:pass@miniserverip/dev/sps/io/w4l_cur_pr/all

user ist dein Miniserver-User, den du in LoxBerry hinterlegt hast
pass ist das zugehörige Passwort
miniserverip ist die IP deines Miniservers

Bitte den Response hier posten.

Danke und lg,
Christian

[menK0]

Hi Christian,
die Ausgabe sieht dann wie folgt aus:

<?xml version="1.0" encoding="utf-8"?>
<LL control="dev/sps/io/w4l_cur_pr/all" value="0.0hPa" Code="200"/>

Als Zusatzinfo:
Ich importiere die Werte meiner Sensoren über VI und passe den Luftdruck mittels Korrekturwert an, so kommt der Luftdruck VQ zustande.
Die Übereinstimmung der Werte die der Grabber holt hat sich die Tage wieder selbstständig angepasst, heißt was der Grabber von VI holt passt auch und wird wieder richtig übergeben.
Nur der Wert der über VQ ausgelesen werden soll, kommt nicht an.

Danke und Gruß
Marco

[Christian Fenzl]

Was soll ich machen - in deinem Baustein steht 0 drin.
Hast du w4l_cur_pr doppelt?

[menK0]

Du alles gut, ich versuche es gerade selber nachzuvollziehen. Evtl. wäre es ja auch ein Berechtigungsproblem gewesen. Zur Not muss ich via Skript rechnen und dann als VI wieder importieren. Die werden ja übernommen.
Doppelt habe ich es nicht, wenn ich es entferne kommt bei der Abfrage Code=404 und der Wert wird vom Wetterdienst genommen, so wie es sein soll.
Danke trotzdem.

[Christian Fenzl]

Probierst du bitte noch

curl http://user:pass@miniserverip/dev/sps/io/w4l_cur_pr

ob das was ändert? Wenn da was anderes kommt, hat die Loxone API einen „Schuss“.

[menK0]

Da kommt tatsächlich mein Wert zurück:

<?xml version="1.0" encoding="utf-8"?>
<LL control="dev/sps/io/w4l_cur_pr" value="1015.0hPa" Code="200"/>

[Christian Fenzl]

Wtf 🤬

[Christian Fenzl]

Was ist der Unterschied zwischen den zwei Bausteinen, die Werte liefern, und den zweien, die 0 zurückliefern?

(BTW Die Änderung in LB2.2 habe ich deswegen durchgeführt, weil die Abfrage ohne /all bei einigen Bausteinen falsch zurückgeliefert hat, aber richtig mit /all - https://github.com/mschlenstedt/Loxb...c7327c66dca8e7)

[Christian Fenzl]

Ich hab mir das jetzt nochmal im Detail angesehen, und aus meiner Sicht ist das ein Bug in der Loxone API.

Bei allen Bausteinen und IO's (inkl. Merker) wird mit /all der korrekte Wert zurückgegeben, außer bei Analogausgängen (und evt. Virtuellen Analog-Ausgängen), da kommt immer 0.
Im Gegenzug liefert die Loxone-API ohne /all bei anderen Bausteinen immer den falschen Wert (z.B. "Schalter"-Baustein liefert 0 zurück, obwohl EIN).

Ich werde den Bug von Loxone in der LoxBerry-API workarounden (nicht das erste Mal - wir workarounden auch schon ein non-valides XML in deren Response), sodass dann immer der richtige Wert zurückkommt. Das wird evt. ein paar Tage dauern.

Da es nach meinen Tests VO's betrifft, erstell dir einen "Virtuellen Status" oder einen Merker mit dem Wert, dort sollte es stimmen.

lg, Christian

[Christian Fenzl]

menK0
Ich habe heute einen Workaround für den Loxone-API-Bug commited.
Könntest du LoxBerry auf den „Letzten Entwicklungsstand“ updaten und prüfen, ob dann die Werte wieder da sind.
Vielen Dank!

[menK0]

Hi Christian,
danke für das schnelle Umsetzen, mein Loxberry ist jetzt mit deinem commit auf dem letzen Stand aber ich erhalte das gleiche Ergebnis. Heißt mit /all kommt der Wert 0, ohne der richtige Wert.
Bei mir ist der Unterschied von geht Virtueller HTTP Eingang und nicht geht Virtueller Analog-Ausgang.

Soll ich lieber einen Merker nehmen?

Gruß
Marco

[Christian Fenzl]

Hast du das mit dem Weather-Plugin getestet oder mit curl?
Bei curl kann ich dir nicht helfen, das ist ein Bug in Loxone.
Über das Weather-Plugin allerdings wird der LoxBerry-Code verwendet, der den Loxone-Bug versucht, „auszubügeln“. Im Loxone-Fetcher von W4L sollten dann die richtigen Werte ankommen.

Lg, Christian

[menK0]

Beides, aus dem Log und curl.
Ich habe mir mal deinen commit gerade angesehen, in line 251 bei der if Schleife machst du eq 0, da ich aber so "clever" war und mein Wert keine Ganzzahl ist kam natürlich 0.0 zurück. habe jetzt im VQ die Einheit auf <v>hPa gesetzt und zack jetzt passt es.
Danke und Gruß
Marco

[Christian Fenzl]

Das muss ich dann aber noch fixen. Danke fürs Ausprobieren

[Christian Fenzl]

Ist jetzt auch korrigiert.

[menK0]

Jap, jetzt funzt auch <v.1>. Danke

[.:Chris:.]

Hallo Forengemeinde,
seit einigen Tagen verliert der Miniserver immer die Verbindung zum Plugin. Erst nach einem Neustart des MS werden die Wetterdaten wieder angezeigt. Mittlerweile sind 4-5 Neustarts pro Tag notwendig.
Ich habe eine MS Gen.1 (10.3.11.25) und die aktuelle Version des Plugins im Einsatz.
Der "Weather4Lox FETCH process läuft regelmäßig alle 5 Minuten, der Emulator bricht jedoch regelmäßig ab.
Gibt es eine Möglichkeit (ohne MS reboot) die regelmäßigen Anfrage vom MS zum LB wieder zu aktivieren, bzw. herauszufinden warum diese abbrechen?

Vielen Dank
.:Chris:.

[LoxLin]

Hallo, ich habe das gleiche Problem. Wetterdaten verschwinden in der App regelmäßig. Wenn ich dann auf "Wetterdaten abonieren" den Dialog durchgehe, kommt das Wetter irgendwann zurück. Ich nutze den MS Gen1. AN den Netzwerkeinstellungen wurde nichts geändert. Vielleicht reagiert Loxberry manchmal zu langsam? Lauft aber auf eine RPI3b, also ausreichend gut.

[Prof.Mobilux]

Wenn der LoxBerry im Netzwerk für kurze Zeit mal nicht erreichbar ist, schaltet der MS auf den zweiten Nameserver um. Es hilft bei beiden Nameservern die IP des Loxberry einzustellen. Und natürlich das Problem zu beheben, dass der Loxberry zeitweise nicht erreichbar ist.

[svethi]

Was heißt der Emulator bricht ab? Du kannst die URL http://IP-LOXBERRY:6066/forecast/ aufrufen und es kommen da dann keine Daten?
Ich denke eher, dass Dein MiniServer nicht mehr den Loxberry befragt und daher das Problem entsteht. Wenn letzteres der Fall ist, solltest Du die Netzwerkeinstellungen des MiniServer überprüfen. Dazu gab es auch schon genügend Posts.

[.:Chris:.]

Hi, die URL liefert die Werte wie gewünscht.
Die Netzwerkeinstellungen im MS wurden nicht geändert und sind genau so konfiguriert wie vorgegeben.
Das kuriose ist ja, dass es jetzt über Jahre?/Monate super funktioniert hat ...

[svethi]

Nun, wie auch immer. Du siehst ja, dass das Plugin problemlos funktioniert.

[t_heinrich]

Hallo,

um bei mir den Betriebsmodus Tag/Nacht umzuschalten nutze ich meine Wetterstation WH2600 und die Beschreibung von Christian Fenzl

https://www.loxwiki.eu/display/LOX/Automatik-Beschattung+aufgrund+des+Lux-Wertes

Nun ist mir mal wieder die Station eingefroren (also der Webserver ).

Da kam mir die Idee, ob man als Fallback-Lösung irgendwie die Helligkeit nutzen kann, die über nahegelegene WunderMap Wetterstationen empfangen wird?

Ist das überhaupt möglich?

Gruß Thomas

[Prof.Mobilux]

Die meisten Wunderground-Stationen melden Sonnenstrahlung, aber keine Helligkeit. Ich denke die Sonnenstrahlung ist zu ungenau, um zwischen Dämmerung und Nacht zu unterscheiden.

[t_heinrich]

Mmh legitimer Punkt, hast Recht.