Datenübertragung zu AWEKAS

1. offizieller Beitrag

    Hallo zusammen,


    ich nutze zur Übertragung meiner Wetterdaten zu AWEKAS eine eigene Software unter Verwendung des Protokolls WU-Fastlink. Das Übertragungsintervall beträgt 5 min.


    Ich habe hierbei 2 Probleme, die ich gerne diskutieren möchte:


    1) Fehlermeldung bei Nullung der Tagesniederschlagsmenge:

    Ich setze um 0 Uhr die Tagesniederschlagsmenge zurück, d.h., mit der ersten Datenübermittlung nach 0 Uhr wird eine Tagesniederschlagsmenge von 0 mm gesendet. Daraufhin erhalte ich die Fehlermeldung „rainrate wrong - [negative Zahl]“ (z.B.: rainrate wrong - -3.6). Die Uhr des Webservers, auf dem die Software läuft, ist korrekt synchronisiert.

    Was führt zu dieser Fehlermeldung?


    2) häufig keine Rückmeldung bei Datenübermittlung:

    Bei der Datenübermittlung per WU-Fastlink kommt häufig keine Antwort zurück, d.h. der Request läuft in ein Timeout. Dies passiert bei einem Sendeintervall von 5 min ca. 10 - 20 mal pro Tag. Was ist hier das Problem und was kann ich tun, um diese Fehlerquote zu reduzieren? Gerne würde ich auch statt dem WU-Protokoll ein AWEKAS-eigenes Protokoll verwenden, vorausgesetzt, es funktioniert mit der GET- oder POST-Methode und Query-String. Jedoch habe ich hierzu keine Informationen gefunden, speziell keine Spezifikation.


    Viele Grüße

    Martin


    AWEKAS-ID: 31481

    • Offizieller Beitrag

    Hallo


    Die Tagesniederschlagsmenge ist ein Zähler welcher um Mitternacht auf 0 gestellt wird und die Summe des Niederschlags seit 0h darstellt.

    Die Regenrate kann nicht negativ sein. Die Regenrate gibt den Gefallenen Niederschlag in den letzten 5 Minuten hochgerechnet auf eine Stunde an. 3.2l/h bedeutet, dass sollte es in dieser Intensität weiterregnen in einer Stunde der Niederschlag von 3,2mm gemessen wird.


    Frage 2: Sendest Du http oder https? Sieht eventuell nach einem Verbindungsproblem aus. Die Anfragen werden auf verschiedene Server verteilt, darum ist es unwahrscheinlich das diese so oft nicht erreichbar sind. Sendest Du genau um 0 und 0 Sek oder zeitversetzt?

    Hallo Othi,


    vielen Dank für die Rückmeldung.


    zu 1:

    die Zusammenhänge zwischen Tagesniederschlagsmenge und Regenrate sind mir bekannt. Ich übertrage beides, die Tagesniederschlagsmenge als Zähler in inch (WU-Protokoll) und die Regenrate in inch/h, gerechnet als delta Niederschlagsmenge / delta Zeit. Bei Nullung der Tagesniederschlagsmenge um Mitternacht erhalte ich eben halt die Fehlermeldung zur falschen Regenrate. Letzte Nacht z.B. um 00:03:33 „rainrate wrong - -73.2“. Das war die erste Sendung nach 0 Uhr mit genullter Tagesniederschlagsmenge. Die zitierte Fehlermeldung ist der HTTP-Response von AWEKAS auf meinen HTTP- Request mit dem anhängenden Daten-Query-String.


    zu 2:

    ich sende HTTP und sende zeitversetzt. Es ist aber nicht auszuschließen, dass hin und wieder eine Sendung exakt auf 0 min. / 0 sek. fällt. Laut meinem Error-Log scheint es aber keinen Zusammenhang mit 0 min. / 0 sek. zu geben.


    Gruß

    Martin

    Wenn ich das hier richtig verstanden habe, steht nur die Regenmenge als primäre Information zur Verfügung und die Regenrate wird daraus berechnet.


    Darf ich hier mal den Vorschlag einbringen, die Regenmenge vor der Nullung zu berechnen? Dann bekommt man keine negative Zahl.


    Übrigens wird bei dem genannten Verfahren der Regen zwischen der letzten Meldung vor Mitternacht und der Meldung für Mitternacht überhaupt nicht an AWEKAS übertragen.

    Hallo zusammen,


    jetzt nochmal ein Update zu der Problemstellung mit der Fehlermeldung zur Regenrate:


    Die Regenrate wird in meinem Programm definitiv unabhängig von der Nullung berechnet. Die Tagesregenmenge wird nicht für die Berechnung der Regenrate herangezogen, sondern die Differenz eines Gesamtzählers, welcher nicht genullt wird.


    Wie auch immer, ich habe gestern Abend einen Log-Schrieb programmiert, der die übermittelten Daten zu AWEKAS und die Antworten darauf protokolliert. Hier der Auszug um Mitternacht (sensible Daten natürlich unkenntlich gemacht):


    2023/11/15 - 23:58:13 - Request: http://ws.awekas.at/weathersta…ph=2.57&windgustmph=3.42&rainin=0&dailyrainin=0.11&solarradiation=0&UV=0&action=updateraw


    2023/11/15 - 23:58:13 - Response: OK


    2023/11/16 - 00:03:35 - Request: http://ws.awekas.at/weathersta…ph=2.85&windgustmph=3.42&rainin=0&dailyrainin=0&solarradiation=0&UV=0&action=updateraw


    2023/11/16 - 00:03:35 - Response: rainrate wrong - -33.6


    Die interessanten Einträge habe ich hervorgehoben. Es ist eindeutig zu erkennen, dass vor Mitternacht der Wert der Tagesregenmenge größer 0 ist (0,11 inch) und, da es zu diesem Zeitpunkt aktuell nicht regnete, der Wert der Regenrate 0 ist. Bei der darauffolgenden Sendung nach Mitternacht erkennt man die genullte Tagesregenmenge und auch wieder eine Regenrate von 0. Die Antwort ist hier „rainrate wrong - -33.6“.


    Wie schon oben geschrieben, handelt es sich hier um das Protokoll von Weather-Underground, da dieses Protokoll offen liegt und frei verwendbar ist. Gerne würde ich auch ein AWEKAS-eigenes Protokoll verwendet, kann dazu aber keine Informationen finden. Dies würde die Umrechnerei in amerikanische Einheiten und somit Rundungsfehler vermeiden.


    Ich freue mich auf Antworten.


    Gruß

    Martin

    Ich sehe gerade, dass die Darstellung der beiden Request-Links eingekürzt wurden. Hier noch mal ein Versuch, sie in Gänze darzustellen:


    2023/11/15 - 23:58:13 - Request: http://ws.awekas.at/weatherstation/updateweatherstation.php?

    ID=***&PASSWORD=***&dateutc=now&tempf=43.2&humidity=96&baromin=29.923&winddir=180&windspeedmph=2.57&windgustmph=3.42&

    rainin=0&dailyrainin=0.11&solarradiation=0&UV=0&action=updateraw


    2023/11/15 - 23:58:13 - Response: OK


    2023/11/16 - 00:03:35 - Request: http://ws.awekas.at/weatherstation/updateweatherstation.php?

    ID=***&PASSWORD=***&dateutc=now&tempf=43.3&humidity=96&baromin=29.925&winddir=195&windspeedmph=2.85&windgustmph=3.42&

    rainin=0&dailyrainin=0&solarradiation=0&UV=0&action=updateraw


    2023/11/16 - 00:03:35 - Response: rainrate wrong - -33.6

    Hi!


    Vielleicht ist es ja nur ein Definitionsproblem - aber im WU-Protokoll gibt es keine Regenrate!

    Es gibt rainin (die Regenmenge der letzten 60 Minuten) und dailyrainin, weeklyrainin, monthlyrainin, yearlyrainin fuer die Mengen des jeweiligen Zeitraums.

    Siehe hier.


    Welchen Wetterstationstyp und welche Art der Datenübernahme hast Du denn auf der Awekas-Einrichtungsseite (Mein Awekas/Benutzerdaten/Wetterstation ausgewaehlt?


    Bzgl. Deiner Anfrage betreffs API siehe hier.


    Gruss,

    Oliver

    Es gibt noch mehr. Es gibt ein REST-API, das ich nirgends beschrieben fand, das aber in WeeWX verwendet wird. Dort ist es wie folgt beschrieben:



    Die URL ist "http://data.awekas.at/eingabe_pruefung.php?val=" Dann folgen die bloßen Werte nach obiger Liste, durch Semikolon getrennt. Bei WeeWX funktioniert die Übertragung mit diesem Protokoll einwandfrei.

    Hallo zusammen,


    vielen Dank für die schnellen Rückmeldungen.


    olicat:

    Das Definitionsproblem bei Weather-Underground fiel mir auch schon auf, da ich nach der von Dir verlinkten WU-Anleitung programmiert hatte. Dort ist für „rainin“ einerseits von der Regenmenge der letzten 60 min die Rede (also ein kumulierter Wert), angezeigt wird dieser Wert auf der dortigen Instrumentenseite jedoch als mm/h (oder inch/h), also Quotient Menge/Zeit (=> Rate). Ich habe das dann mal so aufgefasst, dass die dort selbst nicht wissen, wovon sie reden. Zumal die Werte anderer Stationen eindeutig eine Regenrate darstellen und keinen kumulierten Wert.

    Aufgrund dieser Unstimmigkeiten habe ich testweise die Übertragung von „rainin“ an AWEKAS abgeschaltet, da ich dachte, dass AWEKAS vielleicht die Regenrate selbst anhand der fortlaufend übermittelten Tagesniederschlagsmengen berechnet. Dies hatte zur Folge, dass auf der AWEKAS-Instrumentenseite für die Regenrate „k.a.“ (oder so ähnlich) angezeigt wurde. Offensichtlich führt der übertragene Wert „rainin“ zur Anzeige der Regenrate.


    Zu Deiner Frage der eingestellten Wetterstation:

    Wetterstationstyp Dropdown: „andere“

    Wetterstationstyp Freitext: „Misol WH65LP“

    Datenübernahme: „WU Fastlink“


    Zu deinem Link zur API:

    Hatte ich auch schon recherchiert. Der Beitrag endet mit (Zitat von othi): „Die Daten API ist nicht öffentlich. Wenn du ein Softwarehersteller bist, schreibe mir bitte ein Mail.“


    woellsdorf:

    vielen Dank für das alternative Protokoll. Wie wird hier mit den nicht benutzten Größen umgegangen? Ich nehme an, Semikolon an Semikolon, um die den jeweiligen Platz zu überspringen. Und das auch nach hinten raus für nicht vorhandene Größen?


    @Admins:

    gibt es für mich als privaten Programmierer die Möglichkeit, das nicht öffentliche AWEKAS-Protokoll zu bekommen?


    Gruß

    Martin

    Zitat von Martin MFG Berlin

    woellsdorf:

    vielen Dank für das alternative Protokoll. Wie wird hier mit den nicht benutzten Größen umgegangen? Ich nehme an, Semikolon an Semikolon, um die den jeweiligen Platz zu überspringen. Und das auch nach hinten raus für nicht vorhandene Größen?

    Ja, Semikolon an Semikolon, wenn kein Wert übermittelt wird.


    Falls Python-Kenntnisse vorliegen: https://github.com/weewx/weewx…master/bin/weewx/restx.py ab Zeile 1575.

    Hi!


    Ich fuerchte, da wirst Du auf eine Antwort von othi warten muessen. Nur er weiss, wie das Script fuer die Eingangspruefung der Daten funktioniert.

    Zumindest halte ich aber die Fehlermeldung "rainrate wrong - -33.6" fuer falsch. Weder sendest Du den Wert -33.6 noch eine Regenrate (rainrate).

    Ich halte das - aus den mir vorliegenden Daten - fuer einen Fehler auf Awekas-Seite. Wahrscheinlich uebersehe ich da aber was - denn WU Fastlink wird sicherlich von sehr vielen Stationen genutzt.


    BTW: Das "alternative Protokoll" IST die Awekas Data API ...


    Gruss, Oliver

    Hallo Oliver,


    ja, ich halte es auch für ein Problem auf der AWEKAS-Seite. Aufgefallen ist es wahrscheinlich noch nicht, da die meisten Stationen, welche WU-Fastlink nutzen, Konsolenstationen sein werden, die die Response-Antwort vermutlich gar nicht bewerten, geschweige denn, irgendwie ausgeben.


    Deshalb habe ich das Problem hier zur Diskussion gestellt…


    Gruß

    Martin

    Hi Martin,


    ich werde hier jetzt mal die response-Texte beobachten - bisher ist mir nichts dergleichen aufgefallen.

    Allerdings sende ich auch ein paar mehr Daten - unter anderen auch die rainrate (die aber im WU-Protokoll nicht spezifiziert ist) und ich nutze einen anderen Wetterstationstyp (Froggit DP1500 Wi-Fi Wetterserver"):


    Code
    http://ws.awekas.at/weatherstation/updateweatherstation.php?ID=stationid&PASSWORD=password&softwaretype=GW1000A_V1.7.7&runtime=2496397&dateutc=2023-11-16+16:01:21&indoortempf=62.78&indoorhumidity=49&baromin=29.816&baromabsin=29.666&tempf=41.90&humidity=82&winddir=205&windspeedmph=0.00&windgustmph=0.00&maxdailygust=8.05&solarradiation=0.00&UV=0&rainratein=0.000&eventrainin=0.657&rainin=0.000&dailyrainin=0.028&weeklyrainin=0.657&monthlyrainin=1.201&yearlyrainin=25.307&totalrainin=25.307&temp2f=43.52&humidity2=76&temp5f=41.36&humidity5=82&temp6f=41.90&humidity6=82&temp7f=41.18&humidity7=84&temp8f=67.82&humidity8=43&temp9f=65.48&soilmoisture=46&soilad1=246&soilmoisture2=47&soilad2=242&soilmoisture3=49&soilad3=245&soilmoisture4=50&soilad4=249&soilmoisture5=62&soilad5=291&soilmoisture6=63&soilad6=290&soilmoisture7=47&soilad7=242&soilmoisture8=38&soilad8=207&AqPM2.5=12.0&pm25_avg_24h_ch1=13.9&tf_co2=71.96&humi_co2=41&pm25_co2=1.2&pm25_24h_co2=4.0&pm10_co2=1.5&pm10_24h_co2=4.7&co2=627&co2_24h=753&lightning_num=0&lightning=27&lightning_time=1696349412&leak_ch2=0&leak_ch3=0&leak_ch4=0&soiltempf=48.20&soiltemp2f=66.92&soiltemp3f=49.28&soiltemp4f=50.00&soiltemp5f=68.00&leafwetness=13&batt1=0&batt4=0&batt5=0&batt6=0&batt7=0&batt8=0&leakbatt2=5&leakbatt3=4&leakbatt4=4&tf_batt1=1.54&tf_batt2=1.56&tf_batt3=1.54&tf_batt4=1.54&tf_batt5=1.56&co2_batt=6&leaf_batt1=1.70&isintvl=31&isintvl10=31&dewptf=37.0&windchillf=40.8&feelslikef=40.8&heatindexf=38.6&pm25_AQI_ch1=50&pm25_AQIlvl_ch1=1&pm25_AQI_avg_24h_ch1=55&pm25_AQIlvl_avg_24h_ch1=2&co2lvl=2&pm25_AQI_co2=5&pm25_AQIlvl_co2=1&pm25_AQI_24h_co2=17&pm25_AQIlvl_24h_co2=1&pm10_AQI_co2=1&pm10_AQIlvl_co2=1&pm10_AQI_24h_co2=4&pm10_AQIlvl_24h_co2=1&windspdmph_avg10m=0.0&winddir_avg10m=204&windgustmph_max10m=1.1&windrun=12.62&brightness=0.0&cloudf=1042&sunhours=0.58&sunshine=0&srsum=410.12&osunhours=0.55&nsunhours=0.58&ptrend1=-1&pchange1=-0.0089&ptrend3=-1&pchange3=-0.0207

    Deine Fehlermeldung "rainrate wrong - -33.6" kommt immer nur beim ersten Datensatz eines Tages? Die gemeldete Zahl -33.6 ist immer die selbe?


    Oliver

    Hallo Oliver,


    ja, die Fehlermeldung kommt immer nur beim ersten Datensatz eines Tages. Das ist der Datensatz mit der genullten Tagesniederschlagsmenge.

    Die gemeldete Zahl ist unterschiedlich und hängt von der Tagesniederschlagsmenge ab, welche genullt wurde. Aber einen mathematischen Zusammenhang konnte ich noch nicht erkennen.


    Gruß

    Martin

    Hi!


    Gut, ich liege auf der Lauer ...

    Einen Fehler (?) im WU-Parser von Awekas habe ich offenbar bereits gefunden.

    Es darf fuer den Parser fuer den Key leafwetness keinen Wert oberhalb von 15 geben - dann kommt eine Fehlermeldung "leafwetness1 wrong - 16<br>".

    Allerdings ist leafwetness und leafwetnessN - so wie ich die WU-Protokollbeschreibung verstehe - als Prozentwert definiert. Somit sollten Werte von 0 bis 99 (100) akzeptiert werden.


    Das Davis hier im WU-Protokoll ggf. einen Wert von 0 bis 15 sendet, ist dann wohl eher deren Interpretation des WU-Protokolls geschuldet und meiner Meinung nach ein Fehler.

    Alle Ecowitt-Stationen senden im WU-Protokoll (wie auch im Ecowitt-Protokoll) den prozentualen Wert fuer leafwetness.

    Meteotemplate, Weathercloud, WeeWX, Awekas-API, Weather365, WSWin haben eigene Datenformate, wo der Wertebereich fuer die Blattfeuchte tatsaechlich mit 0..15 definiert ist.

    WU ist aber ein Prozentwert.


    othi

    Interpretierst Du die WU-Protokoll-Dokumentation fuer leafwetness anders? Sendet Davis im WU-Protokoll tatsaechlich Werte von 0..15?


    Gruss, Oliver

    Hi!


    Das geschilderte Problem mit der rainrate kann ich nachvollziehen:


    200: leafwetness1 wrong - 28<br>rainrate wrong - -8.4<br>


    Die Meldung kommt aber hier nicht nur einmal, sondern seit 00:00 Uhr MEZ bei jedem Sendeintervall bis einschliesslich 00:05 Uhr (Sendeintervall 60 Sekunden).

    Da Du ja nur alle 5 Minuten sendest, koennte das also mit einer einmaligen Fehlermeldung bei Dir passen.

    Die gleichen Daten per Awekas Data API eingeliefert ergeben keine Fehlermeldung (da wandle ich den Wert der Blattfeuchte ohnehin nach 0..15).

    Die an Awekas gelieferten Daten im WU-Protokoll sahen von meiner Seite so aus:

    Code
    http://ws.awekas.at/weatherstation/updateweatherstation.php?ID=userid&PASSWORD=password&softwaretype=GW1000A_V1.7.7&runtime=2521600&dateutc=2023-11-16+23:01:26&indoortempf=67.46&indoorhumidity=43&baromin=29.808&baromabsin=29.657&tempf=36.14&humidity=89&winddir=163&windspeedmph=0.89&windgustmph=1.12&maxdailygust=1.12&solarradiation=0.00&UV=0&rainratein=0.000&eventrainin=0.000&rainin=0.000&dailyrainin=0.000&weeklyrainin=0.657&monthlyrainin=1.201&yearlyrainin=25.307&totalrainin=25.307&temp2f=37.40&humidity2=81&temp5f=35.60&humidity5=90&temp6f=36.14&humidity6=89&temp7f=35.42&humidity7=92&temp8f=67.46&humidity8=40&temp9f=64.94&soilmoisture=45&soilad1=244&soilmoisture2=47&soilad2=242&soilmoisture3=49&soilad3=244&soilmoisture4=49&soilad4=247&soilmoisture5=62&soilad5=291&soilmoisture6=62&soilad6=289&soilmoisture7=47&soilad7=242&soilmoisture8=38&soilad8=207&AqPM2.5=12.0&pm25_avg_24h_ch1=13.3&tf_co2=72.50&humi_co2=38&pm25_co2=39.0&pm25_24h_co2=4.5&pm10_co2=42.7&pm10_24h_co2=5.4&co2=635&co2_24h=709&lightning_num=0&lightning=27&lightning_time=1696349412&leak_ch2=0&leak_ch3=0&leak_ch4=0&soiltempf=47.66&soiltemp2f=66.20&soiltemp3f=49.28&soiltemp4f=49.64&soiltemp5f=68.18&leafwetness=28&batt1=0&batt4=0&batt5=0&batt6=0&batt7=0&batt8=0&leakbatt2=5&leakbatt3=4&leakbatt4=4&tf_batt1=1.54&tf_batt2=1.56&tf_batt3=1.54&tf_batt4=1.54&tf_batt5=1.56&co2_batt=6&leaf_batt1=1.70&isintvl=31&isintvl10=31&dewptf=33.4&windchillf=35.2&feelslikef=35.2&heatindexf=32.8&pm25_AQI_ch1=50&pm25_AQIlvl_ch1=1&pm25_AQI_avg_24h_ch1=54&pm25_AQIlvl_avg_24h_ch1=2&co2lvl=2&pm25_AQI_co2=110&pm25_AQIlvl_co2=3&pm25_AQI_24h_co2=19&pm25_AQIlvl_24h_co2=1&pm10_AQI_co2=40&pm10_AQIlvl_co2=1&pm10_AQI_24h_co2=5&pm10_AQIlvl_24h_co2=1&windspdmph_avg10m=0.4&winddir_avg10m=201&windgustmph_max10m=2.2&windrun=0.01&brightness=0.0&cloudf=592&sunhours=0.0&sunshine=0&srsum=0.0&osunhours=0.0&nsunhours=0.0&ptrend1=0&pchange1=0.003&ptrend3=-1&pchange3=-0.0059

    Ich kann auch hier keinen inhaltlichen Fehler bzgl. "rainrate" erkennen. Auch der monierte Wert "-8.4" ist in den Daten nicht enthalten.

    Fuer mich verstaerkt sich der Eindruck, dass es sich hier um einen Fehler auf Seiten von Awekas handelt. othi muss sich das anschauen.


    BTW:

    Auch die gelegentlichen Timeouts kann ich bestaetigen - am 16.11. konnte insgesamt 11 mal eine Sendung nicht in 3 Sendeversuchen (1. Versuch - 6sec Pause - 2. Versuch - 12sec Pause - 3. Versuch) an Awekas abgeliefert werden. Vermutlich ist der Server zu diesen Zeiten sehr stark unter Last, so das es zu einen Timeout kommt. Wobei 11 Verluste bei 1440 Sendungen fuer mich verschmerzbar sind.


    Ich kann also Deine Beobachtungen bestaetigen.


    Gruss, Oliver

    Moin,


    cool, dass meine Beobachtungen verifiziert werden konnten.


    Seit gestern Abend liefere ich die Daten per Awekas Data API ein, entsprechend dem Protokoll von vonwoellsdorf. Hier gibt es keine Fehlermeldungen. Aber das Problem mit den Timeouts besteht hier genauso. Ich werde mich mal mit dem Thema HTTPS auseinandersetzen.


    Gruß

    Martin

    Hallo zusammen,


    ein Update zum Thema Timeout:

    ich sende jetzt seit einigen Tagen per HTTPS statt HTTP. Bei meinem ursprünglichem Sendeintervall von 5 min traten keine Timeouts mehr auf. Frohen Mutes habe ich daraufhin auf ein Sendeintervall von 1 min verkürzt. Hierbei traten dann ca. 5 Timeouts pro Tag auf. Hier kann reproduzierbar festgestellt werden, dass diese Timeouts jeweils zur vollen Stunde auftreten, gefolgt beim nächsten Sendeversuch nach 1 min mit der Rückmeldung „too many requests - try again later“. Bei HTTP kam diese Rückmeldung nicht und die Timeouts traten unabhängig von der Uhrzeit auf.


    Gruß

    Martin