59_Buienradar

[Christoph Morrison]

In Zeile 668 ist Dir wohl irgendwie ein "kk" hinter die Zeile geraten:

https://www.youtube.com/watch?v=y6OOdeEM1sU

[Christoph Morrison]

Wenn es Werte gibt außer 0 fängt der Chart bei 0 an und nicht bei -1. Allerdings kann man bei mir auch die Zeiten nicht lesen.

Hallo Christoph,
wie lautet denn der Aufruf, um den gChart zu erzeugen? Ein

Code Auswählen Erweitern

defmod Buienradar_gChart weblink htmlCode { FHEM::Buienradar::GChart("Buienradar")} liefert bei mir folgendes Bild, da ist aber der Niederschlag von -1 bis +1, und mann kann die Zeiten nicht lesen.

Schräg. Ist bei mir völlig normal skaliert. Habe gerade keine Idee warum das bei euch komisch aussieht.

[mahowi]

https://www.youtube.com/watch?v=y6OOdeEM1sU

Das kenne ich. 

Schräg. Ist bei mir völlig normal skaliert. Habe gerade keine Idee warum das bei euch komisch aussieht.

Wenn ich die Seite auf dem Handy lade sind auch die Minuten abgeschnitten.

[Jamo]

Hallo Christoph, hattest Du das gelesen?

In Zeile 921
Code: if ($forecast_data->{'success'} ne "true") {
durch Code: if (!$forecast_data->{'success'}) {
ersetzen, dann funktionierts. Irgendwie funktioniert also die Abfrage von 'success' auf "true" nicht.

Bei mir liefert $forecast_data->{'success'} eine '1' zurück, und nicht "true". Ich glaube der Interpretiert 'true' als '1';

Ich habe die perl_version v5.24.1, hängts damit zusammen?

[Christoph Morrison]

Hallo Christoph, hattest Du das gelesen?

Ja aber ich hab noch keine Idee wie damit umzugehen, geschweige denn wie ich gerade noch auf 5.24.1 zurückkomme. Hier hab ich überall entweder 5.26 oder 5.28.

Ok, hab mir eine Stretch-Maschine besorgt und stelle es gerade nach. Wird dann ein fix für testing werden (der natürlich auch in development kommt).

Habe das Problem in testing und development behoben.

[Jamo]

Hi Christoph,
ich habe mal ein wenig gelesen, um den Unterschied zwischen 'RainAmount' und 'RainTotal' zu verstehen.

Laut Google Wiki ist "Rainamount" die RegenMenge, die in einem definierten Zeitraum fällt,
üblicherweise pro Stunde, weil man damit einen Referenzwert für die Regenmenge pro Quadratmeter hat, um z.b. Werte in Deutschland miteinander zu vergleichen.

Damit wären die Werte und Einheiten wie im folgenden Beispiel, angenommen Buienradar hat eine 2 Stunden Vorhersage mit 5 Minuten Intervallen.

2 Stunden Vorhersage, 24 intervalle a 5 Minuten:
Interval:  0, 1, 2, 3, 4, 5, 6, 7, 8,10,11,12,13,14,15,16,17,18,19,20,21,22,23
RainData:  5, 1, 2, 3, 4, 6, 7, 8, 7, 2, 5, 5, 3, 2, 1, 0, 0, 1, 1, 0, 0, 1, 1

RainAmount : 50 l/qm in der nächsten Stunde = 50mm/h = sum(Raindata(0..11))
RainMax      :  8 mm (Maximale Regenmenge in einem 5 Minuten Interval, im gesamten Vorhersagezeitraum von 2h)
RainNow     :  5 mm (Regenmenge im jetzigen 5 min Regen Interval)
RainTotal     : 65 mm (Gesamte Regenmenge im Vorhersagezeitraum von 2h)

RainMax/RainNow darf man aber auf keinen Fall auf 1 Stunde hochrechnen, weil der Vorhersagewert für 1 Stunde in 12 unterschiedleichen Werten steckt.
Raintotal ist natürlich der Wert für 2 Stunden, aber ein halbierter wert entspricht nicht dem VorhersageWert für 1 Stunde (das sind natürlich nur die ersten 12 Werte).

Ich denke so machts Sinn.

Wenn das so wäre, dann müsstest Du nur noch den RainAmount ändern auf die Summe der ersten 12 Werte, und die Einheiten müssten angepasst werden.

Beste Grüsse

[Gisbert]

Hallo Christoph,

ich hab gerade das update auf:

Version 2.2.0
Installation
update add https://raw.githubusercontent.com/fhem/mod-Buienradar/development/controls_Buienradar.txt

vollzogen.

Ist diese Version insoweit funktional, dass man mit ihr bereits arbeiten kann, d.h. Readings an anderer Stelle auswerten und damit steuern kann?
Die nächste Frage bezieht sich auf die Stabilität / Neustartverhalten nach Mitternacht - ist dieser Bug (als feature war's wohl nicht gedacht ) aus der Version 2.2.0 entfernt?

Viele Grüße Gisbert

[Christoph Morrison]

Ist diese Version insoweit funktional, dass man mit ihr bereits arbeiten kann, d.h. Readings an anderer Stelle auswerten und damit steuern kann?
Die nächste Frage bezieht sich auf die Stabilität / Neustartverhalten nach Mitternacht - ist dieser Bug (als feature war's wohl nicht gedacht ) aus der Version 2.2.0 entfernt?

Hallo Gisbert,

ja und ja. Der ist auf dem gleichen Bug-Niveau wie die 2.1.0/testing, hat aber noch ein paar Features mehr. Es wird sich allerdings ggf. noch was an den Readings ändern (gleicher Name, anderer Wert, siehe Postings über deinem).

Ist mir ganz recht wenn ihr die development/2.2.0 auch gleich testet, dann überspringe ich nämlich direkt die 2.1.0/testing.

[Gisbert]

Hallo Christoph,

danke für die Antwort - ich werde mich dann mal heldenhaft in den Kampf stürzen und dir morgen früh berichten.

Ich sehe, dass man das Abfrageintervall in vorgebenen Zeiten von 10 bis 300 Sekunden einstellen kann.
Ist das nicht ein wenig zu häufig?
Auch eine Abfrage alle 5 Minuten finde ich bei Wetterabfragen schon vglw. häufig.
Könntest du noch ein paar mehr Daten spendieren, z.B. 600, 900, 1800 und 3600 - und stattdessen Werte unter 120 Sekunden streichen?
Prinzipiell  finde ich es ja gut, dass man auch kürzere Intervalle als eine Stunde abfragen kann, aber alles unter 2 bis 5 Minuten finde ich, ist nicht notwendig.

Viele Grüße Gisbert

[choenig]

Hi,

danke für die Antwort - ich werde mich dann mal heldenhaft in den Kampf stürzen und dir morgen früh berichten.

Ich sehe, dass man das Abfrageintervall in vorgebenen Zeiten von 10 bis 300 Sekunden einstellen kann.
Ist das nicht ein wenig zu häufig?
Auch eine Abfrage alle 5 Minuten finde ich bei Wetterabfragen schon vglw. häufig.
Könntest du noch ein paar mehr Daten spendieren, z.B. 600, 900, 1800 und 3600 - und stattdessen Werte unter 120 Sekunden streichen?
Prinzipiell  finde ich es ja gut, dass man auch kürzere Intervalle als eine Stunde abfragen kann, aber alles unter 2 bis 5 Minuten finde ich, ist nicht notwendig.

Viele Grüße Gisbert

du weisst schon, dass nur Daten im Zeitraum von 2h geliefert werden?!?

Und du wirst vermutlich sehr schnell bemerken, dass die Daten sehr volatil sind und sich im 3 Minuten Takt sehr viel ändert. Meines Erachtens würde eine kleinere Update-Frequenz nur Sinn machen, wenn keine Regendaten absehbar sind.

LG
Christian

[Gisbert]

du weisst schon, dass nur Daten im Zeitraum von 2h geliefert werden?!?

Das ist mir bewusst, aber ich hatte mir bisher noch keine Gedanken über die Folgen gemacht.

Und du wirst vermutlich sehr schnell bemerken, dass die Daten sehr volatil sind und sich im 3 Minuten Takt sehr viel ändert. Meines Erachtens würde eine kleinere Update-Frequenz nur Sinn machen, wenn keine Regendaten absehbar sind.

Das ist mir durch eigene Erfahrung bewußt.

Mit deinem Einwand wären aber sicher noch Intervalle von 600 und 900 Sekunden sinnvoll, oder nicht? Und andersrum, welchen Sinn macht es, Daten mit 10 bis 60 Sekunden-Frequenz upzudaten, wenn du sagst, dass sie sich im 3 Minutentakt ändern können?

Viele​ Grüße​ Gisbert​

[choenig]

Hi,

Mit deinem Einwand wären aber sicher noch Intervalle von 600 und 900 Sekunden sinnvoll, oder nicht? Und andersrum, welchen Sinn macht es, Daten mit 10 bis 60 Sekunden-Frequenz upzudaten, wenn du sagst, dass sie sich im 3 Minutentakt ändern können?

Keine, 10s - 60s sind schon sehr kurz, aber alles über 600s macht auch nur minimal Sinn

LG
Christian

[Gisbert]

Hallo Christoph,

es sieht gut aus, keine Neustarts von Fhem heute Nacht. Ich bleibe dann auf der Version 2.2.0. Muss ich noch irgendetwas für den update-Prozess in der Zukunft berücksichtigen?
Nur zur Vollständigkeit: ich hab das Intervall auf 300 Sekunden gesetzt.

Viele​ Grüße​ Gisbert​

[Christoph Morrison]

danke für die Antwort - ich werde mich dann mal heldenhaft in den Kampf stürzen und dir morgen früh berichten.

Das freut mich. Und auch, dass es nun bei dir ohne Neustarts klappt.

Ich sehe, dass man das Abfrageintervall in vorgebenen Zeiten von 10 bis 300 Sekunden einstellen kann.
Ist das nicht ein wenig zu häufig?
Auch eine Abfrage alle 5 Minuten finde ich bei Wetterabfragen schon vglw. häufig.
Könntest du noch ein paar mehr Daten spendieren, z.B. 600, 900, 1800 und 3600 - und stattdessen Werte unter 120 Sekunden streichen?
Prinzipiell  finde ich es ja gut, dass man auch kürzere Intervalle als eine Stunde abfragen kann, aber alles unter 2 bis 5 Minuten finde ich, ist nicht notwendig.

Wie choenig bereits geschriehen hat, ändern sich die Daten auch sehr häufig. Im Prinzip könnte ich natürlich auch mehr Optionen anbieten, aber einerseits war früher der fest eingestellte Intervall 150 Sekunden, andererseits steht auch in der Doku das 10 Sekunden sehr aggressiv sind und nur zum Testen gedacht sind. Insofern habe ich die Zeiträume in denen gepollt werden kann schon bereits auf jeweils 150 Sekunden in jede Richtung erweitert (0 = disabled vs. 300). Zeiträume über 5 Minuten erscheinen mir auch relativ nutzlos, eine Stunde ist viel zu weit in der Zukunft für eine 2h-Vorhersage die sich auch tatsächlich ständig ändert.

Wenn du wirklich seltener als 5 Minuten pollen willst, kannst du dir ja eine Mechanismus machen, der das Device immer für x Sekunden disabled und dann wieder enabled (DOIF oder so).

Ich wohne in einer Gegend in der sich durch die geographischen Gegebenheiten (Ost-Ende der westfälischen Bucht, begrenzt durch den Höhenzug des Osning/Teutoburger Waldes, Bielefeld als eine der Top-5-Städten bei den Niederschlagsmengen in Deutschland) öfter mal relativ abrupt das Wetter ändert und da sieht man auch ständige "Bewegung" in den Vorhersagedaten. Könnte mir vorstellen dass das an der Küste oder in anderen Kessellagen durchaus ähnlich ist.

[Jamo]

Hallo Christoph,
was mir noch aufgefallen ist / Vorschläge:
- alle Module verwenden attr disable 1 oder attr disable 0, Buienradar hat on/off.

- könnte man evtl noch die 'rainDuration' mit als Reading ausgeben? Ich lasse mir einen Push schicken beim Mountainbiken, falls sich die Regendauer ändert (kurzer Schauer oder langanhaltender Regen), das ist schwieriger zu berechnen, weil die Readings für RainStart und RainEnd nur als HH:MM ausgegeben werden, falls dazwischen ein Tageswechsel liegt.

- Abfrage alle 10 Minuten (also 600) fände ich auch gut, man kann ja, sobald es anfängt zu regnen, das attribut automatisch auf 300 oder 180 runtersetzen. Einfach wegen Serverlast....

- Kannst Du evtl nochmal nachschauen, wie im Code 'rainEnd' gesetzt wird? Ich meine, da müsste in Zeile 655 noch folgendes hin, falls rainEnd nicht auf $end gesetzt ist.

Code Auswählen Erweitern

if (!$rainEnd and $rainStart and $precip != 0 ) {
$rainEnd    = $end;
}


Version 2.2.0 in der jetzigen Version läuft bei mir absolut Prima. Chapeau an Dich für die geile Arbeit.

Danke!