59_Buienradar

Begonnen von Christoph Morrison, 23 Juli 2019, 21:37:15

Vorheriges Thema - Nächstes Thema

Christoph Morrison

Hallo,

Zitat von: inoma am 02 August 2019, 11:25:28
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).

Zitat von: inoma am 02 August 2019, 11:25:28
- 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.

Zitat von: inoma am 02 August 2019, 11:25:28
- 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.

Zitat von: inoma am 02 August 2019, 11:25:28
- 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.
if (!$rainEnd and $rainStart and $precip != 0 ) {
$rainEnd    = $end;
}


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

Zitat von: inoma am 02 August 2019, 11:25:28
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

#76
ZitatJa 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:
$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));
}
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

somansch

Zitat von: Christoph Morrison am 29 Juli 2019, 06:30:56
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,

Zitat von: somansch am 03 August 2019, 19:50:21
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

Zitat von: Christoph Morrison am 04 August 2019, 13:28:53
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

Zitat von: somansch am 04 August 2019, 13:35:42
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?
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

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!

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
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

Christoph Morrison

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

Gisbert

#85
Zitat von: Christoph Morrison am 05 August 2019, 21:59:01
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.
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | tuya local | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

Jamo

Zitat
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 !
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

mahowi

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

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.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

Christoph Morrison

#88
Zitat von: mahowi am 06 August 2019, 18:25:54
rainNow scheint nicht den aktuellen Regen anzuzeigen sondern den der ersten Periode ungleich 0.

Issue #2

Christoph Morrison

Zitat von: inoma am 02 August 2019, 19:20:52
Ich dachte an sowas:
$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