Giter Club home page Giter Club logo

mod-buienradar's Introduction

FHEM::Buienradar

General description

FHEM::Buienradar extends FHEM with precipiation information, delivered by the dutch service Buienradar.

License

This software is public domain by the Unlicense.

Contributions

You are invited to send pull requests to the the release branch you forked from whenever you think you can contribute with some useful improvements to the module. The module maintainer will review you code and decide whether it is going to be part of the module in a future release. Please read the guidelines for contributions to unlicensed software. A Waiver is available.

Branching model

  • stable contains the current version.
  • oldstable contains the previous release version, just for stability issues. Issues for oldstable are not accepted.
  • testing contains the next release version, it's considered stable also, but might contains bugs or issues. Fixed set of features.
  • development does not longer exist. Further development is made in release branches below release/.
  • Branches below bugfix/ contain bugfix branches
  • Branches below feature/ contain feature branches

Community support

Bug reports and feature requests

Bugs and feature requests are tracked using Github Issues.

Contributors

See the Authors file for a list of contributors.

mod-buienradar's People

Contributors

christoph-morrison avatar lubeda avatar

Stargazers

avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar avatar

Forkers

iamjamo christoph-morrison byte009

mod-buienradar's Issues

Südlich von Gamisch keine Daten

  1. Das Buienradar funktioniert südlich in Deutschland bis kurz vor Garmisch Partenkirchen, weiter südlich kommen keine Daten mehr.

rainEnd wird fehlerhaft angezeigt

Aktuelle mock data sehen wie folgt aus:

21:35 | 0.000 | 
21:40 | 0.000 | 
21:45 | 0.000 | 
21:50 | 0.000 | 
21:55 | 0.000 | 
22:00 | 0.000 | 
22:05 | 0.000 | 
22:10 | 0.000 | 
22:15 | 0.000 | 
22:20 | 0.000 | 
22:25 | 0.060 | =
22:30 | 0.370 | ====
22:35 | 0.650 | =======
22:40 | 0.490 | =====
22:45 | 0.220 | ==
22:50 | 0.110 | =
22:55 | 0.290 | ===
23:00 | 0.560 | ======
23:05 | 0.000 | 
23:10 | 0.000 | 
23:15 | 0.560 | ======
23:20 | 0.870 | =========
23:25 | 0.810 | ========
23:30 | 0.000 | 
23:35 | 0.000 |

Nach diesen Daten sollte rainEnd 23:30 sein, denn dann endet der letzte Regenschauer innerhalb der angegebenen Daten. rainEnd ist allerdings 23:05 - das erste Regenende im Datensatz.

strftime is ambigious

strftime should better written POSIX::strftime

strftime('%H:%M', localtime $storedData{$_}{'start'}),
strftime('%F_%T', localtime $data{$_}{'start'}),
strftime('%H:%M', localtime $storedData{$_}{'start'}),
::readingsBulkUpdate( $hash, 'rainDataStart', strftime '%R', localtime $dataStart);
::readingsBulkUpdate( $hash, 'rainDataEnd', strftime '%R', localtime $dataEnd );
::readingsBulkUpdate( $hash, 'rainBegin', (($rainStart) ? strftime '%R', localtime $rainStart : 'unknown'));
::readingsBulkUpdate( $hash, 'rainEnd', (($rainEnd) ? strftime '%R', localtime $rainEnd : 'unknown'));

get rainDuration ist fehlerhaft

Aktuell wird rainDuration wie folgt ermittelt:

    elsif ( $opt eq "rainDuration" ) {
        my $begin = ::ReadingsVal( $name, "rainBegin", "00:00" );
        my $end   = ::ReadingsVal( $name, "rainEnd",   "00:00" );
        if ( $begin ne $end ) {
            return TimeCalc( $end, $begin );
        }
        else {
            return "unknown";
        }
    }

sub TimeCalc($$) {

    # TimeA - TimeB
    my ( $timeA, $timeB ) = @_;

    my @AtimeA = split /:/, $timeA;
    my @AtimeB = split /:/, $timeB;

    if ( $AtimeA[0] < $AtimeB[0] ) {
        $AtimeA[0] += 24;
    }

    if ( ( $AtimeA[1] < $AtimeB[1] ) && ( $AtimeA[0] != $AtimeB[0] ) ) {
        $AtimeA[1] += 60;
    }

    my $result = ( $AtimeA[0] - $AtimeB[0] ) * 60 + $AtimeA[1] - $AtimeB[1];

    return int($result);
}

mit dem anhängenden Data-Set liefert get rainDuration 65 Minuten zurück - es sind allerdings nur 11 Intervalle, in denen ein Niederschlag gemeldt wird, d.h. 55 Minuten wäre korrekt. Das ganze Gehampel mit TimeCalc() sieht auch überarbeitungswürdig aus.

DE Buienradar line 1033: h3 with attributes (apart from class) is not allowed 

*** DE Buienradar line 1033: h3 with attributes (apart from class) is not allowed
*** DE Buienradar line 1039: h3 with attributes (apart from class) is not allowed
*** DE Buienradar line 1044: h3 with attributes (apart from class) is not allowed
*** DE Buienradar line 1051: h3 with attributes (apart from class) is not allowed
*** DE Buienradar line 1068: h3 with attributes (apart from class) is not allowed
*** DE Buienradar line 1081: h3 with attributes (apart from class) is not allowed

*** EN Buienradar line 942: h3 with attributes (apart from class) is not allowed
*** EN Buienradar line 948: h3 with attributes (apart from class) is not allowed
*** EN Buienradar line 953: h3 with attributes (apart from class) is not allowed
*** EN Buienradar line 960: h3 with attributes (apart from class) is not allowed
*** EN Buienradar line 977: h3 with attributes (apart from class) is not allowed
*** EN Buienradar line 990: h3 with attributes (apart from class) is not allowed
*** EN FHEM/59_Buienradar.pm: No a-tag with name="Buienradar"

disabled löschen funktioniert nicht

Wenn man ein "deleteattr Buienradar disabled" eingibt (oder im Webinterface das attribut disabled löscht), kommt folgende Fehlermeldung:
Code: [Auswählen]
is no valid value for disabled. Only 'on', '1', '0' or 'off' are allowed!
Ich weiss allerdings nicht, wie man das beheben kann....

Make settings readonly

There are some settings and translations who should not be altered, so they can be Readonly

Use sub refs instead of named refs

ATM, the exported functions are exported as name refs:

    $hash->{DefFn}       = "FHEM::Buienradar::Define";
    $hash->{UndefFn}     = "FHEM::Buienradar::Undefine";
    $hash->{GetFn}       = "FHEM::Buienradar::Get";
    $hash->{AttrFn}      = "FHEM::Buienradar::Attr";
    $hash->{FW_detailFn} = "FHEM::Buienradar::Detail";

These should be exported as subroutine refs.

Änderung der Berechnung von rainAmount

Siehe Forum #963340

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.

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

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.

[PBP81,82] Localizing Punctuation Variables - If you’re forced to modify a punctuation variable, localize it 

Magic variable "$@" should be assigned as "local" at line 93, column 8.  See pages 81,82 of PBP.  (Severity: 4)
Magic variable "$@" should be assigned as "local" at line 110, column 12.  See pages 81,82 of PBP.  (Severity: 4)
Magic variable "$@" should be assigned as "local" at line 121, column 16.  See pages 81,82 of PBP.  (Severity: 4)
Magic variable "$@" should be assigned as "local" at line 132, column 20.  See pages 81,82 of PBP.  (Severity: 4)
Magic variable "$@" should be assigned as "local" at line 143, column 24.  See pages 81,82 of PBP.  (Severity: 4)

[PBP194] Don’t use subroutine prototypes

Perl::Critic is muttering about (useless) prototypes:

Subroutine prototypes used at line 156, column 1.  See page 194 of PBP.  (Severity: 5)
Subroutine prototypes used at line 176, column 1.  See page 194 of PBP.  (Severity: 5)
Subroutine prototypes used at line 195, column 1.  See page 194 of PBP.  (Severity: 5)
Subroutine prototypes used at line 222, column 1.  See page 194 of PBP.  (Severity: 5)
Subroutine prototypes used at line 259, column 1.  See page 194 of PBP.  (Severity: 5)
Subroutine prototypes used at line 275, column 1.  See page 194 of PBP.  (Severity: 5)
Subroutine prototypes used at line 391, column 1.  See page 194 of PBP.  (Severity: 5)
Subroutine prototypes used at line 445, column 1.  See page 194 of PBP.  (Severity: 5)
Subroutine prototypes used at line 460, column 1.  See page 194 of PBP.  (Severity: 5)
Subroutine prototypes used at line 483, column 1.  See page 194 of PBP.  (Severity: 5)
Subroutine prototypes used at line 706, column 1.  See page 194 of PBP.  (Severity: 5)

Änderung der Intervalle

Forum #963462

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.

Debugging does not work anymore 

2020.04.13 23:34:36 1: DEBUG>@_
2020.04.13 23:34:36 1: DEBUG>@_
2020.04.13 23:34:36 1: DEBUG>@_

Looks not like expected ...

Text Chart

Ich möchte die Regendaten als text chart ausgeben können, wie ich es zum Debugging implementiert habe:

Aktuelle mock data sehen als text chart wie folgt aus:

21:35 | 0.000 | 
21:40 | 0.000 | 
21:45 | 0.000 | 
21:50 | 0.000 | 
21:55 | 0.000 | 
22:00 | 0.000 | 
22:05 | 0.000 | 
22:10 | 0.000 | 
22:15 | 0.000 | 
22:20 | 0.000 | 
22:25 | 0.060 | =
22:30 | 0.370 | ====
22:35 | 0.650 | =======
22:40 | 0.490 | =====
22:45 | 0.220 | ==
22:50 | 0.110 | =
22:55 | 0.290 | ===
23:00 | 0.560 | ======
23:05 | 0.000 | 
23:10 | 0.000 | 
23:15 | 0.560 | ======
23:20 | 0.870 | =========
23:25 | 0.810 | ========
23:30 | 0.000 | 
23:35 | 0.000 |

Improve error handler for locations out of coverage

Buienradar provides data for netherlands and (most of) germany, but if data for a location outside the covered area is requested, it will still fail with a HTTP/404 error, but delivers also an error message:

// 20200413155827
// https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=46.480962&lon=11.305530&region=de&unit=mm/u

{
  "success": false,
  "reason": "not in coverage"
}

If a location is out of coverage, the module should handle this accordingly and should not just fail (mostly) silently.

rainDuration

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.
inoma, Forum #963631

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:

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

inoma, Forum #963769

[PBP199] "return" statement with explicit "undef" 

"return" statement with explicit "undef" at line 186, column 5.  See page 199 of PBP.  (Severity: 5)
"return" statement with explicit "undef" at line 213, column 5.  See page 199 of PBP.  (Severity: 5)
"return" statement with explicit "undef" at line 241, column 5.  See page 199 of PBP.  (Severity: 5)
"return" statement with explicit "undef" at line 355, column 25.  See page 199 of PBP.  (Severity: 5)
"return" statement with explicit "undef" at line 361, column 25.  See page 199 of PBP.  (Severity: 5)
"return" statement with explicit "undef" at line 387, column 13.  See page 199 of PBP.  (Severity: 5)
"return" statement with explicit "undef" at line 405, column 13.  See page 199 of PBP.  (Severity: 5)
"return" statement with explicit "undef" at line 463, column 5.  See page 199 of PBP.  (Severity: 5)
"return" statement with explicit "undef" at line 565, column 9.  See page 199 of PBP.  (Severity: 5)
"return" statement with explicit "undef" at line 710, column 9.  See page 199 of PBP.  (Severity: 5)
"return" statement with explicit "undef" at line 758, column 13.  See page 199 of PBP.  (Severity: 5)
"return" statement with explicit "undef" at line 773, column 13.  See page 199 of PBP.  (Severity: 5)
"return" statement with explicit "undef" at line 782, column 13.  See page 199 of PBP.  (Severity: 5)

[PBP197] Implicit Returns - Always return via an explicit return 

Subroutine "Initialize" does not end with "return" at line 156, column 1.  See page 197 of PBP.  (Severity: 4)
Subroutine "Get" does not end with "return" at line 275, column 1.  See page 197 of PBP.  (Severity: 4)
Subroutine "Attr" does not end with "return" at line 305, column 1.  See page 197 of PBP.  (Severity: 4)
Subroutine "RequestUpdate" does not end with "return" at line 460, column 1.  See page 197 of PBP.  (Severity: 4)
Subroutine "ParseHttpResponse" does not end with "return" at line 706, column 1.  See page 197 of PBP.  (Severity: 4)
Subroutine "ResetResult" does not end with "return" at line 850, column 1.  See page 197 of PBP.  (Severity: 4)
Subroutine "Debugging" does not end with "return" at line 869, column 1.  See page 197 of PBP.  (Severity: 4)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.