Warnungen von warnung.bund.de in FHEM einbinden

[frank]

Aber die events sind doch da. Du regst Dich darüber auf, dass es keine quasi redundanten events für Warn_X_Instruction, Warn_X_LongText, Warn_X_ShortText..... gibt.

nein, das siehst du falsch und redundant ist es auch nicht.

mit aktueller version 13:02 und entsprechender distance bekomme ich 2 gewitter meldungen.
die dwd meldungen aktualisieren ständig creation, wodurch permanent newwarnings triggert. wenn die eventerzeugung in meiner hand läge, könnte ich jetzt schnell und einfach creation aus der eventgenerierung entfernen, damit nicht ständig der tv eine überflüssige meldung anzeigt.

zum testen ist es auch sehr schlecht, wenn sich die timestamps und werte der readings auf der detailseite nicht ändern bei änderung. es ist zudem nicht mehr erkennbar, wann ein update, oder sogar ein erfolgreiches update, ausgeführt wurde.

-------------------------

zudem ist es augenblicklich ein glücksspiel, welche der beiden gewittermeldungen an erster stelle steht.
als sortierung nutze ich, wie beschrieben, sent, was eigentlich sehr gut funktioniert. leider haben grundsätzlich alle gewitterwarnungen die selbe zeit (creation), die ständig geändert wird.
bei genügender anzahl an gewitterwarnungen wird die reihenfolge in der readingsliste ständig durchgemischt, da ja alle die selbe zeit haben.
hier würde ich mir wünschen, dass es bei identischer zeit (creation) eine zweite sortierung nach distance geben würde.


desweiteren fände es sinnvoll, wenn die sortierung umgedreht werden würde. also warn_0 wird ältester/entferntester und warn_max wird jüngster/naheliegenster. das minimiert enorm das listengeschiebe. lange andauernde (badesee/mehrere monate) meldungen würden nach und nach an die niedrigen stellen wandern und dort verweilen, ohne angefasst werden zu müssen. erhöht sogar die performance. 


bisher habe ich auch keine fehlreadings mehr erblickt und auch 2-stellige warn_xx werden nun einwandfrei gelöscht.

[frank]

scheinbar erzeugen nur die zufälligen und unnötigen positionswechsel gerade bei mir die anzahl an newwarnings.
creation update wird gar nicht erkannt und mein sortierungswunsch von eben würde bereits unnötige newreadings minimieren.
bei 3x gewitter mit reihenfolge 1,2,3 gab es nach update die reihenfolge 2,1,3 mit newwarnings=2.


nach welcher formel wird color ermittelt?
die badeseen bei harburg haben kein color reading => "severity":"Minor"
eine farbe (grau) für "msgType":"Cancel" wäre auch fein, falls es noch nicht vorgesehen ist.


habe gerade ein neues event für eventID entdeckt.         (langsam ernährt sich das eichhörnchen)

[frank]

wie wichtig doch events sind: 

durch die neuen events bei eventID habe ich gerade ein problem mit den events bei newwarnings erkannt.
es gab gerade bei 2 aufeinanderfolgenden updates jeweils 3 newwarnings (ausgelöst jeweils durch positionswechsel, aber egal). das bedeutet aber, dass das reading newwarnings auch events bei nichtänderung generieren muss, ausser wenn es den wert null hat. warncount war zu dieser zeit identisch.

bei extremem unwetter gibt es zwar ein color reading, aber dieses hat keinen wert => severity:extreme

eben gab es für einen kreis 3 gewitterwarnungen orange/rot/(violett). creation und distance jeweils identisch. hier müsste man dann sogar eine 3. sortierung zb auf color oder severity machen, um den willkürlichen positionswechsel zu minimieren. alternativ könnte man auch nur die "stärkste" warnung behalten und die schwächeren verwerfen. das wäre sicher schöner, weil die liste kürzer wird.

[KölnSolar]

schon verrückt die dwd-Meldungen. Ich füge Deinen Erkenntnissen meine hinzu.

die dwd meldungen aktualisieren ständig creation

Das ist nicht ganz richtig. Tatsächlich ist es technisch eine neue Meldung. Erkennt man an der Id und creation. Aber so oder so Käse    Die erzeugen permanent neue events  Ob mit oder ohne event in FHEM, habe ich da keine Idee zu. Einzig das reading WarnCountInArea scheint ein vernünftiger Indikator zu sein. Aber auch da scheint es Fälle zu geben, dass die lokale Warnung weg ist und dann beim nächsten update eine neue existiert. In die nächste Version baue ich latitude/longitude ein, so dass wir mehrere devices fürs testen anlegen können.

es ist zudem nicht mehr erkennbar, wann ein update, oder sogar ein erfolgreiches update, ausgeführt wurde.

Vertrau dem Modul.  kein neuer timestamp bei den "übergeordneten"(nicht Warn_x....) readings bedeutet keine Veränderung.

hier würde ich mir wünschen, dass es bei identischer zeit (creation) eine zweite sortierung nach distance geben würde.

Du meinst als 2. level ? Sortierung nach distance hab ich implementiert. Dadurch "beruhigt" sich das Spiel ein wenig. Sortierung eines 2. levels überfordert mich technisch. Außerdem ist fraglich, ob das Feuer beim Nachbarn nicht vielleicht doch prioritärer wäre. Vielleicht ist es aber auch nur der umgekippte Badesee. Da fehlen uns von MoWaS einfach die level. 

desweiteren fände es sinnvoll, wenn die sortierung umgedreht werden würde. also warn_0 wird ältester/entferntester und warn_max wird jüngster/naheliegenster.

Seh ich genau umgekehrt.  Hier sollten wir uns die übliche Nutzung vor Augen führen. Die ist doch Einstieg in die Details und dann möchte man doch die übergeordneten readings und die jüngsten/naheliegensten als erstes durchblättern, oder ?

nach welcher formel wird color ermittelt?

dwd liefert den RGB-Wert, den ich in Text umsetze.

die badeseen bei harburg haben kein color reading

Genau. Nur dwd liefert Farbcodes. Allerdings scheinen die mit severity zu korrespondieren. Nur: MoWaS liefert glaub ich immer nur minor. 

eine farbe (grau) für "msgType":"Cancel" wäre auch fein, falls es noch nicht vorgesehen ist.

Nönö. Wie gesagt, Color ist originär der dwd-Warnung entnommen. Ich denke wir sollten ein künstliches reading je Warnung und ein übergeordnetes max-reading kreieren. MoWaS+Cancel=0, dwd nach Farbe 1,2,3, nur wie kriegen wir MoWaS+Alert vergleichbar qualifiziert ?

bei extremem unwetter gibt es zwar ein color reading, aber dieses hat keinen wert => severity:extreme

das ist violett und schon implementiert.

eben gab es für einen kreis 3 gewitterwarnungen orange/rot/(violett). creation und distance jeweils identisch. hier müsste man dann sogar eine 3. sortierung zb auf color oder severity machen, um den willkürlichen positionswechsel zu minimieren.

Hatte ich noch nie. Wundert mich insofern, dass die doch ständig neue Meldungen raushauen. Wo liegt der Sinn ? Muss man dann mal beobachten wie die inhaltlich aussehen.

alternativ könnte man auch nur die "stärkste" warnung behalten und die schwächeren verwerfen. das wäre sicher schöner, weil die liste kürzer wird.

Ich könnte über Distanz und dwd selektieren. Aber was, wenn gelb für Hagel und rot für Sturm ... Bevor wir eliminieren sollten wir gut beobachten.

Danke fürs umfangreiche testen. Ich denke mit der nächsten Version lässt es sich angenehmer testen: mit mehreren devices, Sortierung nach distance, Warn_0X_ anstatt Warn_X_, vielleicht ein quellübergreifender Level ? Der wäre mir lieb zu finden. Vielleicht vorerst mit MoWaS+Alert=3 ?  Aber den Badesee mit Orkan gleichsetzen ?  Guckt bitte mal in Eure logs. Mir unbekannte Werte logge ich bereits bei verbose=2.

[curt]

Hallo allerseits,

ich glaube verstanden zu haben um was es geht. Leider finde ich den Einstieg nicht - also eine Seite (oder einen Artikel) der mir erklärt, was ich zu tun habe.

Hilft mir jemand bitte auf's Pferd?

[CoolTux]

Das Modul ist aktuell pre-alpha. Es wird noch analysiert wie man die gegebenen Daten am besten verwertet.
Es gibt also weder Wiki und Commandref nur diesen Thread und den Code im Modul.

[KölnSolar]

Ich werde heute eine neue Version veröffentlichen, die dann alpha-Status haben sollte
- endgültige Festlegung auf den Modulnamen 77_Nina(dann doch Nina, weil wir ja durch die DWD-Warnungen nicht mehr nur MoWaS-Warnungen supporten)
- define ohne geocode
- Filterung basierend auf global:latitude/longitude bzw. Attribute latitude/longitude und Attribut distance
- Sortierung: distance(standard), creation, warnlevel
- englische commandref in einem Zustand, dass auch erfahrene User einen Einstieg in das Modul finden
- angepasste verbose level

Hab ich noch was sehr wichtiges vergessen oder Widerspruch zu Namenskonvention etc. ?

Grüße Markus

Und dann harren wir der Warnlage wie sie uns DWD bzw. das Wetter gestern beschert hat:
- Erst sich häufende Warnungen im Umkreis
- dann auch lokal; im Umland mit Erhöhung des levels
- nix passiert; kein Tropfen Regen dafür Sonnenschein
- Warnungen wieder reduziert
- dann das selbe Spiel von vorn und
- tatsächlich hat es mal für 10 min. geschüttet und es gab 20 Donner
- heute ist der angekündigte Regen mal wieder nur über uns hinweg geflogen 

[frank]

moin markus,

Ich werde heute eine neue Version veröffentlichen, die dann alpha-Status haben sollte
- endgültige Festlegung auf den Modulnamen 77_Nina(dann doch Nina, weil wir ja durch die DWD-Warnungen nicht mehr nur MoWaS-Warnungen supporten)
- define ohne geocode
- Filterung basierend auf global:latitude/longitude bzw. Attribute latitude/longitude und Attribut distance
- Sortierung: distance(standard), creation, warnlevel
- englische commandref in einem Zustand, dass auch erfahrene User einen Einstieg in das Modul finden
- angepasste verbose level

Hab ich noch was sehr wichtiges vergessen oder Widerspruch zu Namenskonvention etc. ?

funktioniert die neue sortierung creation dann wie die alte sent? die alte creation hat ja irgendwann nicht das erhoffte getan.
ansonnsten fehlt wohl hauptsätzlich die event unterstützung.

Das ist nicht ganz richtig. Tatsächlich ist es technisch eine neue Meldung. Erkennt man an der Id und creation.

nach deinem post hatte ich gestern abend kurz noch mal geschaut, aber kann das nicht bestätigen.

ich hatte distance so eingestellt, dass ich nur eine gewitterwarnung hatte. nach creationwechsel war die id identisch (zumindestens die 10 letzten zeichen, die ich mir merken konnte).
ohne value/timestamp aktualisierung auf dem monitor durch fehlende events, bleibt die analyse auch schwierig bis unmöglich. insbesondere ist der geniale eventmonitor mit gleichzeitiger fhem.log ausgabe zur zeit ziehmlich nutzlos. da bieten andere module mit event ausgabe deutlich mehr komfort.

dwd hat mal von (land) kreislevel auf gemeindelevel erweitert. nina vertreibt nur den kreislevel. sobald eine gemeinde die warnung auslöst, wird aber eine warnung für den gesamten kreis gesendet. bei vielen gemeinden im kreis gibt es dann eventuell ständig diese creationwechsel der kreis-sammel-warnung.

es ist zudem nicht mehr erkennbar, wann ein update, oder sogar ein erfolgreiches update, ausgeführt wurde.

Vertrau dem Modul.  kein neuer timestamp bei den "übergeordneten"(nicht Warn_x....) readings bedeutet keine Veränderung.

falsch verstanden.
ich mache gerne eine keepalive überwachung. bei uwz hatte sich da besonders das reading lastConnection angeboten. zusammen mit event-on-update gibt es bei jedem interval ein event.
so ein "heartbeat" ist auch manchmal für systemübergreifende performance analysen brauchbar, viele module haben die angewohnheit immer zur selben zeit im internet pollen zu wollen (gerne zur vollen stunde), sehr unschön.

mit modulen, die events liefern, ist bei fhem unheimlich viel möglich. manche sträuben sich allerdings dagegen (haben sie etwas zu verbergen?). 



colors:

dwd liefert normal 4 intensitätsstufen gelb/orange/rot/violett. gelb fällt bei nina weg, bleiben also 3, scheinbar auch, um mit den anderen quellen kompatibel zu sein.

uwz hat auch nur 3 intensitätsstufen => orange, rot, violett.

bei mowas gibt es wohl => minor, severe, extreme => orange, rot, dunkelrot (violett)
das sieht man sehr gut an den farblichen polygonflächen in der googlemaps einblendung auf der bund.de-webseite. zu zeit ist wenig zu sehen. beim waldbrand von trebs war das eventuell so, wenn ich mich recht erinnere.
mir scheint, dass die farben nicht identisch mit dwd sind. orange zb scheint etwas heller zu sein.

mit den passenden events könnte man schnell mal ein eventlog starten, und einsammeln lassen.

bei entwarnungen fällt die meldung aus der übersichtskarte. dann sieht man aber die nun grau gewordene polygonfläche in der detailansicht. dwd hat keine entwarnungen.

minor/orange für einen zerkarienbelasteten badesee ist doch plausibel. der see ist noch nicht gesperrt, aber trinken des wassers sollte vermieden werden. bei orangenem gewitter könnte einem ein ast auf den kopf fallen.

[frank]

hat sich der json-inhalt geändert.
https://warnung.bund.de/bbk.dwd/unwetter.json

ich bekomme nur eine lokale warnung, obwohl weitere kreise in meiner homezone liegen,die auch im json auftauchen.

im json sind diverse kreise mit polygonen unter einer eventid zusammen gefasst.
ausserdem gibt es am ende ein eintrag onset: mit einem timestamp, der scheinbar viel besser zu creation passt.

edit:
ein paar mal ist die id gleich geblieben und sent: (creation) hat gewechselt.
nun wurde creation und eventid gewechselt.
onset: ist immer auf dem selben wert geblieben.

ich vermute die enthaltenen kreise haben sich beim wechsel der id geändert.

[KölnSolar]

onset ist gut. 11:52. Da gibt es aber auch noch effective: 12:54
Das eine oder andere sollten wir sicherlich noch aufnehmen. Für dwd-Warnungen das bessere Sortierkriterium. 
creation ist der technische timestamp. die beiden anderen die inhaltsbezogenen.
Zumindest bei MoWaS gibt es nichts vergleichbares. Ich guck bei katwarn und biwapp....
Das onset ins Creation-reading ? 

Welches Polygon(geocode) hätte denn treffen müssen ? Beim überfliegen habe ich nichts außergewöhnliches gesehen.

Edit: Katwarn liefert einen effective-timestamp. BIWAPP keinen.

[frank]

aus der uwz geschichte ist creation der zeitpunkt, an dem das wetterereignis zuerst registriert wurde, also die digitalisierung einer beobachtung. und zu diesem zeitpunkt wurde auch eine id vergeben. daher ist die älteste zeit sehr wahrscheinlich creation.

effective könnte entweder der zeitpunkt sein, an dem das ereignis erstmalig zu einer warnung (bei dwd könnte es mit gelb starten) wurde, oder der zeitpunkt, an dem der seltsame id wechsel erfolgte.

Welches Polygon(geocode) hätte denn treffen müssen ? Beim überfliegen habe ich nichts außergewöhnliches gesehen.

ich war verwirrt, da ich nur eine lokale warnung hatte, aber ein riesiges gebiet bei mowas angezeigt wurde. die tage gab es oft bis zu 5 warnungen der angrenzenden landkreise zusätzlich.
in diesem fall braucht es dann aber entsprechend viele gewitterzellen drum herum, die dann auch alle einen eigenen identifier abschnitt im json haben.

das hat aber vorhin zb 2 identische meldungen erzeugt, da es 2 gewittergebiete gab, die wohl den gleichen landkreis als nächsten punkt hatten.

[KölnSolar]

Hab dann gerade auch 2 Meldungen gesehen. Die 2. mit eigener Id, creation(onset) etwas später und im Text wurde aus  ..um 15l/m².... ...zwischen 15l/m² u. 25l/m²...   
attached die neue Version als Nina mit den angekündigten features. Zusätzlich noch die führende 0 bei einstelligen Meldungen, damit bei mehr als 9 Warnungen der Überblick gewahrt bleibt und die Sortierung passt. Den Bug, dass ggfs. einzelne Readings noch von der vorhergehenden Warnung selber Position stammen, konnte ich noch nicht beheben. Der neue warnlevel 0-4 korespondiert mit den Farben bei dwd. MoWaS-Meldungen: Cancel=0, Alert,Update=4 bis wir etwas passenderes gefunden haben.

Edit: Attachement removed

[frank]

MoWaS-Meldungen: Cancel=0, Alert,Update=4 bis wir etwas passenderes gefunden haben.

du meinst msgtype?

msgtype hat nichts mit der gefahrenstufe (severity) zu tun, dwd hat auch msgtype. nach meiner beobachtung funktioniert msgtype so:

die erste meldung zu einem ereignis hat (bisher) immer msgtype=alert.
bei mowas meldungen erkennt man das auch an einer art "msgNumber" (die letzten 3 ziffern der id).

jede weitere/veränderte meldung zu diesem ereignis bekommt msgtype=update. "msgNumber" zählt hoch und es gibt zusätzlich einen json-eintrag preferences (hinweise zu den vorherigen meldungen). auf der webseite gibt es dann immer in der meldung eine historie der ganzen zurückliegenden meldungen mit entsprechenden links.

die entwarnungsmeldungen haben dann msgtype=cancel.
cancel meldungen muss es nicht zwangsläufig geben, glaube ich. eventuell gibt es immer eine abschliessende entwarnungsmeldung, wenn es vorher noch keinen "end-timestamp" gab. jedenfalls hatten die entwarnungen dann immer ein end datum für das ereignis, ab dem dann die meldung aus der liste verschwand.

also gefahrensufe/farbcode für mowas ist severity (msgtype=cancel "überschreibt"), wie gestern bereits beschrieben.

[KölnSolar]

Du liegst mit allem fast richtig, theoretisch. severity liefert bisher aber nur Minor. Lediglich für die Bombenwarnung in Remagen wird Severe geliefert. Ist mindestens so schwerwiegend wie extremes Unwetter. Unschön: Auch die Entwarnung liefert Severe. Kein Cancel.
Ist also eher nicht das Kriterium. 

[Florian_GT]

Ich werde heute eine neue Version veröffentlichen, die dann alpha-Status haben sollte
- endgültige Festlegung auf den Modulnamen 77_Nina(dann doch Nina, weil wir ja durch die DWD-Warnungen nicht mehr nur MoWaS-Warnungen supporten)
- define ohne geocode
- Filterung basierend auf global:latitude/longitude bzw. Attribute latitude/longitude und Attribut distance
- Sortierung: distance(standard), creation, warnlevel
- englische commandref in einem Zustand, dass auch erfahrene User einen Einstieg in das Modul finden
- angepasste verbose level

Hab ich noch was sehr wichtiges vergessen oder Widerspruch zu Namenskonvention etc. ?

Grüße Markus

Und dann harren wir der Warnlage wie sie uns DWD bzw. das Wetter gestern beschert hat:
- Erst sich häufende Warnungen im Umkreis
- dann auch lokal; im Umland mit Erhöhung des levels
- nix passiert; kein Tropfen Regen dafür Sonnenschein
- Warnungen wieder reduziert
- dann das selbe Spiel von vorn und
- tatsächlich hat es mal für 10 min. geschüttet und es gab 20 Donner
- heute ist der angekündigte Regen mal wieder nur über uns hinweg geflogen 

Hi, der DWD nimmt an MoWaS teil. Somit wäre der Name MoWaS noch korrekt. Siehe https://www.dwd.de/DE/fachnutzer/katastrophenschutz/mowas/mowas.html.