rdmtc / node-red-contrib-dwd Goto Github PK

Since version 0.1.8 I got regarding forecasts this message:

30.9.2019, 18:51:58node: DWD Weather Current
msg : string[46]
"MOSMIX attribute FF not known or not processed"

Does attribute FF has to do with "Look ahead hours".
This in my case is set to 4

But sometimes this message:
"MOSMIX attribute wwP not known or not processed"

or this:
"MOSMIX attribute RR1c not known or not processed"
is shown.

It seems that this only happens once after implementation.

node-red-contrib-dwd liefert ggf. mehrere warnings-Objekte. Aufeinanderfolgende Abfragen liefern tw. die gleichen Objekte mit gleichem Inhalt, jedoch in anderer Reihenfolge. Das erschwert die Detektierung identischer Warnungen erheblich. Mein Ziel ist, eine aus den Inhalten der Warnungen generierte XMPP-msg nur dann zu versenden, wenn sich gegenüber dem letzten Versand deren Inhalt verändert hat. Ich glaube, das mit meiner letzten Änderung recht gut bewerten zu können. Ein "Luxusproblem" verbleibt dennoch - das Format von warnings.time ermöglicht mit zumutbarem Aufwand nur eine endlich gute Sortierung.
(Ergänzend unten die Kommentierung meines change-nodes, welcher die XMPP-msg generiert. Die Bereitstellung der Zeitangaben im UTC-Format würde deren Bewertung drastisch vereinfachen. Bei Interesse stelle ich den node gerne bereit.)

Ich vermute (wegen der Lösung gem. https://www.home-assistant.io/integrations/dwd_weather_warnings/), dass die DWD-API die Daten zu warnings.time im UTC-Format bereitstellt. Falls dies zutrifft, wäre es sehr schön, wenn mit einem neuen release bspw. warnings.warning_start_utc und warnings.warning_end_utc zusätzlich bereitgestellt werden könnten. Mit dieser sicher minimalinvasiven Änderung wäre Abwärtskompatiblilität gewährleistet.

Vielen Dank im Übrigen für den node, welchen ich seit 2019 gerne nutze.

Gruß
bit-refresher

----- snip ----- snip ----- snip ----- snip ----- snip ----- snip ----- snip ----- snip ----- snip ----- snip -----

// Aus der Original-msg mit den DWD-Daten werden diejenigen Daten extrahiert, die als XMPP-
// Nachricht versendet werden sollen. Weil in der Eingangs-msg ggf. mehrere events über-
// mittelt werden, muss die Abfrage und Aufbereitung mittels einer Schleife erfolgen.
//
// update 03.01.2024:
// node-red-contrib-dwd 0.9.0 liefert Sequenzen von Warnungen, die nicht sortiert sind.
// Bei aufeinanderfolgenden Abfragen werden tw. die gleichen Warnungen, aber in unterschied-
// licher Reihenfolge geliefert. In diesen Fällen wirkt die Unterdrückung von dem Grunde nach
// identischen Nachrichtensequenzen nicht. Aus diesem Grund werden jetzt die Warnungen zuerst
// sortiert und erst dann zur Nachricht zusammengesetzt. Um eine geeignete Sortierung zu
// erreichen, werden einstelligen Stundenangaben vor der Sortierung Nullen vorangestellt.
//
// (Potentiell verbleibender Fehler in der Sortierung: bspw. dürfte eine Eingangssequenz
// "Mi. 3. Jan. 8:00" - "Di. 2. Jan. 18:00" - "Do. 4. Jan. 18:00" wie folgt aufgelöst werden:
// "Di. 2. Jan. 18:00" - "Do. 4. Jan. 18:00" - "Mi. 3. Jan. 08:00". Das sei wegen mutmaßlich
// geringer Vorkommenshäufigkeit b.a.W. mal hinzunehmen ... Lösungsansatz für langweilige
// Stunden: Sortierung auf Basis eines Teilstring mit abgeschnittenem führenden Wochentag -
// dazu müssten aber einstelligen Tagen ebenfalls Nullen vorangestellt werden - jedoch käme
// dennoch mit einer recht hohen Wahrscheinlichkeit in der Sortierung bspw. der 1. vor dem
// 31.)

A few days ago I updated NodeRed to version 2.2.2. I noticed that 'node-red-contrib-dwd' is not compatible with this version. According to my research, the last version that runs 'node-red-contrib-dwd' on NodeRed is version 1.2.9. I've noticed this since several previous versions. Since the node is very useful for me, I was hoping that it would be updated at some point. In any case, the DWD is still making the data available. Until a version compatible with the current version of NodeRed is released, I have set up my own NodeRed instance (V1.2.9) under libvirt, which is only used to download the weather warnings. The data is distributed with MQTT. But actually the weather warnings are far too important to me and should not be distributed via this workaround. At some point this constellation will also become incompatible. Hence my question: Is there a chance of an update?

Wenn ich [1] und einige anderen Blogs richtig verstehe, haben die json-Warnings[2] nur eine Genauigkeit auf Landkreisebene.

Es steht aber auch eine Zip-Datei mit XML-Dateien[3] zur Verfügung, die eine Genauigkeit auf Gemeinde-Ebene haben. Das Format ist in [4] beschrieben. Die CellID lässt sich über [5] ermitteln.

Würdest du evtl. diesen Weg einbauen?

Gruß,
Sven

[1] https://www.dwd.de/DE/leistungen/opendata/help/warnungen/dwd_warnings_products_overview_de_pdf.pdf?__blob=publicationFile&v=6

[2] http://www.dwd.de/DWD/warnungen/warnapp/json/warnings.json

[3] https://opendata.dwd.de/weather/alerts/cap/COMMUNEUNION_DWD_STAT/Z_CAP_C_EDZW_LATEST_PVW_STATUS_PREMIUMDWD_COMMUNEUNION_DE.zip

[4] https://www.dwd.de/DE/leistungen/gds/help/warnungen/cap_dwd_profile_de_pdf.pdf?__blob=publicationFile&v=1

[5] https://www.dwd.de/DE/leistungen/opendata/help/warnungen/cap_warncellids_csv.csv

First of all, thanks for this great little addon! Some time ago unfortunately were some images broken. At the moment we are facing a heat wave in essen but there is some images missing:

"DWD/warnungen/warnapp/viewer/img/warndreieck/undefined.png"

Is there a way to fix that?

The option to change the region code "online" without deploying the node would be a nice feature.
As an idea, the region code may be put into the input msg.payload (optionally in combination with a special msg.topic to keep the functionality compatible) or into a special topic (e.g. regioncode) of the input msg.