PWS-Upload zu weiteren Wetterdiensten

[olicat]

So,

ich habe jetzt mal all meine WSWin-Daten geloescht (*.dat) und mein CSV neu eingelesen.
Dabei habe ich yearlyrainmm der ID34 zugeordnet. Die ID134 lasse ich ausser Acht.
Zumindest sieht es jetzt stimmig aus. Gesamtregensumme Stunde sowie Tag und auch rainrate passen.
Auch wenn ET weiterhin 0.000 anzeigt. Aber das - wie wohl auch windrun - ist vermutlich meiner X-CSV-geschuldet.
Da fehlen vielleicht noch Werte, die zur Berechnung dieser Werte nötig sind.

Ich bin jetzt sehr gespannt, was Werner zu der Vorlage sagt. Wenn es bei seiner Davis funktioniert, koennte man sich ja noch um die Kleinigkeiten wie ET und windrun kuemmern. Was ich bisher jedoch noch gar nicht getestet habe: kommt der http/POST ueberhaupt korrekt beim Empfaenger an?
Im Wireshark kann ich zumindest die Werte sehen. Allerdings sind die Werte der URL nachgelagert. Eigentlich haette ich die Werte als eigenen Block im POST erwartet. Da koennte also noch ein Problem vorliegen.
Aber erstmal:
Vielen Dank fuer die gute Zusammenarbeit!

Oliver

[Tex]

Dabei habe ich yearlyrainmm der ID34 zugeordnet.

Die Jahresregenmenge (yearlyrainmm) auf die current-Regenmenge (ID34) zu bringen - ob das so geht??? Glaube ich kaum.
Welche Variable gibt bei Dir denn an, welche aktuelle Regenmenge gerade fällt? - Also beim Wippenschlag die Regenmenge anzeigt (Auflösung des regenmessers)? - das wäre dann die ID34 bei WSWIN.

[wneudeck]

Hallo,
ich habe jetzt mal das skript nur als benutzerdefinierte Datei getestet, denn "absenden" kann ich ja nicht testen, da bräuchte ich ja den entsprechenden Empfänger.
Es sieht aber gut aus (ich poste am Ende das heutige Ergebnis), aber ich muss natürlich nochmals testen, wenn mehr Faktoren vorhanden sind (hatte ja heute kein UV, Solar usw., da es zu spät war)
So sieht es im Moment aus:

stationid=%ws_template_user%
datum=202103221851
utcstamp=1616435460
press=1023,2hPa
t2m=4,0°C
relhum=74%
windspeed=0,9
windgust=2,2
radi=0W/m²
uvi=0,0UV-I
rainrate=0,0l/m²/h
rainh=0,0l/m²
prec_time=60
raind=0,0l/m²

dew2m=-0,2°C
wchill=4,0°C
appTemp=1,4°C
heat=4,0°C
cloudbase=526m
winddir=261°
latitude=48.716944
longitude=10.751111
altitude=411 m
et=0,000mm
windrun=197.7km

Dabei ist anzumerken:
Bei windspeed und windgust kommt auf Grund der Umrechnung in m/s keine Benennung, aber die kann man ja manuell dazuschreiben.
Die soilmoist-Sensoren fehlen, da ich sie nicht habe, aber man sieht daran, dass das Ausblenden funktioniert. Ich nutze nur einen Bodensensor +5 cm und der ist bei mir auf ID=13
Das ist das von Tex schon angesprochene Problem, dass es nicht bei allen Vantage-Usern gleich ist, je nachdem, was wie installiert ist.
Ich melde mich wieder, wenn ich mehr Daten habe, gehe aber davon aus, dass es so stimmt, denn ich kenne mich ja prinzipiell mit den Variablen aus, auch wenn Tex der OberGuru ist (meine ich ernsthaft und nicht als Gag)

[Tex]

Windspeed und windgust:

windspeed=%ws_newunit[35]=1%%curval[35]%
windgust=%ws_newunit[45]=1%%curval[45]%

Umrechnungen sind auch deshalb nicht wirklich sinnvoll, da einige User garantiert von Haus aus m/s eingestellt haben. Dann würde das nochmals um den Faktor 3,6 reduziert.

[olicat]

Hi!

Umrechnungen sind auch deshalb nicht wirklich sinnvoll, da einige User garantiert von Haus aus m/s eingestellt haben.

Gut, das Du das weisst (und sagst!).
Ich ging davon aus, das es ein Standardformat (Einheit) im WSWin gibt. Wenn es also da nichts gibt, worauf man sich verlassen kann, ist Dein Vorschlag natuerlich deutlich eleganter!
Der Post mit der aktuellen Vorlage ist dahingehend angepasst.

Welche Variable gibt bei Dir denn an, welche aktuelle Regenmenge gerade fällt? - Also beim Wippenschlag die Regenmenge anzeigt (Auflösung des regenmessers)? - das wäre dann die ID34 bei WSWIN.

Bei Ecowitt gibt es unzaehlige Werte fuer den Regen:

Code: Alles auswählen

rainratemm	aktuelle Regenrate auf die Stunde gerechnet, wird bei fehlendem Regen wieder 0
eventrainmm	Menge des Niederschlags fuer das aktuelle Regenereignis, setzt sich erst einige Zeit nach Regen wieder auf 0 zurueck
hourlyrainmm	die Menge des in der letzten Stunde gefallenen Regens, stuendlicher Reset zur Minute 0
dailyrainmm	die Menge des Niederschlags des aktuellen Tages, Reset um 0:00 Uhr
weeklyrainmm	die Menge des Regens in dieser Woche (Reset Sonntag 0:00 Uhr - ja, wirklich Sonntag und NICHT Montag)
monthlyrainmm	die Menge des Regens seit dem Monatsersten (Reset: 1. des Monats)
yearlyrainmm	die laufende Menge des gefallenen Niederschlags des Jahres - Reset jeweils am 1.1.
totalrainmm	identisch zu yearlyrainmm - urspruenglich wohl ohne Reset geplant

Und nochmal im Original:

Code: Alles auswählen

Rain Rate is defined as the rainfall in the last 10 minutes, multiplied by 6  (10 minutes x 6 = 1 hour). This is also referred to as instantaneous rain per hour.
Hourly Rain is defined as the rainfall in the last hour.
Rain event is defined as continuous rain, and resets to zero if accumulated rainfall is less than 1 mm (0.039 in) in a 24 hour period.  Some weather stations may calculate this slightly differently and the customer should reference the User Manual.
Daily Rain is defined as the rainfall since midnight (00:00).
24 Hour Rain is defined as the rainfall in the last 24 hours. For example, if it is currently 5:00 pm, 24 hour rain would be the amount of rain that has fallen since 5:00 pm yesterday.
Weekly Rain is defined as the calendar week total, and resets on Sunday morning at midnight (Sunday thru Saturday).
Monthly Rain is defined as the calendar month total, and resets on the first day of the Month.
Yearly Rain is defined as the calendar year total, and resets on the first day of the Year. The WS-1000 series weather stations allow you to change the month rain is reset to 0.00 (referred to as Rainfall Season).
Total Rain is defined as the running total since station was powered up.

Aus yearlyrainmm laesst sich also unter Betrachtung der Zeit alles errechnen.

Oliver

[Tex]

Ich habe mich bei weather3365 mal versuchsweise angemeldet. Allerdings habe ich außer der StationsID nichts weiter bekommen - auch kein Passwort. In der Dokumentation steht ein allgemeines Passwort: 14991234912, aber auch damit funktioniert es nicht. Post failed.
Hast du da weitere informationen?

[olicat]

Hi!

Hast du da weitere informationen?

Zumindest sende ich hier mit FOSHKplugin per POST an den Dienst.
Das Einzige was zaehlt ist die stationID - das ist die, die Du per EMail erhalten hast. Die musst Du in der WSWin-Vorlage als user eintragen.
Mein POST via FOSHKplugin sieht dann so aus:

Code: Alles auswählen

stationid=A1B2C3D4E5&datum=202103222015&utcstamp=1616440500&press=1020.49&t2m=4.7&relhum=65&windspeed=0&windgust=0&radi=0.00&uvi=0&rainrate=0.0&rainh=0.0&prec_time=60&raind=0.0&soilmoisture=38&dew2m=-1.3&wchill=4.7&appTemp=4.7&heat=2.9&cloudbase=808.0&winddir=207&latitude=52.669481&longitude=13.266531&altitude=53

Dabei wird jedoch der o.a. String komplett und ausnahmslos im body des Pakets versandt. Die aufgerufene URL ist nur "https://channel1.weather365.net/stations/index.php".
Bei WSWin habe ich den Eindruck, das der String (mit val=) mit in die URL gesetzt wird (also wie bei http/GET). Gibt es da vielleicht noch irgendeine Variable, die WSWin dazu anweist, die Daten in den body zu packen?

Oliver

[Tex]

2021-03-22 21:24:45.703 WWW1 ?stationid=GM5CL7EUFF&datum=202103222120&utcstamp=1616444400&press=1020.3&t2m=4.4&relhum=85&windspeed=0.2&windgust=0.2&radi=0&uvi=0.0&rainrate=0.0&rainh=0.0&prec_time=60&raind=0.0&dew2m=2.1&wchill=4.4&apptemp=2.6&heat=4.4&cloudbase=287&winddir=267&latitude=53.503889&longitude=13.564167&altitude=100&et=1.2&windrun=132.3 &leafwetness2=0
2021-03-22 21:24:48.640 WWW1 <html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx</center>
</body>
</html>

Das ist die Meldung im wswin_debug.

[Tex]

Und so sieht das Muster von weather365 aus

Host: channel1.weather365.net
Postvariablen sind: dew2m=4.1&datum=201905021550&humidex=20.8&uvi=2.5&soiltemp=15.0&radi=714.8&prec_time=60&et=0.03300&alt=466.0&soilmoisture=113.2&t2m=20.8&leafwetness=0.0&soiltemp2=12.7&soiltemp3=11.4&soiltemp4=11.4&long=10.6845&rainh=0.00&rxsignal=95&windrun=56.8&utcstamp=1556805000&wchill=20.8&txbattery=0&winddir=257&windspeed=2.7&windgust=5.4&press=1007.053&relhum=33&lat=49.8212&appTemp=17.7&heat=20.8&stationid=XYZABCDEF&raind=0.00&rainrate=0.00&cloudbase=2546.3

https://www.weather365.net/wettersatell ... achen.html

Kann es sein, daß die ID nicht vorweg, sondern so wie im Muster angeordnet werden muß?

Die sollten mal eine klare Ansage machen, wie der Datenstring aussehen muß, sonst tappen wir da im dunkel....

[olicat]

Hi Tex,

bei meinen erfolgreich versandten POSTs(via FOSHKplugin) steht die stationID auch an erster Stelle. Die Reihenfolge der Felder sollte also nicht wesentlich sein.
Aber:
WSWin schickt die Daten an die URL https:/irgendwo/bla.php?val=stationid=abs&temp=n.n&weiteresfeld=wert&usw - ein body ist dabei nicht enthalten - die content-length wird mit 0 angegeben.
weewx (wie auch FOSHKplugin) sendet die Daten an die URL https:/irgendwo/bla.php und die Daten stationid=abs&temp=n.n&weiteresfeld=wert&usw sind im body des Pakets enthalten.
Ich fuerchte, DAS ist das Problem.

Wenn mir nicht weather365.net geschrieben haette, das WSWin auch funktioniert wuerde ich behaupten, WSWin kann diesen Dienst gar nicht beliefern weil WSWin gar keinen echten POST kann.
Ich suche schon die ganze Zeit im Netz aber finde auch kein Beispiel einer anderen POST-basierenden Vorlage.
Die, die ich kenne von wettersektor.de - nimmt die Daten auch aus der URI - weshalb ich urspruenglich dort von einem http/GET ausgegangen war.

Im Moment stehe ich da echt auf dem Schlauch.
WSWin muesste man irgendwie mitteilen koennen, dass die Daten nicht in der URL/URI sondern im Body uebertragen werden sollen.
Dann muesste WSWin den Body anhand der Variablen erzeugen, dessen Laenge feststellen und eine zusaetzliche Headerzeile Content-Length=len gefolgt von einer Leerzeile erzeugen und die generierte Zeile anhaengen.

Ich kann mir aber auch nicht vorstellen, dass Werner Krenn das nicht bedacht hat.
Hattest Du nicht einen guten Kontakt zu ihm?

Vielleicht gibt es ja bereits einen Parameter fuer 4Senddata=%body% aus dem WSWin erkennt, dass es die Daten in den body packen muss?
Ich habe es hier schon ohne 4Senddata= versucht - dann werden die Daten schlicht an die URL angehangt; die content-length bleibt bei 0.

Wenn WSWin die Daten nicht im body verschicken kann, wird der Dienst wohl nicht per WSWin beliefert werden koennen.
Vielleicht befragst Du den Werner Krenn dazu mal?
Und ich die Jungs und Maedels von weather365.net?
Waere ja bloed, eine eigentlich fertige Vorlage zu haben und diese nicht nutzen zu koennen, nur weil der Dienst die Sprache des Programms (vice versa) nicht spricht.

Gruss, Oliver