Neuigkeiten:

Am Sonntag den 8.12.2024 kann es ab ca. 8:00 Uhr zu kurzzeitigen Einschränkungen / Ausfällen bei den Diensten des FHEM Vereines kommen.
Die Server müssen mal gewartet und dabei neu gestartet werden ;)

Hauptmenü

Modul für DWD Open Data

Begonnen von jensb, 21 Januar 2018, 14:38:48

Vorheriges Thema - Nächstes Thema

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

Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

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
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

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
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

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

#1069
ZitatIch 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
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

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
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

mumpitzstuff

#1071
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
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

mumpitzstuff

#1073
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.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

mumpitzstuff

#1075
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

smoothlife

Hi zusammen,

ich versuche aktuell das Modul bei mir einzurichten aber leider bekomme ich beim Eintragen des Attributes IODev folgende Fehlermeldung:
 Du darfst diesen Dateianhang nicht ansehen.
Ich hab versucht es nach diesem Wiki-Eintrag nach zubauen: https://wiki.fhem.de/wiki/DWD_OpenData

Diese Befehle gingen noch alles ohne Probleme:
 define DWD DWD_OpenData
 attr DWD alertArea 111000000
 attr DWD forecastStation 99810
 attr DWD forecastDays 3
 attr DWD forecastWW2Text 1
 attr DWD event-on-update-reading state,fc_state,a_state


Erst ab dem einstellen der Attribute für den Weblink Generator komm nicht mehr weiter und bin mir auch nicht sicher was ich falsch mache.

Kann mir vielleicht jemand zusätzlich erklären was mit IODev gemeint ist?
Brauch ich dafür selbst etwas an bestimmter Hardware oder was muss ich da Eintragen?


KlaGho

Evtl. Musst du die korrigierte Version erst aus dem contrib Verzeichnis von ds_starter herunterladen.

Siehe #1064

Gruß gho

DS_Starter

ZitatKann mir vielleicht jemand zusätzlich erklären was mit IODev gemeint ist?
Brauch ich dafür selbst etwas an bestimmter Hardware oder was muss ich da Eintragen?
IODev ist der Verweis auf die Datenquelle, also das DWD-Device welches du angelegt hast und die Daten liefert.
Du stellst in dem Attribut den Namen des DWD Devices ein.

Hast du nach def Definition des DWD dein FHEM mal restarted?
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter