59_Buienradar

[Christoph Morrison]

Hallo,

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

Das war eine bewusste Entscheidung. Ich finde 1/0 als Flag dämlich. Ggf. baue ich mal eine undokumentierte Kompatiblität ein. Stimmt übrigens nicht das alle Module das so machen. ASC z.B. hat gar keinen off-Modus (was ich auch nicht gut finde).

- 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.

Ja und es ist vor allem schwieriger zu berechnen weil es ja durchaus auch Pausen gibt. Ich könnte natürlich die (ersten zusammenhängenden) 5-Minuten-Intervalle zählen in denen es regnet, dann hat man wenigstens einen groben Wert - aber der kann halt verführerisch gut sein, wenn es erst 5 Minuten regnet, dann 5 Minuten nicht und dann die restliche Zeit wieder doch. Oder halt alle 5-Minuten-Intervalle in den nächsten 2 Stunden. Die Daten sind dafür eigentlich nicht genau genug. Ich überleg's mir mal.

- 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....

Ich hab eine Art automatisches Load-Balancing auf der Agenda: Wenn der Datenabruf ein paar mal nicht geklappt hat, wird die Anfragefrequenz automatisch gedrosselt. Man könnte überlegen ob man das auch macht wenn es z.B. länger gar keinen Regen geben soll (und wieder beschleunigen wenn Regen aufkommt). Vielleicht über einen "auto"-Intervall.

- 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;
}


Nehme ich mir mal mit. Wird aber frühestens nächste Woche was.

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

Gerne.

[Jamo]

Ja und es ist vor allem schwieriger zu berechnen weil es ja durchaus auch Pausen gibt. Ich könnte natürlich die (ersten zusammenhängenden) 5-Minuten-Intervalle zählen in denen es regnet, dann hat man wenigstens einen groben Wert - aber der kann halt verführerisch gut sein, wenn es erst 5 Minuten regnet, dann 5 Minuten nicht und dann die restliche Zeit wieder doch. Oder halt alle 5-Minuten-Intervalle in den nächsten 2 Stunden. Die Daten sind dafür eigentlich nicht genau genug. Ich überleg's mir mal.

Ich dachte an sowas:

Code Auswählen Erweitern

$rainDurationMin = ($rainEnd-$rainStart)/60;
$rainDuration = MinToHours ($rainDurationMin);


::readingsBulkUpdate( $hash, "rainDuration", (($rainStart && $rainEnd) ? $rainDuration : 'unknown'));
::readingsBulkUpdate( $hash, "rainDurationMin", (($rainStart && $rainEnd) ? $rainDurationMin : 'unknown'));


sub MinToHours($) {
  my($intime) = @_;
  return sprintf("%02d:%02d",(($intime/60),$intime%60));
}


[somansch]

Die Unterstützung für logProxy werde ich nicht wieder einbauen. Aktuell sehe ich keinen Sinn der Funktionalität. Wer den Wert haben will, der früher von Buienradar_logProxy zurück kam, soll einfach rainAmount nehmen.

Wenn jemand gute Argumente dafür hat bin ich aber offen.

Hallo Christoph,

erstmal danke für deine super Arbeit  . Habe heute das erste Mal dieses Modul bei mir eingebaut (v.2.2.0), läuft auch super in München mit dem "DE" Attribut. Ebenso "GChart". Nun möchte ich das Chart jedoch auch in FTUI einbauen. Hierfür benötige ich die logproxy-Funktion. Ist das ein gutes Argument? 

Danke vorab
Andreas

[Christoph Morrison]

Hallo Andreas,

erstmal danke für deine super Arbeit  . Habe heute das erste Mal dieses Modul bei mir eingebaut (v.2.2.0), läuft auch super in München mit dem "DE" Attribut. Ebenso "GChart". Nun möchte ich das Chart jedoch auch in FTUI einbauen. Hierfür benötige ich die logproxy-Funktion. Ist das ein gutes Argument? 

kannst du mir mal genauer erklären für was die logproxy-Funktion benötigt wird? Ich hab kein FTUI hier.

Gruß
CM

[somansch]

Hallo Andreas,

kannst du mir mal genauer erklären für was die logproxy-Funktion benötigt wird? Ich hab kein FTUI hier.

Gruß
CM

Na klar  . In FTUi gibt es die Möglichkeit Charts (ähnlich SVG Plots in FHEM) zu erstellen. Hierfür wird ein Logfile, DBLog (beides historische Daten) oder LogProxy (aktuelle Daten) benötigt. Siehe Wiki: https://wiki.fhem.de/wiki/FTUI_Widget_Chart#LogProxy

Viele Grüße
Andreas

[Christoph Morrison]

Na klar  . In FTUi gibt es die Möglichkeit Charts (ähnlich SVG Plots in FHEM) zu erstellen. Hierfür wird ein Logfile, DBLog (beides historische Daten) oder LogProxy (aktuelle Daten) benötigt. Siehe Wiki: https://wiki.fhem.de/wiki/FTUI_Widget_Chart#LogProxy

Welchen Output muss die Unterstüzung von logProxy erzeugen? Aktuell ist das glaube ich nur der Wert von rainAmout, kann das sein?

[mahowi]

Kann man nicht einfach ein Log-Device anlegen und sich rainAmount (und ggfs. noch andere Werte) in ein Logfile schreiben lassen?

[Christoph Morrison]

In development (2.2.1) ist nun auch der Support für logProxy enthalten. Die Funktion lässt sich nun mit FHEM::Buienradar::LogProxy aufrufen, ansonsten wie früher.

[Jamo]

Hallo Christoph,
version 2.2.3 funktioniert soweit wie bei mir vorher auch die version 2.2.0, allerdings ist folgendes an die falsche Stelle gerutscht, das muss man loeschen sonst lädt das Modul nicht.
Ein dickes Danke!

Code Auswählen Erweitern

501a502,507
> =item C<FHEM::Buienradar::GChart>
>
> C<FHEM::Buienradar::GChart> returns the precipitation data from buienradar.nl as PNG, renderd by Google Charts as
> a PNG data.
>
> =cut


[Christoph Morrison]

Was für eine Perl-Version benutzt du? Das ist ein POD-Block, der sollte niemals irgendwie ausgeführt werden.

[Gisbert]

Was für eine Perl-Version benutzt du? Das ist ein POD-Block, der sollte niemals irgendwie ausgeführt werden.

Ich hab gerade auf die Version [Edit]2.3.0 2.2.3 - ich bin der Zeit voraus - upgedatet, also hier sieht es gut aus.

[Jamo]

Was für eine Perl-Version benutzt du? Das ist ein POD-Block, der sollte niemals irgendwie ausgeführt werden.

Sorry, habs gerade nochmal auf 2.2.3 ge-updated, und jetzt tritt der Fehler nicht mehr auf. Beim ersten mal hatte ich nur ein re-load gemacht, jetzt ein shutdown & restart, sieht aber jetzt alles sauber aus. Danke !

[mahowi]

rainNow scheint nicht den aktuellen Regen anzuzeigen sondern den der ersten Periode ungleich 0.

Code Auswählen Erweitern

2019-08-06 18:18:43   rainAmount      0.000
     2019-08-06 18:18:43   rainBegin       19:50
     2019-08-06 18:18:43   rainData        0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0.15:0.22:0.24:0.22:0.25
     2019-08-06 18:18:43   rainDataEnd     20:15
     2019-08-06 18:18:43   rainDataStart   18:10
     2019-08-06 18:18:43   rainEnd         unknown
     2019-08-06 18:18:43   rainLaMetric    0,0,0,0,0,0,0,0,0,0,0,0
     2019-08-06 18:18:43   rainMax         0.250
     2019-08-06 18:18:43   rainNow         0.150
     2019-08-06 18:18:43   rainTotal       1.080
     2019-08-06 18:18:43   state           0.150

Aktuell ist die Regenmenge 0 im nächsten Intervall. rainNow ist aber 0.150, also der nächste Wert >0.

Ich benutze die aktuelle development Version.

[Christoph Morrison]

rainNow scheint nicht den aktuellen Regen anzuzeigen sondern den der ersten Periode ungleich 0.

⇒ Issue #2

[Christoph Morrison]

Ich dachte an sowas:

Code Auswählen Erweitern

$rainDurationMin = ($rainEnd-$rainStart)/60;
$rainDuration = MinToHours ($rainDurationMin);


::readingsBulkUpdate( $hash, "rainDuration", (($rainStart && $rainEnd) ? $rainDuration : 'unknown'));
::readingsBulkUpdate( $hash, "rainDurationMin", (($rainStart && $rainEnd) ? $rainDurationMin : 'unknown'));


sub MinToHours($) {
  my($intime) = @_;
  return sprintf("%02d:%02d",(($intime/60),$intime%60));
}


⇒ Issue #3