Hallo,
ich wollte hier mal ein neues Modul veröffentlichen. Mit dem Modul "
59_Buienradar.pm" kann man die Niederschlagsvorhersage eines niederländischen Wetterdienstes nutzten (https://www.buienradar.nl/overbuienradar/gratis-weerdata (https://www.buienradar.nl/overbuienradar/gratis-weerdata)). Der Dienst stellt eine regionale Vorhersage mit einer 5 Minuten Auflösung zur Verfügung, die Vorhersage geht bis zu 2 Stunden im Voraus. Die Qualität der Daten ist so hoch dass man z.B. die Entscheidung wann man mit seinem Hund spazieren geht darauf basieren lassen kann.
Das Modul Buienradar benötigt die Perl Bibliothek "DateTime", die man mit
cpan install DateTime installieren kann. Wenn man im global Device Longitude und Latitude definiert hat kann man mit
define BR Buienradar das Device BR mit der lokalen Vorhersage einbinden. Es geht aber auch mit
define BR Buienradar <Latitude> <Longitude>. Die Daten werden automatisch alle 5 Minuten nonBlocking abgeholt.
Es gibt auch ein weiteres Modul RainTMC mit einer anderen Datenquelle.
Beide Module haben folgenden Readings:
rainNow: Die vorhergesagte Regenmenge für das aktuelle 5 Min. Intervall in mm/m² pro Stunden
rainAmount: Die Regenmenge die im kommenden Regenschauer herunterkommen soll
rainTotal: Die Regenmenge in den vorliegenden Daten
rainBegin: Die Uhrzeit des kommenden Regenbegins oder "unknown"
rainEnd: Die Uhrzeit des kommenden Regenendes oder "unknown"
rainDataStart: Begin der aktuellen Regenvorhersage.
rainDataStart: Ende der aktuellen Regenvorhersage.
rainLaMetric: Die nächsten 12 Regenmengen aufbereitet für ein LaMetric Display
Folgende Werte kann man mit get abfragen:
rainDuration: Die voraussichtliche Dauer des nächsten Schauers in Minuten
startsIn: der Regen beginnt in x Minuten
refresh: Neue Daten werde nonblocking abgefragt
Zur Visualisierung gibt es drei Funktionen (siehe auch Commandref):
{Buienradar_HTML(<DEVICE>,<Pixel>)} also z.B.
{Buienradar_HTML("BR",500)} gibt eine reine HTML Liste zurück, der längste Balken hat dann 500 Pixel (nicht so schön ;-))
{Buienradar_SVG(<DEVICE>)} also z.B.
{Buienradar_SVG("BR")} gibt eine mit der google Charts API generierte Grafik zurück (siehe Anhang)
{Buienradar_logProxy(<DEVICE>)} also z.B.
{Buienradar_logProxy("BR")} kann in Verbindung mit einem Logproxy Device die typischen FHEM und FTUI Charts erstellen.
Die Daten werden erst nach dem ersten Empfang einer Vorhersage aufbereitet!
Ich versuche Fragen hier im Forum zu beantworten, bin aber kein Perl Profi.
Falls euch das Modul gefällt ;) https://paypal.me/lubeda (https://paypal.me/lubeda)
Viel Spaß mit diesen Modulen.
Ludger
31.10 19:50 Version aktualisiert
15.09. 13:15 Version aktualisiert
15.09. 09:45 Version aktualisiert
03.10. 14:15 Version aktualisiert
23.04. 16:25 Version aktualisiert
Super Sache! ;)
wollte es mal ausprobieren....
- Device angelegt
- beim Klick in der GUI auf das Device => Verbindung zu fhem verloren...
- per Telnet kam ich nicht mehr auf die console
Nach FHEM Neustart fand ich im Log
Undefined subroutine &main::BuienradarasHTML called at ./FHEM/59_Buienradar.pm line 59
Moin,
super, nutzen Buienalarm auf den Smartphones seit ca. 2 Jahren und es gibt nichts zuverlässigeres !!!
Modul werde ich mal testen, Danke !
Hört sich super an, so etwas hat in Fhem bisher gefehlt!
Werde es bei Gelegenheit testen!
Zitat von: LuBeDa am 14 September 2017, 17:24:47
Das Modul benötigt die Perl Bibliothek "DateTime", die man mit cpan install DateTime installieren kann.
Was ist das ? Die Installation dieser Bibliothek auf meinem nicht untermotorisiertem Banana läuft seit über 20min.... ein Ende ist nicht in Sicht
Ganz wohl ist mir dabei nicht....
Zitat von: Bartimaus am 15 September 2017, 09:05:03
Was ist das ? Die Installation dieser Bibliothek auf meinem nicht untermotorisiertem Banana läuft seit über 20min.... ein Ende ist nicht in Sicht
Ganz wohl ist mir dabei nicht....
Per apt-get sollte es auch tun.
apt-get install libdatetime-perl
Ah, ok danke. Libdatetime-perl wird ja auch bei der FHEM-Installation auf der Wiki-Seite "empfohlen".
Zitat von: kumue am 15 September 2017, 08:13:51
wollte es mal ausprobieren....
- Device angelegt
- beim Klick in der GUI auf das Device => Verbindung zu fhem verloren...
- per Telnet kam ich nicht mehr auf die console
Nach FHEM Neustart fand ich im Log
Undefined subroutine &main::BuienradarasHTML called at ./FHEM/59_Buienradar.pm line 59
Gleicher Fehler bei mir. libdatetime-perl ist installiert
2017.09.15 10:21:16 3: first timer
Undefined subroutine &main::BuienradarasHTML called at ./FHEM/59_Buienradar.pm line 59.
Gleicher Fehler bei mir, libdatetime-perl ist installiert, OS Debian 8
Wollte das device per define oben in der Zeile in FHEM anlegen, nach drücken von Enter schmiert FHEM ab.
Die Meldung "Undefined subroutine &main::BuienradarasHTML called at ./FHEM/59_Buienradar.pm line 59." habe ich auch im Log, allerdings laeuft mein fhem weiter und ich bekomme von meinem
nginx/1.6.2 ein "502 Bad Gateway" zurueck.
Udpate: fhem hat sich doch verabschiedet.
Gruss Helmut
Hallo,
es reicht beim Entwickeln scheinbar nicht nur "reload 59_Buienradar.pm" zu machen um alte Funktionen aus Perl zu löschen. Nach einen "shutdown restart" hatte ich ebenfalls das Problem mit:
Undefined subroutine &main::BuienradarasHTML called at ./FHEM/59_Buienradar.pm line 59
Der Fehler von Helmut kommt aber wahrscheinlich vom Buienradar-Server.
Wer sicht traut kann die neue Version von dem Modul im ersten Post nochmal herunterladen.
Sorry, das o.g. Verhalten hab ich nicht erwartet.
Ludger
so, neue Version eingespielt und es sieht schon besser aus..
Und das Gute: nur Nullen die nächsten Stunden :D
Im Log steht
2017.09.15 13:33:58 1: PERL WARNING: Use of uninitialized value $args[0] in subtraction (-) at ./FHEM/59_Buienradar.pm line 107.
2017.09.15 13:33:51 3: Parse Data
<BR>Niederschlag (<a href=./fhem?detail=Regenradar_G>Regenradar_G</a>)<BR>13:30<div style="width: 20px;">0.00</div><div style="width: 20px;">0.00</div><div style="width: 20px;">0.00</div><div style="width: 20px;">0.00</div><div style="width: 20px;">0.00</div><div style="width: 20px;">0.00</div><div style="width: 20px;">0.00</div><div style="width: 20px;">0.00</div><div style="width: 20px;">0.00</div><div style="width: 20px;">0.00</div><div style="width: 20px;">0.00</div><div style="width: 20px;">0.00</div><div style="width: 20px;">0.00</div><div style="width: 20px;">0.00</div><div style="width: 20px;">0.00</div><div style="width: 20px;">0.00</div><div style="width: 20px;">0.00</div><div style="width: 20px;">0.00</div><div style="width: 20px;">0.00</div><div style="width: 20px;">0.00</div><div style="width: 20px;">0.00</div><div style="width: 20px;">0.00</div><div style="width: 20px;">0.00</div><div style="width: 20px;">0.00</div>15:25
</div>
<div class="BRchart">
</style>
}
color: white;
margin: 1px;
padding: 3px;
text-align: right;
background-color: steelblue;
font: 10px sans-serif;
.BRchart div {
2017.09.15 13:32:44 3: <style>
2017.09.15 13:32:31 3: Parse Data
2017.09.15 13:32:30 3: first timer
Bei
2017.09.15 13:33:58 1: PERL WARNING: Use of uninitialized value $args[0] in subtraction (-) at ./FHEM/59_Buienradar.pm line 107.
muss ich mal sehen, habe da noch keine Idee.
Die anderen Ausgaben liegen am Loglevel, den passe ich an.
Ich warte aber noch bis Sonntag, falls noch weitere Sachen gefunden werden....
Ludger
Hallo,
das Problem mit dem Loglevel wurde behoben. Bei der Funktion Buienrar_HTML wurde ein zweiter optionaler Parameter angefügt mit dem man die maximale Länge der Balken festlegen kann.
Für die Darstellung in FTUI nehme ich das Highchart Widget (siehe Bild):
<li data-row="2" data-col="4" data-sizey="1" data-sizex="2">
<div data-type="highchart"
data-device="BR"
data-linenames="Vorhersage"
data-linetypes="area"
data-maxvaylue="rainMax"
data-logdevice="Logproxy"
data-columnspec='Func:Buienradar_logProxy("BR")'
data-style="ftui l3fill"
data-nofulldays='true'
data-title= "Regen"
class="nobuttons fullsize">
</div>
Die neue Version steht im ersten Beitrag zum Download.
Vielleicht traut sich jemand die neue Version zu testen ;-)
Ludger
Moin LuBeDa
Sehr schön.
ZitatVielleicht traut sich jemand die neue Version zu testen ;-)
Habe das Modul gerade in Betrieb genommen.
Mal sehen was sich tut.
Auf deren IE Seite sind auch Symbole zu sehen.
Kann man die auch ins Modul bekommen ?
Läuft bei mir auch auf dem Testsystem seit 11:00 Uhr. Danke für die Arbeit. Jetzt gibt es vermutlich für den Rest des Jahres keinen Regen mehr ;) alles 0 und keine Änderungen ausser rainDataStart 14:15
Bisher auch keine Fehlermeldungen im Log.
Gruss
Enno
Zitat von: Michael am 16 September 2017, 11:41:12
Auf deren IE Seite sind auch Symbole zu sehen.
Kann man die auch ins Modul bekommen ?
Welche genau?
Poste mal die URL oder einen Screenshot.
Ludger
ZitatWelche genau?
Poste mal die URL oder einen Screenshot.
Bitte sehr.
Ein Bild ist im Anhang.
Bisher auch keine Fehlermeldungen im Log.
Zitat von: LuBeDa am 14 September 2017, 17:24:47
Der Dienst stellt eine regionale Vorhersage mit einer 5 Minuten Auflösung zur Verfügung, die Vorhersage geht bis zu 2 Stunden im Voraus. Die Qualität der Daten ist so hoch dass man z.B. die Entscheidung wann man mit seinem Hund spazieren geht darauf basieren lassen kann.
Gibt es die Vorhersage auch für Deutschland? Auf der Webseite finde ich selbst für deutsche Großstädte wie Berlin oder München keine Anzeige mit einer 5 Minuten Auflösung.
Aus dem ersten Post...
Wenn man im global Device Longitude und Latitude definiert hat kann man mit define BR Buienradar das Device BR mit der lokalen Vorhersage einbinden.
Falls Du Longitude und Latitude bei dir definiert hast, bekommst Du die Angaben für deine Region... auch für D
Vielen Dank LuBeDa, so etwas suche ich schon so lange.
Zitat von: Michael am 16 September 2017, 11:41:12
Auf deren IE Seite sind auch Symbole zu sehen.
Kann man die auch ins Modul bekommen ?
Nö, ich habe nur die Niederschlagsvorhersage von Buienradar übernommen. Es gibt schon einige Wetter Module in FHEM, da wollte ich nichts neues machen.
Allerdings finde ich auch die Symbole von Buienradar deutlich schöner als die von Proplanta...
Ludger
Zitat von: kumue am 16 September 2017, 16:53:15
Falls Du Longitude und Latitude bei dir definiert hast, bekommst Du die Angaben für deine Region... auch für D
oder als Parameter beim define.
für den Signal Iduna Park in Dortmund z.B.
define Vorhersage_BVBStadion Buienradar 51.492649 7.451835
Moin,
Kann mir jemand sagen wo ich etwas über Highchart nachlesen kann, ich würde gerne das aus Post #15 darstellen , kenne mich aber mit Highchart überhaupt nicht aus.
Danke
Zitat von: Octopus180 am 16 September 2017, 19:45:00
Moin,
Kann mir jemand sagen wo ich etwas über Highchart nachlesen kann, ich würde gerne das aus Post #15 darstellen , kenne mich aber mit Highchart überhaupt nicht aus.
Danke
Da würde ich bei Frontends => TabletUI suchen
Zitat von: kumue am 16 September 2017, 16:53:15
Aus dem ersten Post...
Wenn man im global Device Longitude und Latitude definiert hat kann man mit define BR Buienradar das Device BR mit der lokalen Vorhersage einbinden.
Falls Du Longitude und Latitude bei dir definiert hast, bekommst Du die Angaben für deine Region... auch für D
Danke!
Ich hatte die Daten auf der Website nicht gefunden, die Daten sind aber verfügbar - Beispiel mit aktuellem Regen: http://gps.buienradar.nl/getrr.php?lat=50.7&lon=9.5
Edit sagt: Der Blick zum Himmel sagte mir die letzte Stunde es wird regnen... die Vorhersage von Buienradar hat auch Wolken angezeigt, aber keinen Regen... was soll ich sagen, es regnet aktuell bei mir :'(
Edit 2: In Bayern funktioniert es wohl nicht (mehr), da auch in Gebieten mit einem Niederschlag 10-100 (roter Bereich auf der Karte) keine Niederschlagsmenge angezeigt wird.
Edit 3: Der DWD stellt wohl auch eine Radar-Vorhersage für die nächsten 2 Stunden im 5-Minuten-Takt zur Verfügung, leider finde ich aber nur Bilder und keine Werte in Textform.
Zitat von: LuBeDa am 14 September 2017, 17:24:47
15.09. 13:15 Version aktualisiert
15.09. 09:45 Version aktualisiert
Mir fehlt im Code ein Hinweis auf die aktuell installierte Version (Datum, Uhrzeit). Hast Du schon in Betracht gezogen, die Installation zu vereinfachen und die Updates zu automatisieren?
Hier ein Beispiel, wie das mit GitHub einfach gelöst werden kann: https://haus-automatisierung.com/hardware/fhem/2017/03/25/fhem-tutorial-reihe-part-30-lametric-time-in-fhem-modul.html (https://haus-automatisierung.com/hardware/fhem/2017/03/25/fhem-tutorial-reihe-part-30-lametric-time-in-fhem-modul.html)
Vielen Dank für das tolle Modul @Ludger!
Neue Version auch über Github :)
update https://raw.githubusercontent.com/lubeda/59_Buienradar/master/controls_Buienradar.txt
Zitat von: LuBeDa am 17 September 2017, 15:46:32
Neue Version auch über Github :)
Vielen Dank für die Mühe.
Das Update läuft übrigens mit dem normalen Update automatisch mit, falls es mit https://wiki.fhem.de/wiki/Update#update_add (https://wiki.fhem.de/wiki/Update#update_add) hinzugefügt wird:
update add https://raw.githubusercontent.com/lubeda/59_Buienradar/master/controls_Buienradar.txtLeider scheint die Vorhersage in Bayern nicht mehr zu funktionieren, ich prüfe das aber zur Sicherheit in den nächsten Tagen/Wochen noch etwas. :'(
Hallo Lubeda,
magst Du deine definitionen für die Grafik mal posten?
Ich habe folgendes, aber das funktioniert nicht, ich hätte gerne die Grafik wie bei Dir im ersten Post. Meine Grafik ist 'leer'.
Kannst Du mir helfen?
define Regenradar Buienradar
define myDbLog ./db.conf Regenradar:rainData:.*
define Regenradar_svg SVG myDbLog:regenradar_db:HISTORY
regenradar_db.gplot:
# Created by Inoma, 2017-09-17 22:40:51
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'Niederschlag'
set ytics
set y2tics
set grid
set ylabel "Niederschlagsmenge"
set y2label ""
#myDbLog {Buienradar_SVG("Regenradar")}
plot "< awk '/rainData/{print $1}' <IN>"\
using 1:2 axes x1y1 title 'Regenmenge' ls l2fill lw 0.2 with lines
Zitat von: inoma am 17 September 2017, 21:33:35
magst Du deine definitionen für die Grafik mal posten?
Gerne :-)
vielleicht ist der Name ungünstig gewählt, aber Buienradar_SVG erstellt eine Grafik unabhängig vom SVG Modul.
Dazu einfach einen "weblink" mit der Funktion
{Buienradar_SVG("BR)"} definieren. (Siehe Bild SVG.PNG)
Um normale Plots zu erstellen benötigt man die Funktion
Buienradar_logProxy("BR").
Definition: siehe Bild Logproxy.png
Wobei "BR" mein Device ist.
Der Plot ist nicht so schön weil immer ein Tag geplottet wird.
Für den Plot wird auch nicht auf die Logs zugegriffen, ich logge nur rainNow damit ich einen Überblick über den vergangenen Regen habe.
Am schönsten ist FTUI mit dem highchart Widget siehe oben.
Ludger
Hallo LuBeda,
erstmal Danke für das gute Modul.
kannst du mir bitte erklären wie das mit dem highchart Widget funktioniert , ich habe schon versucht mich reinzulesen aber irgendwie verstehe ich das nicht.
Danke schon mal im voraus.
Zitat von: Octopus180 am 18 September 2017, 18:03:09
kannst du mir bitte erklären wie das mit dem highchart Widget funktioniert
Kann ich leider nicht, weil ich mir das auch nur zusammen gefummelt habe.
Meine Konfiguration des Widgets steht hier: https://forum.fhem.de/index.php/topic,76651.msg686204.html#msg686204
Highcharts an sich sind hier gut dokumentiert https://www.highcharts.com/docs (https://www.highcharts.com/docs) aber die Schnittstelle zu FHEM bleibt mir auch ein Rätsel. :(
Ludger
Das Modul ist super, leider liefern die Niederländer nur für das Grenzgebiet Deutschland Ergebnisse mit Werten, beim Rest wird konstant Null angezeigt.
Kennt jemand eine deutsche Alternative mit Niederschlagsmengen im 5-Minuten-Takt für die nächsten 2 Stunden?
Moin,
also Hannover würde ich nicht als Grenzgebiet zu den Niederlanden sehen. Für heute hatte ich rechtzeitig genaue Ansage, so dass ich in der Regenpause trocken mit dem Fahrrad nach Hause kam.
Ich beobachte noch, aber bis jetzt zeigt das Modul fast immer Regen an, wenn es auch tatsächlich regnet. Bisher das Wettermodul dessen Ansage die grösste Trefferquote bei mir hat.
Gruss
Enno
Sobald Du einmal Daten hast kannst Du darauf vertrauen. Bayern ist aber definitiv nicht abgedeckt. Zum Test einfach ein Regengebiet der grafischen Vorhersage nehmen und die Koordinaten im Weblink (siehe oben) eingeben. Es wird immer 000 angezeigt.
Zitat von: ares am 17 September 2017, 11:08:23
Beispiel mit aktuellem Regen: http://gps.buienradar.nl/getrr.php?lat=50.7&lon=9.5
Ich habe nun auch eine Seite gefunden, welche Deutschland komplett abdeckt und bei der man sogar mit Radius 1 bzw. 2 einen etwas größeren Bereich abfragen kann. Die Qualität der Daten schein identisch zu sein:
https://api.themeteocompany.com/precipitation/getforecastbylatlon/?lat=50.0&lon=12.5&radius=0 (https://api.themeteocompany.com/precipitation/getforecastbylatlon/?lat=50.0&lon=12.5&radius=0)
Unter Umständen kann man das Modula ja erweitern, so dass die Quelle per Parameter auswählbar ist. Das Ergebnis sollte dann ja wieder identisch sein (JSON: UtcDateString, Value).
für Karlsruhe haben die Holländer auch keine Daten parat.
von daher würde ich eine Erweiterung begrüßen. :)
Ok musste auch gerade festellen, das die Seite zwar Zahlen ausgibt, diese aber immer 000 sind egal ob es regnet oder nicht.
Ich wäre also auch an einer Erweiterung des Moduls interessiert.
Gruß Christian
Auch fuer Westerkappeln (in der Naehe von Osnabrueck) bekomme ich nur Nullwerte geliefert.
Dabei sind wir doch deutlich naeher an Holland als die Hannoveraner.
Daher haette auch ich Interesse an der Erweiterung.
Gruss Helmut
badenwürtenberg ist leider auch draußen
Kommendes Update:
Ich habe festgestellt das eine Regenvorhersage mit zwei Nachkommastellen nicht genügt. Daher arbeite ich an einem Update das drei Nachkommastellen und die Orginalwerte von Buienradar darstellen kann.
Außerdem wird das Reading rainData verschwinden (also zu einem unsichtbaren INTERNAL), weil es für einen User keinen Sinn hat.
Zu der API von https://api.themeteocompany.com/precipitation/getforecastbylatlon/?lat=50.0&lon=12.5&radius=0 (https://api.themeteocompany.com/precipitation/getforecastbylatlon/?lat=50.0&lon=12.5&radius=0): Finde ich auch klasse, sollte aber m.E. in einem eigenen Modul verarbeitet werden. Habe noch keine Ahnung wie man ein JSON Objekt in ein Perl Object umwandelt. Also Freiwillige vor :-)
Zitat von: LuBeDa am 21 September 2017, 16:15:02
Habe noch keine Ahnung wie man ein JSON Objekt in ein Perl Object umwandelt. Also Freiwillige vor :-)
Vielleicht ist regex eine Alternative für Dich?
(?s)"UtcDateString":"([0-9]+)","Value":([0-9.]+)
Zitat von: LuBeDa am 21 September 2017, 16:15:02
Finde ich auch klasse, sollte aber m.E. in einem eigenen Modul verarbeitet werden. Habe noch keine Ahnung wie man ein JSON Objekt in ein Perl Object umwandelt. Also Freiwillige vor :-)
Nun, dafür gibt es doch: libjson-perl. Findet schon in vielen Fhem Modulen Verwendung.
Grüße Jörg
Habe das Buienradar optimiert und eine erste Beta von einem Device RainTMC (für the meteo company) in der Pipeline. Brauche nur noch zwei-drei Regentage zum Testen.
Eine Frage in die Runde: Wird der Befehl get <DEVICE> startsIn also in vievielen Minuten startet der Regen, überhaupt benötigt?
Weil es kein Reading ist kann man damit auch nichts triggern. Ebenso steht get <DEVICE> rainDuration zur Disposition.
Ludger
Zitat von: LuBeDa am 25 September 2017, 16:27:42
Habe das Buienradar optimiert und eine erste Beta von einem Device RainTMC (für the meteo company) in der Pipeline. Brauche nur noch zwei-drei Regentage zum Testen.
Super, vielen Dank!
Manfred
Von mir auch schonmal ein grosses DANKE!
Zitat von: LuBeDa am 25 September 2017, 16:27:42
Habe das Buienradar optimiert und eine erste Beta von einem Device RainTMC (für the meteo company) in der Pipeline. Brauche nur noch zwei-drei Regentage zum Testen.
Auch von meiner Seite herzlichen Dank.
Zitat von: LuBeDa am 25 September 2017, 16:27:42
Eine Frage in die Runde: Wird der Befehl get <DEVICE> startsIn also in vievielen Minuten startet der Regen, überhaupt benötigt?
Weil es kein Reading ist kann man damit auch nichts triggern. Ebenso steht get <DEVICE> rainDuration zur Disposition.
Beides finde ich sehr nuetzlich. Bitte lass beide Abfragen drin.
Gruss Helmut
Es geht "langsam" voran.
Die erste Grafik mit Buienradar und TheMeteoCompany im Vergleich. Auffällig ist das beide System unterschiedliche Regenverläufe liefern.
Weil ich keine Doku zu TheMeteoCompany habe ist die Einheit der gemeldeten Werte unklar.
Ich programmiere in den nächsten Tagen weiter.
Es ist so weit. :)
Ich habe das Modul 59_Buienradar etwas optimiert und ein neues Modul für die von Ares https://forum.fhem.de/index.php/topic,76651.msg688319.html#msg688319 (https://forum.fhem.de/index.php/topic,76651.msg688319.html#msg688319) vorgeschlagene API entwickelt.
Es empfiehlt sich das alte Buienradar-Device zu löschen und neu anzulegen.
Das Update für Buienradar bekommt man so:
update force https://raw.githubusercontent.com/lubeda/59_Buienradar/master/controls_Buienradar.txt
Das für das neue Modul RainTMC so:
update force https://raw.githubusercontent.com/lubeda/59_RainTMC/master/controls_RainTMC.txt
Die Doku zu den Modulen findet sich in der lokalen commandref.
Wem die Module gefallen kann mir gerne einen Kaffee spendieren paypal.me/lubeda (http://paypal.me/lubeda) 8)
Ludger
@Lubeda
Danke für das schnelle Update!
könntest du das Modul nochmal als Datei anhängen?
Das wäre mir lieber :)
Zitat von: Fixel2012 am 01 Oktober 2017, 00:05:26
könntest du das Modul nochmal als Datei anhängen?
Sind im ersten Post.
Mahlzeit,
kann es sein dass Österreich mal wieder nicht dabei ist? Obwohl wenn ich auf der HP nach Tulln suche, ich ein Ergebnis bekomme
https://www.buienradar.nl/weer/tulln/at/2763266
Hier ein List vom Device
Internals:
CFGFN
DEF 48.3315 16.0607
INTERVAL 240
LATITUDE 48.3315
LONGITUDE 16.0607
NAME RegenradarTulln
NEXTUPDATE 2017-10-01 12:49:33
NR 351
STATE Initialized
TYPE Buienradar
URL http://gps.buienradar.nl/getrr.php?lat=48.3315&lon=16.0607
READINGS:
2017-10-01 12:41:33 rainAmount init
2017-10-01 12:41:33 rainBegin unknown
2017-10-01 12:41:33 rainDataStart unknown
2017-10-01 12:41:33 rainEnd unknown
2017-10-01 12:41:33 rainNow unknown
Attributes:
Wenn ich wie im Thread beschrieben das BVBStadion suche bekomme ich Werte???
Schönen Tag
Helmut
Ich habe nirgendwo etwas über die Abdeckung der Vorhersage gefunden. Da muss man nehmen was man bekommt. :-(
Bei dem RainTMC Modul würdest Du aber Daten bekommen.
Danke
Habe jetzt RainTMC installiert und warte auf den nächsten Regen (den ich eigentlich nicht brauche 8))
Lg
Helmut
Zitat von: Helmi55 am 01 Oktober 2017, 15:57:26
Habe jetzt RainTMC installiert
wie? was braucht man dazu ?
Habe gesucht, aber nichts gefunden
Für die Graphen gibt es z.B. Weblinks:
so
defmod WL_RPNG weblink htmlCode {RainTMC_PNG("R")}
oder so:
defmod WL_RHTML weblink htmlCode {RainTMC_HTML('R')}
Wobei "R" der Name des Gerätes ist.
Außerdem die Readings oder auch die LogProxy-Funktion {RainTMC_logProxy("R")}. Damit kann man normale SVGs erstellen.
Steht aber auch unter "Device specific help"
sorry, habe die Datei im ersten Post echt übersehen.
Danke.
Super, vielen Dank!
Um im Frontend später auch sinnvolle Texte und nicht "unknown" ausgeben zu müssen wär vielleicht noch ein neues Reading "rainDataEnd" sinnvoll.
VG
Manfred
Zitat von: ares am 01 Oktober 2017, 19:48:48
Um im Frontend später auch sinnvolle Texte und nicht "unknown" ausgeben zu müssen wär vielleicht noch ein neues Reading "rainDataEnd" sinnvoll.
Das verstehe ich nicht so ganz. Es gibt derzeit rainDataStart, rainBegin und rainEnd.
Die beiden letzten Werte sind "unknown" wenn in den Daten kein Regen "enthalten" ist.
Das Reading "rainDataEnd" müsste, nach meiner Meinung, den letzten in der Datenquelle enthaltenen Zeitpunkt angeben. Also wie im angehängtem Bild.
Oder?
Ludger
Dumme Frage, aber wie bekomme ich denn aus den drei Möglichen Visualisierungen eine Grafik in Fhem angezeigt? Bzw TabletUI?
Über ein Weblink device mit {RainTMC_PNG("Regenvorhersage")} hat es leider nicht geklappt :o
Danke,
Fixel
Zitat von: Fixel2012 am 02 Oktober 2017, 23:02:48
Dumme Frage, aber wie bekomme ich denn aus den drei Möglichen Visualisierungen eine Grafik in Fhem angezeigt? Bzw TabletUI?
Über ein Weblink device mit {RainTMC_PNG("Regenvorhersage")} hat es leider nicht geklappt :o
Danke,
Fixel
Die *_HTML und *_PNG Funktionen funktionieren nur im FHEMWEB. Man kann die PNG auch leider nicht mit Telegram versenden.
Für die Charts gibt es die *_logProxy Funktion.
Hier habe ich beschrieben wie ich es mache https://forum.fhem.de/index.php/topic,76651.msg686204.html#msg686204 (https://forum.fhem.de/index.php/topic,76651.msg686204.html#msg686204) geht analog auch mit dem RainTMC Device.
Ludger
Zitat von: LuBeDa am 02 Oktober 2017, 20:24:20
Das verstehe ich nicht so ganz. Es gibt derzeit rainDataStart, rainBegin und rainEnd.
Die beiden letzten Werte sind "unknown" wenn in den Daten kein Regen "enthalten" ist.
Das Reading "rainDataEnd" müsste, nach meiner Meinung, den letzten in der Datenquelle enthaltenen Zeitpunkt angeben. Also wie im angehängtem Bild.
Oder?
Ludger
Für eine Ausgabe in Textform sind eventuell weitere Werte interessant.
Vorhersagezeitraum von <rainDataStart> bis <?>
Regenmenge aktuell <rainNow>
Regenmenge max <rainMax>
nächster Schauer von <rainBegin> bis <rainEnd>, Regenmenge <rainAmount>
Regenmenge gesamt von <rainBegin> bis <?> , Regenmenge <?>Für eine Ausgabe als Chart auf der LaMetric wird ein Array benötigt. Kann ich das irgendwie abgreifen?
{
"chartData": [ 1, 2, 3, 4, 5, 6, 7 ]
}Manfred
Zitat von: ares am 03 Oktober 2017, 09:38:46
Für eine Ausgabe als Chart auf der LaMetric wird ein Array benötigt. Kann ich das irgendwie abgreifen?
{
"chartData": [ 1, 2, 3, 4, 5, 6, 7 ]
}
Welche Werte können die chartData-Elemente haben von 0..100 o.ä. Was ist dir lieber ein String z.B. "1|2|3" oder direkt der Text wie in deinem Beispiel?
Wenn es läuft hätte ich gerne ein Foto mit einem Chart :-)
Zitat von: LuBeDa am 03 Oktober 2017, 10:54:16
Welche Werte können die chartData-Elemente haben von 0..100 o.ä. Was ist dir lieber ein String z.B. "1|2|3" oder direkt der Text wie in deinem Beispiel?
Mit Komma getrennte ganzzahlige Werte. Die Höhe passt sich automatisch an den höchsten Wert an, welche auch im Milliardenbereich liegen können.
Da die Auflösung fix ist (37×8 Pixel) sieht es mit 1-7, 9, 12, 18 oder 37 Balken am Besten aus.
Beispiel:
8, 7, 6, 5, 4, 3, 2, 1, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4An Text werden bis zu 9 Zeichen gleichzeitig dargestellt bevor automatisch gescrollt wird. Falls Du das selbst im Browser testen möchtest, dann kannst Du Dich unter https://developer.lametric.com (https://developer.lametric.com) kostenlos anmelden und eine Indicator App zum Test erstellen.
Manfred
O.K. habe die Readings erweitert.
Ich liefere 12 Werte für die LaMetric zurück. Damit hat man eine Stunde im voraus.
Damit ich mir auch eine LaMetric leisten kann ;), hier mein Spenden-Link https://paypal.me/lubeda (https://paypal.me/lubeda)
Die neuen Versionen sind auch im ersten Post hinterlegt
Ludger
Zitat von: LuBeDa am 03 Oktober 2017, 14:14:06
O.K. habe die Readings erweitert.
Ich liefere 12 Werte für die LaMetric zurück. Damit hat man eine Stunde im voraus.
Das ging ja flott. Hast Du einfach die Nachkommastellen abgeschnitten? Vielleicht solltest Du die Werte besser mit Faktor 10^"Anzahl maximaler Nachkommastellen" mulitplizieren, da ich trotz Regen keine Werte erhalte. Außerdem sollten 18 Werte möglich sein, für 37 Werte reicht es leider nicht.
defmod Regen RainTMC
setstate Regen 0.00
setstate Regen 2017-10-03 15:38:31 rainAmount 1.776
setstate Regen 2017-10-03 15:38:31 rainBegin 2017-10-03 17:55:00
setstate Regen 2017-10-03 15:38:31 rainDataEnd 2017-10-03 18:20:00
setstate Regen 2017-10-03 15:38:31 rainDataStart 2017-10-03 15:40:00
setstate Regen 2017-10-03 15:38:31 rainEnd 2017-10-03 18:20:00
setstate Regen 2017-10-03 15:38:31 rainLaMetric 0,0,0,0,0,0,0,0,0,0,0,0
setstate Regen 2017-10-03 15:38:31 rainMax 0.562
setstate Regen 2017-10-03 15:38:31 rainNow 0
setstate Regen 2017-10-03 15:38:31 rainTotal 1.776Zitat von: LuBeDa am 03 Oktober 2017, 14:14:06
Damit ich mir auch eine LaMetric leisten kann ;), hier mein Spenden-Link https://paypal.me/lubeda (https://paypal.me/lubeda)
Ludger
Warte einfach auf den Amazon Black Friday 2018. Du sparst Dir dann wahrscheinlich 60 Euro, da die Uhr bei Amazon immer wieder im Angebot ist.
Manfred
rainLaMetric zeigt den Regen der in den nächsten 12*5 Minuten kommt an. Der Regen bei dir kommt erst um 17:55 liegt also noch außehalb des Anzeigebereichs.
Mehr als 12 Datenpunkte wollte ich nicht einbauen weil nicht feststeht das ich immer 18 oder mehr Werte zum Anzeigen habe.
Also das raintmc liefert mir werde, Danke. Jetzt suche ich noch eine Möglichkeit mir die Vorhersage als Bild zuschicken zu lassen. Wie bekomme ich den code aus {RainTMC_PNG("R")} in eine Bilddatei, die ich per Telegram verschicken kann?
Gruß Christian
Zitat von: LuBeDa am 03 Oktober 2017, 16:25:22
rainLaMetric zeigt den Regen der in den nächsten 12*5 Minuten kommt an. Der Regen bei dir kommt erst um 17:55 liegt also noch außehalb des Anzeigebereichs.
Mehr als 12 Datenpunkte wollte ich nicht einbauen weil nicht feststeht das ich immer 18 oder mehr Werte zum Anzeigen habe.
Stimmt, das hatte ich übersehen. Sorry.
Leider blieb der Regen aus, so dass weitere Tests erst einmal ausfallen. Ich bin aber auch nicht wirklich traurig, wenn es nicht regnet.
Zitat von: mrbreil am 04 Oktober 2017, 15:48:03
Jetzt suche ich noch eine Möglichkeit mir die Vorhersage als Bild zuschicken zu lassen. Wie bekomme ich den code aus {RainTMC_PNG("R")} in eine Bilddatei, die ich per Telegram verschicken kann?
Da kenne ich leider keine Möglichkeit :(
Die *_PNG Funktion erzeugt mit Javascript zur Laufzeit ein PNG Bild im Browser. Es gibt also nicht wirklich eine Datei die man versenden kann.
Das Script kann man sich anzeigen lassen indem man {Buienradar_PNG("BR")} in die "Eingabeaufforderung" von FHEM eingibt.
<div id="chart_div_BR"; style="width:100%; height:100%"></div>
<script type="text/javascript" src="https://www.gstatic.com/charts/loader.js"></script>
<script type="text/javascript">
google.charts.load("current", {packages:["corechart"]});
google.charts.setOnLoadCallback(drawChart);
function drawChart() {
var data = google.visualization.arrayToDataTable([
['string', 'mm/m² per h'],
['17:35',0.000],['',0.000],['17:45',0.000],['',0.000],['17:55',0.000],['',0.000],['18:05',0.000],['',0.000],['18:15',0.000],['',0.000],['18:25',0.000],['',0.000],['18:35',0.005],['',0.000],['18:45',0.005],['',0.005],['18:55',0.005],['',0.000],['19:05',0.000],['',0.000],['19:15',0.000],['',0.005],['19:25',0.000],['',0.000]]);
var options = {
title: 'Niederschlag',
subtitle: 'Vorhersage (BR)', hAxis: {slantedText:true, slantedTextAngle:45,
textStyle: {
fontSize: 10}
},
vAxis: {minValue: 0}
};
var my_div = document.getElementById(
"chart_div_BR"); 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> Auf dem Handy nutze ich die kostenlose Version der App "RainToday".
Ludger
Hallo Ludger,
wenn ich, wie in deinem ersten Post,
{RainTMC_HTML(<DEVICE>,<Pixel>)} also z.B. {RainTMC_HTML("Wetterradar",500)}setze, bekomme ich folgende Fehlermeldung.
ERROR evaluating {RainTMC_HTML("Wetterradar",500)}: Too many arguments for main::RainTMC_HTML at (eval 11121) line 1, near "500)"
Was mache ich falsch?
Jetzt regnet es endlich bei mir und auch in RainTMC. Aber mit jedem Refresh wechselt er reproduzierbar rainBegin zwischen 16:50 und 16:30 hin und her!?! Auf http://meteoradar.co.uk zeigt er "rain from 16:45" an, das kann aber auch am dort eingestellten Radius "2" liegen, den ich in RainTMC leider (noch) nicht setzen kann.
Zitat von: inoma am 04 Oktober 2017, 22:36:16
Was mache ich falsch?
Bei Buienradar_HTML kann man einen optionale Breite mit angeben. Bei RainTMC_HTML geht das nicht. Sollte eigentlich jeweils auch so in der Commandref der Befehle stehen.
Ich habe mail einen Screenshot der beiden Ausgaben angehanden, dann wird klar warum man das bei RainTMC nicht braucht.
Ludger
Hallo Ludger, danke, jetzt hab ich es!!
Beste Grüsse!
Zitat von: ares am 05 Oktober 2017, 16:26:21
eingestellten Radius "2"
Habe mal mit unterschiedlichen Radien getestet, ich glaube fast man kann den Radius würfeln :o
Zitat von: LuBeDa am 06 Oktober 2017, 19:44:00
Habe mal mit unterschiedlichen Radien getestet, ich glaube fast man kann den Radius würfeln :o
Die unterschiedlichen Einstellungen für Radius habe ich nicht getestet. In Deiner Grafik sind aber auch die Zeiten verschoben und die Werte nicht alle zur selben Zeit ermittelt. Ein größerer Radius sollte im Randgebiet von Schauern etwas öfter Regen anzeigen.
Auf den angegebenen Seiten https://www.themeteocompany.com/#websites (https://www.themeteocompany.com/#websites) arbeiten aber anscheinend alle mit Radius 2. Die (konstante) Grafik für den aktuellen Ort wird z.B. auf https://www.niederschlagsradar.de (https://www.niederschlagsradar.de) erzeugt nachdem man die Geoposition manuell festgelegt wird. Im Script steht dann der besagte Radius 2. Über einen zusätzlichen Parameter könnte man den Radius in RainTMC optional angeben, als Default scheint 2 aber eventuell sinnvoll zu sein.
Zitat von: ares am 05 Oktober 2017, 16:26:21
Aber mit jedem Refresh wechselt er reproduzierbar rainBegin zwischen 16:50 und 16:30 hin und her!?!
Eventuell ist im Modul aber noch ein kleiner Bug, da die
Ergebnisse bei jedem Refresh hin und her wechseln, obwohl die JSON-Daten konstant sind. Kannst Du das bitte nochmal überprüfen?
Manfred
Zitat von: ares am 07 Oktober 2017, 10:21:34
Ein größerer Radius sollte im Randgebiet von Schauern etwas öfter Regen anzeigen.
Man kann den radius jetzt per Attribut setzen.
Zitat von: ares am 07 Oktober 2017, 10:21:34
Eventuell ist im Modul aber noch ein kleiner Bug, da die Ergebnisse bei jedem Refresh hin und her wechseln, obwohl die JSON-Daten konstant sind.
Das konnte ich so nicht nachvollziehen. Scheinbar gibt der Dienst je nach Koordinaten, machmal auch abhängig vom Radius unterschiedlich viele Vorhersagedaten zurück. Das Modul zeigt immer alle zukünftigen Werte an.
Hallo Ludger,
das Wetterradar mit 'themeteocompany' funktioniert wunderbar präzise, die Vorhersagen sind in der Regel bis auf 5 Minuten genau.
Allerdings bekomme ich manchmal folgende Feherlmeldungen im 8 Sekunden Takt im Log, falls das api nicht erreichbar ist. Ich dachte das Wetterradar wird nur alle 5 oder 10 Minuten abgefragt. Ich habe auch kein Attribut gefunden, mit dem man das Interval einstellen kann. Kann ich das irgendwie einstellen / ändern?
Beste Grüsse!
2017.10.24 04:20:41 3: Wetterradar: error while requesting https://api.themeteocompany.com/precipitation/getforecastbylatlon/?radius=0&lat=48.1378&lon=11.5759 - DNS 172.21.0.1 timed out
2017.10.24 04:20:49 3: Wetterradar: error while requesting https://api.themeteocompany.com/precipitation/getforecastbylatlon/?radius=0&lat=48.1378&lon=11.5759 - DNS 172.21.0.1 timed out
2017.10.24 04:20:57 3: Wetterradar: error while requesting https://api.themeteocompany.com/precipitation/getforecastbylatlon/?radius=0&lat=48.1378&lon=11.5759 - DNS 172.21.0.1 timed out
2017.10.24 04:21:05 3: Wetterradar: error while requesting https://api.themeteocompany.com/precipitation/getforecastbylatlon/?radius=0&lat=48.1378&lon=11.5759 - DNS 172.21.0.1 timed out
2017.10.24 04:21:13 3: Wetterradar: error while requesting https://api.themeteocompany.com/precipitation/getforecastbylatlon/?radius=0&lat=48.1378&lon=11.5759 - DNS 172.21.0.1 timed out
2017.10.24 04:21:21 3: Wetterradar: error while requesting https://api.themeteocompany.com/precipitation/getforecastbylatlon/?radius=0&lat=48.1378&lon=11.5759 - DNS 172.21.0.1 timed out
Zitat von: LuBeDa am 24 Oktober 2017, 07:45:29
Das konnte ich so nicht nachvollziehen. Scheinbar gibt der Dienst je nach Koordinaten, machmal auch abhängig vom Radius unterschiedlich viele Vorhersagedaten zurück. Das Modul zeigt immer alle zukünftigen Werte an.
Den Dienst hatte ich damals überprüft und die Ergebnisse waren immer identisch.
Das Modul hat auch im Wechsel zwischen Ergebnis 1 und Ergebnis 2 konstant identische Werte angezeigt. Das ist nicht nur einmal sondern beliebig oft passiert, getestet habe ich das 10 mal oder öfter.
Kann bitte noch jemand bei Regen testen, ob die Werte hin und her springen wenn mehrfach manuell aktualisiert wird?
Die Werte verändern sich nicht zufällig sondern werden im Wechsel konstant angezeigt, was ich beim Dienst nicht liegen kann.
Aufruf:
get RainTMC_Devicename refresh
Ergebnis bei mir für z.B. rainLaMetric:
177,364,205,80,0,0,0,0,0,99,236,236
236,236,364,236,0,0,0,0,0,0,236,236
177,364,205,80,0,0,0,0,0,99,236,236
236,236,364,236,0,0,0,0,0,0,236,236
Zitat von: ares am 29 Oktober 2017, 09:57:49
Kann bitte noch jemand bei Regen testen
Ich habe mal mein Log als Screenshot angehangen. Man kann dort, an den markierten Stellen, erkennen das bestimmte Werte (Regenmengen) in 5 Minuten Schritten immer näher kommen. Genau so soll es aus meiner Sicht sein.
Deinen Effekt kann ich mir nicht erklären.
Schau doch mal in den Quelltext, vielleicht findest Du dort eine Fehler.
Wartest Du beim Log immer bis zum AutoRefresh oder hast Du auch mal 10x in Folge manuell aktualisiert?
Mir ist eben auch noch aufgefallen, dass die Grafik auf www.niederschlagsradar.de (Radius 2) konstant bleibt und die Werte der API entsprechen. Hast Du das mal mit RainTMC_PNG bei identischen Koordinaten und Radius verglichen?
Zitat von: inoma am 24 Oktober 2017, 07:49:27
Hallo Ludger,
das Wetterradar mit 'themeteocompany' funktioniert wunderbar präzise, die Vorhersagen sind in der Regel bis auf 5 Minuten genau.
Allerdings bekomme ich manchmal folgende Feherlmeldungen im 8 Sekunden Takt im Log, falls das api nicht erreichbar ist....
Hallo Ludger,
ich könnte gerade Kotzen. Mir hat das Modul ebenfalls heute Nachmittag so die Log Datei zugemüllt, sodass mein Server nichts mehr auf die Kette gebracht hat. Sogar Daten meiner SD-Karte sind zerschossen, weil zu viel Speicher benötigt wurde.
Ich habe teilweise 138! Logmeldungen pro Sekunde hatte. Verbose steht auf 3.
Hier mal ein kleiner Auszug:
2017.10.31 16:51:12 3: Buienradar: error while requesting http://gps.buienradar.nl/getrr.php?lat=51.44004&lon=7.11186 - gethostbyname gps.buienradar.nl failed
2017.10.31 16:51:12 3: Buienradar: error while requesting http://gps.buienradar.nl/getrr.php?lat=51.44004&lon=7.11186 - gethostbyname gps.buienradar.nl failed
2017.10.31 16:51:12 3: Buienradar: error while requesting http://gps.buienradar.nl/getrr.php?lat=51.44004&lon=7.11186 - gethostbyname gps.buienradar.nl failed
2017.10.31 16:51:12 3: Buienradar: error while requesting http://gps.buienradar.nl/getrr.php?lat=51.44004&lon=7.11186 - gethostbyname gps.buienradar.nl failed
2017.10.31 16:51:12 3: Buienradar: error while requesting http://gps.buienradar.nl/getrr.php?lat=51.44004&lon=7.11186 - gethostbyname gps.buienradar.nl failed
2017.10.31 16:51:12 3: Buienradar: error while requesting http://gps.buienradar.nl/getrr.php?lat=51.44004&lon=7.11186 - gethostbyname gps.buienradar.nl failed
2017.10.31 16:51:12 3: Buienradar: error while requesting http://gps.buienradar.nl/getrr.php?lat=51.44004&lon=7.11186 - gethostbyname gps.buienradar.nl failed
2017.10.31 16:51:12 3: Buienradar: error while requesting http://gps.buienradar.nl/getrr.php?lat=51.44004&lon=7.11186 - gethostbyname gps.buienradar.nl failed
2017.10.31 16:51:12 3: Buienradar: error while requesting http://gps.buienradar.nl/getrr.php?lat=51.44004&lon=7.11186 - gethostbyname gps.buienradar.nl failed
2017.10.31 16:51:13 3: Buienradar: error while requesting http://gps.buienradar.nl/getrr.php?lat=51.44004&lon=7.11186 - gethostbyname gps.buienradar.nl failed
2017.10.31 16:51:13 3: Buienradar: error while requesting http://gps.buienradar.nl/getrr.php?lat=51.44004&lon=7.11186 - gethostbyname gps.buienradar.nl failed
2017.10.31 16:51:13 3: Buienradar: error while requesting http://gps.buienradar.nl/getrr.php?lat=51.44004&lon=7.11186 - gethostbyname gps.buienradar.nl failed
2017.10.31 16:51:13 3: Buienradar: error while requesting http://gps.buienradar.nl/getrr.php?lat=51.44004&lon=7.11186 - gethostbyname gps.buienradar.nl failed
2017.10.31 16:51:13 3: Buienradar: error while requesting http://gps.buienradar.nl/getrr.php?lat=51.44004&lon=7.11186 - gethostbyname gps.buienradar.nl failed
2017.10.31 16:51:13 3: Buienradar: error while requesting http://gps.buienradar.nl/getrr.php?lat=51.44004&lon=7.11186 - gethostbyname gps.buienradar.nl failed
2017.10.31 16:51:13 3: Buienradar: error while requesting http://gps.buienradar.nl/getrr.php?lat=51.44004&lon=7.11186 - gethostbyname gps.buienradar.nl failed
2017.10.31 16:51:13 3: BDer Aufruf der Adresse hat funktioniert. Ich musste das Device Löschen und einiges Wiederherstellen.
Merkwürdig!
Eigentlich sollte das Modul, im Fehlerfall, nach 90 Sekunden erneut versuchen Daten abzuholen. Warum das so bei dir gelaufen ist kann ich nicht nachvollziehen.
Ich habe provisorisch die Fehlerbehandlung komplett rausgenommen (siehe Version im ersten Post). Jetzt sollte er, wenn vom buienradar.nl keine Daten kommen es im normalen Intervall wieder versuchen.
Die zweite wichtigere Frage ist, warum hat dein FHEM Host den Fehler "gethostbyname gps.buienradar.nl failed" und dein PC nicht?
Ich versuche eine robustere Fehlerbehandlung zu programmieren. Die wird dann auch wieder auf github hochgeladen.
Ludger
Nachtrag: Beim RainTMC ebenfalls die Fehlerbehandlung raugenommen.
@inoma: Das mit den 8 Sekunden kann ich jetzt nachvollziehen, ist in der Version im ersten Post jetzt raus.
Zitat von: LuBeDa am 31 Oktober 2017, 19:45:00
Die zweite wichtigere Frage ist, warum hat dein FHEM Host den Fehler "gethostbyname gps.buienradar.nl failed" und dein PC nicht?
Hi,
hier habe ich natürlich nicht zeitgleich gucken können ob FHEM-Server und mein Windows PC dasselbe Problem gleichzeitig haben.
Vielleicht haben das Problem auch noch andere von Euch. Leider schreckt es mich ein wenig vor einer erneuten Definition zurück.
Zitat von: Kamik am 31 Oktober 2017, 19:49:47
Leider schreckt es mich ein wenig vor einer erneuten Definition zurück.
Das kann ich nachvollziehen!
Bei mir laufen beide Module (Buienradar und RainTMC) dauerhaft in meinem "Produktionssystem".
Zitat@inoma: Das mit den 8 Sekunden kann ich jetzt nachvollziehen, ist in der Version im ersten Post jetzt raus.
Danke!!!
@inoma und @kamik
Hallo, könnten ihr mal des Ergebnis des Befehls{time()."=".gettimeofday()} posten?
Bei mir kommt so etwas heraus:
1509525056=1509525056.49631
Zitat von: LuBeDa am 01 November 2017, 09:31:58
@inoma und @kamik
Hallo, könnten ihr mal des Ergebnis des Befehls{time()."=".gettimeofday()} posten?
Bei mir kommt so etwas heraus:
1509525056=1509525056.49631
Ich wurde zwar nicht angesprochen, erhalte aber in beiden Fällen Nachkommastellen am RasPi:
1509534395.92762=1509534395.92768
Zitat von: LuBeDa am 01 November 2017, 09:31:58
@inoma und @kamik
Hallo, könnten ihr mal des Ergebnis des Befehls{time()."=".gettimeofday()} posten?
Bei mir kommt so etwas heraus:
1509525056=1509525056.49631
Hi,
also bei mir ist es auch fast identisch:
1509549482.79108=1509549482.79115
RPI3: bei mir kommt 1509554404.84147=1509554404.84151
RPi1 B+
Zitat1509557028=1509557028.20215
RPi2 Pi2
Zitat1509557046=1509557046.13395
Gruss Gerd
Kann es sein, dass die letzten Updates nur über die Versionen aus dem 1. Post, nicht aber über den FHEM-Updateprozess kommen? Lt. FHEM erhalte ich bei beiden Modulen "nothing to do...".
Meine Versionen sind vom 29.10.17.
LG
Holger
Weil Im Moment keine Änderungen da sind. Denn update text wirst du ja manuell hinzugefügt haben
Gesendet von meinem SM-T560 mit Tapatalk
Es sind Änderungen da, die Versionen unterscheiden sich.
Wäre schön, wenn das gleichgezogen wird. Ansonsten müsste ich die Module vom automatischen Update ausschließen, was ja nicht wirklich sinnvoll ist.
LG
Holger
In irgendeinem Post hatte ich geschrieben das es die provisorische Fehlerbehebung nur im ersten Beitrag gibt!!!!
Weil das scheinbar überlesen wurde habe ich heute Buienradar im Github auch aktualisiert.
Das Modul holt nun alle 240 Sekunden Daten von Buienradar ab. Wenn es eine Fehlermeldung beim Datenholen gibt wird der State auf error gesetzt. Das Intervall wird also im Fehlerfall nicht mehr verkürzt.
Scheinbar gibt es unterschiedliche Ausprägungen der Time-Funktionen, mal als Intger, mal als float.
In meiner Konstellation funktionierte die Fehlerbehandlung mit einer 90 Sekunden Verzögerung perfekt, es gab aber auch Fälle wo es scheinbar im 90 Nanosekunden intervall versucht wurde.
Viel Glück mit der aktuellen Version ;).
Ludger
Hi,
ich habe aus diesem Thread die Charts für FTUI übernommen. Diese zeigen aber keinerlei Daten an! Hat das jemand von Euch mit Daten gefüllt?
Zitat<li data-row="1" data-col="5" data-sizey="1" data-sizex="2">
<div data-type="highchart"
data-device="BR"
data-linenames="Vorhersage"
data-linetypes="area"
data-maxvaylue="rainMax"
data-logdevice="Logproxy"
data-columnspec='Func:Buienradar_logProxy("BR")'
data-style="ftui l3fill"
data-nofulldays='true'
data-title= "Regen"
class="nobuttons fullsize">
</div>
<li data-row="2" data-col="5" data-sizey="1" data-sizex="2">
<div data-type="highchart"
data-device="TMC"
data-linenames="Vorhersage"
data-linetypes="area"
data-maxvaylue="rainMax"
data-logdevice="Logproxy"
data-columnspec='Func:RainTMC_logProxy("TMC")'
data-style="ftui l3fill"
data-nofulldays='true'
data-title= "Regen"
class="nobuttons fullsize">
</div>
Fehler gefunden laut Wiki muß es: data-logdevice="logProxy" heissen!
data-logdevice muss doch so heißen wie dein LogProxy-Device. Oder?
Ich habe eher Probleme mit data-maxvaylue="rainMax" Zum einen dürfte es ein Tippfehler sein und sollte sich data-maxvalue="rainMax" heißen, aber auch wenn ich das abändere, wird nichts angezeigt.
Hallo,
ich glaube bei data-maxvalue muss eine Zahl stehen, sonst wird nichts angezeigt. Bei mir steht dort 2
Außerdem glaube ich was bei data-logdevice steht ist egal. Bei mir steht "Logproxy".
data-maxvalue=2
data-logdevice="Logproxy"
Ludger
@trinitywhm
...na klar - Du hast natürlich recht, der Name wird ja individuell vergeben. Ich hatte Gurken auf den Augen!
Jetzt habe ich Daten - nur stimmen müssen sie auch noch...
Ich musste mein Buienradar-Device leider auch löschen, da ich schon öfter den Request-Fehler hatte.
Z.B. heute zwischen 20:34:01 und 20:36:47 war mein FHEM lahmgelegt. Es wurden in dieser Zeit sage und schreibe 39266 der folgenden Zeilen ins Log geschrieben:
2017.11.22 20:36:47 3: BR: error while requesting http://gps.buienradar.nl/getrr.php?lat=.................. - gethostbyname gps.buienradar.nl failed
Danach habe ich erstmals überhaupt mehrfach diese Meldung bekommen:
2017.11.22 20:41:56 1: Cannot fork: Nicht genügend Hauptspeicher verfügbar
Zwischen den 39000 Zeilen habe ich zufällig diese 6 entdeckt:
2017.11.22 20:34:52 1: PERL WARNING: Deep recursion on subroutine "main::Buienradar_ScheduleUpdate" at ./FHEM/59_Buienradar.pm line 324.
2017.11.22 20:34:52 1: PERL WARNING: Deep recursion on subroutine "main::Buienradar_RequestUpdate" at ./FHEM/59_Buienradar.pm line 217.
2017.11.22 20:34:52 1: PERL WARNING: Deep recursion on subroutine "main::HttpUtils_NonblockingGet" at ./FHEM/59_Buienradar.pm line 233.
2017.11.22 20:34:52 1: PERL WARNING: Deep recursion on subroutine "main::HttpUtils_Connect" at FHEM/HttpUtils.pm line 825.
2017.11.22 20:34:52 1: PERL WARNING: Deep recursion on subroutine "main::HttpUtils_gethostbyname" at FHEM/HttpUtils.pm line 390.
2017.11.22 20:34:52 1: PERL WARNING: Deep recursion on subroutine "main::Buienradar_ParseHttpResponse" at FHEM/HttpUtils.pm line 343.
Schade, das Modul hat mir gut gefallen ???
Hallo,
den Fehler von smn_fx kann ich nicht nachstellen. Insbesondere weil die letzte Version bei solchen Fehlern den Fehler nur protokolliert aber kein anderes Verhalten wie im Normalbetrieb hat. Gerade der gethostbyname gps.buienradar.nl failed deutet für mich eher auch Probleme mit dem Internetzugang hin.
Daraufhin habe ich mal bei meinem Pi den Internetzugang blockiert und mein FHEM ist auch abgestürzt (allerdings wegen dem Allergy Modul :-))
Trotzdem habe ich meinen Code nochmal aufgeräumt, eine Plausi bei den Daten eingebaut und bei dem Timer etwas vereinfacht. Diese Version läuft jetzt einen Tag lang bei mir und verhält sich auch bei simulierten Fehlern stabil.
Wer Lust hat kann diese Version in diesem Post herunterladen. Wenn ich eine Woche lang keine Fehlermeldung erhalte wird diese Version auch auf github hochgeladen!
Falls jemand ein Fehler findet, diesen bitte mit List posten.
Hallo LuBeDa,
jetzt wird mein Log alle 4 Minuten "vollgemüllt":
2017.11.24 19:06:49 0: Regenradar: returned: 000|19:00
000|19:05
000|19:10
000|19:15
000|19:20
000|19:25
000|19:30
000|19:35
000|19:40
000|19:45
000|19:50
000|19:55
000|20:00
000|20:05
000|20:10
000|20:15
000|20:20
000|20:25
000|20:30
000|20:35
000|20:40
000|20:45
000|20:50
000|20:55
Grüße
Rainer
@ergerd: Mein auch. ;)
Neue Testversion mit angepasstem Loglevel.
@LuBeDa Danke für die Mühen mit der neuen Version. Ich werde sie gleich mal ausprobieren.
Zu deiner Vermutung, dass es an der Internetverbindung liegen würde: Wie könnte ich das feststellen? Im Log finden sich keine Anhaltspunkte für Probleme bei anderen Modulen mit der Internetverbindung. Auch im Log der Fritzbox ist keine Spur von Verbindungsabbrüchen.
@smn_fx
Die erste Fehlermeldung besagt das dein FHEM-Server die IP Adresse des Servers nicht finden kann.
gethostbyname gps.buienradar.nl failed
Eine Möglichkeit dafür ist das die Internetverbindung gerade im Moment der Abfrage gestört ist (vielleicht DSL-Zwangstrennung), da gibt es aber auch noch eintausend andere mögliche Ursachen.
Wenn ich bei mir den Fehler provoziere, in dem ich auf meinem Router den Internetzugang blockiere, stürzt mein FHEM auch ab. Aber nicht zwnagsweise wegen Buienradar.
Ludger
Zitat von: LuBeDa am 25 November 2017, 12:16:10
Wenn ich bei mir den Fehler provoziere, in dem ich auf meinem Router den Internetzugang blockiere, stürzt mein FHEM auch ab. Aber nicht zwnagsweise wegen Buienradar.
Hast Du einen dnsServer in fhem gesetzt?
attr global dnsServer [IP-Router]https://fhem.de/commandref_DE.html#global (https://fhem.de/commandref_DE.html#global)
- dnsServer: Enthält die IP Adresse des DNS Servers. Die von bestimmten Modulen (oder eigenen Code) aufgerufene HttpUtils_NonblockingGet wird auch bei der DNS Auflösung nicht mehr blockieren, falls dieses Attribut gesetzt ist, da es in diesem Fall FHEM eigene Routinen aufgerufen werden. Sonst werden die OS-eigenen, blockierenden Routinen inet_aton bzw gethostbyname aufgerufen.
Hallo Ludger,
mir ist ein Fehler in der 59_RainTMC.pm aufgefallen, in der sub "sub RainTMC_Define($$)" muss es da nicht 60 * 5 heissen? Dort steht zwar "alle 5 Minuten"", aber nur 60 * 4.
# alle fünf Minuten
my $interval = 60 * 4;
SUPER Modul!
@inoma
OK, der Kommentar passt nicht zu der Formel, das ist richtig!
Ich glaube 5 Minuten ist zu wenig. Nach dem Nyquist-Shannon-Abtasttheorem müsste ich sogar 2,5 Min nehmen, das war mir zu viel. Darum habe ich 4 Minuten gewählt.
Bin aber für Vorschläge offen was hier sinnvoll ist. :-)
Ludger
Ja der alte Shannon, Du bist ja lustig. Drauf gekommen bin ich nicht wegen dem Kommentar im Modul, sondern wegen der Modulbeschreibung im ersten Thread, und das passte dann nicht zum Internal. Ich würde ja fast sagen wenn man es konfigurierbar machen könnte . . .
Beste Grüsse!
Das Modul könnte doch im 5 Minuten intervall abrufen und das bei Bedarf bei Regen auf 2,5 Minuten verkürzen...
Gesendet von meinem SM-G935F mit Tapatalk
Hallo,
Zitat von: mrbreil am 04 Oktober 2017, 15:48:03
Also das raintmc liefert mir werde, Danke. Jetzt suche ich noch eine Möglichkeit mir die Vorhersage als Bild zuschicken zu lassen. Wie bekomme ich den code aus {RainTMC_PNG("R")} in eine Bilddatei, die ich per Telegram verschicken kann?
Gruß Christian
ich nutze das RainTMC-Modul und suchte ebenfalls eine Möglichkeit, das Diagramm in meiner Smartvisu darzustellen und ggf. per Telegramm zu versenden. Dabei habe ich folgende Lösung (von hinten durch die Brust ins Auge) gefunden:
Ich habe auf meinem Linux-Server auf dem auch FHEM läuft den chromium-Browser installiert:
sudo apt-get install chromiumDann habe ich mit eine neue FHEMWEB-Instanz angelegt, die alle Räume versteckt und keine Kommandos erlaubt. Hintergrund: ich habe meine anderen Instanzen alle mit Passwort versehen und müsste dieses im nächsten Schritt im Klartext ins Script hinterlegen :().
Nun habe ich mit ein Linux Script geschrieben:
#!/bin/bash
cd /opt/scripts/
chromium --no-sandbox --headless --disable-gpu --screenshot --window-size=1280,300 http://192.168.18.10:9097/fhem?detail=TMC_DIA_WL
convert screenshot.png -crop 1006x200+234+51 /opt/fhem/www/images/default/weather/TMC_DIA_WL.pngDieses macht einen Screenshot der Detailseite (Port 9097 ist das "beschnittene" FHEMWEB ohne Passwort) meines TMC-Weblinks (TMC_DIA_WL) und beschneidet den Screenshot dann so, dass im Ergebnis nur noch das Diagramm über bleibt, welches auch gleich in den FHEM-Bilderordner gelegt wird.
Dieses Script wird nun per cronjob minütlich ausgeführt (geht sicherlich auch seltener) wodurch spätestens nach einer Minute ein aktueller Screenshot zur Verfügung steht -> diese Zeit sollte man berücksichtigen, wenn man nach Aktualisierung der TMC-Devices über ein Notify das Bild versenden möchte...
Dies soll nur als Idee dienen und bedarf bei eigener Umsetzung sicherlich die eine oder andere Anpassung (Verzeichnisstrukturen, Koordinaten für das Zuschneiden, ...)
Ronny
Hallo Zusammen,
ich habe mein FHEM neu aufgestetzt und bekomme seitdem immer folgenden Log-Eintrag:
2018.02.17 23:15:28 1: reload: Error:Modul 59_Buienradar deactivated:
Can't locate DateTime.pm in @INC (you may need to install the DateTime module) (@INC contains: fhem.p/lib fhem.p/FHEM/lib ./FHEM/lib ./lib ./FHEM ./ /usr/local/FHEM/share/fhem/FHEM/lib . /home/fhem/perl5/lib/perl5/5.24.1/arm-linux-gnueabihf-thread-multi-64int /home/fhem/perl5/lib/perl5/5.24.1 /home/fhem/perl5/lib/perl5/arm-linux-gnueabihf-thread-multi-64int /home/fhem/perl5/lib/perl5 /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 /opt/fhem/FHEM) at /opt/fhem/FHEM/59_Buienradar.pm line 32, <$fh> line 2916.
BEGIN failed--compilation aborted at /opt/fhem/FHEM/59_Buienradar.pm line 32, <$fh> line 2916.
Ich habe schon mehrfach DateTime installiert, aber irgendwie will das Modul das nicht annehmen. :(
Habe folgende Befehle ausgeführt und durchlaufen lassen, aber nichts hilft:
cpan DateTime
sudo cpan DateTime
cpan -i DateTime
sudo cpan -i DateTime
cpan install DateTime
sudo cpan install DateTime
cpan -i Bundle::DateTime::Complete
sudo cpan -i Bundle::DateTime::Complete
cpan install Bundle::DateTime::Complete
sudo cpan install Bundle::DateTime::Complete
Hat noch jemand eine Idee?
Hallo,
ich hatte ähnliche Probleme mit anderen Modulen. Eine richtige Lösung kann ich aber leider nicht bieten.
Mit diesem Befehl kann man feststellen ob und wohin das Modul installiert wurde:
perl -MDateTime -le'print $INC{"DateTime.pm"};'
Du könntest nochmal den hier versuchen:
sudo apt-get install libdatetime-perl
Ludger
ZitatDu könntest nochmal den hier versuchen:
Ah vielen Dank Ludger! Das hat geholfen. :)
Ich habe das Modul nun auch seit 3 Tagen im Test und bekomme immer mal wieder diesen Fehler
2018.03.14 13:16:43 1: ERROR evaluating {RainTMC_HTML(Regenvorhersage)}: Bareword "Regenvorhersage" not allowed while "strict subs" in use at (eval 402248) line 1.
Was kann das sein, es liegt doch nicht am Namen vom Gerät, dass kann ich doch nennen wie ich es möchte.
Dies ist mal mein list
Internals:
CFGFN ./FHEM/Wetter.cfg
INTERVAL 240
LATITUDE 52.500368
LONGITUDE 9.624981
NAME Regenvorhersage
NEXTUPDATE 2018-03-14 13:25:29
NR 1913
STATE 0.00
TYPE RainTMC
URL https://api.themeteocompany.com/precipitation/getforecastbylatlon/?radius=0&lat=52.500368&lon=9.624981
READINGS:
2018-03-14 07:01:29 rainAmount 0.000
2018-03-14 07:01:29 rainBegin unknown
2018-03-14 13:13:29 rainDataEnd 2018-03-14 15:10:00
2018-03-14 13:21:29 rainDataStart 2018-03-14 13:25:00
2018-03-14 07:01:29 rainEnd unknown
2018-03-14 07:01:29 rainLaMetric 0,0,0,0,0,0,0,0,0,0,0,0
2018-03-14 07:01:29 rainMax 0.000
2018-03-14 07:01:29 rainNow 0
2018-03-14 07:01:29 rainTotal 0.000
Attributes:
group RainTMC
room Wettervorhersage
Zitat von: moonsorrox am 14 März 2018, 13:26:20
Ich habe das Modul nun auch seit 3 Tagen im Test und bekomme immer mal wieder diesen Fehler
2018.03.14 13:16:43 1: ERROR evaluating {RainTMC_HTML(Regenvorhersage)}: Bareword "Regenvorhersage" not allowed while "strict subs" in use at (eval 402248) line 1.
Was kann das sein, es liegt doch nicht am Namen vom Gerät, dass kann ich doch nennen wie ich es möchte.
Trotzdem musst du den Namen in Anführungszeichen setzen, oder?
da kannst du natürlich absolut recht haben...! :-\ ich habe das jetzt mal ergänzt... und beobachte, war immer nur einmal nach dem "restart"
Manchmal sieht man den Wald vor Bäume nicht... ;)
Hallo Lubeda,
Ich habe das Modul für Buienradar vor ein paar Tagen getestet.
Jetzt regnet es aktuell nicht und dabei habe ich festgestellt, dass das Modul keine Events erzeugt.
Mein Plot ist dadurch leer.
Das Setzen von even-on-update-reading wird meiner Einschätzung nach auch nicht ausgewertet, da das Reading selbst nicht aktualisiert wird.
Der einzige Weg, das Reading zu aktualisieren, wenn der Wert gleich beleibt, scheint mir aktuell ein Neustart von FHEM.
Kannst Du dieses Verhalten bitte anpassen?
Grüße Sidey
Verstehe ich das richtig?
Siehe Bild: Wir haben gerade 11:50 und alle Werte die sich nicht ändern erzeugen kein Event, z.B. "rainNow". Nur rainDataStart und -End haben sich geändert unde erzeugen Events.
Ich finde das Verhalten von dem Buienradar richtig, das Problem liegt eher bei dem SVG Modul.
Oder übersehe ich das etwas?
Ludger
Zitat von: LuBeDa am 15 April 2018, 11:54:29
Ich finde das Verhalten von dem Buienradar richtig, das Problem liegt eher bei dem SVG Modul.
Oder übersehe ich das etwas?
Du bietest die Attribute event-on... in deinem Modul an.
Die Attribute sind dafür da, dass ich als Anwender entscheiden kann wann und wie oft ich Events möchte.
Dadurch, dass Du das Reading nur aktualisiert, wenn es sich geändert hat, nimmst Du mir als Anwender diese Einstellmöglichkeit.
Das SVG Modul hat damit nichts zu tun.
Ich fände es gut, wenn die event-on.. Attribute wie in der commandref beschrieben auch funktionieren würden.
Das würde helfen, durchgehende Plots erstellen zu können.
Grüße Sidey
Gesendet von meinem XT1650 mit Tapatalk
Siehe unten, ich habe das in meiner laufenden Version eingepflegt. Leider kann ich nicht mehr genau sagen was ich zu der letzten veröffentlichten Version geändert habe.
Hiermit bekommt man das alte Verhalten wieder:
attr RainBR event-on-change-reading rainAmount,rainBegin,rainEnd,rainMax,rainNow
Der erste Post und Github wurden nicht aktualisiert.
Zitat von: LuBeDa am 15 April 2018, 13:19:22
Siehe unten, ich habe das in meiner laufenden Version eingepflegt. Leider kann ich nicht mehr genau sagen was ich zu der letzten veröffentlichten Version geändert habe.
Hiermit bekommt man das alte Verhalten wieder:
attr RainBR event-on-change-reading rainAmount,rainBegin,rainEnd,rainMax,rainNow
Der erste Post und Github wurden nicht aktualisiert.
Danke. Wenn Du es bei gihub eincheckst, bekommst Du ja jede Änderung genau angezeigt.
Grüße Sidey
Wichtige Info
Hallo zusammen,
das Reading rainNow funktioniert bei Buienradar nicht richtig. Möglicher Regen wird unter bestimmten Bedingungen zu spät angezeigt.
Zitat von: LuBeDa am 22 April 2018, 15:29:20
Wichtige Info
Hallo zusammen,
das Reading rainNow funktioniert bei Buienradar nicht richtig. Möglicher Regen wird unter bestimmten Bedingungen zu spät angezeigt.
Neue Version im ersten Post und auf github
Bekomme kein Update:
2018.04.27 19:03:20 1 : Buienradar
2018.04.27 19:03:20 1 : UPD FHEM/59_Buienradar.pm
2018.04.27 19:03:21 1 : Got 18239 bytes for FHEM/59_Buienradar.pm, expected 18293
2018.04.27 19:03:21 1 : aborting.
Bin ich der Einzige?
Zahlendreher 8), ich pflege die Datei manuell.
Bitte in 5 Minuten noch mal versuchen
ich bin gerade bei Ersteinrichtung über eine Kleinigkeit gestolpert:
das Modul wird definiert wie folgt:
define Name Modulname Breitengrad Längengrad (kann man aus dem Beispiel mit Dortmund erkennen)
in Post 1 schreibst du aber in der Beschreibung "define Name Modul Longitude Latitude" ..also genau falsch rum:-)
hat bei mir dazu geführt, dass er für mich keine Daten auslesen konnte. Erst als ich es umgedreht habe hat es funktioniert.
Zitat von: LuBeDa am 27 April 2018, 19:38:10
Zahlendreher 8), ich pflege die Datei manuell.
Bitte in 5 Minuten noch mal versuchen
Danke, jetzt funktioniert es.
Zitat von: StephanFHEM am 27 April 2018, 20:04:15
in Post 1 schreibst du aber in der Beschreibung "define Name Modul Longitude Latitude" ..also genau falsch rum:-)
Bin seit 2008 Geocacher und kann mir das immer noch nicht merken ::)
Ist im ersten Post angepasst, in der Doku stand es richtig.
Ludger
Hallo LuBeDa.
Ich nutze dein RainTMC modul. Vorgestern viel bei uns das Internet bis heute aus. Dein Modul schreibt dann mehrmals pro Sekunde " ... error while requesting https://api.themeteocompany... " ins log. Nach ca 22 h schmierte FHEM komplett ab, ob dass jetzt aber nur an deinem Modul lag kann ich nicht bestätigen. Könnte man aber so eine Art OFFLINE-INTERVALL einbauen, ähnlich dem Presence Modul?
Gruß Christian
Sorry,
mittlerweile nutze ich OpenHAB und habe kein FHEM mehr im Einsatz.
Ich nutze für den Download eine "API-Funktion" von FHEM HttpUtils_NonblockingGet($param); wie die mit fehlender Internetverbindung umgeht kann ich nicht sagen. Eventuell genügt es auch in Zeile 199 den Timeoutwert höher zu setzen.
Mehr kann ich nicht helfen.
Ludger
Ich wollte auch mal probieren: define BR Buienradar (Koordinaten in global)
Kann es sein, dass der Dienst nur bis zum 10. Längengrad liefert?
Das ist möglich, die Daten kommen aus den Niederlanden. Ich habe auch die Erfahrung gemacht das die Vorhersagedauer immer kürzer wird. Zu Begin waren es immer mindestens 2 Stunden, jetzt kommen manchmal nur 10 Minuten.
Ok, verstanden.
Auf der ersten Seite erwähnst Du noch ein zweites, TMC-Irgendwie heißt das. Nutzt das den gleichen Radar? Oder was macht das?
TMC benutzt eine andere Datenquelle aus dem Internet. Aber ich bin mittlerweile kein FHEM Nutzer mehr und nutzte beide Voerhersagedienste nicht mehr.
Ich fand früher Buienradar als zuverlässiger/genauer.
Zitat von: LuBeDa am 15 November 2018, 05:18:26
TMC benutzt eine andere Datenquelle aus dem Internet.
Ok, verstanden.
Zitat von: LuBeDa am 15 November 2018, 05:18:26
Aber ich bin mittlerweile kein FHEM Nutzer mehr und nutzte beide Voerhersagedienste nicht mehr.
Aua: Ich komme durch die Drehtür rein - und Du bist grad rausgegangen.
Magst Du bitte die Motivation für "ich bin mittlerweile kein FHEM Nutzer" genauer erklären?
(Ich muss doch wissen, warum ich weglaufen muss)
ich bekomme seit Tagen diese Meldungen im Log und ich dachte es beruhigt sich wieder, aber leider nicht. Meine Frage hier hat dies noch jemand bobachtet..?
2018.12.09 13:40:37 3: Regenvorhersage: error while requesting https://api.themeteocompany.com/precipitation/getforecastbylatlon/?radius=0&lat=52.500368&lon=9.624981 - - https://api.themeteocompany.com/precipitation/getforecastbylatlon/?radius=0&lat=52.500368&lon=9.624981: Can't connect(2) to https://api.themeteocompany.com:443: SSL connect attempt failed with unknown error SSL wants a read first
Yep, ist bei mir genauso.
Wenn ich den link manuell im PC Browser eingebe, funktionierts eigentlich immer. Ich meine aber dass das Modul dann nach 90 Sekunden nochmal probiert.
Keine Ahnung woran das liegt.
Leider ist der user 'LuBeDa' kein FHEM Nutzer mehr, ich weiss nicht ob er hier noch regelmässig mitliest.
Beste Grüsse nach 30900 Wedemark, ......... google kanns!
verraten durch latitude und longitude ;)
Ich habe mir jetzt dadurch geholfen das ich verbose auf "0" gesetzt habe, vorher war nichts drin somit dachte ich es werden die Fehler automatisch geblockt..
Also jetzt kommt erstmal kein Eintrag mehr
Zitat von: inoma am 12 Dezember 2018, 17:33:36
Leider ist der user 'LuBeDa' kein FHEM Nutzer mehr,
Ist das so? Ich hatte vor kaum zwei Wochen Kontakt.
Zitat von: inoma am 12 Dezember 2018, 17:33:36
ich weiss nicht ob er hier noch regelmässig mitliest.
Klick auf den Nutzernamen verrrät das letzte Login. @LuBeDa ist regelmäßig hier.
das steht in diesem Post #134 "nutze jetzt OpenHab und kein FHEM mehr
Wie gesagt, ich nutze FHEM nicht mehr. Bin mittlerweile bei Home-Assistant gelandet (und werde auch dabei bleiben) :-).
Die Module kann ich nicht mehr pflegen. Aber der Code ist offen...
Ab und zu besuche ich das FHEM-Forum noch, schließlich gibt es hier eine große und kompetente Community.
Ludger
Hallo alle,
wenn man bei RainTMC_HTML den 'dark style' verwendet, skaliert die Breite der Grafik des Balkens nicht.
Beim ''default''style siehts wie im ersten screenshot aus, beim ''dark'' style wie im zweiten,
der Wetterradar balken ist immer doppelt so breit (sieht man an der Position der Zahlen von Heizung_Wohn und vom GasSensor),
da muss ich immer nach rechts scrollen. Ich würde gerne beim Dark style bleiben, der gefällt mir eigentlich super, aber das mit dem Wetterradar balken stört mich sehr.
Weiss jemand vielleicht, wie ich das ändern kann?
Danke!
Zitatdefmod Wetterradar_bar weblink htmlCode {RainTMC_HTML("Wetterradar")}
attr Wetterradar_bar group WETTER
Das muss irgendwie an dem Theme liegen. Das Modul generiert immer den selben HTML Code.
Danke, ich habs mal in den Thread FHEMWEB verschoben.
Hallo Ludger,
das Buienradar-Modul bekommt nach Mitternacht für einige Stunden keine neuen Daten.
Bei den Internals steht INTERVAL auf 240, man kann es aber nicht ändern.
Könnte man die Abfrage für den Zeitraum ab Mitternacht bis zu dem Zeitpunkt, an dem wieder üblicherweise Daten verfügbar sind, aussetzen oder wenigsten stark reduzieren?
Viele Grüße Gisbert
Edit:
Wenn man die Abfrage in einen Browser (im entsprechenden Zeitraum) reinkopiert, bekommt man folgende Antwort:
The specified CGI application encountered an error and the server terminated the process.
Hallo zusammen,
es gibt scheinbar eine neue URL mit der man die Daten zuverlässiger bekommt:
https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=51.6&lon=7.3®ion=nl&unit=mm/u (https://cdn-secure.buienalarm.nl/api/3.4/forecast.php?lat=51.6&lon=7.3®ion=nl&unit=mm/u)
Die Rückgabe ist JSON. Vielleicht fühlt sich jemand in der Lage mein altes Modul entsprechend anzupassen.
Ich kann/will nicht weil ich zu home-assistant gewechselt bin.
Guck mal hier: https://github.com/christoph-morrison/59_Buienradar/tree/development
Zitat von: Christoph Morrison am 18 Juli 2019, 22:15:01
Guck mal hier: https://github.com/christoph-morrison/59_Buienradar/tree/development
Heißt das, dass du den Vorschlag von LuBeDa umgesetzt hast?
Wird diese Version in Fhem automatisch verteilt oder muss man die Datei von Github runterladen?
Viele Grüße Gisbert
Zitat von: Gisbert am 18 Juli 2019, 23:06:11
Heißt das, dass du den Vorschlag von LuBeDa umgesetzt hast?
Ja, ich lese die Daten von der (neuen?) JSON-API und liefere auch die entsprechenden Readings. Allerdings ist das noch in Entwicklung, d.h. es können und es werden sich Dinge ändern. Aktuell gibt es z.B. keinen PNG-Output und auch die Websnippets funktionieren (vielleicht) nicht. Ich bin mir auch nicht sicher ob die Daten in Ordnung sind, denn sie weichen recht deutlich von denen der alten Vorhersage ab.
Zitat von: Gisbert am 18 Juli 2019, 23:06:11
Wird diese Version in Fhem automatisch verteilt oder muss man die Datei von Github runterladen?
Nein, es ist von meiner Seite her auch nicht vorhergesehen, dass sie jemals über das SVN verteilt werden soll. Auf eigene Gefahr kann man die Development-Version über
update add https://raw.githubusercontent.com/christoph-morrison/59_Buienradar/development/controls_Buienradar.txt
in FHEM einbinden, dann funktioniert ein
update auch darauf.
Zu den Daten: Ich glaube die neuen Daten sind direkt in mm/h vorher war das ein Wert den man mit einer Funktion noch umrechnen musste. Ich warte auch auf den ersten Regen um das mal zu testen.
Hallo Christoph und LuBeDa,
ich erhalte heute Tonnen von folgenden Einträgen, so 10-20 pro Sekunde (!!):
2019.07.21 10:37:23 3: Buienradar: error while requesting https://gpsgadget.buienradar.nl/data/raintext?lat=51.02943&lon=7.05584 - connect to https://gpsgadget.buienradar.nl:443: Network is unreachable
2019.07.21 10:37:23 3: Buienradar: error while requesting https://gpsgadget.buienradar.nl/data/raintext?lat=51.02943&lon=7.05584 - connect to https://gpsgadget.buienradar.nl:443: Network is unreachable
2019.07.21 10:37:23 3: Buienradar: error while requesting https://gpsgadget.buienradar.nl/data/raintext?lat=51.02943&lon=7.05584 - connect to https://gpsgadget.buienradar.nl:443: Network is unreachable
2019.07.21 10:37:23 3: Buienradar: error while requesting https://gpsgadget.buienradar.nl/data/raintext?lat=51.02943&lon=7.05584 - connect to https://gpsgadget.buienradar.nl:443: Network is unreachable
2019.07.21 10:37:23 3: Buienradar: error while requesting https://gpsgadget.buienradar.nl/data/raintext?lat=51.02943&lon=7.05584 - connect to https://gpsgadget.buienradar.nl:443: Network is unreachable
2019.07.21 10:37:23 3: Buienradar: error while requesting https://gpsgadget.buienradar.nl/data/raintext?lat=51.02943&lon=7.05584 - connect to https://gpsgadget.buienradar.nl:443: Network is unreachable
2019.07.21 10:37:23 3: Buienradar: error while requesting https://gpsgadget.buienradar.nl/data/raintext?lat=51.02943&lon=7.05584 - connect to https://gpsgadget.buienradar.nl:443: Network is unreachable
2019.07.21 10:37:23 3: Buienradar: error while requesting https://gpsgadget.buienradar.nl/data/raintext?lat=51.02943&lon=7.05584 - connect to https://gpsgadget.buienradar.nl:443: Network is unreachable
2019.07.21 10:37:23 3: Buienradar: error while requesting https://gpsgadget.buienradar.nl/data/raintext?lat=51.02943&lon=7.05584 - connect to https://gpsgadget.buienradar.nl:443: Network is unreachable
2019.07.21 10:37:23 3: Buienradar: error while requesting https://gpsgadget.buienradar.nl/data/raintext?lat=51.02943&lon=7.05584 - connect to https://gpsgadget.buienradar.nl:443: Network is unreachable
2019.07.21 10:37:23 3: Buienradar: error while requesting https://gpsgadget.buienradar.nl/data/raintext?lat=51.02943&lon=7.05584 - connect to https://gpsgadget.buienradar.nl:443: Network is unreachable
2019.07.21 10:37:24 3: Buienradar: error while requesting https://gpsgadget.buienradar.nl/data/raintext?lat=51.02943&lon=7.05584 - connect to https://gpsgadget.buienradar.nl:443: Network is unreachable
2019.07.21 10:37:24 3: Buienradar: error while requesting https://gpsgadget.buienradar.nl/data/raintext?lat=51.02943&lon=7.05584 - connect to https://gpsgadget.buienradar.nl:443: Network is unreachable
2019.07.21 10:37:24 3: Buienradar: error while requesting https://gpsgadget.buienradar.nl/data/raintext?lat=51.02943&lon=7.05584 - connect to https://gpsgadget.buienradar.nl:443: Network is unreachable
2019.07.21 10:37:24 3: Buienradar: error while requesting https://gpsgadget.buienradar.nl/data/raintext?lat=51.02943&lon=7.05584 - connect to https://gpsgadget.buienradar.nl:443: Network is unreachable
2019.07.21 10:37:24 3: Buienradar: error while requesting https://gpsgadget.buienradar.nl/data/raintext?lat=51.02943&lon=7.05584 - connect to https://gpsgadget.buienradar.nl:443: Network is unreachable
2019.07.21 10:37:24 3: Buienradar: error while requesting https://gpsgadget.buienradar.nl/data/raintext?lat=51.02943&lon=7.05584 - connect to https://gpsgadget.buienradar.nl:443: Network is unreachable
2019.07.21 10:37:24 3: Buienradar: error while requesting https://gpsgadget.buienradar.nl/data/raintext?lat=51.02943&lon=7.05584 - connect to https://gpsgadget.buienradar.nl:443: Network is unreachable
2019.07.21 10:37:24 3: Buienradar: error while requesting https://gpsgadget.buienradar.nl/data/raintext?lat=51.02943&lon=7.05584 - connect to https://gpsgadget.buienradar.nl:443: Network is unreachable
2019.07.21 10:37:24 3: Buienradar: error while requesting https://gpsgadget.buienradar.nl/data/raintext?lat=51.02943&lon=7.05584 - connect to https://gpsgadget.buienradar.nl:443: Network is unreachable
2019.07.21 10:37:24 3: Buienradar: error while requesting https://gpsgadget.buienradar.nl/data/raintext?lat=51.02943&lon=7.05584 - connect to https://gpsgadget.buienradar.nl:443: Network is unreachable
2019.07.21 10:37:24 3: Buienradar: error while requesting https://gpsgadget.buienradar.nl/data/raintext?lat=51.02943&lon=7.05584 - connect to https://gpsgadget.buienradar.nl:443: Network is unreachable
2019.07.21 10:37:24 3: Buienradar: error while requesting https://gpsgadget.buienradar.nl/data/raintext?lat=51.02943&lon=7.05584 - connect to https://gpsgadget.buienradar.nl:443: Network is unreachable
2019.07.21 10:37:24 3: Buienradar: error while requesting https://gpsgadget.buienradar.nl/data/raintext?lat=51.02943&lon=7.05584 - connect to https://gpsgadget.buienradar.nl:443: Network is unreachable
2019.07.21 10:37:24 3: Buienradar: error while requesting https://gpsgadget.buienradar.nl/data/raintext?lat=51.02943&lon=7.05584 - connect to https://gpsgadget.buienradar.nl:443: Network is unreachable
Das logfile ist wirklich riesig.
Mich wundert nur, dass noch sich im Forum noch niemand wegen des gleichen Fehlers gemeldet hat.
Oder ist Buienradar so selten im Einsatz?
Hallo Christoph,
ich haben deinen Pfad jetzt eingebunden:
update add https://raw.githubusercontent.com/christoph-morrison/59_Buienradar/development/controls_Buienradar.txt
Damit läuft das Modul wieder.
Es gibt ein Reading:
rainNow 0.000 mm/h
Damit dürfte die Einheit wohl geklärt sein, oder nicht?
Viele Grüße Gisbert
Zitat von: Gisbert am 21 Juli 2019, 14:54:51
ich erhalte heute Tonnen von folgenden Einträgen, so 10-20 pro Sekunde (!!)
Das logfile ist wirklich riesig.
Mich wundert nur, dass noch sich im Forum noch niemand wegen des gleichen Fehlers gemeldet hat.
Oder ist Buienradar so selten im Einsatz?
Das liegt eher daran, dass das ein Netzwerkfehler bei dir ist und nicht beim Anbieter. Der war die letzten Tage durchgängig erreichbar.
Zitat von: Gisbert am 21 Juli 2019, 14:54:51
rainNow 0.000 mm/h
Damit dürfte die Einheit wohl geklärt sein, oder nicht?
Die Einheit war nie meine Sorge, sondern dass die Werte (auch nach Konvertierung) stark voneinander abweichen. Die alte Schnittstelle hat teilweise deutlich höhere Mengen gemeldet als die neue. Es mag vielleicht sein, dass hintendran auch andere Datenquellen stehen, aber das glaube ich eigentlich nicht. Außerdem wichen die Daten von der neuen API auch von den Daten ab, die auf der Buienradar-Website angezeigt werden.
Hallo Christoph,
ZitatDas liegt eher daran, dass das ein Netzwerkfehler bei dir ist und nicht beim Anbieter. Der war die letzten Tage durchgängig erreichbar.
Ich will das gar nicht abstreiten, aber es war nur diese Seite, die Probleme machte, merkwürdig.
Viele Grüße Gisbert
Zitat von: Christoph Morrison am 22 Juli 2019, 13:58:54
Die Einheit war nie meine Sorge, sondern dass die Werte (auch nach Konvertierung) stark voneinander abweichen.
Die merkwürdige Umrechnungssformel der alten API führte auch zu "komischen" Werten weil die Schritte zwischen den Stufen nicht linear waren. Die neue API ist da deutlich angenehmer.
Zitat von: LuBeDa am 22 Juli 2019, 18:40:56
Die merkwürdige Umrechnungssformel der alten API führte auch zu "komischen" Werten weil die Schritte zwischen den Stufen nicht linear waren. Die neue API ist da deutlich angenehmer.
Was genau war das denn für eine Einheit die die alte API liefert? Ich habe die Formel natürlich im Quellcode gesehen, aber konnte aus ihr nicht schließen was für eine Einheit das sein soll ...
Zitat von: Gisbert am 22 Juli 2019, 16:45:37
Ich will das gar nicht abstreiten, aber es war nur diese Seite, die Probleme machte, merkwürdig.
Ich hatte früher gelegentlich auch öfter mal mit der API Probleme ohne dass die Seite an sich offline war. Vielleicht sitzt da irgendwo noch ein Proxy oder so dazwischen, das Routing ist gelegentlich kaputt oder PHP auf der Zielmaschine macht mal die Grätsche. Wer weiß. Ich nehm's mir aber mal mit und schaue mal ob ich ein passendes Errorhandlich einbaue (z.B. für eine Weile pausieren wenn zu viele Fehler kamen oder sowas).
Zitat von: Christoph Morrison am 22 Juli 2019, 19:22:55
Was genau war das denn für eine Einheit die die alte API liefert? Ich habe die Formel natürlich im Quellcode gesehen, aber konnte aus ihr nicht schließen was für eine Einheit das sein soll ...
Neerslagintensiteit = 10^((waarde-109)/32)
Ter controle: een waarde van 77 is gelijk aan een neerslagintensiteit van 0,1 mm/u.
https://www.buienradar.nl/overbuienradar/gratis-weerdata
Hallo
Zitat von: Christoph Morrison am 18 Juli 2019, 23:17:24
Nein, es ist von meiner Seite her auch nicht vorhergesehen, dass sie jemals über das SVN verteilt werden soll. Auf eigene Gefahr kann man die Development-Version über
update add https://raw.githubusercontent.com/christoph-morrison/59_Buienradar/development/controls_Buienradar.txt
in FHEM einbinden, dann funktioniert ein update auch darauf.
Das habe ich gerade mal probiert und erhalte beim Laden des Moduls folgenden Fehler:
Global symbol "$OFS" requires explicit package name (did you forget to declare "my $OFS"?) at ./FHEM/59_Buienradar.pm line 376. Global symbol "$name" requires explicit package name (did you forget to declare "my $name"?) at ./FHEM/59_Buienradar.pm line 377.
Ronny
Hab ich gefixt, morgen mache ich dann eine neue Version fertig.
Falls du es selbst bis dahin fixen willst: use English fehlt oben.
Hallo Christoph,
heute nacht wurde Fhem gegen 00:26 mehrfach neu gestartet, ohne dass ich es gemacht habe.
Es fängt an mit:
Can't use an undefined value as an ARRAY reference at .//FHEM/59_Buienradar.pm line 314.
2019.07.23 00:26:59 1: PERL WARNING: "my" variable $Stadtteil masks earlier declaration in same scope at .//FHEM/99_myUtils.pm line 337, <DATA> line 1.
2019.07.23 00:26:59 1: PERL WARNING: "my" variable $Stadt masks earlier declaration in same scope at .//FHEM/99_myUtils.pm line 350, <DATA> line 1.
2019.07.23 00:26:59 1: Including fhem.cfg
2019.07.23 00:26:59 3: WEB: port 8083 opened
...
Hat das mit deinem Modul zu tun oder muss ich an anderer Stelle suchen?
Viele Grüße Gisbert
Zitat von: Gisbert am 23 Juli 2019, 08:39:29
Hat das mit deinem Modul zu tun oder muss ich an anderer Stelle suchen?
Das ist wohl ein Fehler in Buienradar. Schätze mal das keine Daten von Buienradar kamen und deshalb die JSON-Daten natürlich auch nicht geladen werden konnten.
Danke übrigens dass du das Modul im Betrieb testest. Sehr wertvolles Feedback.
Zitat von: Christoph Morrison am 23 Juli 2019, 01:13:09
Hab ich gefixt, morgen mache ich dann eine neue Version fertig.
Falls du es selbst bis dahin fixen willst: use English fehlt oben.
Damit fällt eine Meldung weg, es bleibt aber folgende Meldung beim reload:
Global symbol "$name" requires explicit package name (did you forget to declare "my $name"?) at ./FHEM/59_Buienradar.pm line 378.
Gesendet von meinem LYA-L29 mit Tapatalk
Hallo Christoph,
ich habe in Fhem ein update all / shutdown restart gemacht.
Das Buienradar-Device scheint wieder normal zu arbeiten und es kommen regelmäßig updates rein.
Zuerstmal gibt es eine Entwarnung an dieser Stelle.
Das ungewollte Neustarten von, was schon sehr ungewöhnlich ist, muss ich weiter beobachten.
Viele Grüße Gisbert
Ist nun auch gefixt. Wenn euch etwas auffällt wäre es super wenn ihr einen Bug bei Github anlegen würdet (falls ihr einen Account habt, ansonsten gerne weiter hier).
Vielen Dank auch an dich, RoBra81.
Weitere Diskussionen bitte ausschließlich in 59_Buienradar (https://forum.fhem.de/index.php?topic=102497).