Modul für DWD Open Data

[DS_Starter]

In meinem contrib befindet sich die Version 1.17.5.
Diese Version kann nun auch Unicode (global encode=unicode) verarbeiten.
Zumindest bei meinen Tests war alles ok.

Denkt daran ... global encode=unicode ist experimental und und es gibt sicher viele Module die noch nicht mit encode=unicode komplett getestet wurden. Meine eigenen will ich hier auch nicht ausnehmen.

LG

[DS_Starter]

Zur Info ... ich habe JensB eben angeschrieben mit der Frage wie sein Status ist und ob wir noch auf ihn bauen können. Er war eigentlich immer hier aktiv dabei und es wundert mich etwas so lange nichts gelesen zu haben.

LG,
Heiko

[DS_Starter]

JensB hat mir mitgeteilt, dass er vllt. schon im Juni wieder zu uns stößt. Er wird sich weiter um das Modul kümmern, ist zur Zeit nur stark ausgelastet.
Ich habe ihm den aktuellen Stand der Entwicklungen des Moduls in meinem contrib mitgeteilt, Jens ist also im Bilde.
Wer an den aktuellen Weiterentwicklungen interessiert ist, sollte zunächst weiterhin die V aus meinem contrib verwenden. Mal schauen wann Jens wieder aktiv wird.

LG

[mumpitzstuff]

Das sind ja gute Nachrichten. Ich hatte schon die Befürchtung, das er irgendwie sauer sein würde, weil irgendwelche Leute an seinem Modul rum pfuschen.

Ich habe die guten Nachrichten mal als Anlass genommen, meinen noch offenen Punkt weiter zu verfolgen und bin schon recht weit gekommen, glaube ich. Allerdings bin ich für eine Sache schlicht zu blöd und brauche hier Unterstützung. Die Erweiterung basiert auf der letzten Version aus https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter.

Was funktioniert schon:

Im Falle von MOSMIX S wird zuerst MOSMIX L runtergeladen und die Daten abgelegt und danach MOSMIX S und ebenfalls abgelegt. Das gesamte FileHandling wurde entsprechend erweitert ($hash->{".forecastFile" . $mosmixType} und $hash->{".forecastFileHandle" . $mosmixType}).

Wofür bin ich zu dämlich:

Im Falle von MOSMIX S werden die Zeilen 1901 bzw. 1907 2x durchlaufen (einmal mit MOSMIX L und einmal mit MOSMIX S). $result müsste am Ende 2 Listen enthalten, nämlich die von MOSMIX L und die von MOSMIX S. In der Funktion GetForecastFinish müsste man dann in Zeile 2302 feststellen, ob die empfangene Liste 1 oder 2 weitere Listen enthält und über diese iterieren und somit den gesamten Code der Funktion, im Falle von MOSMIX S, 2x durchlaufen.

Irgendwie scheitere ich daran, das Perl da mit Referenzen zu arbeiten scheint und ich das Konstrukt dann in GetForecastFinish nicht aufgelöst bekomme, um den Code da 2x durchlaufen zu können. Das muss irgendein ganz dummes Perl Problem sein und ist hoffentlich für jemand anderen leicht lösbar.

[DS_Starter]

Ich hatte schon die Befürchtung das er irgendwie sauer sein würde, weil irgendwelche Leute an seinem Modul rum pfuschen.

Warum sollte er. Wir arbeiten doch gemeinsam an Verbesserungen mit dem Ziel Mehrwert für die Community zu schaffen. Und du hast doch super Input eingebaut. Das Modul rennt mit den neuen Features und die User sind glücklich ... was will man mehr als FHEMler und Entwickler.
Und das letzte Wort hat Jens sowieso als Maintainer.

LG

[DS_Starter]

@mumpitzstuff,
ich weiß nicht ob das Vorgehen zielführend ist. Bei einer derartigen Vermischung kann man als User (oder Applikation die die Daten verwendet) nicht sicher das Alter der entsprechenden Daten bestimmen, denn fc_time kann ja nur den Timestamp der Aktualisierung einer Datei enthalten. Ich würde das so nicht machen.

LG,
Heiko

[mumpitzstuff]

Ich bin schon weiter gekommen. Schaut euch das mal an bitte. Zumindest auf den ersten Blick sieht es meiner Meinung nach ganz gut aus. Die entsprechenden Readings wurden gesplittet und jeweils ein S oder L hinten dran gehangen. Somit kann zweifelsfrei bestimmt werden, ob ein Update notwendig ist doer nicht.

[DS_Starter]

Moin mumpitzstuff,

ah ja, das ist eine gute Idee .
Frage ... woher weiß ich ob das von mir benutzte Reading (ww, wwd, rad1h, etc....) den Datenstand 17:00 (timeL) oder Datenstand 23:00 (timeS) hat?

LG,
Heiko

[mumpitzstuff]

Gar nicht. Ist auch unerheblich. Da zuerst mosmix L und danach mosmix S verarbeitet werden sollten, werden die etwas ungenaueren Daten von mosmix L einfach überschrieben, wenn sie bei mosmix S ebenfalls vorliegen. Damit gewinnt mosmix S immer gegenüber L, was meiner Meinung nach genau das ist, was man letzten Endes braucht.

Um es zu testen kann ich aber mal eine Version bauen, in der auch die Daten getrennt vorliegen, das würde ich final aber eher vermeiden. So kann man aber eventuell sauberer testen bzw. vergleichen.

[DS_Starter]

Ja, ok. Man muß als Anwender nur wissen, welche Werte MosmixS UND MosmixL liefern (MosmixS gewinnt) und welche Werte NUR durch MosmixL geliefert werden.
Damit kann man dann das Aktualisierungsstand der jeweiligen Werte anhand der Readings timeL und timeS bestimmen.

[mumpitzstuff]

https://www.dwd.de/DE/leistungen/opendata/help/schluessel_datenformate/kml/mosmix_elemente_xls.html

Die graue Spalte ohne Header ist MOSMIX S und die andere rechts davon MOSMIX L. Dort kann man es direkt auf einen Blick sehen.

[matze1999]

Hallo, ist es möglich, die Größe der Gewitterwolke den anderen Wolken anzugleichen?

Du darfst diesen Dateianhang nicht ansehen.

matze1999