FHEM Forum

FHEM - Hausautomations-Systeme => Unterstützende Dienste => Wettermodule => Thema gestartet von: Christoph Morrison am 23 Juli 2019, 21:37:15

Titel: 59_Buienradar
Beitrag von: Christoph Morrison am 23 Juli 2019, 21:37:15
Ich bevorzuge Bugmeldungen über den issue tracker (https://github.com/fhem/mod-Buienradar/issues) bei Github.

Hier kann die Diskussion, die in Niederschlagsvorhersage (https://forum.fhem.de/index.php/topic,76651.0.html) gestartet wurde, am richtigen Platz und im gewohnten Format fortgesetzt werden.

Planung

Version 2.1.0

Nach Aktualisierung auf die neue JSON-API standen diverse Aufräumarbeiten an, die in Version 2.1.0 (https://github.com/fhem/mod-Buienradar/tree/release/2.1.0) umgesetzt wurden.

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

Changelog

Version 2.2.0

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

Todo

Won't do

Changelog

Quellen

Titel: Antw:59_Buienradar
Beitrag von: Gisbert am 24 Juli 2019, 07:54:36
Hallo Bismosa,

ich hatte gestern über Fhem-Neustarts berichtet.
Heute Nacht gab es im Zeitraum von 0:23 bis 0:31insgesamt 23 (!!) Neustarts, etwa im gleichen Zeitraum wie gestern, dannach war es dann wieder gut.

Buienradar läuft im Moment unauffällig.

Im logfile finden sich exakt 23mal die folgenden Einträge:
Can't use an undefined value as an ARRAY reference at .//FHEM/59_Buienradar.pm line 318.
2019.07.24 00:23:13 1: Including fhem.cfg
2019.07.24 00:23:14 3: WEB: port 8083 opened
...
Die Einträge jeweils kurz davor sind variierend.

Ich nutze aktuell Buienradar in diesem Status: mein Download am 23.7. 17:58

Kannst du dir den obigen Eintrag im log anschauen?
Ob der Fehler bei Buienradar nun die Ursache oder eine Folge eines anderen Vorgangs ist, ist noch nicht gesagt.

Viele​ Grüße​ Gisbert​
Titel: Antw:59_Buienradar
Beitrag von: Gisbert am 24 Juli 2019, 08:44:08
Hallo Bismosa,

ich habe gerade versucht auf die neueste Version 23.7. 18.58 upzudaten; dabei bekomme ich folgenden Eintrag beim update-Prozess:
2019.07.24 08:39:33 1 : Buienradar
2019.07.24 08:39:34 1 : UPD FHEM/59_Buienradar.pm
2019.07.24 08:39:34 1 : Got 13877 bytes for FHEM/59_Buienradar.pm, expected 13875
2019.07.24 08:39:34 1 : aborting.

Viele Grüße Gisbert
Titel: Antw:59_Buienradar
Beitrag von: mahowi am 24 Juli 2019, 08:56:10
Das kann ich bestätigen. Bei mir schlägt das Update auch fehl.
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 24 Juli 2019, 12:09:45
Wie vermutet liegt es daran, dass gelegentlich von der API keine Daten kommen. Ich arbeite gerade daran, dass das Handling von fehlerhaften Daten verbessert wird. Buienradar geht dann in Error und verzögert dann das erneute Abfragen immer weiter bis wieder Daten eingehen.
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 24 Juli 2019, 13:10:35
Testet bitte mal Release 2.1.0 (https://raw.githubusercontent.com/fhem/mod-Buienradar/release/2.1.0/controls_Buienradar.txt).
Dazu müsst ihr das alte Modul mit update delete <url> löschen und das neue dann mit update add https://raw.githubusercontent.com/fhem/mod-Buienradar/release/2.1.0/controls_Buienradar.txt neu hinzufügen.
Titel: Antw:59_Buienradar
Beitrag von: mahowi am 24 Juli 2019, 14:48:03
Ein paar Perl-Warnungen tauchen mit der neuen Version noch im Log auf:
2019.07.24 14:41:15.746 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/59_Buienradar.pm line 344.
2019.07.24 14:42:48.673 1: PERL WARNING: given is experimental at ./FHEM/59_Buienradar.pm line 196, <$fh> line 1544.
2019.07.24 14:42:48.674 1: PERL WARNING: when is experimental at ./FHEM/59_Buienradar.pm line 197, <$fh> line 1544.

Außerdem noch:
Undefined subroutine &main::Buienradar_Timer called at fhem.pl line 3296.
Letzteres hängt vermutlich mit der Umstellung auf Package zusammen.

Edit: Die letzte Fehlermeldung mit "undefined subroutine" führt zum Absturz und Neustart von FHEM!

Edit2: Könntest Du vielleicht "disable" als Attribut einbauen? Dann kann man das Modul bei Problemen abschalten. So musste ich erstmal das Device löschen, da FHEM bei jedem Aufruf von "Buienradar_Timer" neu startet.
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 24 Juli 2019, 15:32:22
Danke. Sobald die Temperaturen hier unter die 40-Grad-Grenze gerutscht sind, verlasse ich den Kühlschrank und fixe die Bugs.
Titel: Antw:59_Buienradar
Beitrag von: mahowi am 24 Juli 2019, 15:37:29
Danke! Hier sind's noch gemütliche 35°.  8)
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 24 Juli 2019, 17:03:36
Es gibt wieder ein neues Release für 2.1.0. Changes:

Wenn ihr die 2.1.0 bereits mit update add hinzugefügt habt, reicht ein update all aus.
Titel: Antw:59_Buienradar
Beitrag von: Gisbert am 24 Juli 2019, 18:45:16
Hallo Christoph,

ich teste die neueste Version 2.1.0 und melde dich dann morgen früh, ob es Auffälligkeiten gab in der Nacht.
Das Update hat jetzt geklappt, und es kommen Werte rein, man get ... refresh bemüht - soweit so gut.

Viele Grüße Gisbert
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 24 Juli 2019, 22:16:29
In der neuesten Version in 2.1.0 (über update zu bekommen) existiert nun auch das Attribut disabled. Mit on wird das Device deaktiviert, mit off wieder aktiviert.

Damit ist 2.1.0 nun im feature freeze, d.h. neue Features gibt es erst in 2.2.0 wieder. Ich passe nun noch die Dokumentation an und fixe Bugs (falls noch welche gefunden werden).
Titel: Antw:59_Buienradar
Beitrag von: Gisbert am 25 Juli 2019, 08:38:03
Hallo Christoph,

in der Version von gestern abend (ohne disabled Attribut) bekomme ich heute nacht im Zeitraum 00:27 bis 00:30 insgesamt 11 Neustarts mit folgendem Eintrag:
Can't use an undefined value as an ARRAY reference at .//FHEM/59_Buienradar.pm line 412.
2019.07.25 00:27:01 1: Including fhem.cfg
2019.07.25 00:27:02 3: WEB: port 8083 opened
...

Viele​ Grüße​ Gisbert​
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 25 Juli 2019, 09:31:38
Can't use an undefined value as an ARRAY reference at .//FHEM/59_Buienradar.pm line 412.
2019.07.25 00:27:01 1: Including fhem.cfg
2019.07.25 00:27:02 3: WEB: port 8083 opened
...

Hallo Gisbert,

sonst kamen da keine Ausgaben von Buienradar? Wenn du die Version mit Fehlerhandling benutzt hast, sollten da mindestens noch andere Fehlerausgaben erscheinen (ab verbose level 1) und eigentlich sollte das JSON auch nur dann geparsed werden, wenn Buienradar auch wirklich ein Ergebnis (HTTP Code 200) liefert. Schau bitte noch mal in deinen Log.

Gruß
CM
Titel: Antw:59_Buienradar
Beitrag von: Gisbert am 25 Juli 2019, 12:51:43
Hallo Christoph,

verbose hatte ich nicht eingeschaltet, und mehr Einträge gab es keine. Wie gesagt 11 Neustarts, d.h. dieser Text taucht 11mal auf.

Welchen verbose level empfiehlst Du?

Viele​ Grüße​ Gisbert​
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 25 Juli 2019, 13:14:13
verbose hatte ich nicht eingeschaltet, und mehr Einträge gab es keine. Wie gesagt 11 Neustarts, d.h. dieser Text taucht 11mal auf.
Welchen verbose level empfiehlst Du?

Hallo Gisbert,

das wundert mich, denn in der aktuellen Version (und auch in der, in der es disable noch nicht gab) loggt Buienradar mit Loglevel 1. Zeig mal bitte dein global-Device mit list.
Mach doch auch bitte mal ein Update.

Gruß
CM
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 25 Juli 2019, 14:59:05
Mit Abschluss der Dokumentation ist nun der finale Erweiterungsstand der 2.1.0 erreicht. Ich fixe dort nun nur noch Bugs.
Titel: Antw:59_Buienradar
Beitrag von: Gisbert am 25 Juli 2019, 17:08:10
Hallo Christoph,

ich hab heute morgen ein update gefahren, und davon kann ich ein list anhängen:
Save config
RSS
AMAD
netatmo
Finance
Traffic
Network
icoHaus Haus
CUL_HM
Rollladen
Heizung
Weather
Unsorted
icoEverything Everything
Logfile
Commandref
Remote doc
Edit files
Select style
Event monitor
Internals:
   CFGFN      ./FHEM/WetterdatenSensorenInternet.cfg
   DATA       0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
   FUUID      5c430dc6-f33f-b139-0391-311dd930d4dd016b
   INTERVAL   150
   LATITUDE   51.02943
   LONGITUDE  7.05584
   NAME       Buienradar
   NEXTUPDATE 2019-07-25 17:07:14
   NR         420
   STATE      <span style='color:#2e5e87'>Niederschlag:<br/>0.000 mm/h</span><br/>
<span style='color:#2e5e87'>max. Niederschlag:<br/>0 mm/h</span>
   TYPE       Buienradar
   URL        https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=51.02943&lon=7.05584&region=nl&unit=mm/u
   VERSION    2.1.0
   READINGS:
     2019-07-25 17:04:44   Zeitstempel     2019-07-25 17:04
     2019-07-25 17:04:44   maxrain         0
     2019-07-25 17:04:44   rain            0.000
     2019-07-25 17:04:44   rainAmount      0.000
     2019-07-25 17:04:44   rainBegin       unknown
     2019-07-25 17:04:44   rainData        0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
     2019-07-25 17:04:44   rainDataEnd     19:00
     2019-07-25 17:04:44   rainDataNow     0.000
     2019-07-25 17:04:44   rainDataStart   16:55
     2019-07-25 17:04:44   rainEnd         unknown
     2019-07-25 17:04:44   rainLaMetric    0,0,0,0,0,0,0,0,0,0,0,0
     2019-07-25 17:04:44   rainMax         0.000
     2019-07-25 17:04:44   rainNow         0.000 mm/h
     2019-07-25 17:04:44   rainTotal       0.000
   helper:
     bm:
       FHEM::Buienradar::Attr:
         cnt        2
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        25.07. 12:53:01
         max        0.00589489936828613
         tot        0.00755786895751953
         mAr:
           set
           Buienradar
           disabled
           off
       FHEM::Buienradar::Get:
         cnt        5
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        25.07. 17:04:30
         max        5.69820404052734e-05
         tot        0.000225067138671875
         mAr:
           HASH(0x564d154ea740)
           Buienradar
           ?
Attributes:
   comment    Das Reading maxrain ist der Maximalwert der Regenmenge aus folgenden Devices:
- Buienradar
- Leverkusen.DarkSky - wegen fehlerhaften Daten (Werte ~ 0.01 mm/qm) rausgenommen
- verschiedene Netatmo-Geräte in der Umgebung
- Am Mühlenweg 1 und Dünenweg 33 wurden rausgenommen wegen Fehlmessungen (Rasen sprengen?)
Das Reading maxrain wird über eine Funktion max_rain() erzeugt, die in 99_myUtils_Dewpoint.pm steht
   disabled   off
   group      Wetter
   icon       weather_rain_meter
   room       Weather
   stateFormat <span style='color:{(ReadingsVal('$name','rainDataNow','') > 0 ? "red":"#2e5e87")}'>Niederschlag:<br/>[$name:rainDataNow] mm/h</span><br/>
<span style='color:{(ReadingsVal('$name','maxrain','') > 0 ? "red":"#2e5e87")}'>max. Niederschlag:<br/>[$name:maxrain] mm/h</span>
   userReadings rainDataNow {substr(ReadingsVal($name,'rainNow',''),0,5)},
Zeitstempel {substr(ReadingsTimestamp($name,'rainDataNow',''),0,16)},
rain {ReadingsNum($name,'rainDataNow',0)},
maxrain {max_rain()}

Viele​ Grüße​ Gisbert​
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 25 Juli 2019, 17:25:53
Dann schauen wir mal was die Nacht bringt ;-)
Stell mal verbose auf 4 bitte über Nacht.
Titel: Antw:59_Buienradar
Beitrag von: Gisbert am 25 Juli 2019, 20:13:13
Hallo Christoph,

wird gemacht - ich melde mich dann morgen früh wieder.

Viele Grüße Gisbert
Titel: Antw:59_Buienradar
Beitrag von: inoma am 25 Juli 2019, 21:11:40
Hallo Christoph,
leider läuft das Modul in München nicht, obwohl https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=48.1234&lon=11.1234&region=de&unit=mm/u einen vernünftigen json String zurückliefert.

Es kommt immer eine Fehlermeldung, wenn ich das im Modul händisch mache: HTTP response code is not 200: 404

Kann man die Region "de" evtl mit in der Def übergeben, wie auch LATITUDE und LONGITUDE?
{"success":true,"start":1564080900,"start_human":"20:55","temp":19,"delta":300,"precip":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"levels":{"light":0.25,"moderate":1,"heavy":2.5},"grid":{"x":880,"y":826},"source":"de","bounds":{"N":56.397869,"E":18.257635,"S":45.506641,"W":3.454513}}
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 25 Juli 2019, 21:39:02
Hallo Christoph,
leider läuft das Modul in München nicht, obwohl https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=48.1234&lon=11.1234&region=de&unit=mm/u einen vernünftigen json String zurückliefert.
[...]
Kann man die Region "de" evtl mit in der Def übergeben, wie auch LATITUDE und LONGITUDE?

Aktuell noch nicht. Ich hatte hier auch mit de getestet, allerdings kamen dann nur weniger Werte an als wenn ich nl genutzt habe - aber wir sind hier in Westfalen auch deutlich näher am Lande der bescheidenen Fahrkünste als ihr in Minga.

Ich nehm's mal in die Liste für 2.2.0 auf.
Titel: Antw:59_Buienradar
Beitrag von: inoma am 25 Juli 2019, 22:42:11
Danke, ich freu mich schon aufs update!
Titel: Antw:59_Buienradar
Beitrag von: Gisbert am 26 Juli 2019, 05:18:49
Hallo Christoph,

heute Nacht ab 0:24 gab es 18 Neustarts; leider hab ich vergessen das verbose-Attribut zu setzen.
Can't use an undefined value as an ARRAY reference at .//FHEM/59_Buienradar.pm line 466.
2019.07.26 00:24:11 1: Including fhem.cfg
2019.07.26 00:24:12 3: WEB: port 8083 opened
...

Viele​ Grüße​ Gisbert​
Titel: Antw:59_Buienradar
Beitrag von: mahowi am 26 Juli 2019, 06:45:21
Zumindest einen Neustart nach der Meldung Can't use an undefined value as an ARRAY reference at .//FHEM/59_Buienradar.pm line 466. kann ich bestätigen. Um 00:29 Uhr hab ich die auch im Log. Leider hatte ich verbose auch nicht gesetzt.
Titel: Antw:59_Buienradar
Beitrag von: Papaloewe am 27 Juli 2019, 10:08:59
Ich auch:
Can't use an undefined value as an ARRAY reference at /opt/fhem/FHEM/59_Buienradar.pm line 466.
Leider startet mein FHEM danach nicht neu, sondern hängt sich ganz weg und nur ein manuelle Start am nächsten Morgen hilft. :'(

Gruß
Thomas
Titel: Antw:59_Buienradar
Beitrag von: Gisbert am 27 Juli 2019, 11:15:22
Hallo Thomas,

meine Hardware scheint wohl stärker im Nehmen zu sein ;D , und versucht es wohl mehrfach, bis Fhem dann wieder läuft.
Bis das Problem gefixt ist, bleibt uns wohl nichts anderes übrig, als das Device zu disablen.

Viele Grüße Gisbert
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 27 Juli 2019, 11:49:17
Habt ihr inzwischen verbose-Logs für mich?
Titel: Antw:59_Buienradar
Beitrag von: mahowi am 27 Juli 2019, 12:09:09
Leider steht auch mit verbose auf 5 nix im Log:
2019.07.27 00:26:40.047 4: BR: Update requested
Can't use an undefined value as an ARRAY reference at ./FHEM/59_Buienradar.pm line 466.
Titel: Antw:59_Buienradar
Beitrag von: Papaloewe am 27 Juli 2019, 12:17:23
Logs ggf. erst Morgen früh, aber wenn da nichts drin steht?
Habe noch diese Einträge bei mir im Log gefunden, weiß aber nicht ob das überhaupt ein Problem von Buinrader ist, oder vom LogProxy:
mylogProxy: Buienradar_logProxy("BR_Lev"): Undefined subroutine &main::Buienradar_logProxy called at (eval 27170) line 1
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 27 Juli 2019, 12:51:36
Logs ggf. erst Morgen früh, aber wenn da nichts drin steht?

Das wundert mich halt. Ich hab hier drei Instanzen von FHEM mit der 2.1.0 von Buienradar laufen und entweder treten gar keine Errors auf (lat/long in Gütersloh/OWL) oder der erwartete Fehler tritt auf (München).
Im Falle von München hab ich auch die erwarteten Log-Ausgaben.

Habe noch diese Einträge bei mir im Log gefunden, weiß aber nicht ob das überhaupt ein Problem von Buinrader ist, oder vom LogProxy:
mylogProxy: Buienradar_logProxy("BR_Lev"): Undefined subroutine &main::Buienradar_logProxy called at (eval 27170) line 1

LogProxy kommt wieder mit 2.2.0. Am besten du nimmst die Def so lange raus.
Titel: Antw:59_Buienradar
Beitrag von: Papaloewe am 27 Juli 2019, 13:28:00
Es passiert halt immer so gegen 00:30 Uhr!
Titel: Antw:59_Buienradar
Beitrag von: Gisbert am 27 Juli 2019, 14:54:43
Hallo Thomas und Christoph,

bei mir war es bisher auch gegen 00:30 bzw. ein paar Minuten davor, so im Bereich Start 00:23 bis 00:27 bis ca. Ende 00:30.

Viele Grüße Gisbert
Titel: Antw:59_Buienradar
Beitrag von: Papaloewe am 27 Juli 2019, 18:33:01
Gerade ist es am hellichten Tag passiert und leider Nichts im Log (verbose=4).
2019.07.27 18:16:32 0: SONOS0: Das Lauschen auf der Schnittstelle wurde beendet. Prozess endet nun auch...
Can't use an undefined value as an ARRAY reference at /opt/fhem/FHEM/59_Buienradar.pm line 466.
2019.07.27 18:16:31 4: BR_Lev: Update requested

Ich habe extra die SONOS Meldung mal dringelassen, denn das ist immer der letzte Eintrag bei einem Absturz.
Titel: Antw:59_Buienradar
Beitrag von: inoma am 27 Juli 2019, 23:20:57
Hallo,
bei der Benutzung des Moduls, bekomme ich immer folgende Fehlermeldung:
HTTP response code is not 200: 404
Die Koordinaten liegen in den Niederlande, was mache ich falsch?

Hier der list und die raw json data:
{"success":true,"start":1564262700,"start_human":"23:25","temp":20,"delta":300,"precip":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0.18,1.65,2.74,6.98,10.75,9.31],"levels":{"light":0.25,"moderate":1,"heavy":2.5},"grid":{"x":503,"y":544},"source":"nl","bounds":{"N":55.973602,"E":10.856429,"S":48.895302,"W":0}}

nternals:
   DATA       0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
   DEF        51.984211 5.848321
   FUUID      ddddddd-aaaa-bbbb-cccc-bc78f1f69daf123a
   INTERVAL   150
   LATITUDE   51.984211
   LONGITUDE  5.848321
   NAME       Buienradar
   NEXTUPDATE 2019-07-27 23:20:19
   NR         4767
   STATE      Error
   TYPE       Buienradar
   URL        https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=51.984211&lon=5.848321&region=nl&unit=mm/u
   VERSION    2.1.0
   READINGS:
     2019-07-27 21:50:32   rainAmount      0.000
     2019-07-27 21:50:32   rainData        0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
     2019-07-27 21:50:32   rainDataEnd     23:40
     2019-07-27 22:33:09   rainDataStart   unknown
     2019-07-27 21:50:32   rainLaMetric    0,0,0,0,0,0,0,0,0,0,0,0
     2019-07-27 21:50:32   rainMax         0.000
     2019-07-27 21:50:32   rainTotal       0.000
Attributes:
   disabled   off
   event-on-change-reading rainBegin
   room       Weather
Titel: Antw:59_Buienradar
Beitrag von: choenig am 28 Juli 2019, 08:11:57
Moin,

so, also das ist der Grund der crashes von heute Nacht:

2019.07.28 00:28:03.001 4: Buienradar: Update requested
2019.07.28 00:28:03.146 1: DEBUG>*** RESULT ***
2019.07.28 00:28:03.147 1: DEBUG>{
  'error' => '',
  'data' => '{"success":false,"reason":"SQLSTATE[HY000] [1040] Too many connections"}',
  'param' => {
               'sslargs' => {},
               'path' => '/api/3.4/forecast.php?lat=50.806564&lon=6.976876&region=nl&unit=mm/u',
               'timeout' => 10,
               'callback' => sub { "DUMMY" },
               'host' => 'cdn-secure.buienalarm.nl',
               'hu_port' => 443,
               'redirects' => 0,
               'addr' => 'https://cdn-secure.buienalarm.nl:443',
               'NAME' => '',
               'hu_filecount' => 1,
               'displayurl' => 'https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=50.806564&lon=6.976876&region=nl&unit=mm/u',
               'auth' => 0,
               'code' => '200',
               'httpheader' => 'HTTP/1.1 200 OK
Server: nginx
Content-Type: application/json
Vary: Accept-Encoding
X-Powered-By: PHP/5.4.32-1~dotdeb.1
Access-Control-Allow-Origin: *
Content-Encoding: gzip
Content-Length: 90
Accept-Ranges: bytes
Date: Sat, 27 Jul 2019 22:28:03 GMT
X-Varnish: 1856607107
Age: 0
Via: 1.1 varnish
Connection: close
X-Request-String: /app/forecast.php?x=515&y=563&unit=mm/u
X-Backend: default',
               'buf' => '',
               'protocol' => 'https',
               'conn' => undef,
               'hu_blocking' => 0,
               'hu_portSfx' => '',
               'url' => 'https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=50.806564&lon=6.976876&region=nl&unit=mm/u',
               'loglevel' => 4,
               'method' => 'GET',
               'compress' => 1,
               'hash' => {

[...SNIP...]

Can't use an undefined value as an ARRAY reference at ./FHEM/59_Buienradar.pm line 466.

LG
Christian
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 28 Juli 2019, 14:49:47
so, also das ist der Grund der crashes von heute Nacht:

Ich hatte sowas ja vermutet (too many connections o.ä.), hatte aber bisher nie das Vergnügen so eine Fehlermeldung auch wirklich mal zu sehen. Baue das Handling dafür noch in die 2.1.0 ein, vllt. heute noch.
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 29 Juli 2019, 04:09:48
Hallo zusammen,

2.1.0/testing hat nun noch Fehlerhandling für "leeres" JSON bekommen. Ihr solltet eure controls von 2.1.0 auf testing (https://raw.githubusercontent.com/fhem/mod-Buienradar/testing/controls_Buienradar.txt) umstellen und ein Update machen.

Ich habe außerdem mit 2.2.0 (https://raw.githubusercontent.com/fhem/mod-Buienradar/development/controls_Buienradar.txt) angefangen (im development-Branch). Dort kann man nun auch die Region und den Abrufinterval konfigurieren, außerdem habe ich noch einen Bug in der CRef gefixt. FHEMWEB liefert nun auch kurze Hilfstexte wenn man ein Attribut auswählt.

Übersichtsbeitrag wurde angepasst.
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 29 Juli 2019, 06:08:03
In development gibt es nun auch wieder "PNG"-Charts. Da das eigentlich aber Google Charts waren, heißen die nun auch so.
Als Zückerlein ist die Ausgabe der Google Charts nun sprachabhängig, d.h. wenn in global language auf EN gesetzt ist, stehen in dem Chart auch englische Texte und keine deutschen Texte.
Einbindung siehe CRef von development.
Titel: Antw:59_Buienradar
Beitrag 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.
Titel: Antw:59_Buienradar
Beitrag von: choenig am 29 Juli 2019, 09:39:02
Moin,

2.1.0/testing hat nun noch Fehlerhandling für "leeres" JSON bekommen. Ihr solltet eure controls von 2.1.0 auf testing (https://raw.githubusercontent.com/fhem/mod-Buienradar/testing/controls_Buienradar.txt) umstellen und ein Update machen.

Vielen Dank!

hab' upgedated. Soweit erstmal OK ... schauen wir, was heute nacht passiert  8)

LG
Christian
Titel: Antw:59_Buienradar
Beitrag von: inoma am 29 Juli 2019, 10:26:18
>> Antwort #34 << hat sich erledigt, es funktioniert jetzt mit dem update von heute morgen!

Danke Christoph!

Hallo,
bei der Benutzung des Moduls, bekomme ich immer folgende Fehlermeldung:
HTTP response code is not 200: 404
Titel: Antw:59_Buienradar
Beitrag von: mahowi am 29 Juli 2019, 14:12:35
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.

Wo liegt denn der Unterschied zwischen rainNow und rainAmount, bzw. auf welchen Zeitraum bezieht sich rainAmount?
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 29 Juli 2019, 14:29:11
Wo liegt denn der Unterschied zwischen rainNow und rainAmount, bzw. auf welchen Zeitraum bezieht sich rainAmount?

rainAmount ist der gesamte vorhergesagte Niederschlag im Vorhersagezeitraum, rainNow der vorhergesagte Niederschlag im jetzigen 5-Minuten-Abschnitt. Steht auch in der CommandRef, sogar zweisprachig ;-)
Titel: Antw:59_Buienradar
Beitrag von: mahowi am 29 Juli 2019, 15:59:02
Die Commandref kenne ich.  ;)

Zitat
    rainAmount - Menge des gemeldeten Niederschlags in mm/h.
    [...]
    rainMax - Die maximale Niederschlagsmenge in mm/h für ein 5 Min. Intervall auf Basis der vorliegenden Daten.
    rainNow - Die vorhergesagte Niederschlagsmenge für das aktuelle 5 Min. Intervall in mm/h.
    rainTotal - Die gesamte vorhergesagte Niederschlagsmenge in mm/h
Also rainNow für die jetzt und rainTotal für den gesamten Zeitraum. Für rainAmount steht aber nichts da.
Titel: Antw:59_Buienradar
Beitrag von: Papaloewe am 29 Juli 2019, 18:09:00
Habe gearde versucht auf "testing" umzustellen:

2019.07.29 18:07:54 1 : Buienradar
2019.07.29 18:07:54 1 : UPD FHEM/59_Buienradar.pm
2019.07.29 18:07:54 1 : Got 25387 bytes for FHEM/59_Buienradar.pm, expected 23162
2019.07.29 18:07:54 1 : aborting.
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 29 Juli 2019, 18:34:06
Die Commandref kenne ich.  ;)
Also rainNow für die jetzt und rainTotal für den gesamten Zeitraum. Für rainAmount steht aber nichts da.

Öh ganz oben?
Titel: Antw:59_Buienradar
Beitrag von: mahowi am 29 Juli 2019, 19:08:03
Ja klar, oben steht die Beschreibung.   :D  Aber vielleicht bin ich zu doof, sie zu verstehen.   ???

Zitat
rainAmount - Menge des gemeldeten Niederschlags in mm/h.
[...]
rainMax - Die maximale Niederschlagsmenge in mm/h für ein 5 Min. Intervall auf Basis der vorliegenden Daten.
rainNow - Die vorhergesagte Niederschlagsmenge für das aktuelle 5 Min. Intervall in mm/h.
rainTotal - Die gesamte vorhergesagte Niederschlagsmenge in mm/h

Wenn ich das richtig verstehe, gibt rainNow an, was die nächsten 5 Minuten runter kommt. rainMax, was maximal innerhalb von 5 Minuten im Vorhersagezeitraum kommt. rainTotal wäre dann die Menge über den gesamten Zeitraum der Vorhersage. Damit bleibt rainAmount übrig. Ist das die Menge innerhalb 1 Stunde, wie die Einheit vermuten lässt, oder in der Zeit zwischen rainBegin und rainEnd? Eigentlich macht die Einheit mm/h für 5-Minuten-Intervalle auch keinen Sinn, eher nur mm, was dann 1 l/mm^2 entspricht.

Sorry, wenn die Fragen vielleicht etwas blöd klingen. Leider hab ich auch keine Beschreibung der API gefunden,  sonst hätte ich da mal nachgelesen.

Edit: Hab jetzt mal genauer ins Modul geguckt (development, Zeile 667,668):
                ::readingsBulkUpdate( $hash, "rainTotal", sprintf( "%.3f", $rainTotal) );
                ::readingsBulkUpdate( $hash, "rainAmount", sprintf( "%.3f", $rainTotal) );
Demnach sind rainTotal und rainAmount identisch.
Titel: Antw:59_Buienradar
Beitrag von: inoma am 29 Juli 2019, 22:57:05
Hallo Christoph,
ich habe auf die Version 2.2.0 ge-updated, folgende Bebachtung / Fehlermeldung im state/STATE:

Die gleiche Fehlermeldung bekomme ich auch wenn ich region 'nl' einstelle, und die Koordinaten in den Niederlanden liegen.
Mit der Version 2.1.0 hat alles problemlos funktioniert. Hier das list und der Json-String.

Internals:
   CHANGED   
   DEF        48.1234 11.1234
   FUUID      ddddddd-aaaa-bbbb-cccc-bc78f1f69daf123a
   INTERVAL   300
   LATITUDE   48.1690
   LONGITUDE  11.5941
   NAME       Buienradar
   NEXTUPDATE 2019-07-29 22:52:16
   NR         4766
   REGION     de
   STATE      Got JSON but buienradar.nl has some troubles delivering meaningful data!
   TYPE       Buienradar
   URL        https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=48.1234&lon=11.1234&region=de&unit=mm/u
   VERSION    2.2.0
   READINGS:
     2019-07-29 22:49:30   rainAmount      unknown
     2019-07-29 22:49:30   rainBegin       unknown
     2019-07-29 22:49:30   rainData        unknown
     2019-07-29 22:49:30   rainDataEnd     unknown
     2019-07-29 22:49:30   rainDataStart   unknown
     2019-07-29 22:49:30   rainEnd         unknown
     2019-07-29 22:49:30   rainLaMetric    unknown
     2019-07-29 22:49:30   rainMax         unknown
     2019-07-29 22:49:30   rainNow         unknown
     2019-07-29 22:49:30   rainTotal       unknown
     2019-07-29 22:49:30   state           Got JSON but buienradar.nl has some troubles delivering meaningful data!
Attributes:
   disabled   off
   event-on-change-reading rainBegin
   interval   300
   region     de
   room       Weather

{"success":true,"start":1564433100,"start_human":"22:45","temp":15,"delta":300,"precip":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"levels":{"light":0.25,"moderate":1,"heavy":2.5},"grid":{"x":915,"y":813},"source":"de","bounds":{"N":56.123456,"E":18.123456,"S":45.123456,"W":3.123456}}
Titel: Antw:59_Buienradar
Beitrag von: choenig am 30 Juli 2019, 08:38:14
Habe gearde versucht auf "testing" umzustellen:

2019.07.29 18:07:54 1 : Buienradar
2019.07.29 18:07:54 1 : UPD FHEM/59_Buienradar.pm
2019.07.29 18:07:54 1 : Got 25387 bytes for FHEM/59_Buienradar.pm, expected 23162
2019.07.29 18:07:54 1 : aborting.

Das selbe bekomme ich auch, nachdem ich dem angegebenen Link gefolgt bin ("testing") und nicht den aus dem 1. Post genommen habe ("release/testing").

Update hat bislang nicht geklappt.
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 30 Juli 2019, 14:28:41
Ich publiziere meinen Code nur in Kopie auf Github. Irgendwas hat bei der Übertragung dorthin wohl nicht geklappt.
Die controls habe ich aktualisiert, dauert ein bisschen bis sie aus dem Cache bei Github raus ist. Dann sollte es klappen.
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 30 Juli 2019, 15:56:55
Hallo Christoph,
ich habe auf die Version 2.2.0 ge-updated, folgende Bebachtung / Fehlermeldung im state/STATE:

Ich hab mir die Def gerade mal selbst angelegt und kann das nicht reproduzieren. Ist das Verhalten bei dir noch so?
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 30 Juli 2019, 16:08:40
Ja klar, oben steht die Beschreibung.   :D  Aber vielleicht bin ich zu doof, sie zu verstehen.   ???

Wenn ich das richtig verstehe, gibt rainNow an, was die nächsten 5 Minuten runter kommt. rainMax, was maximal innerhalb von 5 Minuten im Vorhersagezeitraum kommt. rainTotal wäre dann die Menge über den gesamten Zeitraum der Vorhersage. Damit bleibt rainAmount übrig. Ist das die Menge innerhalb 1 Stunde, wie die Einheit vermuten lässt, oder in der Zeit zwischen rainBegin und rainEnd? Eigentlich macht die Einheit mm/h für 5-Minuten-Intervalle auch keinen Sinn, eher nur mm, was dann 1 l/mm^2 entspricht.


Da hast du wirklich einen Bug entdeckt, hab ich gar nicht weiter drüber nachgedacht. Leider gibt es dazu, wie du schon geschrieben hast, wohl keine Doku, denn nur Niederschlagsdaten soll man gar nicht selbst beziehen können, sondern nur die Stationsdaten (https://data.buienradar.nl/2.0/feed/json). Insofern muss ich mir das mit den Einheiten noch mal überlegen.

Gefixt in testing & development.
Titel: Antw:59_Buienradar
Beitrag von: inoma am 30 Juli 2019, 18:07:30
Zitat
Zitat von: inoma am Gestern um 22:57:05
Hallo Christoph,
ich habe auf die Version 2.2.0 ge-updated, folgende Bebachtung / Fehlermeldung im state/STATE:

Ich hab mir die Def gerade mal selbst angelegt und kann das nicht reproduzieren. Ist das Verhalten bei dir noch so?

Hallo Christoph,
ja, das Verhalten ist immer noch so, ich habe sowohl lat/lon koordinaten in NL mit region=nl, in Hamburg und München mit region=de getestet.

Kann ich helfen, das einzugrenzen? Der JSON String scheint ok zu sein, die Fehlermeldung kommt ja aus dem Buienradar Modul selbst, aber ich kann nicht sehen wieso die Daten nicht meaningful sein sollen. Das einzige was mir aufgefallen ist, ist das die Human readable time (start_human":"22:45) vor der aktuellen Zeit liegt. Keine Ahnung
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 30 Juli 2019, 18:09:08
Kann ich helfen, das einzugrenzen? Der JSON String scheint ok zu sein, die Fehlermeldung kommt ja aus dem Buienradar Modul selbst, aber ich kann nicht sehen wieso die Daten nicht meaningful sein sollen. Das einzige was mir aufgefallen ist, ist das die Human readable time (start_human":"22:45) vor der aktuellen Zeit liegt. Keine Ahnung

Auf jeden Fall. Poste mal bitte lists von jedem Device (einzeln).
Titel: Antw:59_Buienradar
Beitrag von: inoma am 30 Juli 2019, 19:26:59
Hallo Christoph,
hier das list mit der location Hamburg, und der JSON string dazu. Ich habe aber nur 1 device, was meintest Du mit "lists von jedem Device (einzeln)."

 Internals:
   CHANGED   
   DEF        53.737011 10.144003
   FUUID      5d39f59a-f33f-97bf-f0a3-ec67f1f68daf307e
   INTERVAL   120
   LATITUDE   53.737011
   LONGITUDE  10.144003
   NAME       Buienradar
   NEXTUPDATE 2019-07-30 19:25:31
   NR         4766
   REGION     de
   STATE      Got JSON but buienradar.nl has some troubles delivering meaningful data!
   TYPE       Buienradar
   URL        https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=53.737011&lon=10.144003&region=de&unit=mm/u
   VERSION    2.2.0
   READINGS:
     2019-07-30 19:23:31   rainAmount      unknown
     2019-07-30 19:23:31   rainBegin       unknown
     2019-07-30 19:23:31   rainData        unknown
     2019-07-30 19:23:31   rainDataEnd     unknown
     2019-07-30 19:23:31   rainDataStart   unknown
     2019-07-30 19:23:31   rainEnd         unknown
     2019-07-30 19:23:31   rainLaMetric    unknown
     2019-07-30 19:23:31   rainMax         unknown
     2019-07-30 19:23:31   rainNow         unknown
     2019-07-30 19:23:31   rainTotal       unknown
     2019-07-30 19:23:31   state           Got JSON but buienradar.nl has some troubles delivering meaningful data!
Attributes:
   disabled   off
   event-on-change-reading rainBegin
   interval   300
   region     de
   room       Weather

{"success":true,"start":1564506300,"start_human":"19:05","temp":24,"delta":300,"precip":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"levels":{"light":0.25,"moderate":1,"heavy":2.5},"grid":{"x":687,"y":194},"source":"de","bounds":{"N":56.397869,"E":18.257635,"S":45.506641,"W":3.454513}}
Titel: Antw:59_Buienradar
Beitrag von: inoma am 30 Juli 2019, 19:54:17
Hallo Christoph,
In Zeile 921 if ($forecast_data->{'success'} ne "true") { durch 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?

Danke!
Titel: Antw:59_Buienradar
Beitrag von: mahowi am 30 Juli 2019, 20:45:17
Im development Branch ist ein Fehler drin, das Modul lädt nicht:
2019.07.30 20:39:05.947 1: PERL WARNING: Bareword found where operator expected at ./FHEM/59_Buienradar.pm line 669, near "kk
                ::readingsBulkUpdate"
2019.07.30 20:39:05.948 1: stacktrace:
2019.07.30 20:39:05.948 1:     main::__ANON__                      called by ./FHEM/59_Buienradar.pm (669)
2019.07.30 20:39:05.948 1:     (eval)                              called by fhem.pl (2605)
2019.07.30 20:39:05.948 1:     (eval)                              called by fhem.pl (2604)
2019.07.30 20:39:05.948 1:     main::CommandReload                 called by fhem.pl (1236)
2019.07.30 20:39:05.949 1:     main::AnalyzeCommand                called by fhem.pl (1089)
2019.07.30 20:39:05.949 1:     main::AnalyzeCommandChain           called by ./FHEM/01_FHEMWEB.pm (2678)
2019.07.30 20:39:05.949 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (951)
2019.07.30 20:39:05.949 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (578)
2019.07.30 20:39:05.949 1:     main::FW_Read                       called by fhem.pl (3753)
2019.07.30 20:39:05.949 1:     main::CallFn                        called by fhem.pl (748)
2019.07.30 20:39:05.949 1: PERL WARNING:        (Do you need to predeclare kk?)
2019.07.30 20:39:05.950 1: stacktrace:
2019.07.30 20:39:05.950 1:     main::__ANON__                      called by ./FHEM/59_Buienradar.pm (669)
2019.07.30 20:39:05.950 1:     (eval)                              called by fhem.pl (2605)
2019.07.30 20:39:05.950 1:     (eval)                              called by fhem.pl (2604)
2019.07.30 20:39:05.950 1:     main::CommandReload                 called by fhem.pl (1236)
2019.07.30 20:39:05.950 1:     main::AnalyzeCommand                called by fhem.pl (1089)
2019.07.30 20:39:05.951 1:     main::AnalyzeCommandChain           called by ./FHEM/01_FHEMWEB.pm (2678)
2019.07.30 20:39:05.951 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (951)
2019.07.30 20:39:05.951 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (578)
2019.07.30 20:39:05.951 1:     main::FW_Read                       called by fhem.pl (3753)
2019.07.30 20:39:05.951 1:     main::CallFn                        called by fhem.pl (748)

In Zeile 668 ist Dir wohl irgendwie ein "kk" hinter die Zeile geraten:
                ::readingsBulkUpdate( $hash, "rainTotal", sprintf( "%.3f", $rainTotal) );kk
Titel: Antw:59_Buienradar
Beitrag von: inoma am 30 Juli 2019, 20:45:43
Hallo Christoph,
wie lautet denn der Aufruf, um den gChart zu erzeugen? Ein 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.

Titel: Antw:59_Buienradar
Beitrag von: mahowi am 30 Juli 2019, 20:55:22
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.
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 30 Juli 2019, 20:56:32
In Zeile 668 ist Dir wohl irgendwie ein "kk" hinter die Zeile geraten:

https://www.youtube.com/watch?v=y6OOdeEM1sU
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 30 Juli 2019, 21:01:46
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 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.
Titel: Antw:59_Buienradar
Beitrag von: mahowi am 30 Juli 2019, 21:08:56
https://www.youtube.com/watch?v=y6OOdeEM1sU
Das kenne ich.  ;D

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.
Titel: Antw:59_Buienradar
Beitrag von: inoma am 30 Juli 2019, 21:11:40
Hallo Christoph, hattest Du das gelesen?
Zitat

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?
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 30 Juli 2019, 21:27:40
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.
Titel: Antw:59_Buienradar
Beitrag von: inoma am 01 August 2019, 12:40:18
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
Titel: Antw:59_Buienradar
Beitrag von: Gisbert am 01 August 2019, 18:27:09
Hallo Christoph,

ich hab gerade das update auf:
Zitat
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
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 01 August 2019, 18:35:23
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.
Titel: Antw:59_Buienradar
Beitrag von: Gisbert am 01 August 2019, 18:42:32
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
Titel: Antw:59_Buienradar
Beitrag von: choenig am 01 August 2019, 22:09:24
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
Titel: Antw:59_Buienradar
Beitrag von: Gisbert am 01 August 2019, 22:50:27
Zitat
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.

Zitat
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​
Titel: Antw:59_Buienradar
Beitrag von: choenig am 01 August 2019, 22:52:35
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
Titel: Antw:59_Buienradar
Beitrag von: Gisbert am 02 August 2019, 07:57:16
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​
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 02 August 2019, 10:25:04
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.
Titel: Antw:59_Buienradar
Beitrag von: inoma am 02 August 2019, 11:25:28
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.
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!
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 02 August 2019, 14:50:23
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.
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.
Titel: Antw:59_Buienradar
Beitrag von: inoma am 02 August 2019, 19:20:52
Zitat
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));
}
Titel: Antw:59_Buienradar
Beitrag von: somansch am 03 August 2019, 19:50:21
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
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 04 August 2019, 13:28:53
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
Titel: Antw:59_Buienradar
Beitrag von: somansch am 04 August 2019, 13:35:42
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 (https://wiki.fhem.de/wiki/FTUI_Widget_Chart#LogProxy)

Viele Grüße
Andreas
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 05 August 2019, 13:00:38
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 (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?
Titel: Antw:59_Buienradar
Beitrag von: mahowi am 05 August 2019, 14:00:22
Kann man nicht einfach ein Log-Device anlegen und sich rainAmount (und ggfs. noch andere Werte) in ein Logfile schreiben lassen?
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 05 August 2019, 14:26:39
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.
Titel: Antw:59_Buienradar
Beitrag von: inoma am 05 August 2019, 21:13:31
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
Titel: Antw:59_Buienradar
Beitrag 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.
Titel: Antw:59_Buienradar
Beitrag von: Gisbert am 05 August 2019, 22:15:26
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.
Titel: Antw:59_Buienradar
Beitrag von: inoma am 05 August 2019, 23:08:44
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 !
Titel: Antw:59_Buienradar
Beitrag von: mahowi am 06 August 2019, 18:25:54
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.
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 06 August 2019, 21:47:25
rainNow scheint nicht den aktuellen Regen anzuzeigen sondern den der ersten Periode ungleich 0.

⇒ Issue #2 (https://github.com/fhem/mod-Buienradar/issues/2)
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 06 August 2019, 21:49:10
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 (https://github.com/fhem/mod-Buienradar/issues/3)
Titel: Antw:59_Buienradar
Beitrag von: inoma am 07 August 2019, 19:43:57
Hallo Christoph,
anbei ein Patch, wo ich folgendes mal geändert habe. Spart Dir evtl. Arbeit.
- rainNow ist auf das erste Intervall gesetzt
- rainAmount ist die Regen Menge in der erste Stunde, also l/qm
- rainEnd ist korrigiert, falls es mehrer RegenIntervalle gibt (also zwischendurch mal kein Regen). Für den Fall das es am Ende auch noch regnet, ist rainEnd auf das letzte Interval gesetzt
- Rainduration wird berechnet, einmal als HH:MM und auch in Minuten
- Ich hatte gesehen das die Intervalle manchmal vor der jetzigen Zeit anfangen, updates also nur für Zeiträume > TimeNow()
- Formatierung auf %.1f geändert (alle Webseiten geben auch nur Regen in mm auf 1 Stelle genau aus)
- Versionsnummer nur zur Unterscheidung auf 2.2.4 geändert

Hab versucht das als private e-mail zu schicken, aber da kann ich keinen Anhang machen. Viell kanbst Du es gebrauchen.

Danke für das Modul, das ist echt klasse!
Titel: Antw:59_Buienradar
Beitrag von: mahowi am 08 August 2019, 07:41:47
Ich habe für inomas Version mal einen Pull Request auf Github gemacht.
Titel: Antw:59_Buienradar
Beitrag von: eurofinder am 08 August 2019, 19:11:25
Gibt es eine Möglichkeit sich die Werte chartData in einer Grafik so anzeigen zu lassen, dass die X-Achse die Zeitachse und die Y-Achse die Regenmenge als Säulen darstellt, die dann nach der Intervall-Zeit aktualisiert wird?

Bin da leider noch nicht so bewandert, was SVG-Plots angeht.

Gruß und danke für das Modul
eurofinder
Titel: Antw:59_Buienradar
Beitrag von: inoma am 09 August 2019, 00:39:55
Hallo Christoph,
ich habe nochmal ein bischen gebastelt:
Anbei ein weiterer Patch, wo ich folgendes mal geändert habe.
- Doku angepasst sowohl in Deutsch als auch Englisch
- Support für HTML "BAR" Chart, wie auch bei RainTMC, aufruf mit { FHEM::Buienradar::BAR("Name des Buienradar device")}
- Readings 'Start' und 'Ende' -> 'Begin' und 'End'
- zusätzliches Interval 600
- disable 0/1 wählbar
- Einige kleine Änderungen/Anpassungen
- Versionsnummer nur zur Unterscheidung auf 2.2.5 geändert

Bitte nicht falsch verstehen, ich möchte einfach nur beitragen, anstatt einfach immer nur nach Änderungen zu fragen.

Für das "BAR" Chart, verwendet das RainTMC modul $a->{ColorAsRGB}, ich habe damit aber immer eine Fehlermeldung bekommen. Wel das nicht funktioniert hat, habe ich jetzt stattdessen eine Sub raus gemacht, also in Zeile 752 und 757 eine Sub myPrecip2RGB($a) eingebaut. Die Sub ist im modul. Wenn Du Dir das mal angucken magst?

Danke und Beste Grüsse
Titel: Antw:59_Buienradar
Beitrag von: mahowi am 09 August 2019, 10:13:14
Hallo inoma,

ich hab mit Deiner Version noch einen Fehler:
2019.08.09 10:05:08.248 1: PERL WARNING: Argument "unknown" isn't numeric in localtime at ./FHEM/59_Buienradar.pm line 811.
2019.08.09 10:05:08.248 1: stacktrace:
2019.08.09 10:05:08.249 1:     main::__ANON__                      called by ./FHEM/59_Buienradar.pm (811)
2019.08.09 10:05:08.249 1:     FHEM::Buienradar::ParseHttpResponse called by FHEM/HttpUtils.pm (609)
2019.08.09 10:05:08.249 1:     main::__ANON__                      called by fhem.pl (745)
Dadurch wurden mir Räume mit Buienradar-Device nicht mehr angezeigt.  ???
Titel: Antw:59_Buienradar
Beitrag von: inoma am 09 August 2019, 10:18:36
Bitte diese hier angehängte Version nehmen, oben in der Version im Post #93 war doch noch ein Fehler drin. Sag kurz Bescheid ob es geht.
Titel: Antw:59_Buienradar
Beitrag von: mahowi am 09 August 2019, 11:04:10
Danke. Jetzt funktioniert wieder alles ohne Fehlermeldungen.

[Edit]In der letzten Version ist noch eine Klammer zuviel in Zeile 811:
syntax error at ./FHEM/59_Buienradar.pm line 811, near "))"
Nachdem ich das korrigiert habe, funktioniert es wieder.

Pull request: https://github.com/fhem/mod-Buienradar/pull/6
Titel: Antw:59_Buienradar
Beitrag von: inoma am 09 August 2019, 11:30:48
In der tat, sorry, habs korrigiert, neue Version anbei.
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 09 August 2019, 12:30:49
Vielen Dank für den PR. Ich schau ihn mir an sobald ich Zeit habe und merge ihn sobald ich alle Änderungen nachvollzogen habe.
Titel: Antw:59_Buienradar
Beitrag von: inoma am 09 August 2019, 13:23:35
Meinen Dank an Dich und User mahowi!
Titel: Antw:59_Buienradar
Beitrag von: somansch am 10 August 2019, 14:41:38
Ich habe heute auf die letzte Version (2.2.5) aktualisiert. Dabei ist mir aufgefallen, dass das Reading "chartData" nicht mehr aktualisiert wird.

Dies hat mich auf meine ursprüngliche Anforderung bezüglich Darstellung der Daten in einem SVG bzw. FTUI Chart gebracht. Der LogProxy bringt im Moment leider nichts, da dort ja nur ein Wert zurückgegeben wird. Ich habe das mal mit der LogProxy-Lösung für ProPlanta verglichen. Dort ist es auch so, jedoch werden über eine Funktion in der "myUtils" aus den Vorhersage-Readings des ProPlanta die Daten für ein Chart übersetzt. Im Buienradar gibt es jedoch keine einzelnen Vorhersage-Readings.

Gibt es eine Möglichkiet, die aktuellen Daten in ein logFile zu schreiben und die dortigen Daten jedesmal zu überschreiben? Sinnvoll wäre die Bereitstellung pro Zeile im Format (laut Wiki: https://wiki.fhem.de/wiki/Plots_erzeugen (https://wiki.fhem.de/wiki/Plots_erzeugen):

JJJJ-MM-TT_SS:mm:ss Regenmenge

Somit könnten dann Plots und Charts je nach Geschmack und Bedarf erzeugt werden  ;).

Ich bin kein Entwickler, aber vielleicht könnten ihr ja so eine Logfunktion einbauen?

Viele Grüße
Andreas
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 10 August 2019, 15:22:55
Ich habe heute auf die letzte Version (2.2.5) aktualisiert. Dabei ist mir aufgefallen, dass das Reading "chartData" nicht mehr aktualisiert wird.

Richtig, denn die Daten stehen nun - so wie es sein sollte - in einem Internal, gespeichert als Storable. Das chartData-Reading kannst du löschen.

Dies hat mich auf meine ursprüngliche Anforderung bezüglich Darstellung der Daten in einem SVG bzw. FTUI Chart gebracht. Der LogProxy bringt im Moment leider nichts, da dort ja nur ein Wert zurückgegeben wird. Ich habe das mal mit der LogProxy-Lösung für ProPlanta verglichen. Dort ist es auch so, jedoch werden über eine Funktion in der "myUtils" aus den Vorhersage-Readings des ProPlanta die Daten für ein Chart übersetzt. Im Buienradar gibt es jedoch keine einzelnen Vorhersage-Readings.

Das hab ich auch gedacht, aber ich hatte mich geirrt: LogProxy liefert, wenn man die Funktion einfach nur in der Kommandozeile aufruft, nur einen Wert zurück, richtig. Aber wenn es als Logproxy-Device benutzt wird, liefert es deutlich mehr. Ruf FHEM::Buienradar::Logproxy mal mit Data::Dumper auf, dann siehst du den Unterschied:

{ use Data::Dumper;; Dumper(FHEM::Buienradar::LogProxy("name deines Buienradar-Devices"));; }
JJJJ-MM-TT_SS:mm:ss Regenmenge

Genau das liefert FHEM::Buienradar::LogProxy im Listenkontext auch zurück.
Titel: Antw:59_Buienradar
Beitrag von: inoma am 10 August 2019, 21:16:25
Hallo Christoph,
ich habe noch eine kleine Verbesserung, um den rainAmount 'richtiger' zu berechnen, also für den jetzt aktuellen Zeitraum von einer Stunde (weil Buienradar ja manchmal den Zeitraum von 10 oder 15 Minuten vor der aktuellen Zeit anzeigt). Dann folgende Zeile
my $rainAmount      = List::Util::sum @precip[0..11]; durch my $rainAmount      = 0; ersetzen, und dann über der Zeile 1181, also bevor count erhöht wird (über $count++;) folgendes einfügen if ($count < 12) { $rainAmount = $rainAmount + $precip;}Damit wird dann der rainAmount aus den aktuellen 12 Intervallen ab 'TimeNow()' berechnet.

Grüsse!
Titel: Antw:59_Buienradar
Beitrag von: somansch am 15 August 2019, 14:16:46
...Aber wenn es als Logproxy-Device benutzt wird, liefert es deutlich mehr. Ruf FHEM::Buienradar::Logproxy mal mit Data::Dumper auf, dann siehst du den Unterschied:

{ use Data::Dumper;; Dumper(FHEM::Buienradar::LogProxy("name deines Buienradar-Devices"));; }
Genau das liefert FHEM::Buienradar::LogProxy im Listenkontext auch zurück.

Ich habe heute mal versucht per LogProxy die Daten in einen SVG Plot in FHEM zu bekommen, jedoch erschliesst sich mir nicht, an welcher Stelle "FHEM::Buienradar::LogProxy" einzutragen ist. Hat jemand eine funktionierende gplot-Datei?
Titel: Antw:59_Buienradar
Beitrag von: inoma am 18 August 2019, 18:12:48
Hallo Christoph,
kurze Rückmeldung:
1) Das Buienradar funktioniert südlich in Deutschland bis kurz vor Garmisch Partenkirchen, weiter südlich kommen keine Daten mehr.

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

Beste Grüsse
Titel: Antw:59_Buienradar
Beitrag von: mahowi am 18 August 2019, 20:09:27
Wenn ich den Code richtig lese, wird jedes Kommando verhindert, wenn keine Wert für "disabled" angegeben wird:

    given ($attribute_name) {
        when ('disabled') {
            Debugging(
                Dumper (
                    {
                        'attribute_value' => $attribute_value,
                        'attr' => 'disabled',
                        "command" => $command,
                    }
                )
            );

            return "${attribute_value} is no valid value for disabled. Only 'on', '1', '0' or 'off' are allowed!"
                if $attribute_value !~ /^(on|off|0|1)$/;

            given ($command) {
[...]
Da bei fehlendem oder falschem Wert sofort mit der Fehlermeldung zurückgesprungen wird, wird das Kommando zum Löschen nie ausgeführt.
Titel: Antw:59_Buienradar
Beitrag von: mahowi am 18 August 2019, 20:25:51
Ich habe die Überprüfung jetzt bei mir im Github hinter das "set" geschoben. Jetzt wird der Wert nur beim Setzen des Attributs geprüft.
            given ($command) {
                when ('set') {
               
                return "${attribute_value} is no valid value for disabled. Only 'on', '1', '0' or 'off' are allowed!"
                if $attribute_value !~ /^(on|off|0|1)$/;

Solange Christoph den PR noch nicht übernommen hat, kann man auf die Version mit inomas Patches mit
update all https://raw.githubusercontent.com/mahowi/mod-Buienradar/2.2.5/controls_Buienradar.txtupdaten.
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 18 August 2019, 21:11:51
Ich hab' mir für diese Woche ein bisschen mehr Zeit für Buienradar eingeplant (und für FHEM allgemein). Denke ich komme morgen dazu mir die gesammelten Sachen anzuschauen und zu mergen.
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 19 August 2019, 13:43:38
Hallo Christoph,
kurze Rückmeldung:
1) Das Buienradar funktioniert südlich in Deutschland bis kurz vor Garmisch Partenkirchen, weiter südlich kommen keine Daten mehr.

Siehe Issue 8 (https://github.com/fhem/mod-Buienradar/issues/8). Ich bekomme durchaus auch Daten für Innsbruck - und das liegt ja bekanntlich südlich von G-P. Bozen z.B. ist dann out of coverage.
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 19 August 2019, 13:44:30
2) Wenn man ein "deleteattr Buienradar disabled" eingibt (oder im Webinterface das attribut disabled löscht), kommt folgende Fehlermeldung:
is no valid value for disabled. Only 'on', '1', '0' or 'off' are allowed!

Issue #7 (https://github.com/fhem/mod-Buienradar/issues/7) fixed in 2.2.4
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 19 August 2019, 13:50:31
Ich habe heute auf die letzte Version (2.2.5) aktualisiert. Dabei ist mir aufgefallen, dass das Reading "chartData" nicht mehr aktualisiert wird.

Achtung, das ist nicht die offizielle Version des Moduls. Wenn du über mahowis 2.2.5 sprechen möchtest, dann mach bitte einen neuen Thread auf.
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 19 August 2019, 14:00:17
Solange Christoph den PR noch nicht übernommen hat, kann man auf die Version mit inomas Patches mit
update all https://raw.githubusercontent.com/mahowi/mod-Buienradar/2.2.5/controls_Buienradar.txtupdaten.

Das seht dir natürlich frei, ist ja open source. Allerdings haben eure Versionen die ihr hier hochladet dazu geführt, dass nun verschiedene Versionen von Buienradar verwendet werden (z.B. von somansch).

Wirklich helfen könnt ihr mir indem:
- Am besten das Github-Repository nutzen - und auch nur Github - um Code mit mir zu teilen. Wenn ihr hier Versionen der 59_Buienradar.pm hochladet motiviert das Nutzer dazu, diese runterzuladen und am Ende haben wir verschiedene Versionen im Umlauf für die ich keinen Support geben kann bzw. Support komplizierter macht weil es irgendwann auch eine offiziöse 2.2.5 geben wird und dann weiß keiner von welcher Version wir reden.
-  Einzelne Features in einzelnen Feature-Branches entwickelt und dann für einzelne Features auch einzelne Pull-Requests erstellt. Ich hab jetzt einen recht umfangreichen PR von mahowi bekommen über den ich mich eigentlich freue, aber der mich auch vor ein paar Probleme stellt: Ich möchte nicht alle Sachen übernehmen (z.B. die Dokuanpassung für disabled oder den konkreten Code für den Bar-Chart), aber ich kann nun nur recht beschwerlich die Sachen mergen, d.h. ich schaue mir die nun einzeln an und übernehme die doch wieder manuell (oder halt nicht). Mir ist klar, dass die Arbeit mit Branches, Pull Requests und Co. eher ungewohnt sind. Wenn man das aber konsequent sauber macht, kann man wirklich große Vorteile daraus ziehen.
- Issues direkt bei Github anlegt wenn ihr einen Account habt (kostet ja nix, kann man sich schon mal anlegen). Sonst mache ich hier wildes Kreuzverlinken und Copy/Paste mit dem Forum.

Viele Dank insbesondere an mahowi und inoma. Auch wenn ich nicht alle Ideen / Wünsche teile.
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 19 August 2019, 16:44:35
Laut Google Wiki ist "Rainamount" die RegenMenge, die in einem definierten Zeitraum fällt,

Was ist denn Google Wiki? Im Kontext von Buienradar ist rainAmount einfach nur die Regenmenge, die im nächsten 5-Minuten-Intervall gemeldet ist. Das Naming ist vielleicht nicht super, aber das war in der Originalversion schon so und ich möchte das in einer 2er-Version nicht ändern. Ich nehme mir das aber mal für eine kommende 3.0 mit. Allgemein sind solche Kontextänderungen besonders kniffelig zu releasen, denn man löscht den Datenpunkt ja nicht (in dem man ihn z.B. umbenennt), sondern ändert nur seine Bedeutung. Ein hypothetischer Nutzer der eine Logik darauf gebaut hat, dass rainAmount den Niederschlag im nächsten 5-Minuten-Intervall beinhaltet, würde das nun ohne weitere Notiz weggeändert bekommen. Das sollte ein User innerhalb einer major version nicht erwarten müssen.

Ein kurzer Exkurs zu den Versionen:
Ich benutze (wie viele andere FHEM-(Modul)-Entwickler) Semantic Versioning (https://semver.org/). Das Summary in dem Link sagt schon ganz gut, warum LuBeDas Version die 1 und meine Version jetzt die 2 ist, denn ich habe in der 2 ein paar Änderungen gemacht, die die API auf das Modul geändert haben (z.B. habe ich den Namensraum auf FHEM::Buienradar geändert und damit alle Integrationen von Google Charts / HTML-Graph). D.h. jeder der die 1er-Version im Einsatz hat, hat nach einem Update auf die 2er defekte Definitionen in seinem FHEM (kurze geistige Pause um die Tragweite davon zu verdeutlichen). Die 2.1 und 2.2 sind minor versions, d.h. zusammengepackte Feature-Changes. 2.2.x ist dann ein Bugfix an der minor-Version (z.B. 2.2.1 ist der erste Bugfix an 2.2). Das mit den Bugfixes habe ich bisher nicht wirklich verfolgt, ist aber geplant.
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 19 August 2019, 19:27:01
Fehlerhafte Berechnung von rainNow in 2.1 und 2.2 gefixt. Beide finden sich nun in eigene Branches. Development existiert nicht mehr.
Titel: Antw:59_Buienradar
Beitrag von: inoma am 19 August 2019, 22:43:05
Hallo Christoph,
ich habe jetzt noch nicht nicht nachgeguckt wie Du das 'RainAmount' gefixt hast.
Aber ein offener Punkt war doch der fehlende Unterschied zwischen 'rainNow' und rainAmount', die in den ursprünglichen Versionen beide den gleichen Wert geliefert haben, also den Wert für die Regenmenge in den nächsten 5 Minuten.
Deswegen mein Vorschlag, nach Google, rainAmount als die Regenmenge l/qm oder mm/h zu berechnen, und rainNow zu belassen. Das ist meiner Internet Suche der Standard um Regenmengen zu vergleichen. Ich habe immer nur für Regenmenge = RainAmount 1) Werte in mm/h (also Liter/qm), ODER 2) die Tagessumme (Tägliche Niederschlagsmenge) gefunden.

1) https://www.wetter.com/wetterkarten/niederschlagsmengen/niederschlagsmengen-bayern/#geo:49.0000,11.5000,7
2) https://www.wetter.com/deutschland/muenchen/DE0006515.html#niederschlag
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 19 August 2019, 23:30:51
Hallo inoma,

ich habe jetzt noch nicht nicht nachgeguckt wie Du das 'RainAmount' gefixt hast.

In der 2.x wird das noch gar nicht gefixt werden, denn das würde die API für die Benutzer ändern und kommt deshalb in die 3.x (mit ein paar weiteren Änderungen an den Readings, insb. Änderungen im Naming der Readings). Ich denke ich werde mich an deiner / eurer Version orientieren.

Aber ein offener Punkt war doch der fehlende Unterschied zwischen 'rainNow' und rainAmount', die in den ursprünglichen Versionen beide den gleichen Wert geliefert haben, also den Wert für die Regenmenge in den nächsten 5 Minuten.
Deswegen mein Vorschlag, nach Google, rainAmount als die Regenmenge l/qm oder mm/h zu berechnen, und rainNow zu belassen. Das ist meiner Internet Suche der Standard um Regenmengen zu vergleichen. Ich habe immer nur für Regenmenge = RainAmount 1) Werte in mm/h (also Liter/qm), ODER 2) die Tagessumme (Tägliche Niederschlagsmenge) gefunden.

1) https://www.wetter.com/wetterkarten/niederschlagsmengen/niederschlagsmengen-bayern/#geo:49.0000,11.5000,7
2) https://www.wetter.com/deutschland/muenchen/DE0006515.html#niederschlag

Ich nehme das mal mit 'rüber zu Github und meditiere darüber.

Für die 2er wird's wohl nur noch ein paar kleinere Features wie rainDuration und zwei neue Charts geben (fügen der API was hinzu, was keine Kompatibilität bricht, also ist's in einer minor version ok).
Titel: Antw:59_Buienradar
Beitrag von: inoma am 20 August 2019, 00:00:27
Danke! Nur zur Info, hier mal ein Screenshot vom 'BAR', im direkten Vergleich von Buienradar und RainTMC.
Der Regen soll etwa um 1:10 anfangen, laut den Radarbildchen.
Mein Eindruck ist, Buienradar ist etwas akurater, dafür ist der Vorhersagezeitraum kürzer (2 Stunden), RainTMC hat etwa 3 Stunden.

Ich benutze das "dark" Theme von FHEMWEB, ich finde die 'BAR' Darstellung am übersichtlichsten, weil platzsparend, und ich will nur wissen ob es regnet, wenn ja, dann ob schwach/wenig/mittel/stark/heftig, und das ist über die Farben optisch gut dargestellt.
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 20 August 2019, 11:09:50
rainEnd und das Problem mit disabled sind nun in 2.x gefixt.
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 20 August 2019, 11:11:23
Danke! Nur zur Info, hier mal ein Screenshot vom 'BAR', im direkten Vergleich von Buienradar und RainTMC.
Der Regen soll etwa um 1:10 anfangen, laut den Radarbildchen.
Mein Eindruck ist, Buienradar ist etwas akurater, dafür ist der Vorhersagezeitraum kürzer (2 Stunden), RainTMC hat etwa 3 Stunden.

Ich benutze das "dark" Theme von FHEMWEB, ich finde die 'BAR' Darstellung am übersichtlichsten, weil platzsparend, und ich will nur wissen ob es regnet, wenn ja, dann ob schwach/wenig/mittel/stark/heftig, und das ist über die Farben optisch gut dargestellt.

Gefällt mir. Wie hast du das mit dem Picker rechts (AtHome) bei Buienradar realisiert?
Titel: Antw:59_Buienradar
Beitrag von: Christoph Morrison am 20 August 2019, 12:07:31
Ich hab jetzt die 2.3 (https://github.com/fhem/mod-Buienradar/tree/release/2.3) begonnen. Hier seht ihr was geplant ist / gemacht wurde (https://github.com/fhem/mod-Buienradar/issues?utf8=%E2%9C%93&q=is%3Aissue+milestone%3A2.3+).
Titel: Antw:59_Buienradar
Beitrag von: inoma am 20 August 2019, 13:05:36
Zitat
Gefällt mir. Wie hast du das mit dem Picker rechts (AtHome) bei Buienradar realisiert?

Hier mal die Raw definitionen.
Der 'Picker' ist ein einfach ein 'widgetOverride Location'  beim Buienradar_bar. Dann ein notify auf ein change von Location, um die Lat/Lon Koordinaten zu ändern.
Wenn der Location Picker auf 'Location-iPhone' gestellt ist, hole ich mir die aktuellen Koordinaten von owntracks auf dem iPhone, über MQTT (notify auf eine koordinatenändrung). Dann eine Push Notification (Pushover), sobald der Rainbegin von unknown auf eine Anfangszeit geht. Beim Radfahren ganz nützlich.

Zusätzlich zum Buienradar_bar, habe ich auch noch den Buienradar state über stateformat formatiert und verschiedenfarbig gemacht, abhängig von der Regenmenge.

defmod Buienradar Buienradar 48.1234 11.1234
attr Buienradar alias Regenradar
attr Buienradar disabled 0
attr Buienradar event-on-change-reading rainAmount,rainBegin,rainNow
attr Buienradar ALARME
attr Buienradar interval 300
attr Buienradar region de
attr Buienradar room Alarme,Weather
attr Buienradar stateFormat { my $Amount = ReadingsNum($name,"rainAmount",0);
  my $Max    = ReadingsNum($name,"rainMax",0);
  my $Now    = ReadingsNum($name,"rainNow",0);
  my $Ttl    = ReadingsNum($name,"rainTotal",0);
  my $Start  = ReadingsVal($name,"Begin","-");
  my $End    = ReadingsVal($name,"End","-");
  my $Durat  = ReadingsVal($name,"rainDuration","-");
  my $string  = sprintf("%s-%s (%s) &nbsp Now:%.1f &nbsp Max:%.1f &nbsp Amnt:%.1fl/m² &nbsp Tot:%.1f",$Start,$End,$Durat,$Now,$Max,$Amount,$Ttl);
  if ($Amount > 1 && $Amount < 7) {
    return '<font color="teal"><b>' . $string . '</b></font>'}
  elsif ($Amount >= 7 && $Amount < 20 ) {
    return '<font color="DeepSkyBlue"> <b>' . $string . '</b></font>'}
  elsif ($Amount >= 20 && $Amount < 25 ) {
    return '<font color="MediumVioletRed"><b>' . $string . '</b></font>'}
  elsif ($Amount >= 25 || $Max >= 2.5) {
    return '<font color="BlueViolet"><b>' . $string . '</b></font>'}
  else {return $string }
}
defmod Buienradar_bar weblink htmlCode {FHEM::Buienradar::BAR("Buienradar")}
attr Buienradar_bar group WETTER
attr Buienradar_bar room Favourites,PlotsWeather,Weather
attr Buienradar_bar sortby 191
attr Buienradar_bar webCmd Location:upd
attr Buienradar_bar widgetOverride Location:AtHome,Munich,Location-iPhone
Titel: Antw:59_Buienradar
Beitrag von: inoma am 02 September 2019, 13:26:29
Hallo Christoph,
ich habe folgende Fehlermeldung vom Buienradar Modul bekommen, der Grund war, das im Modul im https aufruf, der erst Teil von "&region" als "registered" interpretiert wurde und dort das entsprechende "®" Zeichen für "&reg" eingesetzt wurde, also "®ion".
https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=46.881530&lon=11.435549®ion=de&unit=mm/u returns HTTP status code 404 instead of 200.
Um Abhilfe zu schaffen, habe ich einfach die Reihenfolge umgetauscht, um das &region zu umgehen, also region als erstes (mit Fragezeichen statt &), dann lat/lon, also:
https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?region=de&lat=46.881530&lon=11.435549&unit=mm/u
damit funktionierts, ohne das man die Kodierung irgendwo einstellen muss.
Titel: Antw:59_Buienradar
Beitrag von: jnewton957 am 09 September 2019, 07:06:47
Hallo,
ich habe nun mal das Buienradar installiert. Version 2.2.5



Werte sind vorhanden:
Readings
Begin 06:50 2019-09-09 06:51:47
Duration 01:50 2019-09-09 06:51:47
End 08:40 2019-09-09 06:51:47
rainAmount 2.0 2019-09-09 06:56:47
rainBegin 2019-09-09 06:55:00 2019-09-09 06:56:47
rainData
0.1:0.1:0.1:0.1:0.1:0.1:0.1:0.1:0.1:0.09:0.09:0.09:0.09:0.09:0.09:0.09:0.09:0.08:0.08:0.07:0.07:0.08:0.08:0.08:0.08
2019-09-09 06:51:47
rainDataEnd 2019-09-09 08:40:00 2019-09-09 06:51:47
rainDataStart 2019-09-09 06:35:00 2019-09-09 06:51:47
rainDuration 01:50 2019-09-09 06:51:47
rainDurationMin 110 2019-09-09 06:51:47
rainEnd 2019-09-09 08:40:00 2019-09-09 06:51:47
rainLaMetric 100,100,100,100,100,100,100,100,100,90,90,90 2019-09-09 06:51:47
rainMax 0.1 2019-09-09 06:51:47
rainNow 0.2 2019-09-09 06:56:47
rainTotal 2.2 2019-09-09 06:51:47
state 0.1 2019-09-09 06:51:47


bei state format bekomme ich : Error evaluating Buienradar stateFormat: Can't modify single ref constructor in scalar assignment at (eval 133074) line 2, at EOF
syntax error at (eval 133074) line 9, near "\
  if"

Definition identisch inoma vom 20.8.2019
{ my $Amount = ReadingsNum($name,"rainAmount",0);;\
  my $Max    = ReadingsNum($name,"rainMax",0);;\
  my $Now    = ReadingsNum($name,"rainNow",0);;\
  my $Ttl    = ReadingsNum($name,"rainTotal",0);;\
  my $Start  = ReadingsVal($name,"Begin","-");;\
  my $End    = ReadingsVal($name,"End","-");;\
  my $Durat  = ReadingsVal($name,"rainDuration","-");;\
  my $string  = sprintf("%s-%s (%s) &nbsp Now:%.1f &nbsp Max:%.1f &nbsp Amnt:%.1fl/m² &nbsp Tot:%.1f",$Start,$End,$Durat,$Now,$Max,$Amount,$Ttl);;\
  if ($Amount > 1 && $Amount < 7) {\
    return '<font color="teal"><b>' . $string . '</b></font>'}\
  elsif ($Amount >= 7 && $Amount < 20 ) {\
    return '<font color="DeepSkyBlue"> <b>' . $string . '</b></font>'}\
  elsif ($Amount >= 20 && $Amount < 25 ) {\
    return '<font color="MediumVioletRed"><b>' . $string . '</b></font>'}\
  elsif ($Amount >= 25 || $Max >= 2.5) {\
    return '<font color="BlueViolet"><b>' . $string . '</b></font>'}\
  else {return $string }\
}

Wo liegt mein Fehler?

Danke
Titel: Antw:59_Buienradar
Beitrag von: inoma am 09 September 2019, 07:56:50
Hast du alle "\" entfernt von der Raw definition? Deine Fehlermeldung sagt "line 9, near "\  <-