Dokuthread: Bevölkerungsschutzwarnungen (vergleichbar Nina-App)

Begonnen von KölnSolar, 18 Juli 2019, 13:23:05

Vorheriges Thema - Nächstes Thema

KölnSolar

So, damit ich nicht zig Mal dieselben Fragen beantworten muss, an dieser Stelle die "Vordoku" zu einem Wiki-Eintrag(den dann bitte jemand aus User-Sicht erstellt.) Ich pack das mal in dieses Subforum, weil hier auch der "Entwicklungsthread" läuft. Später wird in das "richtige" Subforum verschoben. Wie man das bei mir kennt, ist der Thread geschlossen und wird nur bei Änderungen durch mich vorübergehend geöffnet.
Bis das Modul offiziell ist werde ich genau an dieser Stelle die jeweils aktuelle Version veröffentlichen.

Ausgangspunkt des Moduls war der Entwicklungsthread. Dort bewegte sich aber nicht viel. Weil ich Monopolhasser bin, kann ich wiederum die Nina-App nicht nutzen. Also habe ich mich des Themas angenommen.

Die Basis für das Modul lieferte das UWZ-Modul(Dank auch an Cooltux für Modul und Unterstützung). Das hat den primären Grund, dass die Module sich bzgl. der Thematik ähneln und sicherlich viele User beide Module einsetzen. Da macht es Sinn, dass Sie auch ähnlich(nicht genau gleich) funktionieren und vergleichbare features bieten.

Für Menschen, die, aus welchen Gründen auch immer, auch nicht die Apps nutzen können, wurde diese Site, aus meiner Sicht gut gelungen, erschaffen. Im Modul passiert ähnliches, aber eben in FHEM. Um sich einen Überblick zu verschaffen, was und wann gemeldet wird, ist es hilfreich einen Blick auf die Website zu werfen.

Das Modul hat dieselbe Datengrundlage. Es sind 5 Quellen. Aufgrund der unterschiedlichen Quellen unterscheiden sich auch die gelieferten Daten leicht. Im Großen und Ganzen, werden aber vergleichbare Daten geliefert. Unterschiedlich ist auch das Aussenden der Warnungen. Während die Bevölkerungsschutzwarnungen einmalig mit fester und eindeutiger "EventID" eine Warnung aussenden(im Falle eine updates eine neue Meldung mit geänderter ID(lfd. Nr.)) , werden bei Wetter- u- Hochwassergefahren permanent neue Warnungen ausgegeben und die alten gelöscht. Dieser Unterschied ist wichtig, um das Verhalten des Moduls zu verstehen.
dwd-Warnungen werden scheinbar erst ab level=2=orange(severity=moderate) für Nina veröffentlicht. 

Ein großer Unterschied zum UWZ ist der Selektionsmechanismus. Während UWZ über die Postleitzahl selektiert, liefern die Warnmeldungen Polygone zu den Geodaten, also latitude/longitude. Anders ausgedrückt: Die Warnungen beziehen sich immer auf eine Region, die individuell ist und nicht mit vordefinierten Regionen vergleichbar ist.
Die meisten haben sicherlich bereits für andere Module im global-device die Attribute latitude/longitude für ihren Standort definiert. Das machen wir uns im Modul zunutze. Es gibt aber auch die Möglichkeit per Attribut die Einstellungen des global device zu übersteuern. Dadurch ist es auch möglich mehre Nina-devices unterschiedlicher Lokation anzulegen.
Bei der Selektion der Warnungen hat sich der User hermannj verdient gemacht(nochmals Danke dafür). Das Modul prüft alle Polygone der Warnungen darauf, ob sich die Lokation innerhalb befindet.
Zusätzlich gibt es das Attribut distance, um auch Warnungen zu selektieren, wo die Lokation sich nicht innerhalb des Polygons befindet, aber der nächste Punkt des Polygons in einer Entfernung, die den User aus individuellen Gründen interessiert. Anders ausgedrückt: der geographische Punkt wird auf einen Kreis um die Lokation erweitert und die Selektion findet anhand des Kreises statt.
Die geringste Entfernung der Lokation zu einem entfernteren Polygon wird ermittelt und in einem reading zur Warnung ausgegeben.
Auf distance lassen sich die Warnungen auch sortieren, so dass die Warnungen mit distance=0, also Warnungen, die die Lokation direkt betreffen, immer oben in der Reihenfolge stehen.
Im Modul lässt sich distance von 0-99km per Attribut setzen. Wer größere Entfernungen benötigt, kann dies trotzdem realisieren, indem er das Attribute per set-Befehl anstatt über die GUI setzt.

Für eine etwas übersichtlichere Darstellung als der Details-Seite lassen sich weblinks mit den internen html-Funktionen definieren(siehe commandref).

Die Definition und die readings sind in der FHEM-Standarddoku(englische commandref) beschrieben, so dass ich das hier nicht wiederhole.

Wohl aber die Erkenntnisse zu einzelnen Inhalten von readings. Das ist dann derzeit ongoing, weil wir keine entsprechende Dokumentation kennen, so dass wir das nur nach und nach ergänzen können.

Es ist zu differenzieren zwischen den  folgenden readings/Warnung:
1:1 Ausgaben:
Area - vom Sender definierte Beschreibung der Region. In der Regel Städte, Landkreise, Bundesländer....
Category - bisher Safety, Fire, Other, Met, Infra
Event - Schlagwort zur Art der Warnung(vergleichbar Category; bei BIWAPP-Meldungen eine Ziffer;noch nicht detailliert analysiert)
Geocode - Text zum Code, aus dem sich Stadt,Landkreis ableiten lassen. Stelle 1-5 des codes entsprechen in der Regel dem allgemeinen Gemeindeschlüssel(AGS)(Es gibt Warnungen, die nur ein Polygon haben aber mehrere geocodes. Es wird dann mangels Abgleichkriterien nur der 1. geocode angezeigt !!!).
Instruction - Anweisung, wie man sich verhalten soll
Short_Text - Kurztext der Warnung
Long_Text - Langtext der Warnung
Sender - Code des Senders der Warnung(hier erkennt man den Ursprung der Warnung(MoWaS, Katwarn, BIWAPP, DWD, Hochwasserzentrale)
Sendername - Bezeichnung des Senders der Warnung
Creation - timestamp der Warnung (bei dwd wird "onset" genutzt, da die Meldungen permanent erneuert werden. "onset" scheint der "Ursprungs" timestamp zu sein)
End - timestamp zum Ende des Zeitraums der Warnung
msgType - "Alert" oder "Cancel" einer Warnung

Die Readings, die etwas mehr bewirken:
Distance - geringste Distanz zum Polygon der Warnung (0 bedeutet Lokation befindet sich im Polygon) - wird durch das Modul ermittelt
Level: Anhand eines Feldes msgType(bisher bekannt: Alert oder Cancel) wird der Level der Warnung gesetzt. Alert=4; Cancel=0
          dwd-Warnungen erzeugen nach den bekannten Farbkodierungen: yellow=1, orange=2, red=3, violet=4
     Über alle Warnungen hinweg wird der maximale Level aller selektierten Warnungen(WarnLevelMax) devicespezifisch ermittelt.
Severity - bisher nicht aussagekräftig; in der Regel "Minor" oder "Severe"
               bei Wettermeldungen: orange=Moderate, red=Severe, violet=Extreme
Color - nur bei Wettermeldungen wird die RGB-verschlüsselte Farbe im reading als Klartext ausgegeben

Um den Sinn bzw. Wertebereich anderer Felder herauszufinden, werden mit verbose=2 Werte gelogged, die noch nicht bekannt sind. Das gilt für folgende Felder, die derzeit auch NICHT als reading ausgegeben werden.
status - bisher nur "Actual"
scope - bisher nur "Public"
certainty - "Observed" oder "Unknown"
urgency - "Immediate" oder "Unknown"
responseType - "Prepare" oder "Monitor"

übergeordnete, also devicespezifische, readings:
NewWarnings - eher als Flag zu verstehen(0=keine neue Warnung seit dem letzten Abfragezeitpunkt;>0 bedeutet neue Warnungen,wobei es hier zu "Fehlern" kommt wenn der User das Sortierkriterium ändert oder auch wenn nur eine neue Warnung erkannt wird, die die in der Reihenfolge folgenden um eine Position nach hinten verschiebt)
WarnCount - Zähler der aktuell selektierten Warnungen(direkt über die Lokation oder per distance)
WarnCountInArea - Zähler der aktuell selektierten Warnungen für die Lokation
WarnLevelMax - höchste severity der selektierten Warnungen
currentIntervalMode - "normal"; bei aktiver Warnung kann das per define definierte Intervall übersteuert werden. Dann zeigt das reading "warn".
durationFetchReadings - von UWZ übernommener Laufzeitindikator
lastConnection - Anzeige der gelesenen Zeichen (wenig aussagekräftig)
state - Anzeige von WarnCount und WarnCountInArea in einem reading

Das Modul ist technisch so konzipiert, dass sich die readings nur ändern, wenn sich deren Inhalt geändert hat. Folglich werden auch NICHT bei JEDEM Laufzyklus events erzeugt.
Für die readings der einzelnen Warnungen ist das noch weiter eingeschränkt. Es gibt NUR events der EventID bei ihrer Änderung. Sämtliche anderen readings lösen NIE ein event aus. Einzige Ausnahme: state

Bitte beachten bei der Konstruktion von Automatismen !

Wer unbedingt die Details loggen möchte, kann sich entsprechende userReadings anlegen, z.B. für Warn_00_ShortTextattr NinaTest userReadings eventWarn_00_ShortText:Warn_00_EventID.* {ReadingsVal($name,"Warn_00_ShortText,"")}Jedes Event Warn_00_EventID erzeugt nun ein event eventWarn_00_ShortText.

weitere modulspezifische Attribute:
html... - zur individuellen Gestaltung der html-Ausgaben
sort_readings_by - Sortierkriterien(distance(default),creation,severity)
disableDWD - Ausschluss von DWD-Warnungen von der Selektion
IntervalAtWarnlevel - Möglichkeit zur Definition der Refereshzyklen in Abhängigkeit des WarnLevelMax


in Diskussion
- Grafikausgabe (Landkarte)
- icons für NinaAsHtml-Ausgabe
- Distanz, Area oder geocode zusätzlich  für NinaAsHtml-Ausgabe
- Leveldefinition
- mehrstufige Sortierung
- Verarbeitung des Feldes "web"
- möglichkeit zur abschaltung weiterer quellen

bugs known
- reading sendername für die hochwassermeldungen liefert keine daten
- tw. falsche Inhalte in readings einer Warnung, die von der Warnung stammen, die vorher die Position/Rangfolge inne hatte
  (erkennt man am älteren timestamp dieses reading gegenüber den anderen readings einer Warnung)
- Bei Änderung der Sortierung oder neuen Meldungen mit Positionsverschiebungen ist der Counter NewWarnings inhaltlich falsch
- kein update/event von newwarnings, wenn sich Warnungen ändern, aber die Anz. gleich bleibt
- Begrenzung auf 30 Warnungen
- ssl-Problematik

Versionhistorie:


next version(not yet planned):
- keine Parameter mehr in der Definition !!!; neue Attribute zur Steuerung für Intervall u. Sprache

02.05.2021(after 11 downloads)
- URL's of icons for html-views corrected

03.02.2021(after 62 downloads)
- commandref
- minor corrections(e.g. colors)

22.01.2020(after 21 downloads)
- reduction of tls-handshakes
- minor changes(e.g. additional valid field contents => reduction of level2-warnings)

24.09.2019(after 55 downloads):
- new reading Warn_xy_Web if defined
- Attribut disableLHP -  0(default),1 zum abschalten von Hochwasserwarnungen(LHP=LänderHochwasserPortale)
- code changes for technical reasons
- error correction:
  - update/event von newwarnings, wenn sich Warnungen ändern, aber die Anz. gleich bleibt
  - reading sendername für die hochwassermeldungen liefert keine daten
  - tw. falsche Inhalte in readings einer Warnung, die von der Warnung stammen, die vorher die Position/Rangfolge inne hatte
 
27.07.2019
- WarnLevelMax: höchster level der selektierten Warnungen Minor=1, Moderate=2, Severe=3, Extreme=4  others=0
- reading Warn_xy_Level entfernt
- reading Warn_xy_MsgType (Alert|Cancel) hinzugefügt
- keine get-Befehle mehr
- NinaAsHtml, NinaAsHtml:  mit icons zur groben Visualisierung; Farben nach severity,Cancel=keineFarbe;ansonsten Attribute wie bei UWZ
- Begrenzung auf 30 Warnungen
- überflüssige Attribute entfernt
- commandref überarbeitet
- ssl-Problematik
- Text des geocodes (anstatt des codes)
- Korrektur der angezeigten area kürzester Distanz bei Mehrfach-Areas


19.07.19(11 Downloads) 
new features
- zusätzliche Datenquelle Hochwassergefahren
- Attribut disableDWD 0(default),1 zum abschalten von Wetterwarnungen
- Erweiterung des readings Warn_xy_Event um Wetterdetails(Wind, Starkregen, Hagel....)
- Warn_xy_Creation: bei dwd nun mit Wert aus on-set befüllt
- NinaAsHtml für die weblink-Ausgabe(Darstellung noch nicht im endgültigen Stadium)
- cycle time in Abhängigkeit des warnlevel über Attribut intervalAtWarnLevel; reading currentIntervalMode zeigt normal/warn
- vorübergehend warnlevelmax mit event u. update je Durchlauf

t.b.c


WIP

Dies ist ein Dokuthread. Bitte keine posts !
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