Warnungen von warnung.bund.de in FHEM einbinden

[curt]

OT: Inhalt einer Meldung

Es gibt eine offensichtlich falsche Meldung: Für das komplette Land Brandenburg wird täglich die gleiche Hochwasserwarnung neu herausgegeben - real für das Flüsslein Steppenitz bei Perleberg (muss man wirklich nicht kennen).

Ich dachte mir: Tue mal ein gutes Werk. Also schrieb ich warnung.bund (Bundeamt) mit Cc an Landesamt Umwelt BRB eine freundliche Mail:
1) Die Meldung wird täglich aktualisiert, wild gewordenes Script?
2) Meldung ist regional, nicht landesweit.

Ich schrieb das gestern Nachmittag über den Firmenaccount und ging in Feierabend ... das Ticketsystem informierte mich zeitnah, dass es einen schnellen Rückruf gab, offenbar Landesamt:
"In diesem Bereich gibt es einen Biber mit Damm und Nachwuchs, der die Ergebnisse verfälscht. An einer Lösung wird gearbeitet."

Abgesehen davon, dass das ansich ja lustig ist - erstens sieht man da Schwächen des Gesamtkonzepts von Nina et al. Zweitens haben die offenbar gar nicht begriffen, dass man zwar vor Hochwasser eines nicht eingedeichten Flusses warnen muss, aber doch bitte nicht gleich landesweit.

[frank]

@curt
jetzt wurde der biber wohl "überzeugt". 
die meldung wurde gerade entfernt.

[herrmannj]

In Brandenburg werden IT Probleme durch den Revierförster gelöst 😂

[Christoph Morrison]

Das müssen diese robusten Lösungen sein, von denen man gelegentich aus der Presse hört.
RIP, Problembiber.

[curt]

Das müssen diese robusten Lösungen sein, von denen man gelegentich aus der Presse hört.

Die Formulierung ... da wird doch nicht jemand Fefe lesen?
Nehneh, das sind die agilen Prozesse, also best practices.

Ein gewisses Verständnis habe ich da sogar: Wir sind nun mal ein föderaler Staat mit daraus resultierenden vielen Vorteilen und auch dem einen oder anderen Nachteil: Im Katastrophenschutz gibt es zig Zuständigkeiten, teilweise über Meldeketten verknüpft - da wissen einzelne zuständige Behörden gar nicht, wo ihre Meldungen landen.

Das Problem (ich habe am Rande mit so etwas zu tun) ist, dass man Katastrophen nur schlecht üben kann. Aber im Ernstfall sind falsche Meldungen hoch gefährlich. - Nun kann man nicht immer nur maulen, ich schrieb denen halt. Zwar mit telefonischer und tatsächlicher Reaktion, aber ohne Mailantwort.

Also schrieb ich sowohl warnung.bund (Bundeamt) als auch Landesamt Umwelt BRB nochmals: Deren Hochwasserwarnungen sind nicht regionalisiert, sondern werden mit Warngebiet "komplettes Bundesland" rausgeschoben. Und das geht mal gar nicht.

[KölnSolar]

Da Du und @KölnSolar offensichtlich nicht die allerbesten Freunde sind, möchte ich quasi moderierend eingreifen

Kopfschüttel.

Code: [Auswählen]

   $message .= Nina_content($hash,"_Instruction",(defined($warning->{'info'}[0]{'instruction'}))?$warning->{'info'}[0]{'instruction'}:"no_data",$i);

@KölnSolar
Kannst Du das bitte testen und dann testweise in Dein Modul einbauen?

Nein, weil es nicht die Lösung des Problems ist und nur ein reading beeinflusst.
Ich hab aber jetzt die Ursache des Problems beheben können. Kommt mit der nächsten Version.

dass das reading sendername für die hochwassermeldungen keine daten liefert

Auch in der nächsten Version behoben.

bei genau jedem 3. poll der warnungen wird die hochwasser meldung nicht erkannt, bei den nächsten 2 intervallen ist sie wieder dabei. dadurch triggert newwarnings natürlich bei 2 von 3 intervallen, da ich eine weitere meldung in der homezone habe.

im log mit verbose=5 kann ich erkennen, dass die meldung in diesen fällen dann leer ist.

Code: [Auswählen]

2019.08.06 21:40:03.960 4: Nina nina: JSONAcquire.555 Start capturing of https://warnung.bund.de/bbk.lhp/hochwassermeldungen.json
2019.08.06 21:40:04.136 5: Nina nina: JSONAcquire.575 2 characters captured:  []


über den browser habe ich es allerdings noch nicht geschaft eine leere json datei abzurufen.
vermutlich muss exakt zu gewissen zeiten gepollt werden, um diese leere json datei zu bekommen. eventuell ist das der zeitpunkt, an dem die timestamps in der meldung geändert werden. der aussetzer erfolgte regelmässig zu minute 10, 25, 40 und 55 plus jeweils einige sekunden.

Konnte ich so nicht beobachten. Und nun ist die "Bibermeldung" weg. 

zur abschaltung weiterer quellen, insbesondere die hochwasser meldungen,

Sehe ich auch so. Allerdings keine Liste, durch welche einzelne Quellen ausgeschlossen werden können. Hochwasser ist ja in der Regel nur eine Folge des Wetters(Niederschlag, Schmelze), weshalb ich der Einfachheit/Klarheit halber lieber das Attribut disableDWD in disable_weather umdefinieren würde und damit die beiden Quellen dwd u. Hochwasser aus der Selektion ausschließen würde.

ebenso wäre ein attribut alignTime hilfreich

Finde ich mit Kanonen auf Spatzen geschossen. Nur bei Dir und Deiner interval-Definition gab es scheinbar das Problem. Eine Entzerrung der diversen aufs WWW zugreifenden Modulen, ließe sich auch durch ungewöhnliche Intervalleinstellungen(z.B. 61 anstatt 60 s) erreichen.
Im UWZ und Nina wird extra Blockingcall für eine positive Performance eingesetzt.

Und schließlich noch allgemein zu den Log-Meldungen:

2019.07.20 08:18:37.218 1: Nina nina: JSONAcquire.695 Error: Can't get https://warnung.bund.de/bbk.biwapp/warnmeldungen.json -- https://warnung.bund.de/bbk.biwapp/warnmeldungen.json: Can't connect(2) to https://warnung.bund.de:443:  SSL wants a read first
2019.07.20 08:18:40.512 1: PERL WARNING: Odd number of elements in hash assignment at ./FHEM/77_Nina.pm line 594.
2019.07.20 08:18:40.513 3: eval: {Nina_Done('nina|Error|Error https://warnung.bund.de/bbk.mowas/gefahrendurchsagen.json: Can\'t connect(2) to https://warnung.bund.de:443:  SSL

oder

Nina NinaTest: Run.322  malformed JSON ? decode returns: malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "<?xml version="1.0" ...") at ./FHEM/77_Nina.pm line 318.

oder

2019.08.14 07:03:11 1: Nina myNina: JSONAcquire.588 Error: Can't get https://warnung.bund.de/bbk.lhp/hochwassermeldungen.json -- https://warnung.bund.de/bbk.lhp/hochwassermeldungen.json: Can't connect(1) to https://warnung.bund.de:443: IO::Socket::INET: connect: timeout

sind Meldungen, die richtigerweise auf Probleme hinweisen. Die liegen aber nicht im Modul, sondern entweder beim Server oder der lokalen Installation. Mal ist der Server gar nicht erreichbar, mal liefert er nur unvollständige JSON-Daten.
Wie soll das Modul das jetzt anders handhaben ? 

Edit:

Zweitens haben die offenbar gar nicht begriffen, dass man zwar vor Hochwasser eines nicht eingedeichten Flusses warnen muss, aber doch bitte nicht gleich landesweit.

Genau. Qualiät der Warnungen und erst recht Granualität der Meldungen sind ungenügend. Daher werde ich auch den Inhalt des Feldes web nur in einem separaten reading ausgeben.

[curt]

Hochwasser ist ja in der Regel nur eine Folge des Wetters(Niederschlag, Schmelze), weshalb ich der Einfachheit/Klarheit halber lieber das Attribut disableDWD in disable_weather umdefinieren würde und damit die beiden Quellen dwd u. Hochwasser aus der Selektion ausschließen würde.

Nein, bitte nicht! Das geht schief!

Begründung:
Hochwasser am Elbepegel Wittenberg entsteht nie durch Regen/Schmelze in der Region Wittenberg. Sondern in den Einzugsgebieten; das ist erstens das Einzugsgebiet der Moldau südlich Prag und zweitens die Mittelgebirge Riesengebirge, Erzgebirge, Thüringer Wald.

Ich möchte die DWD-Warnungen nicht, aber ich möchte die Hochwasserwarnungen.

[curt]

(Ich schrieb)
Zweitens haben die offenbar gar nicht begriffen, dass man zwar vor Hochwasser eines nicht eingedeichten Flusses warnen muss, aber doch bitte nicht gleich landesweit.

Edit:Genau. Qualiät der Warnungen und erst recht Granualität der Meldungen sind ungenügend. Daher werde ich auch den Inhalt des Feldes web nur in einem separaten reading ausgeben.

Entschuldigung bitte, das hatte ich überlesen.

Vermutlich hast Du einen Denkfehler, aber das ist kein Vorwurf, das kannst Du nicht wissen:
Wir konnten noch gar kein Hochwasser über Dein Modul beobachten. Es gab einfach keine.

Wir (sorry: Auch Du) machen im Moment den Fehler, an Hand dieser einen Meldung anzunehmen, dass genau so Hochwassermeldungen aussehen. Nein, das wird anders sein (leider weiß auch ich nicht, wie es ganz konkret aussehen wird, ich kann das nur anhand nichtöffentlicher Daten vermuten)!

Ok, mal ganz von vorn:
Flüsse in Deutschland sind kategorisiert. Daran macht sich fest, wer zuständig ist und insoweit an das Bundesamt Kat meldet.

Erstens haben wir Bundeswasserstraßen, beispielsweise den Rhein, die Elbe, die Oder (und so einige mehr). Für Bundeswasserstraßen ist ausschließlich die Bundeswasserstraßenverwaltung zuständig - und das sind wirklich Profis. Wir sollten davon ausgehen, dass sie genau wissen, was sie an Bundesamt Kat melden.
(Ich bitte um Beachtung meiner Ausarbeitung zu Pegeln bei Bundeswasserstraßen unter https://wiki.fhem.de/wiki/Flusspegel )

Zweitens haben wir Flüsse, die eben keine Bundeswasserstraßen sind. Mal eingedeicht, mal nicht. Die fallen in Landeszuständigkeit - und weil wir deren viele haben, haben wir auch viele Modelle. Mal ist wie in BRB das Landesumweltamt zuständig, mal die Talsperrenverwaltung - und alle sind Zulieferer für das Bundesamt Kat, also Nina.

An diesem Punkt abschweifend: Das brandenburgische Landesumweltamt hat mit der Stepenitz ein Flüsschen, welches ich sogar persönlich kenne: Der Abfluss ist lächerlich, auch bei Hochwasser - aber das Flüsslein ist nicht eingedeicht. Und das ist für unmittelbare Anrainer (wir reden da von 100m) fatal.
Die (sowie das Bundesamt selbst) sind in der Sache nun angesprochen, also da sollte Sensibilität hergestellt sein.

Drittens haben wir Bäche - die lokal auch riesigen Ärger machen können: Meldende können die Landkreise, die Kommunalverwaltungen, die Zweckverbände sein. Aber sowas kann eben auch (zumindest theoretisch) unter "Hochwasser" in Nina landen.

@KölnSolar
Wir leben in einem der sichersten Länder der Welt. Bei uns ist Hochwasser die weit überwiegende Katastrophenlage. Daher bitte ich Dich, Hochwasser nicht fachfremd mit Wetter (mein letzter Beitrag) zu vermischen. Ich bitte Dich weiterhin darum, nicht auf Grund der lustigen Stepenitz-Meldung zu urteilen. Das ginge völlig fehl.

Danke.

[KölnSolar]

Ich bitte Dich weiterhin darum, nicht auf Grund der lustigen Stepenitz-Meldung zu urteilen.

Mache ich gar nicht. Aber bisher hatten wir in 2 Monaten 3 Hochwassermeldungen. Alle hatten die area Bundesland(so wird es vermutlich immer sein). Und alle waren dauerhaft, ohne dass es tatsächlich Hochwasser gegeben hätte.

Wir konnten noch gar kein Hochwasser über Dein Modul beobachten. Es gab einfach keine.

Da geb ich Dir recht. Allerdings glaub ich auch, dass auch im Fall der Fälle nur unspezifische(unbrauchbare) Meldungen kommen werden. Ich geh eine kleine Wette ein, dass die brauchbaren(konkreten,regionalen) Meldungen dann über MoWaS kommen werden.

Hochwasser am Elbepegel Wittenberg entsteht nie durch Regen/Schmelze in der Region Wittenberg. Sondern in den Einzugsgebieten; das ist erstens das Einzugsgebiet der Moldau südlich Prag und zweitens die Mittelgebirge Riesengebirge, Erzgebirge, Thüringer Wald.

Schon klar, nicht durch regionales Wetter, aber eben doch Wetter.

Ich möchte die DWD-Warnungen nicht, aber ich möchte die Hochwasserwarnungen.

Auch wenn ich es nicht verstehe, dann mach ich ein 2. Attribut. Begrifflich fände ich disableHochwasser richtig, um den Bezug zur Quelle zu haben. Gefällt mir aber nicht, wg. dem allgemeinen Ausdruck "Hochwasser". Und in deutsch schon gar nicht. Guck ich auf die Website liest man

Das Länderübergreifende Hochwasserportal wird gemeinsam von den deutschen Bundesländern betrieben.
Jedes teilnehmende Bundesland stellt hierfür laufend aktuelle Daten einer Auswahl von Hochwassermeldepegeln und eine Kurzinformation zur aktuellen Hochwasserlage zur Verfügung.

Da kommt mir dann disableFloodPortal in den Sinn. Bessere Ideen ?

[frank]

Bessere Ideen ?

LHP

http://warnung.bund.de/bbk.lhp/hochwassermeldungen.json

[KölnSolar]

bisher nur gefühlt, nun am konkreten Fall Bestätigung einer Spekulation: dwd-Warnungen werden für Nina erst ab severity moderate veröffentlicht. Meldungen mit severity=minor=1=gelb gibt es nicht. (im JSON der dwd-Quelle geprüft)
Aktueller Fall: von West-Ost gibt es in der Mitte v. D eine Sturmwarnung Stufe 2. Schmale flankierende Streifen nördlich u. südlich mit Stufe 1. Letztere finden in Nina nicht statt.
(Nur zur Info, damit sich niemand über fehlende level-1-Warnungen im Modul beklagt)

[Christoph Morrison]

Code Auswählen Erweitern

2019.09.17 12:49:41.203 1: PERL WARNING: Subroutine acos redefined at ./FHEM/77_Nina.pm line 607, <$fh> line 11.
2019.09.17 12:49:41.204 1: PERL WARNING: Prototype mismatch: sub main::deg2rad ($;$) vs none at ./FHEM/77_Nina.pm line 617, <$fh> line 11.
2019.09.17 12:49:41.204 1: PERL WARNING: Subroutine deg2rad redefined at ./FHEM/77_Nina.pm line 613, <$fh> line 11.
2019.09.17 12:49:41.204 1: PERL WARNING: Prototype mismatch: sub main::rad2deg ($;$) vs none at ./FHEM/77_Nina.pm line 624, <$fh> line 11.
2019.09.17 12:49:41.205 1: PERL WARNING: Subroutine rad2deg redefined at ./FHEM/77_Nina.pm line 620, <$fh> line 11.

Das ist mir gerade bei einem Reboot entgegen gepurzelt. Ich verwende die Version aus dem Git, die Florian_GT pflegt.

[mahowi]

Die Warnungen habe ich im Log, seitdem ich das Modul einsetze (21.07).

Die Diskussion dazu gibt es ab #274. Markus wollte das eigentlich am 30.07. ändern.

[KölnSolar]

Hat er auch. Die Version ist nur noch nicht veröffentlicht. 
Ich kämpfe gerade mit einem anderen neuen Modul und wollte vor der nächsten Veröffentlichung auf dem aktuellen 77_UWZ(wo ich noch die define-Parameter in Attribute schieben will)  neu aufsetzen.

Dauert also noch....

Grüße Markus

[KölnSolar]

Hallo Ninas,
da ich im Augenblick nicht konzentriert und durchgängig am UWZ-Modul arbeiten kann, habe ich Euch die Version hochgeladen, die bei mir seit einem Monat problemlos läuft. Leider ist deshalb immer noch die Definition mit CountryCode u. Interval erforderlich. Die wesentlichen Änderungen der neuen Version sind wie immer im Dokuthread beschrieben.

Viel Spaß bei der Nutzung des Moduls. bug-Meldungen und Verbesserungsvorschläge willkommen.

Grüße Markus