Modul für DWD Open Data

[DS_Starter]

Hallo Jens,

habe ich natürlich gleich ausprobiert.
Ich bekomme eine Fehlermeldung die ich noch nie sah:

Code Auswählen Erweitern

Status: forecast error: Can't "break" in a loop topicalizer

Und das Attr forecastDataPrecision hat als mögliche Argumente "low" oder "highalertArea".

Da fehlt mit Sicherheit in Zeile 2822 hinten ein Leerzeichen:

Code Auswählen Erweitern

.'forecastStation forecastDays forecastProperties forecastResolution:1,3,6 forecastWW2Text:0,1 forecastPruning:0,1 forecastDataPrecision:low,high'
LG

[DS_Starter]

Das mit dem Leerzeichen hatte ich richtig erkannt. Aber jetzt kommt noch:

Code Auswählen Erweitern

forecast error: Can't "break" outside a given block

Nut bei forecastDataPrecision=high.

[jensb]

Interessant, dass nicht alle Systeme die gleichen Fehler ausspucken, hatte ich aber schon ein paar mal. Gibt gleich eine neue Version. Break hat in Perl nicht viel verloren, in getStationPos() gehört last hin.

[jensb]

Neue Version ist hochgeladen. Werde bis zur Optimierung des RAM-Bedars "S" nicht testen können, da ich dazu nicht genug RAM habe. Daher fallen Probleme, die nur bei "S" vorkommen bei mir nicht immer auf.

[DS_Starter]

Hast du die wrklich hochgeladen? Im contrib ist noch "break" in Zeile 1721 und 48 Minuten alt.

[jensb]

Ja, leider, hatte ich auch schon bemerkt. Allerdings im FHEM-Verzeichnis - ist korrigiert.

[DS_Starter]

Jetzt rennt es. 
Danke Jens. Ich entferne das Modul dann aus meinem contrib.

Hilfreich wäre für die User vllt. wenn du dein contrib im Footer vermerken würdest damit jeder gleich weiß wo er die Entwicklungsversion herunterladen kann.

LG,
Heiko
 

[xerion]

Ich habe mit das Modul heute aus dem SVN von "jensb" gezogen. Wenn ich ein  reload des Moduls mache bekomme ich folgende Fehlermeldung:

Code Auswählen Erweitern

Unrecognized character \xE2; marked by <-- HERE after           <-- HERE near column 57 at ./FHEM/55_DWD_OpenData.pm line 8.

[DS_Starter]

Hallo xerion,

da hast du wahrscheinlich nicht das .pm File heruntergeladen sondern irgendwas anderes. Schau mal in das File und lade es ggf. neu vom Jens contrib.

Übrigens gebe ich dir Recht gezüglich der Readings fc0_0_x. Die werden mit MOSMIX_S (high) tatsächlich nicht mehr erstellt/aktualisiert. Bei mir waren noch alte Readings vorhanden und ich hatte mir den Zeitstempel nicht angeschaut.

Grüße,
Heiko

[xerion]

Hallo xerion,

da hast du wahrscheinlich nicht das .pm File heruntergeladen sondern irgendwas anderes. Schau mal in das File und lade es ggf. neu vom Jens contrib.

Übrigens gebe ich dir Recht gezüglich der Readings fc0_0_x. Die werden mit MOSMIX_S (high) tatsächlich nicht mehr erstellt/aktualisiert. Bei mir waren noch alte Readings vorhanden und ich hatte mir den Zeitstempel nicht angeschaut.

Grüße,
Heiko

Hallo Heiko,

ich habe das aus dem SVN von Jens mit wget heruntergeladen:

Code Auswählen Erweitern

"wget -qO ./FHEM/55_DWD_OpenData.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/jensb/55_DWD_OpenData.pm"

aber ich schau mir das nochmal an.

EDIT: Fehler gefunden, war ein Copy&Paste Fehler der Link war falsch habe ich korrigiert

[DS_Starter]

@erwin, sorry du hattest ja die Sache mit den Readings fc0_0_x entdeckt.

[DS_Starter]

Hallo Jens,

ich habe festgestellt, dass der Timer mit deiner Version nicht mehr so gut läuft.
Es wird offensichtlich das Quarter 2 nicht mehr jede Stunde angefahren. Dadurch wird MOSMIX_S seltener als jede Stunde upgedated.
Ich bin erstmal wieder auf meine Version zurück und warte bis du die DWD Updatezyklus sensible Version erstellt hast.

LG,
Heiko

[stefanru]

Hi Heiko,

habe ich auch bemerkt, die updates werden nicht mehr richtig getriggert.
Wollte nur erst noch genaueres herausfinden bevor ich mich melde.

Ich gehe dann vorerst auch zurück auf deine letzte Version.

[DS_Starter]

Hallo Jens,

ich habe die sub Timer deiner contrib-Version ersetzt durch den Timer wie ich die sub in meiner contrib-Version implementiert hatte.
Damit funktioniert das Update wieder zuverlässig wie es soll im Quarter 2 zwischen xx:30 - xx:45.
Habe die V hier angehängt. Da du ohnehin den Timer sensitiv gestalten willst, kannst du die V vllt. vorerst so in dein contrib übernehmen damit Interessenten nicht über das Update-Problem stolpern.

Grüße,
Heiko

[mumpitzstuff]

Ich hätte noch eine Idee, wie ihr das ganze superschnell und so Ressourcenschonend wie möglich hinbekommen könnt. Die Header Daten kommen nur 1x im ganzen Dokument vor. Sucht doch einfach mit index() nach den Header Daten z.b. (könnte man sich auch schön in eine Funktion packen):

$start = index($data, '<dwd:Issuer>');
$end = index($data, '<dwd:Issuer>', $start + 1);
{substring extrahieren}
usw.

Jetzt braucht ihr noch die Daten der einen Station:

$pos_station = index($data, '<kml:name>'.$station.'</kml:name>');
$start = rindex($data, '<kml:Placemark>', $pos_station);
$end = index($data, '</kml:Placemark>', $pos_station + 1);
{substring extrahieren, also <kml:Placemark>...</kml:Placemark>}

Diesen neuen substring, der nur die eine wirklich benötigte Station enthält, könnt ihr jetzt ganz normal mit libXML parsen und mit eurem bisherigen Code weiter machen (ihr könnt eigentlich fast 99% wiederverwenden!). Der Vorteil liegt darin, das die Textsuche superschnell ist und ihr nur einen ganz ganz kleinen Teil der XML Daten parsen müsst. RAM Verbrauch weit unter 700MB würde ich schätzen (das meiste geht für das entpackte zip drauf).