Warnungen von warnung.bund.de in FHEM einbinden

Begonnen von oesi, 02 Februar 2016, 19:32:26

Vorheriges Thema - Nächstes Thema

Christoph Morrison

Zitat von: KölnSolar am 14 Juni 2019, 20:19:36
Nur,
als genau eine Angabe im define u. wer mehrere "geocodes" abfragen will legt mehrere devices an
oder
Angabe mehrerer geocodes in einem Attribut blank-separiert ?

Ich hätte ja lieber pro Geocode (und meinetwegen auch pro Quelle, also Waldbrand / Unwetter / etc.) ein Device statt eines Sammeldevices.

KölnSolar

Ok. 2 Tage, wenig Resonanz.  :( somit 3:0 für device/geocode.  :)

ZitatEdit: Ich hab ja keine Nina-App, weil ich die beiden Monopolisten nicht unterstütze. Auf der Warnseite vom Bundkann man auch Hochwasser u. Unwetter sehen. Kann man das in der App auch ?
beantworte ich dann mal selbst
Zitat....Für diese Orte erhalten Sie dann alle amtlichen Warnungen des Bevölkerungsschutzes, Wetterwarnungen und Hochwasserinformationen. ....

Dann reden wir hier also nicht über ein Ninamodul, sondern "MoWaS".

Die Analyse der Attribute macht bisher wenig her. Folglich macht dann auch ein entsprechendes Reading wenig Sinn. Ich werde vermutlich nur dann ein Reading nebst Logmeldung verbose=2 anlegen, wenn dann doch mal ein "neuer" Wert kommt.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Christoph Morrison

Zitat von: KölnSolar am 16 Juni 2019, 11:49:14
Dann reden wir hier also nicht über ein Ninamodul, sondern "MoWaS".

Sowieso, siehe auch die Mail aus meinem Anhang. NINA ist nur ein Frontend für MoWaS.

KölnSolar

Jetzt hab ich auch gleich 4 Unwetterwarnungen in UWZ.

Was mach ich bitte als User mit diesem "Start"-Reading: 1560760200 ?  :o
OK, mit humanreadable wird es lesbar umgesetzt. Jetzt kenn ich auch dieses Attribut.  :D
Da wir lesbare Infos bekommen, werde ich auf Umformatierungen verzichten und die Readings ...._Time u. ...._Date nicht nutzen.

Mir fehlen immer noch Attribute wie z.B. uwzlevel oder Kategorien wonach ich sortieren könnte/sollte bzw. den höchsten level zu ermitteln  :'( Da scheint es bei MoWaS nix zu geben.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

KölnSolar

#34
So, nun eine erste Version auf Basis 77_UWZ.

define myMoWaS MoWaS DE 05170 900

aktuell funktioniert AGS=geocode(1-5)=15088

Mit verboselevel=2 werden die codes gelogged, zu denenen es derzeit Meldungen gibt.

Mir geht es erst einmal nur um die Readings. Fehlt etwas ? Andere Gestaltung ?

Edit: Keiner der Downloader eine Meinung ?  ???
Aktuell bekomme ich nur 3 Warnungen. Auf der Internetseite gibt es 5. Die älteste(18.6. 16:24) und die von 15:43 fehlen.  :-\ Wie sieht das in der Nina-App aus ? Das wäre ja das aus für das Modul bzw. der Link ist Käse.
(Edit2: scheinbar sind neben MoWaS noch Katwarn und BIWAPP eigenständige Bevölkerungsschutzmeldungen)
Edit3: Katwarn gibt es mit https://warnung.bund.de/bbk.katwarn/warnmeldungen.json
         BIWAPP mit https://warnung.bund.de/bbk.biwapp/warnmeldungen.json
         Die JSON-Strukturen sind nicht gleich, aber ähnlich. Ich bau die mal zusätzlich ein.  :D
Edit4: Attachement removed after 4 downloads)
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

KölnSolar

#35
Keine Meinung liebe Downloader ?  ???

Attached die neuste Version mit Unterstützung von Katwarn u. BIWAPP.  ;D
(Bug, wenn linefeed in Texten vorhanden ist, fixed: replacement von linefeed mit space)

Modulname trotzdem MoWaS oder eher BBK (wg. Bundesamt für Bevölkerungsschutz und Katastrophenhilfe ) oder .....?
Schönes Wochenende(für die Feier- u. Brückentagler)
Markus
Edit: Attachement removed.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

CoolTux

Zitat von: KölnSolar am 20 Juni 2019, 13:43:51
Keine Meinung liebe Downloader ?  ???

Keine Meinung. Zum testen bin ic nicht gekommen, habe nur etwas im Code gestöbert. Lach.
Ich habe die nächsten Wochen vor das UWZ Modul auf packages um zu bauen. Eventuell hast Du ja Interesse es gleich zu tun.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

KölnSolar

Hi Cooltux,
klar passe ich mich dem "moderneren" UWZ an.  ;) Entwickelst Du dazu auf "Eurem" github ?
Mir sind da so einige Dinge aufgefallen, die nicht mehr in die Landschaft nach aktuellen "Entwicklerrichtlinien" passen. Richtig gut finde ich aber das Logging mit Code-Zeilennr.  Das wäre fast was für den Standard Log3.

Bisher ist das neue Modul ja eher als "proof-of-concept" zu verstehen. Wenn die Funktionalität erledigt ist geht es an Code-Verschönerung, commandref.....
Grüße Markus
PS: Guck Dir bitte mal bei Gelegenheit den Code von Zeile 424-458 an. Das habe ich mir "zusammengewürgt" um die 3 Quellen in ein gemeinsames Array zu bekommen. Geht das schöner/einfacher bei dem Referenzgedönse ?
Die Errorabfrage Zeile 449 und das return fehlen im UWZ bei Fehler im JSONAcquire.(bei meinem Test waren kurzzeitig die URL's nicht erreichbar).
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

CoolTux

Zitat von: KölnSolar am 20 Juni 2019, 15:53:30
Hi Cooltux,
klar passe ich mich dem "moderneren" UWZ an.  ;) Entwickelst Du dazu auf "Eurem" github ?
Mir sind da so einige Dinge aufgefallen, die nicht mehr in die Landschaft nach aktuellen "Entwicklerrichtlinien" passen. Richtig gut finde ich aber das Logging mit Code-Zeilennr.  Das wäre fast was für den Standard Log3.

Bisher ist das neue Modul ja eher als "proof-of-concept" zu verstehen. Wenn die Funktionalität erledigt ist geht es an Code-Verschönerung, commandref.....
Grüße Markus
PS: Guck Dir bitte mal bei Gelegenheit den Code von Zeile 424-458 an. Das habe ich mir "zusammengewürgt" um die 3 Quellen in ein gemeinsames Array zu bekommen. Geht das schöner/einfacher bei dem Referenzgedönse ?
Die Errorabfrage Zeile 449 und das return fehlen im UWZ bei Fehler im JSONAcquire.(bei meinem Test waren kurzzeitig die URL's nicht erreichbar).

Hallo Markus,

Das UWZ wird dann im FHEM Organisations GitHub weiter entwickelt. Ich habe das damals zusammen mit Tobias gemacht, hat schon ein bisschen was auf dem Buckel das Modul. Mal schauen was ich da mache.

Die Zeilen zum Array schaue ich mir an.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Florian_GT

Zitat von: KölnSolar am 14 Juni 2019, 20:19:36
Hab die Tabelle mal überflogen: Stelle 1-5: RAU RS = AGS = RS alt; scheinbar immer eindeutig für eine Stadt/Gemeinde/Kreis

Also wie ich schon schrieb, 5-stelligen Filter durch User definieren.

Nur,
als genau eine Angabe im define u. wer mehrere "geocodes" abfragen will legt mehrere devices an
oder
Angabe mehrerer geocodes in einem Attribut blank-separiert ?

Ich guck mir aktuell die codes urgency, severity, response.... an, um die Meldungen später zu klassifizieren/sortieren.

Edit: Ich hab ja keine Nina-App, weil ich die beiden Monopolisten nicht unterstütze. Auf der Warnseite vom Bundkann man auch Hochwasser u. Unwetter sehen. Kann man das in der App auch ? Das dachte ich bisher, aber in https://warnung.bund.de/bbk.mowas/gefahrendurchsagen.json sind die ja nicht enthalten. Unwetter kriegen wir ja über UWZ, aber Hochwasser  :-\
Hier gibt es wohl weitere Infos   
"http://warnung.bund.de/bbk.wsv/hochwasser.json",
"http://warnung.bund.de/bbk.lhp/hochwassermeldungen.json",
"http://warnung.bund.de/bbk.dwd/waldbrand.json",
"http://warnung.bund.de/bbk.bgr/erdbeben.json
Die sähe ich dann aber in einem separaten Modul....

Hallo,

ich hätte gerne ein Zentrales Module, dass sich um den Download der Daten und deren Verarbeitung in ein Array kümmert. Von dort aus könnte es dann in Submodules weiter gehen. Dann könnte man die jeweilige Gefahr entsprechend mit unterschiedlichen Verarbeitungen und oder Regeln behandeln. Da wird sicherlich z.B. zwischen Gefahrenlagen und Hochwasser einiges unterschiedlich zu schreiben sein.

Ich möchte aber um jeden Preis jede Form der Warnmeldung die der Bund uns dort liefert auch in Fhem zur Verfügung stellen. Zum Beispiel haben wir in der Verganheit ja schon gesehen, dass UWZ mit der Metogroup als Quelle nicht zuverlässig ist.

Da bieten sich dann also nachfolgende Module zu schreiben an:
- unwetter
- hochwasser
- waldbrand
- erdbeben
- gefahrendurchsagen + hochwassermeldungen
FHEM: Proxmox Server, FHEM in VM, pgSQL DB
Hardware: Ethersex (Pollin NETIO Boards), Diverse Tasmota MQTT Devices, Raspberry Pi Zero W Kameras, (Github RaspberryPiStreamingCamera), Zigbee2MQTT, ESPEasy

Development: UBA (Umwelt Bundesamt), BFS (Bundesamt für Strahlenschutz)

CoolTux

Man kann ohne weiteres alle Quellen nehmen und entsprechend abfragen. So ein Array Abfrage habe ich bereits in anderen Modulen gemacht. Die erhaltenen Daten könnte man dann logischen Modulen zukommen lassen. Quasi ein 2. Stufiges Modulsystem.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

KölnSolar

#41
Hm,
sehe ich nicht so(also 2-Stufigkeit). Wir sammeln auch nicht bei anderen unterschiedlichen "Quellen" erst einmal alle Daten und verarbeiten dann wieder irgendwie individuell.

Was will man denn noch groß "weiter bearbeiten" ? Hat man einmal die Daten und events, ist jegliche Weiterverarbeitung mit FHEM individuell gestaltbar. Manche mögen sich klicki-bunti Dinge basteln. Mir persönlich genügt Ereignis->Info(je nach Anwesenheitsstatus aufs Handy, auf den TV, oder über Alexa).->manuelles Handeln(ich weiß, nicht smart, aber ich halte mich nach wie vor für smarter bzgl. individueller Entscheidung bei individuellen Ereignissen) ;). Ich sehe auch keinen großen Unterschied, ob mein Haus(oder ich) drohen abzubrennen, wegzuschwimmen, zu explodieren.....

Da ich begeisterter Alarmmodulnutzer bin, ist das die weiterverarbeitende Ebene von "Gefahren" meiner Wahl.

Wo ich zustimme: Wie schon gesagt ist mir erst einmal ziemlich wurscht, welche Gefahr droht. Deshalb fände ich es nicht verkehrt, die Datensammlung in EINEM Modul auszuführen. Über ein Attribut könnte man die unterschiedlichen Gefahren je device AUSSCHLIESSBAR machen. Letztendlich hab ich ja auch nur das UWZ-Modul kopiert und den Part für die Datenselektion angepasst.(und die überflüssigen Sprach-, Ländergeschichten zwecks besserer Übersicht  eliminiert).
Etwas schwierig wird lediglich die "Regionaldefinition". UWZ macht es über PLZ, weil auch der externe Datenzugriff mit PLZ gemacht wird. Für die Katastrophenmeldungen lese ich alles aus und modulintern wird dann nach geocode selektiert. Tatsächlich haben wir die Polygoninformation verfügbar.
Die Bedürfnisse der einzelnen User kann ich mir sehr unterschiedlich vorstellen. Dem einen genügt seine Stadt/Landkreis, der andere möchte informiert werden, wenn sich in seinem Umkreis etwas tut. Sensibilität=userspezifisch. Hier könnte man auf die statischen und sehr starren Bundesländergrenzen abheben oder so etwas wie eine individuelle "Umkreisselektionen/Radius um einen geographischen Punkt(Längen-/Breitengrad)(technisch schwieriger zu realisieren).

Technisch ließe sich also das UWZ-Modul für "allgemeine Bedrohungen" so umbauen, dass lediglich die ...Run-Funktion als attributgesteuerter Funktions-Baustein entwickelt wird.
Unwetter->Unwetterzentrale
Katastrophen-> MoWaS(incl. Katwarn, BIWAPP)
Hochwasser->Hochwasser/Hochwassergefahren
.
.
.
Im Ergebnis sind Anz. der Warnungen innerhalb der Regionendefinition wichtig. Ggfs. noch ein level/Wahrscheinlichkeit/... wie bei UWZ, wobei bei den Katastrophen es nun einmal so ist, dass die in der Regel eingetreten sind und daher auch (fast) IMMER Warnstufe rot bedeuten.

Hab mir jetzt noch die anderen genannten Links angesehen: Hochwasser/Hochwassermeldungen liefern ein ähnliches JSON-Format wie die Katastrophenmeldungen. Könnte man noch integrieren. Brandgefahr-/Erdbeben-Link scheinen tot.

Grüße Markus
Edit: Obiges ist sehr "deutsch" gedacht. Für andere Länder hätten wir dann ggfs. weitere ...Run-Funktionen/Gefahr.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Florian_GT

Zitat von: KölnSolar am 21 Juni 2019, 11:45:11
Hm,
sehe ich nicht so(also 2-Stufigkeit). Wir sammeln auch nicht bei anderen unterschiedlichen "Quellen" erst einmal alle Daten und verarbeiten dann wieder irgendwie individuell.

Was will man denn noch groß "weiter bearbeiten" ? Hat man einmal die Daten und events, ist jegliche Weiterverarbeitung mit FHEM individuell gestaltbar. Manche mögen sich klicki-bunti Dinge basteln. Mir persönlich genügt Ereignis->Info(je nach Anwesenheitsstatus aufs Handy, auf den TV, oder über Alexa).->manuelles Handeln(ich weiß, nicht smart, aber ich halte mich nach wie vor für smarter bzgl. individueller Entscheidung bei individuellen Ereignissen) ;). Ich sehe auch keinen großen Unterschied, ob mein Haus(oder ich) drohen abzubrennen, wegzuschwimmen, zu explodieren.....

Da ich begeisterter Alarmmodulnutzer bin, ist das die weiterverarbeitende Ebene von "Gefahren" meiner Wahl.

Wo ich zustimme: Wie schon gesagt ist mir erst einmal ziemlich wurscht, welche Gefahr droht. Deshalb fände ich es nicht verkehrt, die Datensammlung in EINEM Modul auszuführen. Über ein Attribut könnte man die unterschiedlichen Gefahren je device AUSSCHLIESSBAR machen. Letztendlich hab ich ja auch nur das UWZ-Modul kopiert und den Part für die Datenselektion angepasst.(und die überflüssigen Sprach-, Ländergeschichten zwecks besserer Übersicht  eliminiert).
Etwas schwierig wird lediglich die "Regionaldefinition". UWZ macht es über PLZ, weil auch der externe Datenzugriff mit PLZ gemacht wird. Für die Katastrophenmeldungen lese ich alles aus und modulintern wird dann nach geocode selektiert. Tatsächlich haben wir die Polygoninformation verfügbar.
Die Bedürfnisse der einzelnen User kann ich mir sehr unterschiedlich vorstellen. Dem einen genügt seine Stadt/Landkreis, der andere möchte informiert werden, wenn sich in seinem Umkreis etwas tut. Sensibilität=userspezifisch. Hier könnte man auf die statischen und sehr starren Bundesländergrenzen abheben oder so etwas wie eine individuelle "Umkreisselektionen/Radius um einen geographischen Punkt(Längen-/Breitengrad)(technisch schwieriger zu realisieren).

Technisch ließe sich also das UWZ-Modul für "allgemeine Bedrohungen" so umbauen, dass lediglich die ...Run-Funktion als attributgesteuerter Funktions-Baustein entwickelt wird.
Unwetter->Unwetterzentrale
Katastrophen-> MoWaS(incl. Katwarn, BIWAPP)
Hochwasser->Hochwasser/Hochwassergefahren
.
.
.
Im Ergebnis sind Anz. der Warnungen innerhalb der Regionendefinition wichtig. Ggfs. noch ein level/Wahrscheinlichkeit/... wie bei UWZ, wobei bei den Katastrophen es nun einmal so ist, dass die in der Regel eingetreten sind und daher auch (fast) IMMER Warnstufe rot bedeuten.

Hab mir jetzt noch die anderen genannten Links angesehen: Hochwasser/Hochwassermeldungen liefern ein ähnliches JSON-Format wie die Katastrophenmeldungen. Könnte man noch integrieren. Brandgefahr-/Erdbeben-Link scheinen tot.

Grüße Markus
Edit: Obiges ist sehr "deutsch" gedacht. Für andere Länder hätten wir dann ggfs. weitere ...Run-Funktionen/Gefahr.

Hallo,

über https://warnung.bund.de/assets/json/suche_channel.json erhält man mehr Infos zu den jeweiligen Channels die auch auf der Webseite gesucht und mit denen gefiltert werden kann. Ich könnte mir vorstellen, dass wir darüber filtern. Dann ist es halt genau so, wie auf der Webseite selbst.

Von mir aus, kann auch alles in ein Module. Ich will langfristig aber von UWZ (oder besser gesagt, dem aktuell genutzten Anbieter) weg, weil dieser mir unzuverlässig erscheint. Die Unwetterwarnungen fehlten mir gerade oben in deiner Auflistung.

Gruß Florian
FHEM: Proxmox Server, FHEM in VM, pgSQL DB
Hardware: Ethersex (Pollin NETIO Boards), Diverse Tasmota MQTT Devices, Raspberry Pi Zero W Kameras, (Github RaspberryPiStreamingCamera), Zigbee2MQTT, ESPEasy

Development: UBA (Umwelt Bundesamt), BFS (Bundesamt für Strahlenschutz)

KölnSolar

Zitathttps://warnung.bund.de/assets/json/suche_channel.json
Interessant. Da könnte man über Gemeindenamen filtern.
ZitatDie Unwetterwarnungen fehlten mir gerade oben in deiner Auflistung.
Zitat
Technisch ließe sich also das UWZ-Modul für "allgemeine Bedrohungen" so umbauen, dass lediglich die ...Run-Funktion als attributgesteuerter Funktions-Baustein entwickelt wird.
Unwetter->Unwetterzentrale
::)
ZitatIch will langfristig aber von UWZ (oder besser gesagt, dem aktuell genutzten Anbieter) weg, weil dieser mir unzuverlässig erscheint
War mir so nicht klar.  Also meteogroup raus und DWD(wie bei Nina) rein ?
Dann wären wir dann doch bei einem Ninamodul gelandet.  ;D
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Hollo

Zitat von: KölnSolar am 22 Juni 2019, 09:56:10
Interessant. Da könnte man über Gemeindenamen filtern. ::)War mir so nicht klar.  Also meteogroup raus und DWD(wie bei Nina) rein ?
Dann wären wir dann doch bei einem Ninamodul gelandet.  ;D
Grüße Markus
Ich will es mal so "sagen"...
wenn es um "amtliche Warnungen" geht, sollten auch die amtlichen (Un)wetter-Warnungen drin sein; und die kommen nunmal vom DWD.   ;)
FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"