Open-Meteo

[hoetzgit]

@roe-dl

Hast Du Dir mal die API Open-Meteo / GitHub angesehen? Es werden u.a. auch DWD Daten angeboten.

Es sind (noch) keine MOSMIX Daten dabei, scheint aber in Planung zu sein #142

Grüße
Henry

[roe-dl]

Nein, ich habe es mir bisher nicht angesehen. Im Moment ist es zeitlich schwierig.

[hoetzgit]

@roe-dl

Hast Du Interesse an einem PR? Branch Status: MVP

[roe-dl]

Ja, natürlich.

Folgende Anmerkungen hätte ich:

• Da ich selbst gerade auch an dieser Datei gearbeitet habe, müssen wir erst einmal gucken, wie weit das noch kompatibel ist.
• Das Einlesen der JSON-Datei unterscheidet sich von dem wget() nur in der nachfolgenden Konvertierung. Also würde ich es begrüßen, wenn wget() dort für den Internetzugriff benutzt würde.
• Ich habe etwas aufgeräumt und die gemeinsamen Teile der verschiedenen Klassen in einer Basisklasse BaseThread zusammengefaßt. Es wäre sinnvoll, wenn auch die OPENMETEO-Klasse jetzt diese Basisklasse benutzt.
• Ich sehe da jetzt keinen Import für OPENMETEO. Habe ich das übersehen? Auf jeden Fall wäre es sinnvoll, wenn die Datei auch geladen werden kann, wenn der Import fehlschlägt. Da sollte es eine Fehlermeldung im Log geben, die übrigen Sachen aber geladen werden.
• Für die geographischen Koordinaten habe ich gerade eine Gruppe group_coordinate erfunden, damit das in WeeWX auch sauber verbarbeitet wird. Als Maßeinheit habe ich die vorhandene Einheit degree_compass genommen. Das klingt zwar komisch, aber die Einheit heißt wahrscheinlich nur deshalb so, um sie von degree_C usw. zu unterscheiden.

[hoetzgit]

Ja, ich habe bemerkt, dass Du fleißig bist. Deshalb hab ich auch jetzt schon angefragt, damit das nicht zu weit auseinander läuft. Was sollte ich jetzt noch vor einem PR erledigen? Soll ich noch auf einen günstigen Stand von Dir warten?

• Das Einlesen der JSON-Datei unterscheidet sich von dem wget() nur in der nachfolgenden Konvertierung. Also würde ich es begrüßen, wenn wget() dort für den Internetzugriff benutzt würde.

HO: ok

• Ich habe etwas aufgeräumt und die gemeinsamen Teile der verschiedenen Klassen in einer Basisklasse BaseThread zusammengefaßt. Es wäre sinnvoll, wenn auch die OPENMETEO-Klasse jetzt diese Basisklasse benutzt.

HO: ich versuche es wenn ich es kapiere

• Ich sehe da jetzt keinen Import für OPENMETEO. Habe ich das übersehen? Auf jeden Fall wäre es sinnvoll, wenn die Datei auch geladen werden kann, wenn der Import fehlschlägt. Da sollte es eine Fehlermeldung im Log geben, die übrigen Sachen aber geladen werden.

HO: Welchen Import meinst Du? Fehlende Daten oder Fehler erzeugen auch Fehlermeldungen

• Für die geographischen Koordinaten habe ich gerade eine Gruppe group_coordinate erfunden, damit das in WeeWX auch sauber verbarbeitet wird. Als Maßeinheit habe ich die vorhandene Einheit degree_compass genommen. Das klingt zwar komisch, aber die Einheit heißt wahrscheinlich nur deshalb so, um sie von degree_C usw. zu unterscheiden.

HO: Koordinaten benutze ich bisher nur für den API Call und werte zurück gelieferte Koordinaten (bisher) nicht aus

Edit: Nicht mit openmeteo verwechseln, es ist open-meteo

[roe-dl]

• BaseThread:
  • Bei der Klassendefinition threading.Thread durch BaseThread ersetzen.
  • Da run bereits in der Basisklasse definiert ist, kann es in der Kindklasse entfallen.
• Import
  • Du hattest mich auf eine Open-Meteo-Bibliothek auf Github hingewiesen. Ich habe es so verstanden, daß Du diese Bibliothek benutzen willst. Wenn das so ist, muß sie ja auch irgendwo mit import eingebunden werden. Das kann man dann so schreiben:

    try:
        import openmeteo
        has_openmeteo=True
    except ImportError:
        has_openmeteo=False
    

    Wobei hier openmeteo ein Platzhalter ist, weil ich nicht weiß, wie es richtig heißt.
• Solltest Du das Github-Archiv von Openmeteo nur Inspiration benutzt und nicht direkt eingebunden haben, dann kommt es auf den Copyright-Hinweis an, damit jeder sieht, wo man sich bedient hat. Also das wäre dann zum Beispiel eine Danksagung an das Vorbild mit Namensnennung und Link.

[hoetzgit]

Das GitHub Repository ist nur der Sourcecode der API. Es gäbe noch eine Python Schnittstelle für die API, aber diese benutzte ich ja nicht. D.h. ich mache nur einen API Call Richtung diesen hier beschriebenen Endpoint (/v1/dwd-icon), also keine Verwendung von "Fremdcode".

z.Z. ist mein Branch aktuell zu Deinem master. Dann würde ich morgen noch die Klassendefinitionen anpassen?

Edit: Auf Open-Meteo habe ich im Header hingewiesen, passt das so?

[roe-dl]

Ich würde noch auf dieses Github-Repository https://github.com/open-meteo/open-meteo hinweisen.

Außerdem müßtest Du angesichts der vielen Zeilen, die Du hinzugefügt hast, Deinen Namen auch in der zweiten Zeile der Datei (also dem Copyright-Hinweis) hinzufügen.

Ich kann diese Zusammenführung mit dem BaseThread übrigens auch erledigen, wenn Du möchtest.

Ich fasse dwd.py erst einmal nicht an.

Hast Du den Code bei Dir ausgiebig getestet?

[hoetzgit]

Ich würde noch auf dieses Github-Repository https://github.com/open-meteo/open-meteo hinweisen.

ist bereits enthalten

Außerdem müßtest Du angesichts der vielen Zeilen, die Du hinzugefügt hast, Deinen Namen auch in der zweiten Zeile der Datei (also dem Copyright-Hinweis) hinzufügen.

Nur wenn Du darauf bestehst. Es ist Dein Modul und Deine Arbeit. Ich habe ja auch nur versucht, mich an Deiner Codebasis zu orientieren. Wenn ich Dich unterstützen kann, ist das ok.

Ich kann diese Zusammenführung mit dem BaseThread übrigens auch erledigen, wenn Du möchtest.

Ich hab's mal versucht.

Hast Du den Code bei Dir ausgiebig getestet?

Ja, aber ich denke Du machst sicher ein Review. Du könntest auch bei Dir einen entsprechenden Branch anlegen und wir machen den PR dort?

[roe-dl]

Ich habe es mir wegen eventueller Nebenwirkungen angesehen und nichts Gefährliches gefunden. Also würde ich sagen, Du machst mal den PR und ich füge den ein.

Für meine Testumgebung bräuchte ich ein Konfigurationsbeispiel.

Und bitte die Doku ergänzen! (README.md)

[hoetzgit]

Eine Unsicherheit habe ich noch bei interval. Die API liefert lt. Doku Momentanwerte und Durchschnittswerte der vorangegangenen Stunde. Welchen Wert trägt man da am besten ein?

gibst Du mir mit der Doku ein bisschen Zeit?

[roe-dl]

Eine Unsicherheit habe ich noch bei interval. Die API liefert lt. Doku Momentanwerte und Durchschnittswerte der vorangegangenen Stunde. Welchen Wert trägt man da am besten ein?

Eine Stunde. Mit der passenden Einheit, also eine 1 zusammen mit hour oder 60 zusammen mit minute.

[hoetzgit]

Meine Konfiguration:

[Station]
    
    # Description of the station location
    location = PWS Weiherhammer
    
    # Latitude in decimal degrees. Negative for southern hemisphere
    latitude = 49.632270
    # Longitude in decimal degrees. Negative for western hemisphere.
    longitude = 12.056186
    
    # Altitude of the station, with the unit it is in. This is used only
    # if the hardware cannot supply a value.
    altitude = 394, meter    # Choose 'foot' or 'meter' for unit

    [[forecast]]
        icon_set = dwd

    [[OPENMETEO]]
        enabled = True
        prefix = om_
        debug = 3 # 0 = no debug infos, 1 = min debug infos, 2 = more debug infos, >3 = max debug infos, optional, default 0
        log_success = True
        log_failure = True

[roe-dl]

Ohne Konfigurationseintragungen für Openmeteo läuft es bei mir nach wie vor durch. Soweit Ok.

Fehlt der Abschnit [station] gibt es folgende Fehlermeldung und das Programm bricht ab:

Traceback (most recent call last):
  File "bin/user/dwd.py", line 1642, in <module>
    sv = DWDservice(None,conf_dict)
  File "bin/user/dwd.py", line 1496, in __init__
    self._create_openmeteo_thread('current', openmeteo_dict)
  File "bin/user/dwd.py", line 1555, in _create_openmeteo_thread
    self.threads[thread_name]['thread'] = DWDOPENMETEOthread(thread_name,
  File "bin/user/dwd.py", line 1088, in __init__
    altitude.split(',')
AttributeError: 'NoneType' object has no attribute 'split'

Hier müßtest Du mögliche Konfigurationsfehler abfangen und mit einer aussagekräftigen Meldung versehen, welche Werte fehlen.

Ich selbst verwende die Funktion weniger für Werte an meinem Wohnort (denn die kann ich selbst messen), sondern für Ausflugsziele in der Gegend. Deswegen kann man in der Konfiguration zum einen überhaupt Orte angeben und zum anderen mehrere. Von daher erscheint es mir nicht ausreichend, wenn nur die Koordinaten aus dem [station]-Abschnitt abgefragt werden können.

Beispiel

Und schließlich fällt mir noch der Unterstreichstrich im Präfix Deiner Konfiguration auf. Die Belchertown-Skin benutzt bei der MQTT-Übertragung den Unterstreichstrich als Trennzeichen zwischen Meßgrößenname und Maßeinheit. Das kommt durcheinander, wenn es mehrere Unterschreichstriche gibt. Deswegen hatte ich diesen Trick mit dem Großbuchstaben angewandt.

dateTime (ohne Zusätze) wäre der "offizielle" Zeitstempel des empfangenen Datensatzes, nicht der Abfragezeitpunkt.

[roe-dl]

Ich vermute mal, wenn man die Höhe nicht übermittelt, dann bekommt man weniger genaue Daten. Ansonsten müßte ich nachdenken, was der Satz genau sagen will. Mir fallen jetzt verschiedene Interpretationen ein.

Bei

Dann würden wir aber um die eine API zu benutzen die andere API fragen.

Bei DWD-CDC und ZAMG mache ich es genau so. Innerhalb des Konstruktors __init__() werden die Stationsmetadaten, darunter auch die Höhe, abgefragt und gespeichert.

Man könnte es ja dem Benutzer überlassen. Wenn er eine Höhe einträgt, nehmen wir die. Wenn er keine Höhe einträgt, fragen wir sie einmalig über das andere API ab.

[hoetzgit]

Man könnte es ja dem Benutzer überlassen. Wenn er eine Höhe einträgt, nehmen wir die. Wenn er keine Höhe einträgt, fragen wir sie einmalig über das andere API ab.

Das hört sich doch gut an. Habe einen PR mit der (hoffentlich) korrekten Abfrage der Koordinaten und der dateTime Korrektur gemacht.

Edit: Habe noch einen mächtigen "Bock" korrigiert

[roe-dl]

Test lief durch.

[hoetzgit]

wie möchtest Du mit den verschiedenen Locations vorgehen? Möchtest Du Dir das mit mir nochmal antun und ich versuche das in Absprache mit Dir? Oder willst Du dies lieber selbst machen? Du entwickelst ja viel. Ich hätte da nur eine Chance, wenn das Grundprinzip - wie Du die Daten holst und verarbeitest - sich nicht zu sehr ändert.

[roe-dl]

Die Frage, die sich mir zuerst stellt, ist, wie man die Konfiguration für die eigene Station und die Konfiguration für beliebige Positionen in der Konfigurationsdatei miteinander verknüpft. Die Variante mit dem Unterabschnitt locations finde ich schon einmal passend.

Und wenn ich so nachdenke, dann würde ich Openmeteo in der Konfiguration aus dem Abschnitt für den Deutschen Wetterdienst herausnehmen und ihm einen eigenen Abschnitt gönnen.

Vielleicht so:

[OpenMeteo]
    [[current]]
        [[[ThisStation]]]
            enable = True
            prefix = om
        [[[locations]]]
            [[[[blabla]]]]
                latitude = ...
                longitude = ...
                altitude = ...
                usw. wie von Dir beschrieben

Mir fällt dann noch auf, daß der Name "Open-Meteo" von verschiedenen Leuten für unabhängige Projekte genutzt wird, die sich irgendwann noch ins Gehege kommen könnten:

• https://open-meteo.com/ von Patrick Zippenfenig aus der Schweiz
• https://openmeteo.org/ von einem griechischen Projekt
• http://www.openmeteo.com/location/de/neuseenland-wetter von Andreas Gärtig aus Leipzig

[roe-dl]

Warum ist eigentlich dwd-icon in der URL fest codiert und nicht nutzer-konfigurierbar? Openmeteo scheint da ja verschiedene Modelle anzubieten, und das API ist überall in etwa gleich. Wir müßten auch deutlich darauf hinweisen, daß es sich hier um berechnete Werte aus Vorhersagemodellen handelt und nicht um Meßwerte wie bei DWD-POI, DWD-CDC und ZAMG. Beides ist berechtigt, aber man sollte wissen, was man gerade vor sich hat.

[hoetzgit]

Warum ist eigentlich dwd-icon in der URL fest codiert und nicht nutzer-konfigurierbar? Openmeteo scheint da ja verschiedene Modelle anzubieten, und das API ist überall in etwa gleich.

Na weil Dein Service dwd.py heißt ;-) Und es ist (noch immer) nur ein (ausbaufähiger) Prototyp

Wir müßten auch deutlich darauf hinweisen, daß es sich hier um berechnete Werte aus Vorhersagemodellen handelt und nicht um Meßwerte wie bei DWD-POI, DWD-CDC und ZAMG. Beides ist berechtigt, aber man sollte wissen, was man gerade vor sich hat.

Es ist mir noch nicht 100% klar mit den Werten. Ich hatte mal ein wenig in den Issues gelesen, Daten stammen wohl teilweise aus konkreten Messergebnissen (der current_weather Teil) und teilweise sind sie auch dort aus berechneten Werten, wenn z.B. keine Sensordaten vorhanden sind. Hourly Daten sind berechnet.

Edit: Hätte sich doch ein dev Branch angeboten. Mir war klar, dass Du da einen besseren Überblick hast als ich.

[roe-dl]

dwd.py und der Name weewx-DWD waren wohl zu kurz gedacht. Jetzt ist es aber für einen zukunftsweisenderen Namen zu spät.

Warum ich denke, daß es berechnete Daten sind, ist das dwd-icon in der URL. ICON ist ein Wettermodell, das vom DWD berechnet wird. Davon hatte ich zuvor schon gehört. Da gehen natürlich Meßwerte ein, aber die Zahlen sind am Ende alle berechnet. Dasselbe gilt für die anderen Wettermodelle, die da noch erwähnt werden.

[hoetzgit]

dwd.py und der Name weewx-DWD waren wohl zu kurz gedacht. Jetzt ist es aber für einen zukunftsweisenderen Namen zu spät.

Dabei ist dwd.py ja noch nicht sooo alt, noch ist die Chance da, meinst Du nicht?

Warum ich denke, daß es berechnete Daten sind, ist das dwd-icon in der URL. ICON ist ein Wettermodell, das vom DWD berechnet wird. Davon hatte ich zuvor schon gehört. Da gehen natürlich Meßwerte ein, aber die Zahlen sind am Ende alle berechnet. Dasselbe gilt für die anderen Wettermodelle, die da noch erwähnt werden.

Ja ich weiß was Du meinst. Momentan gibt es nur diesen DWD Daten Endpoint wenn ich's richtig gesehen habe. Auch sind die einzelnen Modelle nicht separat abrufbar, sondern nur die Kombinationen aus den verschiedenen ICON* Modellen. Dann auch noch als Mischung aus Modelldaten und Istwerten. Wenn Du mal Zeit und Lust hast, in der Doku ist es ganz gut beschrieben. Du verstehst das besser als ich.

Willst Du nicht doch einen dev Branch anlegen? Dann müsste man sich nicht zu sehr um alle User sorgen und die Software könnte reifen.

Edit: Wenn ich so überlege, ich habe da viel zu wenig Background. Dabei hat mich nur das (sehr oft) nicht passende Icon in der Belchertown skin gestört und ich habe nach Quellen für weitere Istwerte gesucht. POI/CDC ist da schon sehr hilfreich. Irgendwann möchte ich das Bild meiner AllSky Kamera auswerten, um die aktuellen Bedingungen besser anzuzeigen.

[roe-dl]

Das nicht passende Icon in der Belchertown-Skin ist auch immer wieder mein Thema gewesen. Ich habe jetzt bei Ott-Hydromet ein Meßgerät angefragt, weiß aber noch nicht, wie sehr es das Budget sprengen wird.

https://api.open-meteo.com/v1/gfs für NOAA oder https://api.open-meteo.com/v1/meteofrance gibt es zum Beispiel auch, wenn ich das richtig verstanden habe.

[roe-dl]

Willst Du nicht doch einen dev Branch anlegen? Dann müsste man sich nicht zu sehr um alle User sorgen und die Software könnte reifen.

Bis jetzt weiß noch niemand davon, weil es noch keine Dokumentation gibt. Also keine Gefahr.

[roe-dl]

Was hältst Du von dieser Variante?

1d10125

https://github.com/roe-dl/weewx-DWD/tree/openmeteo-current

Config:

[Open-Meteo]
    [[current]]
        [[[ThisStation]]]
            enabled = True
            prefix = om_
            debug = 3 # 0 = no debug infos, 1 = min debug infos, 2 = more debug 
            log_success = True
            log_failure = True
        [[[locations]]]
            ...

[roe-dl]

Das verwendete Datenmodell würde ich eher als Konfigurationsparameter denn als Zwischenüberschrift sehen. Also so etwas wie model = dwd-icon in den Abschnitt eines konkreten Ortes. Dann kann man das auch schneller ändern, wenn einen das ankommt. Man muß dann nicht einen ganzen Abschnitt in einen anderen Abschnitt verschieben.

Wenn ich für den gleichen Ort z.B. unterschiedliche Modelle haben möchte? Da wäre ich dann wieder bei [[DWD-Icon]], [[DWD-MOSMIX]] Sections mit den Locations u.a. darunter.

Da die Abschnittsüberschrift frei ist, ist das kein Hinderungsgrund, etwa so (Anzahl der eckigen Klammern jetzt beliebig):

[[[Ort-Icon]]]
    model = dwd-icon
    latitude = ...
    longitude = ...
    ...
[[[Ort-MOSMIX]]]
    model = dwd-mosmix
    ...

[roe-dl]

Und wenn ich das so lese, was ich selbst geschrieben habe, dann könnte man die Konfigurationsstruktur komplett anders aufbauen. Man beginnt nicht mit dem Provider sondern mit dem Namen des Moduls. In der nächsten Ebene kommen die ganzen Orte und darunter als Konfigurationsoptionen, was damit zu tun ist. Oder man schaltet noch eine Ebene dazwischen, die Werte, Vorhersagen und Warnungen unterscheidet.

[hoetzgit]

Das verwendete Datenmodell würde ich eher als Konfigurationsparameter denn als Zwischenüberschrift sehen. Also so etwas wie model = dwd-icon in den Abschnitt eines konkreten Ortes. Dann kann man das auch schneller ändern, wenn einen das ankommt. Man muß dann nicht einen ganzen Abschnitt in einen anderen Abschnitt verschieben.

Wenn ich für den gleichen Ort z.B. unterschiedliche Modelle haben möchte? Da wäre ich dann wieder bei [[DWD-Icon]], [[DWD-MOSMIX]] Sections mit den Locations u.a. darunter.

Da die Abschnittsüberschrift frei ist, ist das kein Hinderungsgrund, etwa so (Anzahl der eckigen Klammern jetzt beliebig):

[[[Ort-Icon]]]
    model = dwd-icon
    latitude = ...
    longitude = ...
    ...
[[[Ort-MOSMIX]]]
    model = dwd-mosmix
    ...

ah verstanden, dass ist gut

[hoetzgit]

Das geht mir auch so. Also kann ich die Bitte gleich wieder zurückgeben.

Ich kann von Dir nur lernen und schätze daher jeden Kommentar sehr.

[hoetzgit]

Und wenn ich das so lese, was ich selbst geschrieben habe, dann könnte man die Konfigurationsstruktur komplett anders aufbauen. Man beginnt nicht mit dem Provider sondern mit dem Namen des Moduls. In der nächsten Ebene kommen die ganzen Orte und darunter als Konfigurationsoptionen, was damit zu tun ist. Oder man schaltet noch eine Ebene dazwischen, die Werte, Vorhersagen und Warnungen unterscheidet.

Dann hat es sich schon gelohnt, dass wir ein bisschen Brainstorming betrieben haben.

[hoetzgit]

Was hälts Du eigentlich davon, eine Klassensammlung bspw. unter sowas wie "weewx-external" zusammenzufassen? Dann bist Du völlig frei, was in diesen Klassen passiert. Das Prinzip bleibt die zur Verfügungstellung externer Daten. Eine zusätzliche Schnittstelle per MQTT könnte man dort auch machen. So könnten auch endlich Textfelder (dazu habe ich übrigens gleich noch eine Frage an Dich) im Broker landen. Icons, Wetterbescheibung etc. Die Vorhersagen könnten dort implementiert werden, man kann JSON's, HTML Code, also unerschöpflich für irgendeine Schnittstelle (File, Broker ...) generieren.

Jetzt noch eine Frage. Für die aktuellen Bedingungen (Icon, Text ...). In der Belchertown skin wollte ich mir für den Anfang ein JSON Template mit den Daten icon und icontitle und ein paar Werten generieren. Dazu wollte ich bspw. $current.om_Icon.raw oder $current.om_Snow.raw nutzen. Offensichtlich stehen aber die (zumindest manche) raw Daten per $current/$latest ... nicht zur Verfügung. Bei mir zumindest trifft das auch auf die POI/CDC Daten zu. Hab ich da was verhunzt? Dann habe ich überlegt, dass mir das mit JSON nicht gefällt und wollte die Daten lieber in den MQTT Broker schicken. Kann man einen (dann eben eigenen) Fork von weewx-mqtt so modifizieren, dass man auf den Inhalt der current Objekte zugreifen kann und die Textfelder auch mit in den Broker sendet? Dann könnte ich auch die Textfelder der Skin per MQTT und jQuery updaten. Oder eben über alternative Methoden, aber im Prinzip hätte ich gerne auch Textfelder im Broker

[roe-dl]

Ich denke mal, wir sollten die Programmiergesichtspunkte und die konkrete Nutzung in Skins in verschiedenen Threads halten, sonst kommen wir irgendwann durcheinander.

Mit so etwas ähnlichem wie Klassensammlung habe ich schon angefangen, als ich dwd.py und capwarnings.py geschrieben habe. Letztere faßt schon die Warnmeldungen von DWD und BBK zusammen. Beim Blick in die Vorhersagen von Open-Meteo würde ich das auch mit dwd-mosmix zusammenführen wollen.

[hoetzgit]

Ich denke mal, wir sollten die Programmiergesichtspunkte und die konkrete Nutzung in Skins in verschiedenen Threads halten, sonst kommen wir irgendwann durcheinander.

gerne, wo am besten?

Mit so etwas ähnlichem wie Klassensammlung habe ich schon angefangen, als ich dwd.py und capwarnings.py geschrieben habe. Letztere faßt schon die Warnmeldungen von DWD und BBK zusammen. Beim Blick in die Vorhersagen von Open-Meteo würde ich das auch mit dwd-mosmix zusammenführen wollen.

Ja, das Prinzip passt ja auch. Nur eben wg. der Namensgebung

[roe-dl]

Ich denke mal, wir sollten die Programmiergesichtspunkte und die konkrete Nutzung in Skins in verschiedenen Threads halten, sonst kommen wir irgendwann durcheinander.

gerne, wo am besten?

Na mach doch einfach noch ein Diskussionsthema auf.

[roe-dl]

Wie wäre es damit?

50080e9

Konfigurationsbeispiel dazu:

[WeatherServices]
    [[current]]
        [[[ThisStation]]]
            enable = True
            prefix = om_
            debug = 3 # 0 = no debug infos, 1 = min debug infos, 2 = more debug infos, >3 = max debug infos, optional, default 0
            log_success = True
            log_failure = True
            provider = Open-Meteo

        [[[11361]]]
            prefix = austria
            provider = ZAMG

        [[[10688]]]
            prefix = hoetzgit
            provider = DWD
            model = POI

Wenn es einen Schlüssel station gibt, dann wird dessen Wert als Stations-Code verwendet, anderenfalls die Abschnittsüberschrift. Wenn der Wert Here oder ThisStation lautet, werden die Koordinaten der Wetterstation verwendet.

In WeeWX heißt der Schlüssel für das Ein- und Ausschalten eines Konfigurationsabschnittes enable, nicht enabled, siehe weewx.conf.

[hoetzgit]

Guten Morgen. Dadurch, dass Du für dwd-mosmix den Endpoint v1/forecast verwendest, habe ich jetzt auch Deine Rückfrage warum dwd-icon fest codiert ist verstanden. Ich hatte den Endpoint auf Grund seines Namens überhaupt nicht auf dem Schirm als ich den PR für dwd.py gemacht habe. Dieser Endpoint ist ja viel besser geeignet, da er viel flexibler ist. U.a. die Auswahl der Modelle. Current ist auch dabei und auch visibility. Das einzige was wohl nicht dabei ist, ist Snowfall Height, bei mir aktuell eh immer Null. Wollen wir auch in dwd.py v1/forecast statt v1/dwd-icon verwenden? Die Werte sind wahrscheinlich gleich und die Abfrage ist flexibler.

Edit: Ich habe eine Frage zu MOSMIX in einer neuen Diskussion gestellt. Deine Antwort können wir auch auf Open-Meteo Daten beziehen. Ich habe bis jetzt immer bei einem Abfragezeitpunkt z.B. 12:17 den Datensatz von 12:00 genommen.

[roe-dl]

Die Frage ist ja, welchen von beiden nehmen wir für das Wolkensymbol?

[hoetzgit]

Die Frage ist ja, welchen von beiden nehmen wir für das Wolkensymbol?

bei "MOSMIX"? Effective hört sich immer gut an, alles andere klingt dann in diesem Zusammenhang als "theoretisch". Also würde ich Neff nehmen. Die anderen Modelle scheinen nur "Gesamtbedeckung" zu verwenden. Bin jetzt auch unsicher

[hoetzgit]

Bei Open-Meteo ist doch dann auch cloudcover gleich Neff oder? Die unterschiedlichen Höhen werden ja separat auch mit angegeben.

[roe-dl]

Ich hätte nun gerade 'N' vermutet, weil 'Neff' aus mehreren Werten zusammengesetzt ist, in die auch die unterschiedlichen Höhen eingehen.

[hoetzgit]

Wenn ich versuche mit meinem laienhaften Verständnis, gekoppelt mit schlechtem English den Satz von oben (Erklärung Clouds bei Open-Meteo) zu interpretieren, dann sind Clouds (cloudcover) berechnete Werte aus dem prozentualen Anteil der mit Wolken auf verschiedenen Höhenebenen. Das hört sich doch (für mich zumindest) ähnlich der Erklärung des DWD zum Neff an oder?

Edit. Wenn ich dann noch versuche den Satz weiter zu verstehen, dann sind eigentlich die untersten Wolkenebenen die interessantesten, weil man die eher wahrnimmt. D.h. das Icon müsste sich eher an der Wahrnehmung orientieren?

[roe-dl]

Ich habe die Erweiterungen in den Hauptzweig übernommen.

b1c53d0

[hoetzgit]

Alles klar, hole ich in mein Testsystem. Setz bitte mal gedanklich mein Issue #36 auf hold. Ich bin gerade drüber das zu verstehen warum das bei mir so war (ist). Aktuell bin ich auf dem Stand, dass es sich wohl um ein Userproblem handelt :-(

[hoetzgit]

Finde ich toll, dass Du das alles so umgesetzt hast. Spätestens nächste Woche werde ich die ganzen neuen Sachen versuchen bei mir einzubauen. Vielen Dank.

[roe-dl]

Danke für die Zwischenmeldung. Ich bin gespannt.

[hoetzgit]

Du hast bei der Auswertung des Modells in dwd-mosmix für Open-Meteo schon den evtl. nötigen Switch von v1/dwd-icon oder v1/forecast drin. Ich glaube das fehlt noch in weatherservices.py. Evtl auch noch visibility wieder mit rein?

[roe-dl]

Open-Meteo wünscht sich einen Link auf Anwendungen, die das API nutzen. Das habe ich gestern erledigt und den gewünschten PR dort eingereicht.

Open-Meteo-Startseite

[hoetzgit]

Hallo, Du bist fleißig am Bug fixen sehe ich. Hast Du schon die Anpassungen bei Dir im Einsatz? Ich frage, weil ich versuche die Woche auch zu implementieren und ich funktionierende Konfigs suche. Ich werde aber auch nach Doku vorgehen, evtl. sehe ich noch ein paar Stolpersteine - dann aus Benutzersicht. Hast Du so etwas wie eine kleine Roadmap, dann kann ich mir bestimmt einige Fragen sparen, die ich noch habe. VG

[teffi71]

Hallo @roe-dl & @hoetzgit !

ich versuche mit Eurer Erweiterung (herzlichen Dank für Eure Entwicklung) die Wetterstation in meinem Wohnmobil mit extra "current" Wetterdaten und Wettervorhersage in der Belchertown Skin zu realisieren.
Mein Internetrouter im WoMo liefert mir die aktuellen GPS Koordinaten, die ich per MQTT in WeeWX / Belchertown einbinde. Da meine Wetterstation im WoMo nur eine EcoWitt GW1100 erhalte ich nur Temp, Baro & Humidity.
Die aktuellen Wetterdaten würde ich gerne um Wind-, Regen- und Sonnen-Infos ergänzen.
Dazu möchte ich auch die Wettervorhersage für den gerade aktuellen Ort einbinden.

Ich habe alles installiert und bekomme auch "eine" Wettervorhersage für "Döbeln" und keine zusätzlichen aktuellen Daten.

Daher gehe ich davon aus, dass meine Konfiguration in weewx.conf fehlerhaft ist.
Könnt Ihr mir weiterhelfen?

Hier meine weewx.conf:

[WeatherServices]
path='/etc/weewx/skins/Belchertown/dwd'
[[current]]
[[[ThisStation]]]
# actual readings out of the forecast for the location of this station
enable = True
prefix = om_
debug = 3
log_success = True
log_failure = True
provider = Open-Meteo
model = dwd-icon
observations = air,wind,gust,precipitation,solar
# Konfiguration für dwd-mosmix
[[forecast]]
# Speicherort der Symbole auf dem Web-Server
icons = '../images'
# zu verwendender Symbolsatz: belchertown, dwd, aeris
icon_set = belchertown
# für welche Orientierungen soll die HTML-Datei erzeugt werden?
orientation = h,v
# Sollen die Meßgrößensymbole in die Tabelle aufgenommen werden?
#show_obs_symbols = True # optional
# Soll die Meßgrößenbeschreibung in die Tabelle aufgenommen werden?
#show_obs_description = False # optional
# Soll der Ortsname über die Tabelle geschrieben werden?
show_placemark = True # optional
# Konfiguration für die --belchertown Option von dwd-mosmix
[[Belchertown]]
# Name des Abschnittes der Belchertown-Skin in [StdReport]
section = Belchertown
# Warndatei aus dem Abschnitt [[warnings]]
#warnings = DL
# Vorhersagedatei aus dem Aufruf 'dwd-mosmix'
#forecast = P0291
# schließe Warnungen ein, die die angegebene Zahl von Sekunden in
# der Zukunft gültig werden (optional)
#include_advance_warnings = 0
# Quelle für Luftqualtitätsdaten (optional)
# mögliche Werte: aeris, ubaXXXX
aqi_source = open-meteo
# Sprache für die Himmelsrichtungen (optional)
# mögliche Werte: de, en, fr, it, cz, es, nl, no, gr
#compass_lang = 'de' # optional

und ein direkter Aufruf von dwd-mosmix:

teffi@rvwx:~ $ sudo dwd-mosmix --weewx --open-meteo=icon_eu --belchertown -v
Using configuration file /etc/weewx/weewx.conf
ERROR Belchertown config KeyError 'forecast'
-- configuration data ----------------------------------
log success: True
log failure: True
target path: /etc/weewx/skins/Belchertown/dwd
horiz. tab: True
vertical tab: True
icon set: 4
station location: lat 52.0 lon 9.0 alt 29.8704
aeris api id: None
aeris api secret: None
SQLITE_ROOT: /var/lib/weewx

Traceback (most recent call last):
File "/usr/local/bin/dwd-mosmix", line 2785, in
lat = float(loc[0])
ValueError: could not convert string to float: 'Döbeln'

Danke im Voraus für jede Hilfestellung!

P.S.: ich sehe gerade, dass "station location: lat 52.0 lon 9.0 alt 29.8704" nicht die Koordinaten des WoMo-Routers sind, sondern die händisch eingetragenen in weewx.conf ... Hmm ...

[teffi71]

Möglicherweise ist es eine Frage der Geduld.

So war es ;)

[teffi71]

Die Dateien mit geo am Anfang enthalten übrigens Angaben über den Ort.

Das schaue ich mir gleich mal an. Vielleicht kann ich das noch einbinden.

[teffi71]

mosmix scheint AQI über Aeris abzurufen.
INFO successfully downloaded https://api.aerisapi.com/airquality/closest?p=52.152493,9.929383&format=json&radius=50mi&limit=1&client_id=zyx&client_secret=xyz
Hier werden wohl die fixen Koordinaten der Wetterstation verwendet.

Kann man dies in dem dwd-mosmix-call.sh.tmpl fixen? [Edit: habe eben # command 'aqi' converts to Belchertown format in dwd-mosmix gefunden und damit denke ich ... nein]

Oder sollte man etwas in dwd-mosmix verändern?

    def download_aeris(self, what):
        if what=='aqi':
            url = (
                "https://api.aerisapi.com/airquality/closest?p=%s,%s&format=json&radius=50mi&limit=1&client_id=%s&client_secret=%s"
                % (self.latitude, self.longitude, self.forecast_api_id, self.forecast_api_secret)
                )
        else:
            return []

Ich glaube, dies ist das erste Mal das self.latitude auftaucht:

        # almanac
        stn = config_dict.get('Station',dict())
        self.latitude = float(stn.get('latitude'))
        self.longitude = float(stn.get('longitude'))

[roe-dl]

Von wem AQI heruntergeladen wird, kann man beim Aufruf von dwd-mosmix als Parameter übergeben. Das muß nicht Aeris sein.

[teffi71]

Verstanden bzgl. AQI Provider.

[roe-dl]

Diesen Diskussionsstrang mache ich jetzt mal zu, sonst enthält er zu viele verschiedene Themen auf einmal. Selbst das Thema Wohnmobil hätte schon besser in einen eigenen Strang gepaßt. Jetzt geht's noch um AQI. Dazu siehe #56.