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.
Folgende Ressourcen sind relevant:
Releases: https://github.com/fhem/mod-Buienradar/releases
Issues: https://github.com/fhem/mod-Buienradar/issues
Wichtige Vorankündigung!
Mit der (Re-)Implementierung des ColourBarCharts und der Unterstützung von will-it-rain-at-Anfragen (wird es zu einem angegebenen Zeitpunkt regnen) wird die Version 3.0 erstmal feature complete sein und - nach ein paar Wochen - auf stable gehen. Ich plane die 3.0 etwa Ende Juli / Anfang August als stable zu markieren. Es wird dann all die API-Änderungen in stable geben, die bisher nur in testing / development-3.0 zu finden sind.
Mit einem Update werden die bisher eingebundenen Charts über weblink erstmal nicht mehr funktionieren!
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
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
Das kann ich bestätigen. Bei mir schlägt das Update auch fehl.
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.
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.
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.
Danke. Sobald die Temperaturen hier unter die 40-Grad-Grenze gerutscht sind, verlasse ich den Kühlschrank und fixe die Bugs.
Danke! Hier sind's noch gemütliche 35°. 8)
Es gibt wieder ein neues Release für 2.1.0. Changes:
- Fehler durch main::Timer() gefixt
- Fehler mit split und den rainData-Daten (damit funktioniert auch der HTML-Graph wieder)
- DateTime wurde entfernt, da es nie benutzt wurde
- Fehlermeldungen durch given/when entfernt
Wenn ihr die 2.1.0 bereits mit
update add hinzugefügt habt, reicht ein
update all aus.
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
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).
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
Zitat von: Gisbert am 25 Juli 2019, 08:38:03
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
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
Zitat von: Gisbert am 25 Juli 2019, 12:51:43
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
Mit Abschluss der Dokumentation ist nun der finale Erweiterungsstand der 2.1.0 erreicht. Ich fixe dort nun nur noch Bugs.
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®ion=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
Dann schauen wir mal was die Nacht bringt ;-)
Stell mal verbose auf 4 bitte über Nacht.
Hallo Christoph,
wird gemacht - ich melde mich dann morgen früh wieder.
Viele Grüße Gisbert
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®ion=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}}
Zitat 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®ion=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.
Danke, ich freu mich schon aufs update!
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
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.
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
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
Habt ihr inzwischen verbose-Logs für mich?
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.
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
Zitat von: Papaloewe am 27 Juli 2019, 12:17:23
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.
Zitat von: Papaloewe am 27 Juli 2019, 12:17:23
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.
Es passiert halt immer so gegen 00:30 Uhr!
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
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.
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®ion=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
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®ion=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®ion=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®ion=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
Zitat von: choenig am 28 Juli 2019, 08:11:57
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.
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.
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.
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.
Moin,
Zitat von: Christoph Morrison am 29 Juli 2019, 04:09:48
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
>> 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
Zitat von: Christoph Morrison am 29 Juli 2019, 06:30:56
Die Unterstützung für logProxy werde ich nicht wieder einbauen. Aktuell sehe ich keinen Sinn der Funktionalität. Wer den Wert haben will, der früher von Buienradar_logProxy zurück kam, soll einfach rainAmount nehmen.
Wo liegt denn der Unterschied zwischen
rainNow und
rainAmount, bzw. auf welchen Zeitraum bezieht sich
rainAmount?
Zitat von: mahowi am 29 Juli 2019, 14:12:35
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 ;-)
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.
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.
Zitat von: mahowi am 29 Juli 2019, 15:59:02
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?
Ja klar, oben steht die Beschreibung. :D Aber vielleicht bin ich zu doof, sie zu verstehen. ???
ZitatrainAmount - 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.
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®ion=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}}
Zitat 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.
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.
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.
Zitat 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:
Ich hab mir die Def gerade mal selbst angelegt und kann das nicht reproduzieren. Ist das Verhalten bei dir noch so?
Zitat 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. ???
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.
ZitatZitat 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
Zitat von: inoma am 30 Juli 2019, 18:07:30
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).
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®ion=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}}
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!
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
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.
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.
Zitat von: mahowi am 30 Juli 2019, 20:45:17
In Zeile 668 ist Dir wohl irgendwie ein "kk" hinter die Zeile geraten:
https://www.youtube.com/watch?v=y6OOdeEM1sU
Zitat 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.
Zitat 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.
Schräg. Ist bei mir völlig normal skaliert. Habe gerade keine Idee warum das bei euch komisch aussieht.
Zitat von: Christoph Morrison am 30 Juli 2019, 20:56:32
https://www.youtube.com/watch?v=y6OOdeEM1sU
Das kenne ich. ;D
Zitat von: Christoph Morrison am 30 Juli 2019, 21:01:46
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.
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?
Zitat von: inoma am 30 Juli 2019, 21:11: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.
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
Hallo Christoph,
ich hab gerade das update auf:
ZitatVersion 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
Zitat von: Gisbert am 01 August 2019, 18:27:09
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.
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
Hi,
Zitat von: Gisbert am 01 August 2019, 18:42:32
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
Zitatdu 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.
ZitatUnd 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
Hi,
Zitat von: Gisbert am 01 August 2019, 22:50:27
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
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
Zitat von: Gisbert am 01 August 2019, 18:42:32
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.
Zitat von: Gisbert am 01 August 2019, 18:42:32
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.
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!
Hallo,
Zitat von: inoma am 02 August 2019, 11:25:28
was mir noch aufgefallen ist / Vorschläge:
- alle Module verwenden attr disable 1 oder attr disable 0, Buienradar hat on/off.
Das war eine bewusste Entscheidung. Ich finde 1/0 als Flag dämlich. Ggf. baue ich mal eine undokumentierte Kompatiblität ein. Stimmt übrigens nicht das alle Module das so machen. ASC z.B. hat gar keinen off-Modus (was ich auch nicht gut finde).
Zitat von: inoma am 02 August 2019, 11:25:28
- könnte man evtl noch die 'rainDuration' mit als Reading ausgeben? Ich lasse mir einen Push schicken beim Mountainbiken, falls sich die Regendauer ändert (kurzer Schauer oder langanhaltender Regen), das ist schwieriger zu berechnen, weil die Readings für RainStart und RainEnd nur als HH:MM ausgegeben werden, falls dazwischen ein Tageswechsel liegt.
Ja und es ist vor allem schwieriger zu berechnen weil es ja durchaus auch Pausen gibt. Ich könnte natürlich die (ersten zusammenhängenden) 5-Minuten-Intervalle zählen in denen es regnet, dann hat man wenigstens einen groben Wert - aber der kann halt verführerisch gut sein, wenn es erst 5 Minuten regnet, dann 5 Minuten nicht und dann die restliche Zeit wieder doch. Oder halt alle 5-Minuten-Intervalle in den nächsten 2 Stunden. Die Daten sind dafür eigentlich nicht genau genug. Ich überleg's mir mal.
Zitat von: inoma am 02 August 2019, 11:25:28
- Abfrage alle 10 Minuten (also 600) fände ich auch gut, man kann ja, sobald es anfängt zu regnen, das attribut automatisch auf 300 oder 180 runtersetzen. Einfach wegen Serverlast....
Ich hab eine Art automatisches Load-Balancing auf der Agenda: Wenn der Datenabruf ein paar mal nicht geklappt hat, wird die Anfragefrequenz automatisch gedrosselt. Man könnte überlegen ob man das auch macht wenn es z.B. länger gar keinen Regen geben soll (und wieder beschleunigen wenn Regen aufkommt). Vielleicht über einen "auto"-Intervall.
Zitat von: inoma am 02 August 2019, 11:25:28
- Kannst Du evtl nochmal nachschauen, wie im Code 'rainEnd' gesetzt wird? Ich meine, da müsste in Zeile 655 noch folgendes hin, falls rainEnd nicht auf $end gesetzt ist.
if (!$rainEnd and $rainStart and $precip != 0 ) {
$rainEnd = $end;
}
Nehme ich mir mal mit. Wird aber frühestens nächste Woche was.
Zitat von: inoma am 02 August 2019, 11:25:28
Version 2.2.0 in der jetzigen Version läuft bei mir absolut Prima. Chapeau an Dich für die geile Arbeit.
Danke!
Gerne.
ZitatJa und es ist vor allem schwieriger zu berechnen weil es ja durchaus auch Pausen gibt. Ich könnte natürlich die (ersten zusammenhängenden) 5-Minuten-Intervalle zählen in denen es regnet, dann hat man wenigstens einen groben Wert - aber der kann halt verführerisch gut sein, wenn es erst 5 Minuten regnet, dann 5 Minuten nicht und dann die restliche Zeit wieder doch. Oder halt alle 5-Minuten-Intervalle in den nächsten 2 Stunden. Die Daten sind dafür eigentlich nicht genau genug. Ich überleg's mir mal.
Ich dachte an sowas:
$rainDurationMin = ($rainEnd-$rainStart)/60;
$rainDuration = MinToHours ($rainDurationMin);
::readingsBulkUpdate( $hash, "rainDuration", (($rainStart && $rainEnd) ? $rainDuration : 'unknown'));
::readingsBulkUpdate( $hash, "rainDurationMin", (($rainStart && $rainEnd) ? $rainDurationMin : 'unknown'));
sub MinToHours($) {
my($intime) = @_;
return sprintf("%02d:%02d",(($intime/60),$intime%60));
}
Zitat von: Christoph Morrison am 29 Juli 2019, 06:30:56
Die Unterstützung für logProxy werde ich nicht wieder einbauen. Aktuell sehe ich keinen Sinn der Funktionalität. Wer den Wert haben will, der früher von Buienradar_logProxy zurück kam, soll einfach rainAmount nehmen.
Wenn jemand gute Argumente dafür hat bin ich aber offen.
Hallo Christoph,
erstmal danke für deine super Arbeit :). Habe heute das erste Mal dieses Modul bei mir eingebaut (v.2.2.0), läuft auch super in München mit dem "DE" Attribut. Ebenso "GChart". Nun möchte ich das Chart jedoch auch in FTUI einbauen. Hierfür benötige ich die logproxy-Funktion. Ist das ein gutes Argument? ;)
Danke vorab
Andreas
Hallo Andreas,
Zitat von: somansch am 03 August 2019, 19:50:21
erstmal danke für deine super Arbeit :). Habe heute das erste Mal dieses Modul bei mir eingebaut (v.2.2.0), läuft auch super in München mit dem "DE" Attribut. Ebenso "GChart". Nun möchte ich das Chart jedoch auch in FTUI einbauen. Hierfür benötige ich die logproxy-Funktion. Ist das ein gutes Argument? ;)
kannst du mir mal genauer erklären für was die logproxy-Funktion benötigt wird? Ich hab kein FTUI hier.
Gruß
CM
Zitat von: Christoph Morrison am 04 August 2019, 13:28:53
Hallo Andreas,
kannst du mir mal genauer erklären für was die logproxy-Funktion benötigt wird? Ich hab kein FTUI hier.
Gruß
CM
Na klar ;). In FTUi gibt es die Möglichkeit Charts (ähnlich SVG Plots in FHEM) zu erstellen. Hierfür wird ein Logfile, DBLog (beides historische Daten) oder LogProxy (aktuelle Daten) benötigt. Siehe Wiki: https://wiki.fhem.de/wiki/FTUI_Widget_Chart#LogProxy (https://wiki.fhem.de/wiki/FTUI_Widget_Chart#LogProxy)
Viele Grüße
Andreas
Zitat von: somansch am 04 August 2019, 13:35:42
Na klar ;). In FTUi gibt es die Möglichkeit Charts (ähnlich SVG Plots in FHEM) zu erstellen. Hierfür wird ein Logfile, DBLog (beides historische Daten) oder LogProxy (aktuelle Daten) benötigt. Siehe Wiki: https://wiki.fhem.de/wiki/FTUI_Widget_Chart#LogProxy (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?
Kann man nicht einfach ein Log-Device anlegen und sich rainAmount (und ggfs. noch andere Werte) in ein Logfile schreiben lassen?
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.
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
Was für eine Perl-Version benutzt du? Das ist ein POD-Block, der sollte niemals irgendwie ausgeführt werden.
Zitat von: Christoph Morrison am 05 August 2019, 21:59:01
Was für eine Perl-Version benutzt du? Das ist ein POD-Block, der sollte niemals irgendwie ausgeführt werden.
Ich hab gerade auf die Version [Edit]
2.3.0 2.2.3
- ich bin der Zeit voraus - upgedatet, also hier sieht es gut aus.
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 !
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.
Zitat von: mahowi am 06 August 2019, 18:25:54
rainNow scheint nicht den aktuellen Regen anzuzeigen sondern den der ersten Periode ungleich 0.
⇒ Issue #2 (https://github.com/fhem/mod-Buienradar/issues/2)
Zitat von: inoma am 02 August 2019, 19:20:52
Ich dachte an sowas:
$rainDurationMin = ($rainEnd-$rainStart)/60;
$rainDuration = MinToHours ($rainDurationMin);
::readingsBulkUpdate( $hash, "rainDuration", (($rainStart && $rainEnd) ? $rainDuration : 'unknown'));
::readingsBulkUpdate( $hash, "rainDurationMin", (($rainStart && $rainEnd) ? $rainDurationMin : 'unknown'));
sub MinToHours($) {
my($intime) = @_;
return sprintf("%02d:%02d",(($intime/60),$intime%60));
}
⇒ Issue #3 (https://github.com/fhem/mod-Buienradar/issues/3)
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!
Ich habe für inomas Version mal einen Pull Request auf Github gemacht.
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
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
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. ???
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.
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
In der tat, sorry, habs korrigiert, neue Version anbei.
Vielen Dank für den PR. Ich schau ihn mir an sobald ich Zeit habe und merge ihn sobald ich alle Änderungen nachvollzogen habe.
Meinen Dank an Dich und User mahowi!
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
Zitat 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.
Richtig, denn die Daten stehen nun - so wie es sein sollte - in einem Internal, gespeichert als Storable. Das chartData-Reading kannst du löschen.
Zitat von: somansch am 10 August 2019, 14:41:38
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"));; }
Zitat von: somansch am 10 August 2019, 14:41:38
JJJJ-MM-TT_SS:mm:ss Regenmenge
Genau das liefert FHEM::Buienradar::LogProxy im Listenkontext auch zurück.
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!
Zitat von: Christoph Morrison am 10 August 2019, 15:22:55
...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?
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
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.
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.txt
updaten.
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.
Zitat 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.
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.
Zitat von: inoma am 18 August 2019, 18:12:48
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
Zitat 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.
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.
Zitat von: mahowi am 18 August 2019, 20:25:51
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.txt
updaten.
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.
Zitat von: inoma am 01 August 2019, 12:40:18
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.
Fehlerhafte Berechnung von rainNow in 2.1 und 2.2 gefixt. Beide finden sich nun in eigene Branches. Development existiert nicht mehr.
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
Hallo inoma,
Zitat von: inoma am 19 August 2019, 22:43:05
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.
Zitat von: inoma am 19 August 2019, 22:43:05
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).
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.
rainEnd und das Problem mit disabled sind nun in 2.x gefixt.
Zitat 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.
Gefällt mir. Wie hast du das mit dem Picker rechts (AtHome) bei Buienradar realisiert?
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+).
ZitatGefä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)   Now:%.1f   Max:%.1f   Amnt:%.1fl/m²   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
Hallo Christoph,
ich habe folgende Fehlermeldung vom Buienradar Modul bekommen, der Grund war, das im Modul im https aufruf, der erst Teil von "®ion" als "registered" interpretiert wurde und dort das entsprechende "®" Zeichen für "®" 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 ®ion 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.
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)   Now:%.1f   Max:%.1f   Amnt:%.1fl/m²   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
Hast du alle "\" entfernt von der Raw definition? Deine Fehlermeldung sagt "line 9, near "\ <-
Inzwischen habe ich 2.2 als stable veröffentlicht.
In 2.3 gibt es nun den gewünschten ColourBar und bald auch die Anpassungen für RainAmount.
Schön zu sehen, dass es weitergeht.
Du hast 2.2 als stable im github veröffentlicht, überlegst du darüber hinausgehend eine Veröffentlichtung des Moduls via FHEM-Standard?
Zitat von: Timmäää am 14 Januar 2020, 08:53:54
Du hast 2.2 als stable im github veröffentlicht, überlegst du darüber hinausgehend eine Veröffentlichtung des Moduls via FHEM-Standard?
Nein. Es ist mir zu aufwändig, eine technisch dermaßen altmodische Struktur wie das SVN zu pflegen. Und da Buienradar nie über das SVN ausgeliefert wurde, gibt es auch da auch keine legacy zu pflegen.
Danke für die Info und das Modul, ich nutze es natürlich trotzdem :) Wäre für den Benutzer einfacher gewesen, aber wenn du mehr Arbeit hast, habe ich für die Entscheidung nur Verständnis.
Gruß,
Tim
Hallo,
wie kann ich das Modul bzw. {FHEM::Buienradar::HTML('Buienradar')} in FTUI einbinden?
Das Modul funktioniert einwandfrei in FHEMWEB abgesehen von der Integration in FTUI.
Es liegt aber 100% an mir. Als weblink device wird alles korrekt angezeigt, wie auch im Buienradar device selbst: htmlCode {FHEM::Buienradar::HTML('Buienradar')}
Vielen Dank im voraus!
Gruß
Horst
Buienradar wurde in Version 3.0.5 (https://github.com/fhem/mod-Buienradar/releases/tag/v3.0.5) veröffentlicht.
Changenotes etc. stehen dort.
Da sind wohl noch ein paar Debug-Zeilen im Code geblieben:
2020.04.19 12:29:05.828 1: DEBUG>Attr called \n $VAR1 = 'set';
$VAR2 = 'BR';
$VAR3 = 'region';
$VAR4 = 'nl';
2020.04.19 12:29:05.831 1: DEBUG>Attr called \n $VAR1 = 'set';
$VAR2 = 'BR';
$VAR3 = 'interval';
$VAR4 = '120';
2020.04.19 12:29:05.837 1: DEBUG>Attr called \n $VAR1 = 'set';
$VAR2 = 'BR';
$VAR3 = 'interval';
$VAR4 = '120';
2020.04.19 12:29:05.841 1: DEBUG>Attr called \n $VAR1 = 'set';
$VAR2 = 'BR';
$VAR3 = 'region';
$VAR4 = 'nl';
2020.04.19 12:29:05.844 1: DEBUG>Attr called \n $VAR1 = 'set';
$VAR2 = 'BR';
$VAR3 = 'room';
$VAR4 = 'Weather';
2020.04.19 12:29:05.845 1: DEBUG>Attr called \n $VAR1 = 'set';
$VAR2 = 'BR';
$VAR3 = 'verbose';
$VAR4 = '1';
Und da ist noch ein Fehler: in der sub 'Get', Zeile 303: "return q[It is raining] if $begin = 0;"
2020.04.19 12:54:10 1: PERL WARNING: Found = in conditional, should be == at ./FHEM/59_Buienradar.pm line 303, <$fh> line 7079.
Hallo,
wollte fragen ob es was vergleichbares für Österreich gibt.
Bei diesem Modul kommt "Location is not in coverage for region 'de|nl'"
Danke, lg
Hat sich am Weblink für die GoogleCharts etwas geändert? Ich bekomme beim Aufrufen der Seite einen Fehler im Javascript angezeigt:
fhem?detail=BR_weblink line 1734:
Uncaught SyntaxError: Unexpected token '{'
Die Stelle im Quelltext der Seite:
<script type='text/javascript'>
google.charts.load('current', {packages:['corechart']});
google.charts.setOnLoadCallback(drawChart);
function drawChart() {
var data = google.visualization.arrayToDataTable([
['string', '${legend}'],
${data}
]);
var options = {
title: '${title}',
hAxis: {
title: '${hAxis}',
slantedText:true,
slantedTextAngle: 45,
textStyle: {
fontSize: 10}
},
vAxis: {
minValue: 0,
title: '${vAxis}'
}
};
var my_div = document.getElementById(
'chart_${name}'); var chart = new google.visualization.AreaChart(my_div);
google.visualization.events.addListener(chart, 'ready', function () {
my_div.innerHTML = '<img src='' + chart.getImageURI() + ''>';
});
chart.draw(data, options);}
</script>
Der Fehler wird hinter ${data} angezeigt (siehe Screenshot).
Zitat von: mahowi am 20 April 2020, 13:04:07
Hat sich am Weblink für die GoogleCharts etwas geändert? Ich bekomme beim Aufrufen der Seite einen Fehler im Javascript angezeigt:
Hab's aufgenommen: https://github.com/fhem/mod-Buienradar/issues/94
Zitat von: Jamo am 19 April 2020, 13:09:05
Und da ist noch ein Fehler: in der sub 'Get', Zeile 303: "return q[It is raining] if $begin = 0;"
Wird in 3.0.6 (https://github.com/fhem/mod-Buienradar/pull/86) gefixt sein, war mir auch schon aufgefallen.
Zitat von: mahowi am 19 April 2020, 12:32:52
Da sind wohl noch ein paar Debug-Zeilen im Code geblieben
Per se sind die ok, allerdings hatte ich wohl die Schwelle zum Debugging zu niedrig eingestellt, so dass ihr die nun sehen konntet.
Hab's mal auf
verbose 4 +
debug-Attribut hochgedreht (https://github.com/fhem/mod-Buienradar/issues/85).
Zitat von: lichtimc am 20 April 2020, 02:22:39
wollte fragen ob es was vergleichbares für Österreich gibt.
Bei diesem Modul kommt "Location is not in coverage for region 'de|nl'"
Ja die Reichweite des niederländischen Dienstes reicht gerade mal bis knapp zu Südgrenze DE-AT. Ich kenne leider keinen Service in AT, der eine freie API hat. http://www.zamg.ac.at/incaanalyse/ (http://www.zamg.ac.at/incaanalyse/) kennst du? Da gibt es aber keine API soweit ich das sehe.
Danke für deine Antwort. Ja, die Seite kenne ich und Bilder einzubetten wäre eh kein Problem, aber fürs Ausschalten der automatischen Bewässerung bei genug Regen wäre die API notwendig...
Buienradar wurde in Version 3.0.6 (https://github.com/fhem/mod-Buienradar/releases/tag/v3.0.6) veröffentlicht.
Changenotes etc. stehen dort.
Ich freue mich über Feedback.
Ankündigung: Version 3.0.7 (https://github.com/fhem/mod-Buienradar/milestone/9) wird geplant am 08.05.2020 erscheinen.
Hallo Christoph,welche Abhängigkeiten muss man denn installieren?
Ich bekomme die Fehlermeldung:
ZitatCan't locate Readonly.pm in @INC (you may need to install the Readonly module) (@INC contains: . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/arm-linux-gnueabihf/perl5/5.24 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base ./FHEM ./FHEM/lib) at ./FHEM/59_Buienradar.pm line 54. BEGIN failed--compilation aborted at ./FHEM/59_Buienradar.pm line 54.
Zitat von: Steigerbalett am 26 April 2020, 08:17:36
Hallo Christoph,welche Abhängigkeiten muss man denn installieren?
Ich bekomme die Fehlermeldung:
Hi, du musst
Readonly installieren, entweder über cpan (vorzugsweise mit cpan-minus) oder ein Paket deiner Distribution, unter Debian ist das
libreadonly-perl (allerdings wird das dort zumindest unter Buster automatisch installiert).
Welches OS benutzt du denn?
Ich passe die Release notes noch an, ist mir völlig durchgegangen dass das kein Core-Modul ist.
Ich dachte eigentlich, Readonly gehört zum Core, aber Du musst das Paket libreadonly-perl installieren. (Da war Christoph schneller :) )
@Christoph: Könntest Du die controls.txt vielleicht so zur Verfügung stellen, daß man updaten kann, ohne jedes Mal eine neue Datei hinzuzufügen?
Auch mit der v3.0.6 bekomme ich noch den Fehler beim Aufruf von FHEM::Buienradar::GChart():
fhem?detail=BR_weblink line 1755:
Uncaught SyntaxError: Unexpected string
Edit: Ich hab ein Issue in Github dazu erstellt.
Zitat von: mahowi am 26 April 2020, 09:29:07
@Christoph: Könntest Du die controls.txt vielleicht so zur Verfügung stellen, daß man updaten kann, ohne jedes Mal eine neue Datei hinzuzufügen?
Also du kannst folgendes tun:
- Im Branch
release/3.0 liegt jeweils die letzte Version des 3.0-Zweiges, aktuell demnach 3.0.6. Wenn du also immer nur auf dem 3.0-Release-Zweig bleiben möchtest, nimmst du https://raw.githubusercontent.com/fhem/mod-Buienradar/release/3.0/controls_Buienradar.txt
- Im Branch
release/2.0 liegt jeweils analoig die letzte Version 2.0-Zweiges, aktuell 2.3: https://raw.githubusercontent.com/fhem/mod-Buienradar/release/2.0/controls_Buienradar.txt
- Im Branch
testing liegt jeweils die aktuelle Entwicklungsversion, d.h. aktuell ist
testing identisch zu 3.0, wird aber irgendwann zu 4.0: https://raw.githubusercontent.com/fhem/mod-Buienradar/testing/controls_Buienradar.txt
Ich würde den Leuten, die ein stabiles FHEM haben wollen, allerdings immer den stable-Branch empfehlen (aktuell ist das v2.3.0): https://raw.githubusercontent.com/fhem/mod-Buienradar/stable/controls_Buienradar.txt
Irgendwann wenn ich mit 3.0 fertig bin, wandert stable in oldstable, testing in stable und development/3.1 in testing, wobei man mal schauen muss, was da eigentlich noch geschehen kann.
Danke, jetzt tut es.
Hab es mit
Zitatsudo apt install libreadonly-perl
installiert.
Bin noch auf stretch unterwegs - muss jetzt glaube ich langsam echt mal updaten/neu aufsetzten.
Nur der Vollständigkeit halber: Beim ersten Starten habe ich noch die Fehlermeldungen bekommen:
Zitat2020.04.26 16:20:41 1: PERL WARNING: Use of uninitialized value $language in hash element at ./FHEM/59_Buienradar.pm line 591.
2020.04.26 16:20:41 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/59_Buienradar.pm line 591.
2020.04.26 16:20:41 1: PERL WARNING: Use of uninitialized value $language in hash element at ./FHEM/59_Buienradar.pm line 593.
2020.04.26 16:20:41 1: PERL WARNING: Use of uninitialized value in sprintf at ./FHEM/59_Buienradar.pm line 593.
mit Perl v5.24.1 auf raspbian stretch
Modul Version 3.0.6
Nach shutdown restart kam es aber nicht wieder.Update:Fehler kam doch wieder.
Zitat von: Steigerbalett am 26 April 2020, 16:49:52
Update:Fehler kam doch wieder.
Ist dann mit v3.0.7 gefixt.
Ist in einer 3.X Version eigentlich geplant das ColourBarChart wieder mit zu integrieren?
{ FHEM::Buienradar::ColourBarChart (Buienradar)}
Zitat von: Steigerbalett am 28 April 2020, 20:08:30
Ist in einer 3.X Version eigentlich geplant das ColourBarChart wieder mit zu integrieren?
{ FHEM::Buienradar::ColourBarChart (Buienradar)}
Ja, schon. Leider hab ich noch keine Umsetzung hinbekommen, die mir gut genug gefällt und die FHEMWEB nicht kaputt macht.
Hab's mal vorerst in v3.0.11 (https://github.com/fhem/mod-Buienradar/milestone/13) eingeplant.
Zitat von: Christoph Morrison am 26 April 2020, 14:50:06
- Im Branch testing liegt jeweils die aktuelle Entwicklungsversion, d.h. aktuell ist testing identisch zu 3.0, wird aber irgendwann zu 4.0: https://raw.githubusercontent.com/fhem/mod-Buienradar/testing/controls_Buienradar.txt
Das habe ich gemacht. Leider hast Du aber die Updates in 3.0.x hier nicht übernommen.
Zitat von: mahowi am 02 Mai 2020, 11:33:34
Das habe ich gemacht. Leider hast Du aber die Updates in 3.0.x hier nicht übernommen.
Da liegt aktuell 3.0.6 (https://raw.githubusercontent.com/fhem/mod-Buienradar/testing/FHEM/59_Buienradar.pm)
Ich weiß ;)
Ich dachte nur, testing enthält eher neuere Versionen als stable.
Zitat von: mahowi am 02 Mai 2020, 13:27:39
Ich weiß ;)
Ich dachte nur, testing enthält eher neuere Versionen als stable.
In Stable liegt 3.0.3 (https://raw.githubusercontent.com/fhem/mod-Buienradar/stable/FHEM/59_Buienradar.pm), nicht 3.0.6.
Sorry, ich dachte 3.0.6 wäre stable. Worauf ich mich aber eigentlich bezog, war
Zitat
aktuell ist testing identisch zu 3.0, wird aber irgendwann zu 4.0:
Ich bin davon ausgegangen, daß testing jeweils die aktuellste Version ist, also momentan 3.0.7 oder neuer, irgendwann dann 4.0.x.
Auf die Weise wollte ich eigentlich die aktuellen Versionen testen, ohne ständig den Update-Zweig zu wechseln. So mache ich es auch bei anderen Programmen, die ich z.B. über Github beziehe. Ich abonniere den testing- oder development-Branch und gebe natürlich auch Feedback dazu.
Zitat von: mahowi am 02 Mai 2020, 13:58:34
Sorry, ich dachte 3.0.6 wäre stable. Worauf ich mich aber eigentlich bezog, war
Ich bin davon ausgegangen, daß testing jeweils die aktuellste Version ist, also momentan 3.0.7 oder neuer, irgendwann dann 4.0.x.
Auf die Weise wollte ich eigentlich die aktuellen Versionen testen, ohne ständig den Update-Zweig zu wechseln. So mache ich es auch bei anderen Programmen, die ich z.B. über Github beziehe. Ich abonniere den testing- oder development-Branch und gebe natürlich auch Feedback dazu.
So wird das auch sein, 3.0.7 (https://github.com/fhem/mod-Buienradar/pull/121) ist ja noch gar nicht released worden. Sobald ich die - heute oder morgen - fertig mache, werde ich sie nach
releases/3.0.7,
releases/3.0 und nach
testing mergen. Wenn du
testing abonniert hast, dann bekommst du auch ein Update. Wenn du wirklich den aktuellen Stand von 3.0.7 nehmen willst, findest du das in
development/3.0.7 (usw.). Da hast du den ungefilterten Zugang, würde ich aber nicht empfehlen, denn da kommt auch öfter Zeug rein was überhaupt nicht funktioniert ;-)
Ich finde hier sieht man auch den größten Vorteil von einer Branch-basierten Entwicklung, auch wenn das ein bisschen mehr Arbeit für mich ist.
(Pre-) Release v3.0.7 (https://github.com/fhem/mod-Buienradar/releases/tag/v3.0.7) ist erschienen und nach testing und releases/3.0 gemerged. Es gibt auch den Tag v3.0.7 (https://github.com/fhem/mod-Buienradar/tree/v3.0.7), wenn jemand diese Version pinnen möchte.
ZitatIst in einer 3.X Version eigentlich geplant das ColourBarChart wieder mit zu integrieren?
Hallo Christoph,
danke für die Weiterentwicklung des Buienradar. Ich habe auf Basis deiner Version 3.0.7 ein GChart gebaut, das sieht so wie im Anhang aus, oben Buienradar, unten Regenradar (von 59_RainTMC.pm). Die Farben und wie man die HTML Tabelle für den GChart aufbaut, habe ich von dem RainTMC Modul übernommen. Allerdings weiss ich ehrlich gesagt nicht wie ich einen Pull request machen kann, einen Github Account habe ich. Habe Dir eine PM geschickt.
Hab dir schon geantwortet und bin gespannt auf den Code. Hattest du die Version in 2.3.0 gesehen?
Aktueller Status:
Aufgrund der Diskussionen um die Einführung einer neuen Verzeichnisstruktur innerhalb von FHEM steht die Entwicklung gerade.
Hallo Christoph,
ich habe mal angefangen mit dem Modul zu spielen. Dabei ist mir aufgefallen:
Readonly.pm wird benötigt. Habe ich behoben mit:
apt install libreadonly-perl
Kannst Du bitte diesen Hinweis als Voraussetzung in die Doku aufnehmen?
Auf der ersten Thread Seite: Die Version 2.1 habe ich installiert. Die Version 2.2 hat er irgendwie gar nicht geladen?
Sehe gerade: die controls sind doch dort gar nicht aktuell? Oder schau ich falsch?
Sollte doch https://raw.githubusercontent.com/fhem/mod-Buienradar/stable/controls_Buienradar.txt sein?
Mal schauen wie gut die Daten hier im Osten weit weg von den Holländern sind :)
Gruß Otto
Zitat von: Otto123 am 19 Mai 2020, 11:38:23
Kannst Du bitte diesen Hinweis als Voraussetzung in die Doku aufnehmen?
In den release notes (https://github.com/fhem/mod-Buienradar/releases/tag/v3.0.6) stand es, aber ich habe es mal aufgenommen (https://github.com/fhem/mod-Buienradar/issues/134).
ZitatAuf der ersten Thread Seite: Die Version 2.1 habe ich installiert. Die Version 2.2 hat er irgendwie gar nicht geladen?
Sehe gerade: die controls sind doch dort gar nicht aktuell? Oder schau ich falsch?
Sollte doch https://raw.githubusercontent.com/fhem/mod-Buienradar/stable/controls_Buienradar.txt sein?
Ich hab den ersten Beitrag mal angepasst und die alten Infos entfernt. Ich bin ja kein Fan von diesen Mega-Threads mit "aktuellem" ersten Posting inkl. Download.
Stable ist aktuell v3.0.3 (https://github.com/fhem/mod-Buienradar/releases/tag/v3.0.3) und länger nicht mehr 2.3.x.
ZitatMal schauen wie gut die Daten hier im Osten weit weg von den Holländern sind :)
region de setzen, dann könnte es klappen. Für Bautzen kommen Daten, iirc.
Zitat von: Christoph Morrison am 19 Mai 2020, 13:52:55
Ich bin ja kein Fan von diesen Mega-Threads mit "aktuellem" ersten Posting inkl. Download.
Ja, aber so ein Späteinsteiger wie ich hat es irgendwie schwer ;)
Soll ich mal ein paar Zeilen in den noch völlig leeren Wiki Artikel klopfen?
Momentan ist bei mir alles 0000 in den Werten - aber bei dem Wetter ist das ja richtig :'(
Bin mal gespannt wie zuverlässig die Werte sind - falls es mal wieder regnet.
Als Version zeigt er mir 3.0.7 an.
Zitat von: Otto123 am 19 Mai 2020, 14:07:05
Ja, aber so ein Späteinsteiger wie ich hat es irgendwie schwer ;)
Dafür gibt es ja die release notes und die Doku am Modul ;-)
Zitat von: Otto123 am 19 Mai 2020, 14:07:05
Soll ich mal ein paar Zeilen in den noch völlig leeren Wiki Artikel klopfen?
Ich habe eben die Originalquellen verlinkt, auch wenn das Projektwiki noch leer ist.
Zitat von: Otto123 am 19 Mai 2020, 14:07:05
Momentan ist bei mir alles 0000 in den Werten - aber bei dem Wetter ist das ja richtig :'(
Bin mal gespannt wie zuverlässig die Werte sind - falls es mal wieder regnet.
Ich hab's mal gemessen und beide Vektoren (Zeit und Menge) sind ziemlich zuverlässig, die Abweichung lag etwa bei t 5% und Menge 10%. Für einen Onlineservice ist das bemerkenswert und (hier) deutlich besser als das, was z.B. Proplanta liefert.
Zitat von: Otto123 am 19 Mai 2020, 14:07:05
Als Version zeigt er mir 3.0.7 an.
Dann hast du das von Release-Page oder? Stable ist (noch) 3.0.3, aber ich ändere das gleich auf 2.3 zurück, damit die Leute kein Problem mit Readonly bekommen.
Wenn ich jetzt wüsste wo die Release Page ist ;D
Ich hatte Artikel von Torxgewinde gelesen, der war mein catcher.
Dann hab ich den alten Thread gefunden, vorne und hinten gelesen und deinen neuen Thread gefunden. Dort gab es zwei update controls die eine ging die andere nicht. Dann habe ich auf Github geschaut und dort die stable genommen.
Welcher Versuch jetzt was geladen hat kann ich nur sagen wenn ich es nochmal mache. Mach ich die nächsten Tage ;)
Hallo zusammen,
habe das heute auch mal eingebaut.
Irgendwie sieht das komisch aus:
defmod myBuienRadar Buienradar
attr myBuienRadar interval 120
attr myBuienRadar region nl
attr myBuienRadar room 1_test
setstate myBuienRadar 2020-05-20 00:18:56 rainAmount 36517.410
setstate myBuienRadar 2020-05-20 00:18:56 rainBegin 00:05
setstate myBuienRadar 2020-05-20 00:18:56 rainData 36517.41:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
setstate myBuienRadar 2020-05-20 00:18:56 rainDataEnd 02:10
setstate myBuienRadar 2020-05-20 00:18:56 rainDataStart 00:05
setstate myBuienRadar 2020-05-20 00:18:56 rainDuration 5
setstate myBuienRadar 2020-05-20 00:18:56 rainDurationIntervals 1
setstate myBuienRadar 2020-05-20 00:18:56 rainDurationPercent 4
setstate myBuienRadar 2020-05-20 00:18:56 rainDurationTime 00:05
setstate myBuienRadar 2020-05-20 00:18:56 rainEnd 00:10
setstate myBuienRadar 2020-05-20 00:18:56 rainLaMetric 36517410,0,0,0,0,0,0,0,0,0,0,0
setstate myBuienRadar 2020-05-20 00:18:56 rainMax 36517.410
setstate myBuienRadar 2020-05-20 00:18:56 rainNow unknown
setstate myBuienRadar 2020-05-20 00:18:56 rainTotal 36517.410
setstate myBuienRadar 2020-05-20 00:18:56 state unknown
vor allem die riesigen Werte. Soll das so?
Setze ich Region auf de, kommt nichts.
So sieht der Aufruf aus:
https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=53.5653&lon=10.0014®ion=nl&unit=mm/u
Koordinaten kommen aus dem global device.
Version: 2.3.2
Zitat von: slor am 20 Mai 2020, 00:24:55
vor allem die riesigen Werte. Soll das so?
[Spass]Vielleicht weil deine Koordinaten in der Aussenalster liegen? Quasi immer Regen, die Holländer sind sehr genau[/Spass]
So ist das mit Hausbooten ;)
Auch Festland Koordinaten liefern das gleiche.
;D
Aber wenn du auf de gehst sieht die Antwort doch besser / richtig aus:
{"success":true,"start":1589970000,"start_human":"12:20","temp":16,"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":681,"y":215},"source":"de","bounds":{"N":56.397869,"E":18.257635,"S":45.506641,"W":3.454513}}
Oder regnet es?
Zitat von: slor am 20 Mai 2020, 00:24:55
vor allem die riesigen Werte. Soll das so?
Setze ich Region auf de, kommt nichts.
So sieht der Aufruf aus:
https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=53.5653&lon=10.0014®ion=nl&unit=mm/u
Koordinaten kommen aus dem global device.
Version: 2.3.2
Hm, da liefert der Webservice einfach Müll als Input (36517.41) - das könnte der Maximalwert sein. Wie Otto schon geschrieben hat, sehen die Werte in der Region
de besser aus (hab mir eine Webcam zum Nachschauen ob es regnet gesucht). Auch ein Wert auf dem "Festland" nebenan liefert den gleichen Fehler. Sehe ich tatsächlich zum ersten Mal (https://github.com/fhem/mod-Buienradar/issues/299).
Zitat von: Otto123 am 19 Mai 2020, 22:19:46
Wenn ich jetzt wüsste wo die Release Page ist ;D
Dir kann geholfen (https://github.com/fhem/mod-Buienradar/releases) werden.
Hallo Christoph,
ich habe inzwischen auf "stable" umgestellt (aktuell v 2.3.2). ich bekomme öfters einen Fehler beim Abrufen der Daten: "Error: gethostbyname cdn-secure.buienalarm.nl failed =>". Bin ich allein betroffen? Ist dies bekannt?
Viele Grüße
Andreas
Hab gerade mal in meinen Logs geguckt. Produktiv nutze ich auch noch stable und da war in den letzten 100.000 Einträgen kein DNS-Fehler dabei. Hast du vielleicht einen Pihole eingebaut oder etwas anderes an deiner Netzwerkinfrastruktur geändert? Vielleicht einen anderen DNS-Resolver benutzt?
Zitat von: Christoph Morrison am 23 Mai 2020, 20:25:22
Hab gerade mal in meinen Logs geguckt. Produktiv nutze ich auch noch stable und da war in den letzten 100.000 Einträgen kein DNS-Fehler dabei. Hast du vielleicht einen Pihole eingebaut oder etwas anderes an deiner Netzwerkinfrastruktur geändert? Vielleicht einen anderen DNS-Resolver benutzt?
Nein, die einzige Änderung ist das Update auf die stable version. Vorher war glaube ich v.2.2.5. Der Fehler kommt in unregelmäßigen Abständen.
Dann würde ich auf Netzwerkprobleme tippen.
Sonntag, Releasetag.
Habe gerade das Pre-Release 3.0.8 (https://github.com/fhem/mod-Buienradar/releases/tag/v3.0.8) mit vielen Änderungen (https://github.com/fhem/mod-Buienradar/issues?q=is%3Aissue++milestone%3A3.0.8) veröffentlicht und nach testing gemerged.
⚠️ Achtung!
- JSON::MaybeXS is now a mandatory module
- The HTML bar chart must now be retrieved with FHEM::Buienradar::chart_html_bar() instead of FHEM::Buienradar::HTML()
- The Text bar chart must now be retrieved with FHEM::Buienradar::chart_textbar() instead of FHEM::Buienradar::TextChart()
- The Google chart must now be retrieved with FHEM::Buienradar::chart_gchart() instead of FHEM::Buienradar::GChart()
- The LogProxy wrapper must now be called with FHEM::Buienradar::logproxy_wrapper instead of FHEM::Buienradar::LogProxy()
Zitat von: Christoph Morrison am 24 Mai 2020, 15:06:00
Dann würde ich auf Netzwerkprobleme tippen.
Ich habe jetzt auch die ganz neue Version probiert und stoße auf das gleiche Problem :(.
Mein FHEM läuft auf Debian 10 in einer VM auf der QNAP. Router ist eine aktuelle Fritz!Box mit T-Online Verbindung. Um das Problem einzugrenzen, habe ich "nslookup" innerhalb der Debian VM abgesetzt:
> bild.de
Server: 192.168.5.1
Address: 192.168.5.1#53
Non-authoritative answer:
Name: bild.de
Address: 145.243.248.20
Name: bild.de
Address: 145.243.240.20
> cdn-secure.buienradar.nl
Server: 192.168.5.1
Address: 192.168.5.1#53
** server can't find cdn-secure.buienradar.nl: NXDOMAIN
"bild.de" und auch sämtliche andere Webadressen, welche in FHEM verwendet werden, werden sauber aufgelöst. Nur bei cdn-secure.buienradar.nl gibt es kein Ergebnis?! Der nslookup liefert auf meinem Windows Rechner (direkt an der Fritz!Box die richtige IP zurück! Diese IP habe ich jetzt in die hosts-Datei vom Debian hinzugefügt. Leider auch keine Verbesserung. Was könnte das sein und hat jemand noch eine Idee zur Eingrenzung?
Bei mir heisst das Teil
cdn-secure.buienalarm.nl
im Internal url ;)
Auch wenn das Modul dann radar heisst
Gruß Otto
Zitat von: Otto123 am 24 Mai 2020, 23:26:52
Bei mir heisst das Teil
cdn-secure.buienalarm.nl
im Internal url ;)
Auch wenn das Modul dann radar heisst
Gruß Otto
Manchmal sieht man den Wald vor lauter Bäumen nicht ;). Aber daran lag es nicht, konnte ja auch auf meinem Windows die cdn-secure.buienalarm.nl auflösen. Es liegt wohl am CDN (Cloudflare) in Verbindung mit dem virtuellen Switch auf der QNAP. Habe jetzt in der Debian VM die DNS Server von Cloudflare (1.1.1.1 und 1.0.0.1) eingetragen. --- und siehe da, es flutscht ;D (auch mit der 3.0.8 und den neuen Settings.
Zitat von: Christoph Morrison am 20 Mai 2020, 14:13:17
Hm, da liefert der Webservice einfach Müll als Input (36517.41) - das könnte der Maximalwert sein. Wie Otto schon geschrieben hat, sehen die Werte in der Region de besser aus (hab mir eine Webcam zum Nachschauen ob es regnet gesucht). Auch ein Wert auf dem "Festland" nebenan liefert den gleichen Fehler. Sehe ich tatsächlich zum ersten Mal (https://github.com/fhem/mod-Buienradar/issues/299).
Ich habe das jetzt seit ein paar Tagen auf de laufen und die Werte passen halbwegs. Hat halt nur nicht geregt, daher war alles au 0.
Könnte man die Readings statt mit Unknown mit etwas anderem füllen? Wie z.B. not available oder not provided? Unknown hört sich so an als ob was nicht in Ordnung ist.
state steht übriges immer auf unknown bei mir.
Zitat von: slor am 27 Mai 2020, 12:13:08
Ich habe das jetzt seit ein paar Tagen auf de laufen und die Werte passen halbwegs. Hat halt nur nicht geregt, daher war alles au 0.
Könnte man die Readings statt mit Unknown mit etwas anderem füllen? Wie z.B. not available oder not provided? Unknown hört sich so an als ob was nicht in Ordnung ist.
state steht übriges immer auf unknown bei mir.
Ich wäre für einen Wert "0.000" anstatt "unknown".
Dann weiß man ja nicht ob es wirklich 0 ist oder nur nix in den Daten.
Zitat von: slor am 27 Mai 2020, 12:13:08
Ich habe das jetzt seit ein paar Tagen auf de laufen und die Werte passen halbwegs. Hat halt nur nicht geregt, daher war alles au 0.
Könnte man die Readings statt mit Unknown mit etwas anderem füllen? Wie z.B. not available oder not provided? Unknown hört sich so an als ob was nicht in Ordnung ist.
state steht übriges immer auf unknown bei mir.
Prinzipiell kommt die Diskussion zu einer guten Zeit, denn im Rahmen einer Major-Version könnte man das mitändern.
Für mich hört sich
unknown allerdings an, als wäre der Wert aktuell nicht bekannt und ich würde da auch nicht auf einen Fehler schließen.
0(.000) ist nicht korrekt benutzbar, denn das ist der Wert wenn es keinen Regen gibt, da hast du Recht.
undef funktioniert als Wert im Framework nicht, wäre aber in Perl der richtige Wert (einfach undefiniert).
null wäre auch noch eine Option, aber auch nicht besser benutzbar und hätte auch nicht mehr Aussagekraft als
unknown und sagt dem Gemeinen User vermutlich auch nicht mehr als unknown.
Ich bin für Argumente offen, aber sehe aktuell keinen Änderungsbedarf, bzw. keine bessere Variante.
So sehen meine Readings aus.
rainBegin, rainEnd, rainNow und state stehen auf unknown.
Wechselt state mal auf irgendwas anderes? Könnte man das nicht in rain/norain ändern oder die aktuelle regenmenge oder ok für daten erfolgreich abgeholt?
Bei den anderen bin ich mir nicht so sicher, was sinnvoll ist.
ggf. für rainNow yes/now?
rainBegin und rainEnd werden nur gefüllt wenn es auch wirlich regent? Das könnte man evtl. mit 00:00 als default füllen. oder NoData.
Readings
rainAmount 0.000 2020-06-02 10:41:36
rainBegin unknown 2020-06-02 10:41:36
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 2020-06-02 10:41:36
rainDataEnd 12:35 2020-06-02 10:41:36
rainDataStart 10:30 2020-06-02 10:41:36
rainDuration 0 2020-06-02 10:41:36
rainDurationIntervals 0 2020-06-02 10:41:36
rainDurationPercent 0 2020-06-02 10:41:36
rainDurationTime 00:00 2020-06-02 10:41:36
rainEnd unknown 2020-06-02 10:41:36
rainLaMetric 0,0,0,0,0,0,0,0,0,0,0,0 2020-06-02 10:41:36
rainMax 0.000 2020-06-02 10:41:36
rainNow unknown 2020-06-02 10:41:36
rainTotal 0.000 2020-06-02 10:41:36
state unknown 2020-06-02 10:41:36
Vorab: Welche Version benutzt du?
Zitat von: slor am 02 Juni 2020, 10:56:02
rainBegin, rainEnd, rainNow und state stehen auf unknown.
Ok, wenn es aktuell keine Informationen über diese Daten gibt.
Zitat von: slor am 02 Juni 2020, 10:56:02
Wechselt state mal auf irgendwas anderes? Könnte man das nicht in rain/norain ändern oder die aktuelle regenmenge oder ok für daten erfolgreich abgeholt?
Klar.
state nimmt sogar verschiedene an, z.B. Fehler (https://github.com/fhem/mod-Buienradar/blob/1d98f479ba420e06ccfd85404bd7904e5b514422/FHEM/59_Buienradar.pm#L812) wenn der Datenabruf fehlgeschlagen ist oder halt die aktuelle Regenmenge (https://github.com/fhem/mod-Buienradar/blob/1d98f479ba420e06ccfd85404bd7904e5b514422/FHEM/59_Buienradar.pm#L921).
unknown bedeutet nur, dass es aktuell keine Daten gibt.
Zitat von: slor am 02 Juni 2020, 10:56:02
Bei den anderen bin ich mir nicht so sicher, was sinnvoll ist.
ggf. für rainNow yes/now?
rainNow enthält die aktuelle Regenmenge (und damit indirekt, ob es regnet oder nicht). Steht auf
unknown wenn es keine Daten gibt, sonst auf der Regenmenge. Da könnte man vielleicht tatsächlich 0 als default-Wert (https://github.com/fhem/mod-Buienradar/issues/311) nehmen (kein Regen).
Zitat von: slor am 02 Juni 2020, 10:56:02
rainBegin und rainEnd werden nur gefüllt wenn es auch wirlich regent? Das könnte man evtl. mit 00:00 als default füllen. oder NoData.
00:00 könnte eine valide Uhrzeit sein, geht also nicht.
NoData ist auch nicht korrekt, denn es gibt ggf. Daten aber der nächste Zeitpunkt ist nicht bekannt. Da passt
unknown also auch.
Version 2.3.2
Ich bin mit allem Happy.
Morgen soll es hier regnen, dann gucke ich mir die Readings Mal in Action an...
Ich bin für "0" für "RainNow" :D
Ich möchte das Modul für die Regenwarnung nutzen, um z.B. die Dachfenster zu schliessen. Im Moment bin ich noch am Testen, welcher Wert am besten dafür (DOIF) geeignet ist. Numerische Zahlen helfen natürlich ungemein dafür, da man einfach >=0.5 o.ä. verwenden kann.
Zur Bewertung, was ein sinnvoller Schwellwert ist, habe ich mir einen Chart in FTUI gebaut, welcher auch die Daten von Netatmo beinhaltet. Mal sehen, wann es das nächste Mal regnet ;).
Viele Grüße
Andreas
jetzt regnet es gerade...
Buienradar hat mit 10 Minütiger Verspätung Regen gemeldet... Mal sehen ob das immer so ungenau ist hier
rainAmount 5.090 2020-06-03 16:41:06
rainBegin 16:30 2020-06-03 16:41:06
rainData 1.43:1.91:1.24:0.37:0.08:0.02:0.01:0:0.02:0.01:0:0:0:0:0.01:0.03:0.08:0.18:0.6:1.15:2.37:8.06:15.4:10:6.98 2020-06-03 16:41:06
rainDataEnd 18:35 2020-06-03 16:41:06
rainDataStart 16:30 2020-06-03 16:41:06
rainDuration 100 2020-06-03 16:41:06
rainDurationIntervals 20 2020-06-03 16:41:06
rainDurationPercent 80 2020-06-03 16:41:06
rainDurationTime 01:40 2020-06-03 16:41:06
rainEnd unknown 2020-06-03 16:35:06
rainLaMetric 1430,1910,1240,370,80,20,10,0,20,10,0,0 2020-06-03 16:41:06
rainMax 15.400 2020-06-03 16:41:06
rainNow 1.240 2020-06-03 16:41:06
rainTotal 49.950 2020-06-03 16:41:06
state 1.240 2020-06-03 16:41:06
Hat schon jemand ein schönes SVG Plot für die Werte gebaut? Wäre am Code interessiert.
So, Regen erst mal vorbei. Regenmenge stimmt halbwegs. ~300ml unterschied zu meiner Messung.
Gelernt habe ich, dass man RainBegin nicht als Trigger verwenden kann. Das wird bei Regen alle 10 min auf ca. 10 min davor gesetzt.
Hatte mir ein Doif auf RainBegin gebaut, dass mir eine Telegram Nachricht bei einer Veränderung von RainBegin sendet.
Das ist die Ausbeute :-)
Home, [03.06.20 16:33]
"rainBegin: 17:55"
Home, [03.06.20 16:35]
"rainBegin: 17:55"
Home, [03.06.20 16:41]
"rainBegin: 16:30"
Home, [03.06.20 16:47]
"rainBegin: 16:35"
Home, [03.06.20 16:53]
"rainBegin: 16:40"
Home, [03.06.20 16:59]
"rainBegin: 16:50"
Home, [03.06.20 17:05]
"rainBegin: 16:55"
Home, [03.06.20 17:17]
"rainBegin: 17:05"
Home, [03.06.20 17:23]
"rainBegin: 17:15"
Home, [03.06.20 17:29]
"rainBegin: 17:20"
Home, [03.06.20 17:35]
"rainBegin: 17:25"
Home, [03.06.20 17:41]
"rainBegin: 17:30"
Home, [03.06.20 17:47]
"rainBegin: 17:35"
Home, [03.06.20 17:53]
"rainBegin: 17:40"
Home, [03.06.20 17:59]
"rainBegin: 17:50"
Home, [03.06.20 18:05]
"rainBegin: 17:55"
Home, [03.06.20 18:17]
"rainBegin: 18:05"
Home, [03.06.20 18:23]
"rainBegin: 18:15"
Home, [03.06.20 18:29]
"rainBegin: 18:20"
Home, [03.06.20 18:35]
"rainBegin: 18:25"
Home, [03.06.20 18:41]
"rainBegin: 18:30"
Home, [03.06.20 18:47]
"rainBegin: 18:35"
Home, [03.06.20 18:53]
"rainBegin: 18:45"
Home, [03.06.20 19:41]
"rainBegin: 20:30"
Home, [03.06.20 19:47]
"rainBegin: 20:25"
Zitat von: slor am 03 Juni 2020, 20:01:27
So, Regen erst mal vorbei. Regenmenge stimmt halbwegs. ~300ml unterschied zu meiner Messung.
Gelernt habe ich, dass man RainBegin nicht als Trigger verwenden kann. Das wird bei Regen alle 10 min auf ca. 10 min davor gesetzt.
Interessant. Das werde ich mir mal bei einem der nächsten Milestones anschauen. Das ist ein Bereich des Codes, den ich praktisch komplett von LuBeDa übernommen und noch nicht wirklich logisch durchdrungen habe.
Am Ende werde ich wohl den ganzen Data-Retrieval-Teil mal neu schreiben müssen :-(
Wir hatten jetzt einigen Regen und ich konnte die Daten mit dem tatsächlichen Geschehen und der Regenmenge der Netatmo Station vergleichen. Für die Regenwarnung verwende ich nun "rainMax" mit 1.2 als Schwellwert.
Viele Grüße
Andreas
Zitat von: slor am 03 Juni 2020, 16:47:17
Hat schon jemand ein schönes SVG Plot für die Werte gebaut? Wäre am Code interessiert.
Das würde mich auch interessieren. Meine bisherigen Versuche mit dem logproxy waren leider erfolglos.
Wichtige Vorankündigung!
Mit der (Re-)Implementierung des ColourBarCharts und der Unterstützung von will-it-rain-at-Anfragen (wird es zu einem angegebenen Zeitpunkt regnen) wird die Version 3.0 erstmal feature complete sein und - nach ein paar Wochen - auf stable gehen. Ich plane die 3.0 etwa Ende Juli / Anfang August als stable zu markieren. Es wird dann all die API-Änderungen in stable geben, die bisher nur in testing / development-3.0 zu finden sind.
Mit einem Update werden die bisher eingebundenen Charts über weblink erstmal nicht mehr funktionieren!
ZitatZitat von: slor am 03 Juni 2020, 20:01:27
Gelernt habe ich, dass man RainBegin nicht als Trigger verwenden kann. Das wird bei Regen alle 10 min auf ca. 10 min davor gesetzt.
Hallo Christoph,
das war mir ja auch schon aufgefallen, und das hatte ich Dir in meiner PM vom 10 Mai, siehe Antwort #156 in diesem Thread, auch schon geschrieben,
das Rainbeginn bei Regen alle 10 min auf ca. 10 min davor gesetz wird. Abhilfe ist im aktuellen 3.0.8 code, hinter dem Block
for my $precip_index ( 0 .. $precip_length ) {
my $start = $forecast_start + $precip_index * $INTERVAL_LENGHT_SECONDS;
my $end = $start + $INTERVAL_LENGHT_SECONDS;
my $precip = $precip[$precip_index];
$is_raining = undef; # reset
auf die aktuelle Zeit abzufragen, also
for my $precip_index ( 0 .. $precip_length ) {
my $start = $forecast_start + $precip_index * $INTERVAL_LENGHT_SECONDS;
my $end = $start + $INTERVAL_LENGHT_SECONDS;
my $precip = $precip[$precip_index];
$is_raining = undef; # reset
if (::time_str2num(::TimeNow()) < $start) {
}
damit die 10 Minuten die VOR der aktuellen Zeit liegen, weggeschmissen werden.
Danke!
Hallo Christoph,
das 'disabled' im Buienradar funktioniert nicht, ich bekomme immer folgende Fehlermeldung (egal ob on oder off):
Zitaton is not a valid value for disabled. Only 'on' or 'off' are allowed!
Zitat von: Jamo am 09 Juni 2020, 21:57:06
Hallo Christoph,
das 'disabled' im Buienradar funktioniert nicht, ich bekomme immer folgende Fehlermeldung (egal ob on oder off):
Welche Version benutzt du?
3.0.8
Ich nutze den FHEM-Docker-Container und scheitere am Readonly-Modul, welches du eingebunden hast.
Wirst du es weiter einsetzen? Dann muss ich mir eine Lösung einfallen lassen.
Danke.
Zitat von: FunkOdyssey am 21 Juni 2020, 11:04:55
Ich nutze den FHEM-Docker-Container und scheitere am Readonly-Modul, welches du eingebunden hast.
Wirst du es weiter einsetzen? Dann muss ich mir eine Lösung einfallen lassen.
Ja, definitiv. Du kannst den Container aber so modifizieren, dass das Paket automatisch installiert wird.
Danke für deine Antwort.
Ich habe Readonly als optionales CPAN-Package in der YML aufgenommen.
Zitat von: Christoph Morrison am 07 Juni 2020, 16:53:45
Wichtige Vorankündigung!
Mit der (Re-)Implementierung des ColourBarCharts und der Unterstützung von will-it-rain-at-Anfragen (wird es zu einem angegebenen Zeitpunkt regnen) wird die Version 3.0 erstmal feature complete sein und - nach ein paar Wochen - auf stable gehen. Ich plane die 3.0 etwa Ende Juli / Anfang August als stable zu markieren. Es wird dann all die API-Änderungen in stable geben, die bisher nur in testing / development-3.0 zu finden sind.
Mit einem Update werden die bisher eingebundenen Charts über weblink erstmal nicht mehr funktionieren!
Schafft es dieses Feature noch in ein zeitnahes Release?
https://forum.fhem.de/index.php/topic,111318.0.html
Ich bräuchte die Niederschlagsmengen der letzten Tage und aktuell.
Hi,
Zitat von: Christoph Morrison am 21 Juni 2020, 11:58:48
Ja, definitiv. Du kannst den Container aber so modifizieren, dass das Paket automatisch installiert wird.
Und hier steht wie: https://github.com/fhem/fhem-docker#add-custom-packages
LG
Christian
Zitat von: choenig am 21 Juni 2020, 13:46:37
Hi,
Und hier steht wie: https://github.com/fhem/fhem-docker#add-custom-packages
LG
Christian
Danke. War schon erledigt. Siehe Post darüber. War ein zeitgleiches Edit. Wir haben uns überschnitten.
Zitat von: FunkOdyssey am 21 Juni 2020, 13:47:53
Danke. War schon erledigt. Siehe Post darüber. War ein zeitgleiches Edit. Wir haben uns überschnitten.
Ok, hatte Deinen Post gesehen, aber nur den Teil unter dem Zitat gelesen ;).
LG
Christian
Zitat von: FunkOdyssey am 21 Juni 2020, 13:44:40
Danke für deine Antwort.
Ich habe Readonly als optionales CPAN-Package in der YML aufgenommen.
Schafft es dieses Feature noch in ein zeitnahes Release?
https://forum.fhem.de/index.php/topic,111318.0.html
Ich bräuchte die Niederschlagsmengen der letzten Tage und aktuell.
Aktuell hab ich leider nur wenig Zeit für Softwareentwicklung übrig. Verzögert sich also alles vermutlich bis Mitte Juli.
Ich würde gerne ein Reading kumulieren, so dass ich den kumulierter Niederschlag des laufenden Tages herausfinde.
Kann ich dafür das Reading rainNow nutzen? Und dann das Intervall auf 300sec einstellen, damit bei der Addition die Zeitspanne für rainNow zum Vorhersagezeitraum passt?
Oder gibt es bessere Wege?
Guck Mal hier https://forum.fhem.de/index.php/topic,111318.0.html (https://forum.fhem.de/index.php/topic,111318.0.html)
Zitat von: somansch am 07 Juni 2020, 15:31:26
Wir hatten jetzt einigen Regen und ich konnte die Daten mit dem tatsächlichen Geschehen und der Regenmenge der Netatmo Station vergleichen. Für die Regenwarnung verwende ich nun "rainMax" mit 1.2 als Schwellwert.
Viele Grüße
Andreas
Kannst du dazu bitte Mal deine doifs oder was auch immer du nutzt Posten?
Hallo,
ich versuche 59_Buienradar ans Laufen zu bringen, bekomme aber folgende Fehlermeldung bei reload 59_Buienradar:
syntax error at ./FHEM/59_Buienradar.pm line 641, near "<<~"
syntax error at ./FHEM/59_Buienradar.pm line 649, near "3ex"
syntax error at ./FHEM/59_Buienradar.pm line 650, near "2ex"
syntax error at ./FHEM/59_Buienradar.pm line 654, near "color:"
syntax error at ./FHEM/59_Buienradar.pm line 658, near "color:"
syntax error at ./FHEM/59_Buienradar.pm line 662, near "color:"
syntax error at ./FHEM/59_Buienradar.pm line 666, near "color:"
syntax error at ./FHEM/59_Buienradar.pm line 670, near "color:"
syntax error at ./FHEM/59_Buienradar.pm line 674, near "color:"
syntax error at ./FHEM/59_Buienradar.pm line 678, near "color:"
./FHEM/59_Buienradar.pm has too many errors.
DateTime und Readonly habe ich installiert.
In den Zeilen 641-650 steht folgendes:
my $colourBarChart = <<~"END_MESSAGE";
<style type="text/css">
div.buienradar table {
empty-cells: show;
width: 70%
}
div.buienradar table td {
height: 3ex;
width: 2ex;
}
Kann mir jemand helfen?
Danke,
Roland
hier selbiges Problem! Ab Zeile 641...
wie schön ist es, mit einem Problem nicht alleine zu sein ;)
Versuche dieses ~ zu entfernen.
Ich habe den Fehler gefunden.
In Zeile 600 müssen die Leerzeilen vor "END_MESSAGE" entfernt werden.
</div>
END_MESSAGE
return $colourBarChart;
}
dann gehts.
muss werden zu
</div>
END_MESSAGE
return $colourBarChart;
}
Hallo Christoph,
ich habe den Fehler von disabled in der version 3.0.8 gefunden, Zeile 340. Die invertierung fehlt, also anstatt
if ( List::Util::any { $_ eq $attribute_value } qw{ on off 0 1 } );
muss es
if (!List::Util::any { $_ eq $attribute_value } qw{ on off 0 1 } );
heissen.
Zitat von: Jamo am 09 Juni 2020, 21:57:06
Hallo Christoph,
das 'disabled' im Buienradar funktioniert nicht, ich bekomme immer folgende Fehlermeldung (egal ob on oder off):
Zitat von: Christoph Morrison am 09 Juni 2020, 22:08:25
Welche Version benutzt du?
Hallo, ich versuche das Modul zu integrieren, finde aber leider keine Anleitung.
Habe bis jetzt folgendes gemacht:
- Modul 59_Buienradar unter /opt/fhem/FHEM abgelegt
- apt-get install libdatetime-perl
alles neugestartet, aber im Log kommt folgendes: Danke für eure Hilfe!!!
020.07.16 15:33:34 1: PERL WARNING: Use of bare << to mean <<"" is deprecated at ./FHEM/59_Buienradar.pm line 641, <$fh> line 876.
2020.07.16 15:33:34 1: PERL WARNING: Bareword found where operator expected at ./FHEM/59_Buienradar.pm line 649, near "3ex"
2020.07.16 15:33:34 1: PERL WARNING: (Missing operator before ex?)
2020.07.16 15:33:34 1: PERL WARNING: Bareword found where operator expected at ./FHEM/59_Buienradar.pm line 650, near "2ex"
2020.07.16 15:33:34 1: reload: Error:Modul 59_Buienradar deactivated:
syntax error at ./FHEM/59_Buienradar.pm line 641, near "<<~"
syntax error at ./FHEM/59_Buienradar.pm line 649, near "3ex"
syntax error at ./FHEM/59_Buienradar.pm line 650, near "2ex"
syntax error at ./FHEM/59_Buienradar.pm line 654, near "color:"
syntax error at ./FHEM/59_Buienradar.pm line 658, near "color:"
syntax error at ./FHEM/59_Buienradar.pm line 662, near "color:"
syntax error at ./FHEM/59_Buienradar.pm line 666, near "color:"
syntax error at ./FHEM/59_Buienradar.pm line 670, near "color:"
syntax error at ./FHEM/59_Buienradar.pm line 674, near "color:"
syntax error at ./FHEM/59_Buienradar.pm line 678, near "color:"
./FHEM/59_Buienradar.pm has too many errors.
2020.07.16 15:33:34 0: syntax error at ./FHEM/59_Buienradar.pm line 641, near "<<~"
syntax error at ./FHEM/59_Buienradar.pm line 649, near "3ex"
syntax error at ./FHEM/59_Buienradar.pm line 650, near "2ex"
syntax error at ./FHEM/59_Buienradar.pm line 654, near "color:"
syntax error at ./FHEM/59_Buienradar.pm line 658, near "color:"
syntax error at ./FHEM/59_Buienradar.pm line 662, near "color:"
syntax error at ./FHEM/59_Buienradar.pm line 666, near "color:"
syntax error at ./FHEM/59_Buienradar.pm line 670, near "color:"
syntax error at ./FHEM/59_Buienradar.pm line 674, near "color:"
syntax error at ./FHEM/59_Buienradar.pm line 678, near "color:"
./FHEM/59_Buienradar.pm has too many errors.
Ich habe es nach dieser Anleitung installiert und es läuft:
https://github.com/fhem/mod-Buienradar/releases (https://github.com/fhem/mod-Buienradar/releases)
VG Dieter
@dk3572
Entschuldigung, aber ich finde da keine Anleitung. Dafür bin ich vielleicht nicht versiert genug.
Aber trotzdem Danke
Grüße Molli
Using this release
Add new source by update add https://raw.githubusercontent.com/fhem/mod-Buienradar/v3.0.8/controls_Buienradar.txt
Check with update check
update Buienradar
In fhem einfügen:
update add https://raw.githubusercontent.com/fhem/mod-Buienradar/v3.0.8/controls_Buienradar.txt
dann
update check
dann
update Buienradar
Readonly und JSON::MaybeXS bitte nicht vergessen.
wo wir grad dabei sind, wie bekomme ich solch eine Visualisierung hin?
https://forum.fhem.de/index.php/topic,102497.msg1057319.html#msg1057319 (https://forum.fhem.de/index.php/topic,102497.msg1057319.html#msg1057319)
Für Hilfe dankbar und VG Dieter
@ dk3572
bekomme aber folgendes:
"Buienradar
UPD FHEM/59_Buienradar.pm
open ./FHEM/59_Buienradar.pm failed: Permission denied, trying to restore the previous version and aborting the update"
und was bedeutet: "Readonly und JSON::MaybeXS bitte nicht vergessen."
Dankeschön!
ich würde die zuvor händisch kopierte 59_Buienradar.pm wieder löschen und von vorne beginnen.
Zitat von: molli123 am 16 Juli 2020, 16:30:57
und was bedeutet: "Readonly und JSON::MaybeXS bitte nicht vergessen."
Diese beiden Perl Module müssen installiert werden. Um zu klären ob diese schon installiert sind, helfen vielleicht meine Notizen (https://heinz-otto.blogspot.com/2019/07/infos-zur-installation-von-modulen-und.html).
Permission:
Im Terminal:
chown -R fhem: /opt/fhem
Gruß Otto
Hallo,
so hab mich durchgekämpft!
- kopiertes Modul gelöscht
- neues über Updatebefehl hinzugefügt
- sudo apt-get install -y libjson-maybexs-perl ausgefüht
- sudo apt-get install -y libreadonly-xs-perl ausgeführt
- attribut Region auf "de" gestellt
Log zeigt eine Meldung an:
2020.07.17 09:21:29 1: PERL WARNING: Use of uninitialized value $precip in numeric gt (>) at ./FHEM/59_Buienradar.pm line 677.
und in den readings stehen nur nullen und unknown? ist das normal?
Vielen Dank!
Ja, das ist normal und ändert sich mit dem ersten Regen
Intended Here-Docs are introduced with Perl v5.26 #321 (https://github.com/fhem/mod-Buienradar/issues/321)
Bei mir werden seit gestern Morgen (28.10.2020 7Uhr) keine Daten mehr aktualisiert. Über den direkten API Aufruf sehe ich, dass es nicht am Modul liegt, sondern am "Datenlieferant".
Habt ihr das gleiche Problem?
Viele Grüße
Andreas
Zitat von: somansch am 29 Oktober 2020, 08:54:47
Habt ihr das gleiche Problem?
Hab gerade mal geschaut: Nein, bekomme für meinen Standort (https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=51.9293504&lon=8.377413199999978®ion=nl&unit=mm/u) aktuelle Daten. Zeig mal ein list deines Devices.
Hier mein List:
defmod Regen Buienradar xx.xxxxxx xx.xxxxxx
attr Regen event-on-update-reading .*
attr Regen interval 180
attr Regen region de
attr Regen room 096_Wetter
attr Regen stateFormat rainMax
setstate Regen 3.650
setstate Regen 2020-10-29 11:03:48 rainAmount 0.000
setstate Regen 2020-10-29 11:03:48 rainBegin 05:35
setstate Regen 2020-10-29 11:03:48 rainData 0:0:0:0:0:0:0:0:0.03:0.25:0.34:0.27:0.22:0.09:0.02:0.03:0.1:0.05:0:0:0:0.42:3.65:1.65:0.42
setstate Regen 2020-10-29 11:03:48 rainDataEnd 07:00
setstate Regen 2020-10-29 11:03:48 rainDataStart 04:55
setstate Regen 2020-10-29 11:03:48 rainDuration 70
setstate Regen 2020-10-29 11:03:48 rainDurationIntervals 14
setstate Regen 2020-10-29 11:03:48 rainDurationPercent 56
setstate Regen 2020-10-29 11:03:48 rainDurationTime 01:10
setstate Regen 2020-10-29 11:03:48 rainEnd 07:00
setstate Regen 2020-10-29 11:03:48 rainLaMetric 0,0,0,0,0,0,0,0,30,250,340,270
setstate Regen 2020-10-29 11:03:48 rainMax 3.650
setstate Regen 2020-10-29 11:03:48 rainNow unknown
setstate Regen 2020-10-29 11:03:48 rainTotal 7.540
setstate Regen 2020-10-29 11:03:48 state unknown
Ohne deine Standort-Daten wird's leider nicht gehen. Das ist übrigens auch kein list, sondern die raw def.
Zitat von: Christoph Morrison am 29 Oktober 2020, 11:29:10
Ohne deine Standort-Daten wird's leider nicht gehen. Das ist übrigens auch kein list, sondern die raw def.
Ok, ich schicke dir das List per PN ;)
@Christoph: Wie geht es mit Buienradar nun eigentlich weiter?
Ich habe hier (https://forum.fhem.de/index.php/topic,113722.msg1079869.html#msg1079869) vor ein paar Wochen gelesen, dass du die Modulentwicklung aufgeben willst.
Willst du das Modul an jemanden weiterreichen?
Wäre wirklich schade, wenn der jetzige Stand verloren gehen würde.
Zitat von: somansch am 29 Oktober 2020, 11:37:49
Ok, ich schicke dir das List per PN ;)
Ja kann ich bestätigen, auch im nächst größeren Ort P. gibt es keine aktuellen Daten über die API, aber welche bei BR direkt. Ist wohl ein Problem bei denen, das nur die API betrifft.
Du kannst ja denen mal schreiben, dass ihre API keine Daten mehr für deinen Standort liefert.
Zitat von: Christoph Morrison am 29 Oktober 2020, 11:52:54
Ja kann ich bestätigen, auch im nächst größeren Ort P. gibt es keine aktuellen Daten über die API, aber welche bei BR direkt. Ist wohl ein Problem bei denen, das nur die API betrifft.
Du kannst ja denen mal schreiben, dass ihre API keine Daten mehr für deinen Standort liefert.
Danke dir :). Hast du einen Link für die API Doku bzw. Kontaktinfo? Per URL werde ich auf "Drops" geleitet, leider ist auf dieser Seite kein Verweis zur API bzw. Kontakt.
Zitat von: FunkOdyssey am 29 Oktober 2020, 11:39:41
@Christoph: Wie geht es mit Buienradar nun eigentlich weiter?
Ich habe hier (https://forum.fhem.de/index.php/topic,113722.msg1079869.html#msg1079869) vor ein paar Wochen gelesen, dass du die Modulentwicklung aufgeben willst.
Ich schildere kurz mal das Problem von meiner Seite aus: Das BR-Modul ist im Prinzip ein JSON-Downloader + -Parser + Gedöns für die davon abgeleiteten Werte. Ich habe aber ein paar eigene, private Module, die ebenfalls JSON-Downloader + Gedöns sind -- sie teilen Code und haben eine Dependency zum JSON-Downloader-Modul. Nun möchte ich natürlich nicht
n JSON-Downloader pflegen, sondern nur einen, deshalb habe ich den in ein eigenes Modul verpackt, das ich privat ja auch problemlos verteilen kann. Die Dependencies sind geregelt.
Ich kann aber keine Dependencies über den FHEM-Updater verteilen, ohne es
für euch wirklich unangenehm zu machen oder Logik in das BR-Modul zu packen, der da auch nicht hin gehört (dependency management). Deshalb steht das BR-Modul auf dem Stand, auf dem es steht (Stable v2.3) und alles darüber ist nur Alpha und erfährt aktuell keine Pflege.
Selbst wenn ich einen neuen Updater schreiben würde, der dann z.B. Dependencies beherrscht (was ein gigantischer Aufwand und doppelte Arbeit wäre, denn es gibt bereits einen Perl-Paketmanager: CPAN), müsste der von euch dann noch vorher installiert werden und wäre auch eine Dependency. Ein Umzug nach CPAN ist auch nicht so einfach, denn dann müsste man deutlich mehr Sachen auch dorthin umziehen, in erster Linie vorallem mal FHEM selbst.
Zitat von: FunkOdyssey am 29 Oktober 2020, 11:39:41
Willst du das Modul an jemanden weiterreichen?
Wäre wirklich schade, wenn der jetzige Stand verloren gehen würde.
Die Software ist ja unter einer freien Lizenz (https://github.com/fhem/mod-Buienradar/blob/stable/LICENSE) und kann von jedem geforkt und weiter entwickelt werden, der sich dazu berufen fühlt. Schreibrechte hat jeder darauf, der auf Github in der FHEM-Core-Gruppe ist.
Zitat von: somansch am 29 Oktober 2020, 12:06:11
Danke dir :). Hast du einen Link für die API Doku bzw. Kontaktinfo? Per URL werde ich auf "Drops" geleitet, leider ist auf dieser Seite kein Verweis zur API bzw. Kontakt.
Ich würde https://www.buienradar.nl/overbuienradar/contact versuchen.
Buienradar liefert für Deutschland gerade keine aktuellen Daten mehr.
Bzw wird immer der gleiche json string geliefert, e.g. https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=49.1234&lon=11.4321®ion=de&unit=mm/u, der timestamp "start":1603857300,"start_human":"04:55" bleibt immer gleich.Ist das bei euch auch so?
Zitat von: Jamo am 30 Oktober 2020, 11:52:11
Buienradar liefert für Deutschland gerade keine aktuellen Daten mehr.
Bzw wird immer der gleiche json string geliefert, e.g. https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=49.1234&lon=11.4321®ion=de&unit=mm/u, der timestamp "start":1603857300,"start_human":"04:55" bleibt immer gleich.Ist das bei euch auch so?
Lies mal drei Postings oder so über deinem. Nein, BR liefert hier (https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=51.9293504&lon=8.377413199999978®ion=nl&unit=mm/u) z.B. aktuell Daten.
Der Unterschied: Wenn ich die Region hier von
nl auf
de ändere - liefert BR auch nur alte Daten. Damit kann eigentlich jeder BR vergessen, der nicht mit Region
nl Daten bekommt - für Deutschland. Entweder haben die die Belieferung kommentarlos eingestellt oder es ist ein Bug in der API dort.
Hi Christoph, danke.
Ja, ich habe gesehen das fuer NL die Daten weiterhin aktualisiert werden, aber eben fuer DE nicht. Bis zum 27.10 oder 28.10 hat es immer funktioniert. Schade.
Ich habe nun auch mal dort hin geschrieben und nachgefragt.
Zitat von: Christoph Morrison am 30 Oktober 2020, 12:16:48
Ich habe nun auch mal dort hin geschrieben und nachgefragt.
Hast du schon Antwort bekommen? Ich habe am Donnerstag mal nachgefragt und bisher noch keinerlei Feedback :(
Nein bisher nicht.
Buienalarm scheint das Backend Problem gelöst zu haben. Ich bekomme wieder aktuelle Daten :)
Stimm, geantwortet haben sie allerdings trotzdem nicht. Naja, wir bezahlen ja auch nix ;-)
Hallo,
{ FHEM::Buienradar::GChart("buienradar device name")} liefert ja ein PNG Bild
Wäre es auch denkbar die URL des Bildes zurück zuliefern um dann das Bild aus der URL in Tablet UI anzeigen zu lassen?
VG
Olli
Hallo Olli,
das PNG wird von Google Charts generiert, nicht von Buienradar - Buienradar generiert nur JavaScript-Code für Google Charts. Deshalb kann man leider keine URI generieren.
Zitat von: Christoph Morrison am 14 Dezember 2020, 21:28:53
Hallo Olli,
das PNG wird von Google Charts generiert, nicht von Buienradar - Buienradar generiert nur JavaScript-Code für Google Charts. Deshalb kann man leider keine URI generieren.
Ok, trotzdem vielen dank für die schnelle Antwort.
Grüße
Olli
Zitat von: Christoph Morrison am 14 Dezember 2020, 21:28:53
Hallo Olli,
das PNG wird von Google Charts generiert, nicht von Buienradar - Buienradar generiert nur JavaScript-Code für Google Charts. Deshalb kann man leider keine URI generieren.
Wie könnte man realisieren das der erzeugte Code automatisch in eine .html Datei gespeichert wird?
Theoretisch kann man so ein Bild abspeichern (https://developers.google.com/chart/interactive/docs/printing), aber ich habe von Google Charts keine Ahnung. Der Code stammt vom Vorersteller und wurde von mir nur übernommen und ein wenig refaktoriert.
Da ich außerdem (vorerst) an Buienradar für FHEM gar nicht mehr weiterarbeite, würde eine solche Funktion sowieso nie in den Code kommen.
Zitat von: Christoph Morrison am 21 Dezember 2020, 19:24:22
Theoretisch kann man so ein Bild abspeichern (https://developers.google.com/chart/interactive/docs/printing), aber ich habe von Google Charts keine Ahnung. Der Code stammt vom Vorersteller und wurde von mir nur übernommen und ein wenig refaktoriert.
Da ich außerdem (vorerst) an Buienradar für FHEM gar nicht mehr weiterarbeite, würde eine solche Funktion sowieso nie in den Code kommen.
Alles klar, danke!
Buienradar liefert wohl seit dem 2021-03-11 morgens keine Daten mehr aus, ist das bei euch auch so?
Zitat von: Jamo am 15 März 2021, 12:33:51
Buienradar liefert wohl seit dem 2021-03-11 morgens keine Daten mehr aus, ist das bei euch auch so?
Leider wahr.
Seit heute morgen gehts wieder!
Hallo Gemeinde,
ich bekomme beim Versuch ein Chart zu generieren folgenden Fehler.
Undefined subroutine &FHEM::Buienradar::GChart called at (eval 57775) line 1
Hat jemand eine Idee?
Welche Version nutzt du? Hast du überhaupt ein Buienradar-Device definiert? Wenn nicht, kennt FHEM die Subroutinen von BR nicht.
Hallo Chritoph,
ich benutze Verion 3.0.8 und habe auch ein device definiert.
Es werden auch Daten geliefert. Soweit scheint alles ok zu sein.
Einzig, dass aus den gelieferten Daten dann keine Grafik erzeugt wird, da beim Anlegen mit
define Buienradar_gChart weblink htmlCode { FHEM::Buienradar::GChart("mein device")}
diese Fehlermeldung kommt.
Du solltest keine Beta-Version (Version 3.x) benutzen. Da wurden die meisten Funktionsaufrufe umbenannt.
Ansonsten bitte immer die Release Notes lesen: https://github.com/fhem/mod-Buienradar/releases/tag/v3.0.8 - da steht auch die Lösung zu deinem Problem.
Hallo,
seit einiger Zeit zeigt Buinenradar keine Regenmengen mehr an.
List:
Internals:
DEF 50.779647 6.153432
FUUID 5f326c9a-f33f-8133-9f51-c9f552c6ecac4870
INTERVAL 240
LATITUDE 50.779647
LONGITUDE 6.153432
NAME BuienRadar
NEXTUPDATE 2021-05-09 13:19:14
NR 943
REGION de
STATE unknown
TYPE Buienradar
URL https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=50.779647&lon=6.153432®ion=de&unit=mm/u
VERSION 3.0.8
READINGS:
2021-05-09 13:15:14 rainAmount unknown
2021-05-09 13:15:14 rainBegin unknown
2021-05-09 13:15:14 rainData unknown
2021-05-09 13:15:14 rainDataEnd unknown
2021-05-09 13:15:14 rainDataStart unknown
2021-05-09 13:07:15 rainDuration 0
2021-05-09 13:07:15 rainDurationIntervals 0
2021-05-09 13:07:15 rainDurationPercent 0
2021-05-09 13:07:15 rainDurationTime 00:00
2021-05-09 13:15:14 rainEnd unknown
2021-05-09 13:15:14 rainLaMetric unknown
2021-05-09 13:15:14 rainMax unknown
2021-05-09 13:15:14 rainNow unknown
2020-08-15 14:43:43 rainNow_rounded 0.00
2021-05-09 13:15:14 rainTotal unknown
2021-05-09 13:15:14 state Pulling https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=50.779647&lon=6.153432®ion=de&unit=mm/u returns HTTP status code 502 instead of 200.
Attributes:
group Wetter
icon weather_rain_gauge
interval 240
region de
room 90_System
stateFormat rainTotal
Hat sich bei Buinenradar etwas geändert ?
Ich habe zum Testen parallel RainTMC installiert. Da wurde der Regen der letzten Tage angezeigt, bei Buienenradar blieb alles bei 0
Wenn ich set buienenradar refresh aufrufe werden die unknown Readings manchmal mit 0 Werten gesetzt, auch wenn's eigentlich regnet.
Internals:
DEF 50.779647 6.153432
FUUID 5f326c9a-f33f-8133-9f51-c9f552c6ecac4870
INTERVAL 240
LATITUDE 50.779647
LONGITUDE 6.153432
NAME BuienRadar
NEXTUPDATE 2021-05-09 13:27:14
NR 943
REGION de
STATE 0.000
TYPE Buienradar
URL https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=50.779647&lon=6.153432®ion=de&unit=mm/u
VERSION 3.0.8
READINGS:
2021-05-09 13:24:19 rainAmount 0.000
2021-05-09 13:24:19 rainBegin unknown
2021-05-09 13:24:19 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
2021-05-09 13:24:19 rainDataEnd 17:50
2021-05-09 13:24:19 rainDataStart 15:45
2021-05-09 13:24:19 rainDuration 0
2021-05-09 13:24:19 rainDurationIntervals 0
2021-05-09 13:24:19 rainDurationPercent 0
2021-05-09 13:24:19 rainDurationTime 00:00
2021-05-09 13:24:19 rainEnd unknown
2021-05-09 13:24:19 rainLaMetric 0,0,0,0,0,0,0,0,0,0,0,0
2021-05-09 13:24:19 rainMax 0.000
2021-05-09 13:24:19 rainNow unknown
2020-08-15 14:43:43 rainNow_rounded 0.00
2021-05-09 13:24:19 rainTotal 0.000
2021-05-09 13:24:19 state unknown
Attributes:
group Wetter
icon weather_rain_gauge
interval 240
region de
room 90_System
stateFormat rainTotal
Beim nächsten refresh aber meist wieder auf unknown
Danke,
hatte die Release-Note nicht gesehen.
Funktioniert jetzt.
Zitat von: hanswerner1 am 09 Mai 2021, 13:29:11
Hallo,
seit einiger Zeit zeigt Buinenradar keine Regenmengen mehr an.
List:
Internals:
...
stateFormat rainTotal
Hat sich bei Buinenradar etwas geändert ?
Ich habe zum Testen parallel RainTMC installiert. Da wurde der Regen der letzten Tage angezeigt, bei Buienenradar blieb alles bei 0
Wenn ich set buienenradar refresh aufrufe werden die unknown Readings manchmal mit 0 Werten gesetzt, auch wenn's eigentlich regnet.
Internals:
.....
2021-05-09 13:24:19 state unknown
Attributes:
.....
stateFormat rainTotal
Beim nächsten refresh aber meist wieder auf unknown
Ist bei mir auch so... Irgendwie liefern die über die API wohl keine Daten mehr aus....
Hallo,
auch bei mir steht bei rainBegin, rainEnd, rainNow und state: unknown.
Viele Grüße Gisbert
Die letzten Daten für https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=50.779647&lon=6.153432®ion=de&unit=mm/u sind von 1619617500:
Assuming that this timestamp is in seconds:
GMT: Wednesday, 28. April 2021 13:45:00
Your time zone: Mittwoch, 28. April 2021 15:45:00 GMT+02:00 DST
Relative: 12 days ago
Wenn man auf nl umstellt, kommen aktuelle Daten.
(Wenn Aachen richtig ist, war ich da letztens, an dem Gefallenendenkmal)
Zitat von: Christoph Morrison am 10 Mai 2021, 20:33:58
Wenn man auf nl umstellt, kommen aktuelle Daten.
(Wenn Aachen richtig ist, war ich da letztens, an dem Gefallenendenkmal)
auf nl umgestellt, und jetzt kommen wieder Daten. Vielen Dank !!!
ja ist richtig, Gefallendenkmal ??
Zitat von: hanswerner1 am 11 Mai 2021, 11:07:46
auf nl umgestellt, und jetzt kommen wieder Daten. Vielen Dank !!!
ja ist richtig, Gefallendenkmal ??
Meinst du das Attribut region, welches ich jetzt von de auf nl geändert habe? Aber leider ohne Auswirkung auf den Bezug von Regendaten.
Viele Grüße Gisbert
ja, region habe ich gestern Abend auf nl geändert und der Regen heute morgen wurde angezeigt.
ja, wenn man in Aachen ist, an der hollaendischen Grenze, dann gahts, aber für München gehts dann nicht.
Zitat von: Gisbert am 11 Mai 2021, 11:52:25
Meinst du das Attribut region, welches ich jetzt von de auf nl geändert habe? Aber leider ohne Auswirkung auf den Bezug von Regendaten.
nl funktioniert, überraschend, in erster Linie für die Niederlande, aber auch für Grenzregionen, wobei die Definition davon sehr liberal ist. Hier in Gütersloh sind wir zwei Autostunden weg von der Grenze und ich bekomme Daten über die nl-Region.
So wie es aussieht, liefert BR aber für die de-Region keine aktuellen Daten mehr. Das kommt wohl öfter vor. Ihr könnt mal an RTL/BR schreiben und nachfragen, die haben vermutlich nur wenig Motivation einfach so was an der de-Region zu fixen.
Hallo zusammen,
seit heute ca. 14.00 bekomme ich einen ellenlangen, verstörenden Eintrag im logfile, der sich alle halbe Stunde wiederholt.
Hat das noch jemand festgestellt oder bin ich der einzig verbleibende Nutzer von Buienradar?
2021.09.11 14:15:08.181 1: DEBUG>[Buienradar]
HTTP Response code is: 502
2021.09.11 14:15:08.190 1: DEBUG>[Buienradar]
$VAR1 = {
'loglevel' => 4,
'hu_portSfx' => '',
'callback' => sub { "DUMMY" },
'hu_port' => 443,
'host' => 'cdn-secure.buienalarm.nl',
'protocol' => 'https',
'hu_blocking' => 0,
'timeout' => 10,
'url' => 'https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=51.02943&lon=7.05584®ion=de&unit=mm/u',
'addr' => 'https://cdn-secure.buienalarm.nl:443',
'httpheader' => 'HTTP/1.1 502 Bad Gateway
Date: Sat, 11 Sep 2021 12:15:08 GMT
Content-Type: text/html
Connection: close
Vary: Accept-Encoding
CF-Cache-Status: DYNAMIC
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Report-To: {"endpoints":[{"url":"https:\\/\\/a.nel.cloudflare.com\\/report\\/v3?s=PZ2F6f6vC%2B0Pqmr%2BAlZvy%2BHBz9Qitv504EpCB7TXLYlfY701PGgKSCt3vbXgzZvbI%2BIy7Qy%2FcQLS7rBB6zqNJ06Sz5YmsNCzGcQJOtO65ty4S6QnwEisGcnI6FdznHaM2lc73BnRLxwZMg%3D%3D"}],"group":"cf-nel","max_age":604800}
NEL: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
Server: cloudflare
CF-RAY: 68d0d1dbaca6c2bd-FRA',
'NAME' => '',
'method' => 'GET',
'sslargs' => {},
'auth' => 0,
'redirects' => 0,
'code' => 502,
'compress' => 1,
'conn' => undef,
'hu_filecount' => 1,
'displayurl' => 'https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=51.02943&lon=7.05584®ion=de&unit=mm/u',
'path' => '/api/3.4/forecast.php?lat=51.02943&lon=7.05584®ion=de&unit=mm/u',
'hash' => {
'DEF' => '',
'LONGITUDE' => '7.05584',
'.FhemMetaInternals' => 1,
'NAME' => 'Buienradar',
'.userReadings' => [
{
'trigger' => undef,
'reading' => 'rainDataNow',
'TIME' => '2021-09-11 14:10:09',
't' => '1631362209.26899',
'modifier' => 'none',
'value' => '0.0',
'perlCode' => '{round(ReadingsNum($name,\'rainNow\',\'\'),1)}'
},
{
'trigger' => undef,
'reading' => 'Zeitstempel',
'TIME' => '2021-09-11 14:10:09',
'modifier' => 'none',
't' => '1631362209.26899',
'value' => '2021-09-11 14:10',
'perlCode' => '{substr(ReadingsTimestamp($name,\'rainDataNow\',\'\'),0,16)}'
},
{
'value' => '0.0',
'perlCode' => '{ReadingsNum($name,\'rainDataNow\',\'\')}',
'reading' => 'rain',
'TIME' => '2021-09-11 14:10:09',
'trigger' => undef,
't' => '1631362209.26899',
'modifier' => 'none'
},
{
'perlCode' => '{round(max_rain(),1)}',
'value' => '0.0',
't' => '1631362209.26899',
'modifier' => 'none',
'trigger' => undef,
'TIME' => '2021-09-11 14:10:09',
'reading' => 'maxrain'
},
{
'perlCode' => '{(ReadingsAge($name,\'state\',0) > 300 ? "not ok":"ok")}',
'value' => 'ok',
't' => '1631362209.26899',
'modifier' => 'none',
'reading' => 'active',
'TIME' => '2021-09-11 14:10:09',
'trigger' => undef
}
],
'FUUID' => '5c430dc6-f33f-b139-0391-311dd930d4dd016b',
'TYPE' => 'Buienradar',
'URL' => 'https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=51.02943&lon=7.05584®ion=de&unit=mm/u',
'INTERVAL' => 300,
'.RainStart' => undef,
'.SERIALIZED' => '12345678
0
precipitation���`endЁ�`start
1619624400�z�`start�{�`end
0
precipitation
1619622600�m�`end
0
precipitation�l�`start
1619619000Ё�`end
0
precipitation���`start
1619624100�{�`start
0
precipitation }�`end
1619622900h�`end
0
precipitation�f�`start
1619617500�s�`end
0
precipitation�r�`start
1619620500 }�`start
0
precipitationL~�`end
1619623200�y�`start
0
precipitation�z�`end
1619622300�t�`end
0
precipitation�s�`start
1619620800px�`end
0
precipitationDw�`start
1619621700
0
precipitation�l�`end�k�`start
1619618700h�`start4i�`end
0
precipitation
1619617800
0
precipitation(��`end���`start
1619624700hq�`start
0
precipitation�r�`end
1619620200x�`end
0
precipitationL~�`start
1619623500�m�`starto�`end
0
precipitation
1619619300x�`start
0
precipitation���`end
1619623800`j�`start�k�`end
0
precipitation
16196184004i�`start
0
precipitation`j�`end
1619618100
0
precipitationv�`end�t�`start
1619621100<p�`start
0
precipitationhq�`end
1619619900v�`start
0
precipitationDw�`end
1619621400px�`start
0
precipitation�y�`end
1619622000<p�`end
0
precipitationo�`start
1619619600',
'READINGS' => {
'maxrain' => {
'TIME' => '2021-09-11 14:10:09',
'VAL' => '0.0'
},
'rainData' => {
'VAL' => '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',
'TIME' => '2021-09-11 14:10:09'
},
'state' => {
'TIME' => '2021-09-11 14:10:09',
'VAL' => 'unknown'
},
'rainTotal' => {
'TIME' => '2021-09-11 14:10:09',
'VAL' => '0.000'
},
'rainDurationIntervals' => {
'VAL' => 0,
'TIME' => '2021-09-11 14:10:09'
},
'rainDataStart' => {
'VAL' => '15:45',
'TIME' => '2021-09-11 14:10:09'
},
'rainEnd' => {
'VAL' => 'unknown',
'TIME' => '2021-09-11 14:10:09'
},
'rainDurationTime' => {
'VAL' => '00:00',
'TIME' => '2021-09-11 14:10:09'
},
'chartData' => {
'TIME' => '2019-08-05 22:09:07',
'VAL' => '[\'00:00\', 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.000], [\'22:30\', 0.000], [\'22:35\', 0.000], [\'22:40\', 0.000], [\'22:45\', 0.000], [\'22:50\', 0.000], [\'22:55\', 0.000], [\'23:00\', 0.000], [\'23:05\', 0.000], [\'23:10\', 0.000], [\'23:15\', 0.000], [\'23:20\', 0.000], [\'23:25\', 0.000], [\'23:30\', 0.000], [\'23:35\', 0.000], [\'23:40\', 0.000], [\'23:45\', 0.000], [\'23:50\', 0.000], [\'23:55\', 0.000]'
},
'rainDataNow' => {
'VAL' => '0.0',
'TIME' => '2021-09-11 14:10:09'
},
'rainDurationPercent' => {
'TIME' => '2021-09-11 14:10:09',
'VAL' => 0
},
'active' => {
'TIME' => '2021-09-11 14:10:09',
'VAL' => 'ok'
},
'rainAmount' => {
'TIME' => '2021-09-11 14:10:09',
'VAL' => '0.000'
},
'rainDuration' => {
'TIME' => '2021-09-11 14:10:09',
'VAL' => 0
},
'rain' => {
'VAL' => '0.0',
'TIME' => '2021-09-11 14:10:09'
},
'rainNow' => {
'VAL' => 'unknown',
'TIME' => '2021-09-11 14:10:09'
},
'rainMax' => {
'TIME' => '2021-09-11 14:10:09',
'VAL' => '0.000'
},
'Zeitstempel' => {
'VAL' => '2021-09-11 14:10',
'TIME' => '2021-09-11 14:10:09'
},
'rainLaMetric' => {
'TIME' => '2021-09-11 14:10:09',
'VAL' => '0,0,0,0,0,0,0,0,0,0,0,0'
},
'rainBegin' => {
'TIME' => '2021-09-11 14:10:09',
'VAL' => 'unknown'
},
'rainDataEnd' => {
'TIME' => '2021-09-11 14:10:09',
'VAL' => '17:50'
}
},
'REGION' => 'de',
'STATE' => 'Regen: <span style=\'color:#2e5e87\'>0.0 mm/h</span><br/>
max. Regen: <span style=\'color:#2e5e87\'>0.0 mm/h</span>',
'NR' => 532,
'FVERSION' => 'Buienradar.pm:?/2021-09-11',
'VERSION' => '3.0.9',
'.attrminint' => [],
'NEXTUPDATE' => '2021-09-11 14:20:08',
'helper' => {
'bm' => {
'CODE(0x55efc490e5c0)' => {
'tot' => '0.00111269950866699',
'dtotcnt' => 0,
'cnt' => 41,
'mAr' => [
$VAR1->{'hash'},
'Buienradar',
'?'
],
'dmx' => -1000,
'max' => '9.20295715332031e-05',
'mTS' => '11.09. 13:15:11',
'dtot' => 0
}
}
},
'.attraggr' => [],
'LATITUDE' => '51.02943',
'CFGFN' => './FHEM/WetterdatenSensorenInternet.cfg'
}
};
2021.09.11 14:35:08.202 1: DEBUG>[Buienradar]
... usw...usw
Viele Grüße Gisbert
Hi,
Zitat von: Gisbert am 11 September 2021, 19:28:34
Hat das noch jemand festgestellt oder bin ich der einzig verbleibende Nutzer von Buienradar?
Nein und nein :-).
Bei mir ist alles normal.
LG
Christian
Siehe https://github.com/fhem/mod-Buienradar/issues/325
Ich habe übrigens endlich mal v3.0.9 (https://github.com/fhem/mod-Buienradar/releases/tag/v3.0.9) veröffentlicht. Nach wie vor beta.
Ich werde aber die Entwicklung des Moduls wieder aufnehmen, auch wenn für die Region de (wohl) keine Daten mehr kommen. Ich habe aber bei BR noch mal angefragt, denn auf der Website und der App gibt es noch Daten z.B. für München oder Dresden, die es früher nur in der Region de gab.
ZitatHallo Christoph,
ich bekomme im logfile einen Bad Request 502 mit einem merkwürdigen Zeichen in der Adresszeile:
https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=51.02943&lon=7.05584®ion=de&unit=mm/u
®ion statt Region
Ich hab's heute erstmalig gegen 14.00 im logfile gesehen.
Viele Grüße
Gisbert
Hallo Giesbert,
die Loesung dazu steht hier, ich hatte Christoph schon mal gebeten das mit in den Code mit aufzunehmen, aber dazu ist es nie gekommen.
Der erst Teil von "®ion" wird als "registered" interpretiert, und dort das entsprechende "®" Zeichen für "®" eingesetzt , also "®ion".
Um den Fehler zu vermeiden, hilft es im Code die Reihenfolge zu veraendern, also aus
https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=46.881530&lon=11.435549®ion=nl
ein
https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?region=nl&lat=46.881530&lon=11.435549
Also das Region an den Anfang zu nehmen, direkt nach dem Fragezeichen, damit vermeidet man das ®ion.
https://forum.fhem.de/index.php/topic,102497.msg971402.html#msg971402
Hab ich damals total überlesen.
Mich wundert halt, welches Subsystem diese Konvertierung durchführt. Eigentlich gehört hinter ® dann auch noch ein Semikolon um daraus ein named entity zu machen. BR macht sowas zumindest mal nicht.
Zeig mal bitte das latitude und das longitude-Reading aus deinem Global und zwar als Raw. Ist da irgendwo ein Semikolon reingekommen?
Und mal euere Buienradar-Raw-Def und ein list.
Hallo Christoph,
hier sind meine raw-Definitionen:
defmod Buienradar Budefmod Buienradar Buienradar
attr Buienradarienradar
attr Buienradar 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
attr Buienradar group Wetter
attr Buienradar icon weather_rain_meter
attr Buienradar interval 300
attr Buienradar region nl
attr Buienradar room Weather
attr Buienradar stateFormat Regen: <span style='color:{(ReadingsVal('$name','rainDataNow','') > 0 ? "red":"#2e5e87")}'>[$name:rainDataNow] mm/h</span><br/>\
max. Regen: <span style='color:{(ReadingsVal('$name','maxrain','') > 0 ? "red":"#2e5e87")}'>[$name:maxrain] mm/h</span>
attr Buienradar userReadings rainDataNow {round(ReadingsNum($name,'rainNow',''),1)}, \
Zeitstempel {substr(ReadingsTimestamp($name,'rainDataNow',''),0,16)}, \
rain {ReadingsNum($name,'rainDataNow','')}, \
maxrain {round(max_rain(),1)}, \
active {(ReadingsAge($name,'state',0) > 300 ? "not ok":"ok")}
setstate Buienradar Regen: <span style='color:red'>0.1 mm/h</span><br/>\
max. Regen: <span style='color:red'>0.1 mm/h</span>
setstate Buienradar 2021-09-15 07:05:00 Zeitstempel 2021-09-15 07:05
setstate Buienradar 2021-09-15 07:05:00 active ok
setstate Buienradar 2019-08-05 22:09:07 chartData ['00:00', 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.000], ['22:30', 0.000], ['22:35', 0.000], ['22:40', 0.000], ['22:45', 0.000], ['22:50', 0.000], ['22:55', 0.000], ['23:00', 0.000], ['23:05', 0.000], ['23:10', 0.000], ['23:15', 0.000], ['23:20', 0.000], ['23:25', 0.000], ['23:30', 0.000], ['23:35', 0.000], ['23:40', 0.000], ['23:45', 0.000], ['23:50', 0.000], ['23:55', 0.000]
setstate Buienradar 2021-09-15 07:05:00 maxrain 0.1
attr global userattr assistantName:textField babbleDevice cmdIcon devStateIcon devStateIcon:textField-long devStateStyle gassistantName:textField genericDeviceType:aircondition,coffeemaker,ac_unit,aircooler,airfreshener,airpurifier,audio_video_receiver,awning,bathtub,bed,blender,blinds,boiler,camera,carbon_monoxide_detector,charger,closet,coffee_maker,cooktop,curtain,dehumidifier,dehydrator,dishwasher,door,drawer,dryer,fan,faucet,fireplace,freezer,fryer,garage,gate,grill,heater,hood,humidifier,kettle,light,lock,remotecontrol,mop,mower,microwave,multicooker,network,outlet,oven,pergola,petfeeder,pressurecooker,radiator,refrigerator,router,scene,sensor,securitysystem,settop,shutter,shower,smoke_detector,sousvide,speaker,streaming_box,streaming_stick,streaming_soundbar,soundbar,sprinkler,standmixer,switch,tv,thermostat,vacuum,valve,washer,waterheater,waterpurifier,watersoftener,window,yogurtmaker homebridgeMapping:textField-long icon readingsWatcher realRoom:textField sortby stateFormat valueStyle webCmd webCmdLabel:textField-long widgetOverride
attr global autoload_undefined_devices 1
attr global autosave 0
attr global backup_before_update 1
attr global backupdir /media/USBBackup/FhemBackup
attr global commandref modular
attr global comment SecurityCheck:\
telnetPort is not password protected\
Protect this FHEM installation by configuring the allowed device allowedWEB\
You can disable this message with attr global motd none\
\
blocking: https://forum.fhem.de/index.php/topic,99492.msg929439.html#msg929439\
DNS-Lookup ist blockierend. \
Um das zu vermeiden kann man "attr global dnsServer 8.8.8.8" (oder Vergleichbares) setzen.\
Laut https://forum.fhem.de/index.php/topic,94957.msg953012.html#msg953012 soll ein DNS-Server im eigenen Netz eingetragen werden, um disconnects beim HMLAN zu vermeiden.\
Mit eingeschaltetem stacktrace erhält man im log file detailierte Information, die im Falle von PERL WARNING oder ERROR helfen.\
\
narchive: hier ist die Anzahl der täglichen log-Dateien gemeint, die beibehalten werden.\
\
restoreDirs: Anzahl der Sicherungen bei einem Fhem save und update.
attr global dnsServer 127.0.0.1
attr global exclude_from_update 72_FRITZBOX.pm 98_DLNARenderer.pm 00_HMLAN.pm 50_Signalbot.pm
attr global featurelevel 6.0
attr global holiday2we nw
attr global latitude 51.02943
attr global logfile ./log/fhem-%Y-%m-%d.log
attr global longitude 7.05584
attr global modpath ./
attr global motd SecurityCheck:\
httpWEB is not password protected\
telnetPort is not password protected\
\
Protect this FHEM installation by configuring the allowed device allowedWEB\
You can disable this message with attr global motd none
attr global mseclog 1
attr global nrarchive 7
attr global restoreDirs 18
attr global sendStatistics onUpdate
attr global showInternalValues 0
attr global sslVersion TLSv12:!SSLv3
attr global stacktrace 0
attr global statefile ./log/fhem.save
attr global updateInBackground 1
attr global verbose 3
setstate global no definition
Viele Grüße Gisbert
Hatte ich ja schon auf GH geschrieben: Deine Def, auch die von global, sieht absolut unverdächtig aus. Irgendein Subsystem von FHEM muss diese URL modifizieren. Aber BR macht das nicht.
Ich kann's übrigens auch auf meiner Testinstanz nicht nachvollziehen.
Trotzdem habe ich mal in v3.0.10 die Position des region-Parameters im Query-String verschoben um das & davor loszubekommen.
Hallo Christoph,
danke für die Info; ich sag's ja, wenn Software im Spiel ist, kann alles passieren ;D
Wo kann ich denn den neuesten Release/Beta runterladen? Auf Github scheint die 3.0.10 noch nicht bereitzustehen.
Viele Grüße Gisbert
Die bekommst du im development/3.0-Zweig
https://raw.githubusercontent.com/fhem/mod-Buienradar/development/3.0/controls_Buienradar.txt
Hallo Christoph,
mit Updates von außerhalb von Fhem frage ich lieber nach, bevor ich größeres Unheil anrichte.
Ich würde es so machen, d.h. in der Kommandozeile von Fhem eingeben:
update https://raw.githubusercontent.com/fhem/mod-Buienradar/development/3.0/controls_Buienradar.txt
Richtig?
Viele Grüße Gisbert
Hallo Christoph,
wenn ich update all https://raw.githubusercontent.com/fhem/mod-Buienradar/development/3.0/controls_Buienradar.txt in der Kommandozeile von Fhem eingebe, ändert sich in der Versionsnummer bei Buienradar nichts, es bleibt bei der Version 3.0.9.
Viele Grüße Gisbert
Steht eigentlich immer in den RL wie man es macht, in deinem Fall:
Remove any old source from FHEM by update delete, i.e. update delete https://raw.githubusercontent.com/fhem/mod-Buienradar/release/2.3/controls_Buienradar.txt.
Da musst du halt deinen Link reinkopieren.
You can find the current source by issuing update list
Add new source by update add https://raw.githubusercontent.com/fhem/mod-Buienradar/development/3.0/controls_Buienradar.txt
Check with update check
update Buienradar
Restart FHEM
Guten Morgen Christoph,
danke dafür, dass du den Update-Prozess explizit aufgeschrieben hast. Den hatte ich bei Github in der Zwischenzeit auch gefunden und vermeintlich auch so ausgeführt.
Allerdings habe ich mir selbst Knüppel zwischen die Beine geworfen, indem ich .../release/3.0/... statt .../development/3.0/... benutzt habe - so konnte es nicht funktionieren.
Allem Anschein nach funktioniert das Modul jetzt wieder. Die URL sieht aber mit dem @region bei mir so aus:
https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=51.02943&lon=7.05584®ion=nl&unit=mm/u
Ich dachte, dass du region nach vorne gezogen hättest.
Viele Grüße Gisbert
Jetzt sollte ein normales update reichen.
Hallo Christoph,
EDIT: ich habe gesehen, dass du heute vormittag ein weiteres Update eingestellt hast. Dieses Update habe ich erst jetzt gesehen, so dass die folgenden Zeilen gegenstandslos geworden sind. Sorry für die Verwirrung.
leider kommt mit der Version 3.0.10 immer noch der gleiche Fehler (@ion, also @ion statt region).
Die Position dieses Teil steht unverändert nach lat/long:
https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=51.02943&lon=7.05584®ion=nl&unit=mm/u
Kannst du nochmals reinschauen?
2021.09.19 18:14:17.156 1: DEBUG>[Buienradar]
HTTP Response code is: 502
2021.09.19 18:14:17.162 1: DEBUG>[Buienradar]
$VAR1 = {
'hu_portSfx' => '',
'hu_port' => 443,
'method' => 'GET',
'code' => 502,
'hash' => {
'helper' => {
'bm' => {
'CODE(0x556171dcf508)' => {
'max' => '0.00237107276916504',
'cnt' => 208,
'tot' => '0.014554500579834',
'dmx' => -1000,
'mAr' => [
$VAR1->{'hash'},
'Buienradar',
'refresh'
],
'dtot' => 0,
'mTS' => '19.09. 07:09:45',
'dtotcnt' => 0
},
'CODE(0x556171e31960)' => {
'dtot' => 0,
'dtotcnt' => 0,
'mTS' => '19.09. 07:04:48',
'cnt' => 3,
'max' => '0.00427412986755371',
'mAr' => [
'set',
'Buienradar',
'disabled',
'off'
],
'dmx' => -1000,
'tot' => '0.00844788551330566'
},
'CODE(0x556171ea0bc8)' => {
'mTS' => '19.09. 07:06:14',
'dtotcnt' => 0,
'dtot' => 0,
'mAr' => [
$VAR1->{'hash'},
'Buienradar',
'?'
],
'tot' => '0.000838279724121094',
'dmx' => -1000,
'cnt' => 12,
'max' => '0.000123023986816406'
}
}
},
'NAME' => 'Buienradar',
'URL' => 'https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=51.02943&lon=7.05584®ion=nl&unit=mm/u',
'.SERIALIZED' => '12345678�gGastart
0
precipitationiGaend
1632069600
0
precipitationpGastart@qGaend
1632071700�lGaenddkGastart
0
precipitation
1632070500�fGaend
0
precipitation�eGastart
16320690008jGastart
0
precipitationdkGaend
1632070200\\dGastart
0
precipitation�eGaend
1632068700
0
precipitationHxGastarttyGaend
1632073800�`Gaend
0
precipitation�_Gastart
1632067500�sGaend
0
precipitationlrGastart
1632072300�^Gastart
0
precipitation�_Gaend
1632067200
0
precipitation�tGastart�uGaend
1632072900
0
precipitation�nGastartpGaend
1632071400�sGastart
0
precipitation�tGaend
1632072600�{Gaend�zGastart
0
precipitation
1632074400HxGaend
0
precipitationwGastart
1632073500lrGaend
0
precipitation@qGastart
1632072000
0
precipitation�`GastartbGaend
1632067800
0
precipitation�uGastartwGaend
1632073200\\dGaend
0
precipitation0cGastart
1632068400�mGaend
0
precipitation�lGastart
1632070800
0
precipitation�fGastart�gGaend
16320693000cGaendbGastart
0
precipitation
1632068100�mGastart
0
precipitation�nGaend
1632071100
0
precipitationiGastart8jGaend
1632069900tyGastart
0
precipitation�zGaend
1632074100',
'READINGS' => {
'rainNow' => {
'TIME' => '2021-09-19 18:09:16',
'VAL' => 'unknown'
},
'state' => {
'TIME' => '2021-09-19 18:09:16',
'VAL' => 'unknown'
},
'rainAmount' => {
'TIME' => '2021-09-19 18:09:16',
'VAL' => '0.000'
},
'maxrain' => {
'TIME' => '2021-09-19 18:09:16',
'VAL' => '0.0'
},
'rainDurationPercent' => {
'VAL' => 0,
'TIME' => '2021-09-19 18:09:16'
},
'rainDuration' => {
'TIME' => '2021-09-19 18:09:16',
'VAL' => 0
},
'rainEnd' => {
'VAL' => 'unknown',
'TIME' => '2021-09-19 18:09:16'
},
'rainDurationIntervals' => {
'TIME' => '2021-09-19 18:09:16',
'VAL' => 0
},
'rainData' => {
'VAL' => '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',
'TIME' => '2021-09-19 18:09:16'
},
'rain' => {
'VAL' => '0.0',
'TIME' => '2021-09-19 18:09:16'
},
'rainBegin' => {
'VAL' => 'unknown',
'TIME' => '2021-09-19 18:09:16'
},
'rainMax' => {
'VAL' => '0.000',
'TIME' => '2021-09-19 18:09:16'
},
'rainDataNow' => {
'VAL' => '0.0',
'TIME' => '2021-09-19 18:09:16'
},
'rainDataStart' => {
'TIME' => '2021-09-19 18:09:16',
'VAL' => '18:00'
},
'rainDataEnd' => {
'VAL' => '20:05',
'TIME' => '2021-09-19 18:09:16'
},
'rainLaMetric' => {
'TIME' => '2021-09-19 18:09:16',
'VAL' => '0,0,0,0,0,0,0,0,0,0,0,0'
},
'rainDurationTime' => {
'VAL' => '00:00',
'TIME' => '2021-09-19 18:09:16'
},
'rainTotal' => {
'TIME' => '2021-09-19 18:09:16',
'VAL' => '0.000'
},
'chartData' => {
'VAL' => '[\'00:00\', 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.000], [\'22:30\', 0.000], [\'22:35\', 0.000], [\'22:40\', 0.000], [\'22:45\', 0.000], [\'22:50\', 0.000], [\'22:55\', 0.000], [\'23:00\', 0.000], [\'23:05\', 0.000], [\'23:10\', 0.000], [\'23:15\', 0.000], [\'23:20\', 0.000], [\'23:25\', 0.000], [\'23:30\', 0.000], [\'23:35\', 0.000], [\'23:40\', 0.000], [\'23:45\', 0.000], [\'23:50\', 0.000], [\'23:55\', 0.000]',
'TIME' => '2019-08-05 22:09:07'
},
'Zeitstempel' => {
'TIME' => '2021-09-19 18:09:16',
'VAL' => '2021-09-19 18:09'
},
'active' => {
'VAL' => 'ok',
'TIME' => '2021-09-19 18:09:16'
}
},
'FUUID' => '5c430dc6-f33f-b139-0391-311dd930d4dd016b',
'LONGITUDE' => '7.05584',
'LATITUDE' => '51.02943',
'.RainStart' => undef,
'FVERSION' => 'Buienradar.pm:?/2021-09-19',
'NR' => 532,
'.attrminint' => [],
'DEF' => '',
'STATE' => 'Regen: <span style=\'color:#2e5e87\'>0.0 mm/h</span><br/>
max. Regen: <span style=\'color:#2e5e87\'>0.0 mm/h</span>',
'REGION' => 'nl',
'NEXTUPDATE' => '2021-09-19 18:19:16',
'VERSION' => '3.0.10',
'.FhemMetaInternals' => 1,
'.userReadings' => [
{
't' => '1632067756.30531',
'reading' => 'rainDataNow',
'value' => '0.0',
'modifier' => 'none',
'perlCode' => '{round(ReadingsNum($name,\'rainNow\',\'\'),1)}',
'TIME' => '2021-09-19 18:09:16',
'trigger' => undef
},
{
'trigger' => undef,
'perlCode' => '{substr(ReadingsTimestamp($name,\'rainDataNow\',\'\'),0,16)}',
'modifier' => 'none',
'TIME' => '2021-09-19 18:09:16',
'reading' => 'Zeitstempel',
'value' => '2021-09-19 18:09',
't' => '1632067756.30531'
},
{
'trigger' => undef,
'perlCode' => '{ReadingsNum($name,\'rainDataNow\',\'\')}',
'modifier' => 'none',
'TIME' => '2021-09-19 18:09:16',
'reading' => 'rain',
'value' => '0.0',
't' => '1632067756.30531'
},
{
'value' => '0.0',
'reading' => 'maxrain',
't' => '1632067756.30531',
'trigger' => undef,
'TIME' => '2021-09-19 18:09:16',
'modifier' => 'none',
'perlCode' => '{round(max_rain(),1)}'
},
{
'trigger' => undef,
'TIME' => '2021-09-19 18:09:16',
'perlCode' => '{(ReadingsAge($name,\'state\',0) > 300 ? "not ok":"ok")}',
'modifier' => 'none',
'value' => 'ok',
'reading' => 'active',
't' => '1632067756.30531'
}
],
'CFGFN' => './FHEM/WetterdatenSensorenInternet.cfg',
'TYPE' => 'Buienradar',
'INTERVAL' => 300,
'.attraggr' => []
},
'displayurl' => 'https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=51.02943&lon=7.05584®ion=nl&unit=mm/u',
'hu_filecount' => 1,
'host' => 'cdn-secure.buienalarm.nl',
'addr' => 'https://cdn-secure.buienalarm.nl:443',
'protocol' => 'https',
'conn' => undef,
'httpheader' => 'HTTP/1.1 502 Bad Gateway
Date: Sun, 19 Sep 2021 16:14:17 GMT
Content-Type: text/html
Connection: close
Vary: Accept-Encoding
CF-Cache-Status: DYNAMIC
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Report-To: {"endpoints":[{"url":"https:\\/\\/a.nel.cloudflare.com\\/report\\/v3?s=f%2FD41d2dKOzBTnmXCBziTdO%2B0cnssQIXjosjsHjFtJH%2FtZM8gYwchdsF5Tg9Tro3vq0riwHHNuKMwih%2FRXtKWaNhgaqkEPUBB8MCE5BghkoqRce%2Fs76QKxs8ncPlwy0J2pYP6ntxNtj6IA%3D%3D"}],"group":"cf-nel","max_age":604800}
NEL: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
Server: cloudflare
CF-RAY: 69141b2c8b185be5-FRA',
'NAME' => '',
'auth' => 0,
'url' => 'https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=51.02943&lon=7.05584®ion=nl&unit=mm/u',
'callback' => sub { "DUMMY" },
'timeout' => 10,
'redirects' => 0,
'loglevel' => 4,
'compress' => 1,
'hu_blocking' => 0,
'sslargs' => {},
'path' => '/api/3.4/forecast.php?lat=51.02943&lon=7.05584®ion=nl&unit=mm/u'
};
Viele Grüße Gisbert
Guten Morgen Christoph,
im Prinzip funktioniert das Modul.
Es kommt jedoch vor, dass Buienradar nicht erreichbar ist, dann gibt es den Fehler 502. Daran ist ja nichts zu ändern, die Seite ist halt nicht erreichbar.
In diesem Fall wird ein ellenlanger Text in das log-file geschrieben. Kann man das irgendwie unterbinden?
Hier ein Beispiel von heute Nacht.
Verbose auf null zu setzen hatte ich auch schon probiert, aber ohne Erfolg. Gibt es eine andere Möglichkeit die Länge der log-Einträge drastisch zu kürzen? Eine Zeile würde mir ausreichen.
2021.09.25 00:02:41.171 1: DEBUG>[Buienradar]
HTTP Response code is: 502
2021.09.25 00:02:41.177 1: DEBUG>[Buienradar]
$VAR1 = {
'hu_blocking' => 0,
'displayurl' => 'https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?region=nl&lat=51.02943&lon=7.05584&unit=mm/u',
'path' => '/api/3.4/forecast.php?region=nl&lat=51.02943&lon=7.05584&unit=mm/u',
'hu_port' => 443,
'protocol' => 'https',
'code' => 502,
'NAME' => '',
'method' => 'GET',
'compress' => 1,
'hu_filecount' => 1,
'host' => 'cdn-secure.buienalarm.nl',
'callback' => sub { "DUMMY" },
'httpheader' => 'HTTP/1.1 502 Bad Gateway
Date: Fri, 24 Sep 2021 22:02:41 GMT
Content-Type: text/html
Connection: close
Vary: Accept-Encoding
CF-Cache-Status: DYNAMIC
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Report-To: {"endpoints":[{"url":"https:\\/\\/a.nel.cloudflare.com\\/report\\/v3?s=ZKA9q600W9Jvakns8o5MTPfR6DuGoIeduGtCm3zdO5U3Tq%2FjLIZYRmIkSqn8nKQD%2F2HuYwxzjZ0ESX8r3VJGIKaWKNk%2FalSSmw1YLqYY6OFUPJGmOARC7OVqjUO9dg%2FzLdt5OxdtqofNVg%3D%3D"}],"group":"cf-nel","max_age":604800}
NEL: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
Server: cloudflare
CF-RAY: 693f4c66ee594a56-FRA',
'hu_portSfx' => '',
'hash' => {
'NR' => 565,
'REGION' => 'nl',
'.attraggr' => [],
'TYPE' => 'Buienradar',
'DEF' => '',
'.userReadings' => [
{
'TIME' => '2021-09-24 23:57:41',
'modifier' => 'none',
'perlCode' => '{round(ReadingsNum($name,\'rainNow\',\'\'),1)}',
't' => '1632520661.2134',
'trigger' => undef,
'value' => '0.0',
'reading' => 'rainDataNow'
},
{
'TIME' => '2021-09-24 23:57:41',
'perlCode' => '{substr(ReadingsTimestamp($name,\'rainDataNow\',\'\'),0,16)}',
'modifier' => 'none',
't' => '1632520661.2134',
'value' => '2021-09-24 23:57',
'reading' => 'Zeitstempel',
'trigger' => undef
},
{
'value' => '0.0',
'reading' => 'rain',
'trigger' => undef,
't' => '1632520661.2134',
'perlCode' => '{ReadingsNum($name,\'rainDataNow\',\'\')}',
'modifier' => 'none',
'TIME' => '2021-09-24 23:57:41'
},
{
'trigger' => undef,
'value' => '0.0',
'reading' => 'maxrain',
'perlCode' => '{round(max_rain(),1)}',
'modifier' => 'none',
't' => '1632520661.2134',
'TIME' => '2021-09-24 23:57:41'
},
{
'trigger' => undef,
'reading' => 'active',
'value' => 'ok',
'TIME' => '2021-09-24 23:57:41',
't' => '1632520661.2134',
'perlCode' => '{(ReadingsAge($name,\'state\',0) > 300 ? "not ok":"ok")}',
'modifier' => 'none'
}
],
'FVERSION' => 'Buienradar.pm:?/2021-09-24',
'.attrminint' => [],
'READINGS' => {
'maxrain' => {
'TIME' => '2021-09-24 23:57:41',
'VAL' => '0.0'
},
'rainTotal' => {
'VAL' => '0.000',
'TIME' => '2021-09-24 23:57:41'
},
'rainLaMetric' => {
'VAL' => '0,0,0,0,0,0,0,0,0,0,0,0',
'TIME' => '2021-09-24 23:57:41'
},
'rainAmount' => {
'TIME' => '2021-09-24 23:57:41',
'VAL' => '0.000'
},
'rainDataStart' => {
'VAL' => '23:50',
'TIME' => '2021-09-24 23:57:41'
},
'state' => {
'TIME' => '2021-09-24 23:57:41',
'VAL' => 'unknown'
},
'active' => {
'TIME' => '2021-09-24 23:57:41',
'VAL' => 'ok'
},
'rainDuration' => {
'VAL' => 0,
'TIME' => '2021-09-24 23:57:41'
},
'rainNow' => {
'VAL' => 'unknown',
'TIME' => '2021-09-24 23:57:41'
},
'rainMax' => {
'TIME' => '2021-09-24 23:57:41',
'VAL' => '0.000'
},
'rainDurationIntervals' => {
'TIME' => '2021-09-24 23:57:41',
'VAL' => 0
},
'rainData' => {
'TIME' => '2021-09-24 23:57:41',
'VAL' => '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'
},
'rainDataNow' => {
'TIME' => '2021-09-24 23:57:41',
'VAL' => '0.0'
},
'chartData' => {
'VAL' => '[\'00:00\', 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.000], [\'22:30\', 0.000], [\'22:35\', 0.000], [\'22:40\', 0.000], [\'22:45\', 0.000], [\'22:50\', 0.000], [\'22:55\', 0.000], [\'23:00\', 0.000], [\'23:05\', 0.000], [\'23:10\', 0.000], [\'23:15\', 0.000], [\'23:20\', 0.000], [\'23:25\', 0.000], [\'23:30\', 0.000], [\'23:35\', 0.000], [\'23:40\', 0.000], [\'23:45\', 0.000], [\'23:50\', 0.000], [\'23:55\', 0.000]',
'TIME' => '2019-08-05 22:09:07'
},
'rainEnd' => {
'VAL' => 'unknown',
'TIME' => '2021-09-24 23:57:41'
},
'rain' => {
'VAL' => '0.0',
'TIME' => '2021-09-24 23:57:41'
},
'rainBegin' => {
'VAL' => 'unknown',
'TIME' => '2021-09-24 23:57:41'
},
'rainDurationPercent' => {
'TIME' => '2021-09-24 23:57:41',
'VAL' => 0
},
'rainDataEnd' => {
'VAL' => '01:55',
'TIME' => '2021-09-24 23:57:41'
},
'Zeitstempel' => {
'VAL' => '2021-09-24 23:57',
'TIME' => '2021-09-24 23:57:41'
},
'rainDurationTime' => {
'VAL' => '00:00',
'TIME' => '2021-09-24 23:57:41'
}
},
'LATITUDE' => '51.02943',
'helper' => {
'bm' => {
'CODE(0x56247a87b4a8)' => {
'dtot' => 0,
'cnt' => 64,
'dtotcnt' => 0,
'mTS' => '24.09. 20:31:40',
'tot' => '0.00132203102111816',
'dmx' => -1000,
'max' => '4.41074371337891e-05',
'mAr' => [
$VAR1->{'hash'},
'Buienradar',
'?'
]
}
}
},
'.FhemMetaInternals' => 1,
'LONGITUDE' => '7.05584',
'FUUID' => '5c430dc6-f33f-b139-0391-311dd930d4dd016b',
'.SERIALIZED' => '12345678
0
precipitationpXNaendDWNastart
1632524100TeNaend
0
precipitation(dNastart
1632527400<PNastarthQNaend
0
precipitation
1632522300x_Nastart�`Naend
0
precipitation
1632526200
0
precipitation�aNaend�`Nastart
1632526500�bNaend
0
precipitation�aNastart
1632526800 ]NastartL^Naend
0
precipitation
1632525600ONastart
0
precipitation<PNaend
1632522000�YNastart
0
precipitation�ZNaend
1632524700�LNastart
0
precipitation�MNaend
1632521400x_Naend
0
precipitationL^Nastart
1632525900�ZNastart
0
precipitation�[Naend
1632525000
0
precipitation�LNaend�KNastart
1632521100�RNaend
0
precipitationhQNastart
1632522600�SNaend
0
precipitation�RNastart
1632522900HNastart4INaend
0
precipitation
16325202004INastart`JNaend
0
precipitation
1632520500
0
precipitation�KNaend`JNastart
1632520800ONaend
0
precipitation�MNastart
1632521700
0
precipitation(dNaend�bNastart
1632527100DWNaend
0
precipitationVNastart
1632523800VNaend
0
precipitation�TNastart
1632523500 ]Naend
0
precipitation�[Nastart
1632525300
0
precipitation�YNaendpXNastart
1632524400�TNaend
0
precipitation�SNastart
1632523200',
'STATE' => 'Regen: <span style=\'color:#2e5e87\'>0.0 mm/h</span><br/>
max. Regen: <span style=\'color:#2e5e87\'>0.0 mm/h</span>',
'VERSION' => '3.1.0-10',
'NEXTUPDATE' => '2021-09-25 00:07:40',
'CFGFN' => './FHEM/WetterdatenSensorenInternet.cfg',
'NAME' => 'Buienradar',
'URL' => 'https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?region=nl&lat=51.02943&lon=7.05584&unit=mm/u',
'.RainStart' => undef,
'INTERVAL' => 300
},
'loglevel' => 4,
'url' => 'https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?region=nl&lat=51.02943&lon=7.05584&unit=mm/u',
'sslargs' => {},
'auth' => 0,
'redirects' => 0,
'conn' => undef,
'addr' => 'https://cdn-secure.buienalarm.nl:443',
'timeout' => 10
};
Viele Grüße Gisbert
Zitat von: Gisbert am 25 September 2021, 08:21:01
In diesem Fall wird ein ellenlanger Text in das log-file geschrieben. Kann man das irgendwie unterbinden?
Hier ein Beispiel von heute Nacht.
Verbose auf null zu setzen hatte ich auch schon probiert, aber ohne Erfolg. Gibt es eine andere Möglichkeit die Länge der log-Einträge drastisch zu kürzen? Eine Zeile würde mir ausreichen.
Du kannst in global verbose auf 1 setzen und wirst dann keine debug messages mehr sehen, so lange du nicht im BR-Device noch debug auf 1 gesetzt hast. Habs mir aber mal mitgenommen (https://github.com/fhem/mod-Buienradar/issues/332), 1 ist in global schon sehr wenig verbose.
Beim Update bekomme ich folgenden Fehler:
Downloading https://raw.githubusercontent.com/fhem/mod-Buienradar/development/3.0/controls_Buienradar.txt
Buienradar
UPD lib/FHEM/Weather/Buienradar.pm
UPD FHEM/59_Buienradar.pm
Got 13197 bytes for FHEM/59_Buienradar.pm, expected 13538
aborting.
Gruß, Sascha
Bei mir das gleiche Problem
: Downloading https://raw.githubusercontent.com/fhem/mod-Buienradar/development/3.0/controls_Buienradar.txt
:
: Buienradar
: UPD lib/FHEM/Weather/Buienradar.pm
: UPD FHEM/59_Buienradar.pm
: Got 13197 bytes for FHEM/59_Buienradar.pm, expected 13538
: aborting.
Bug des Updates ist seit ca. vier Tagen mit #335 im Branch development/3.0 gefixt.
Zitat von: Timmäää am 26 Oktober 2021, 11:55:45
Bug des Updates ist seit ca. vier Tagen mit #335 im Branch development/3.0 gefixt.
Naja, es ist nicht wirklich gefixt. Ich habe die Stelle gefunden, die das Problem verursacht und deaktiviert, aber dafür gibt es jetzt keine aktuelle Dokumentation mehr (was für die meisten eh kein Thema ist ;-))
Tatsächlich überlege ich aber, das ganze Konstrukt umzubauen und statt einem nativen FHEM-Modul lieber eine Art Gateway von Buienradar zu MQTT zu schreiben.
Ich musste heute feststellen, dass das Modul nicht mehr die richtigen Daten bzw keine Daten mehr holt.
Hat sich was geändert ?
gruß
Sascha
P.S.: unter der eingetragenen URL die automatisch angelegt wird, gibt es keine Aktualsierungen !!
Hallo Sascha,
es kommen bei mir noch Daten an. Ob diese relevant sind, kann ich so nicht sagen; es sieht aber nicht ungewöhnlich aus.
Hier ist meine Definition (nur das wesentliche), ich wohne in Leverkusen:
defmod Buienradar Buienradar
attr Buienradar disabled off
attr Buienradar icon weather_rain_meter
attr Buienradar interval 300
attr Buienradar region nl
Viele Grüße Gisbert
Danke für deine Antwort.
Ich habe mal dann die Region von DE auf NL umgestellt und schon kommen die Daten !
Danke !
Sascha
P.S.: Was ist mit den Charts ? Laufen diese nicht mehr ?!?!