Posts by Geri

Quote from gerald

Zum Thema Vorhersage: Die Daten stammen von weatherapi.com - wir werden das auch im Stationsweb irgendwo einblenden. Geri: Ich schau mir in deinem Fall an, ob bei uns der Fehler liegt. Bei unserer Station ist die Vorhersage deutlich besser.

Gerald (Hi, Namenskollege), das könnte an den Wetterportalen selbst liegen, die nehmen oft einfach die geographisch nächsten »offiziellen« Stationen. Bei z.B.: wetteronline.de erscheinen bei mir in der Statistik einfach so die Daten der ZAMG-Station Obervellach:

und das, obwohl da der Alpenhauptkamm dazwischen liegt und die Seehöhe über 500m anders ist (1200m bei mir vs. 690m in Obervellach)!

Auch von mir jetzt ein großes DANKE!!!

Edit: bezüglich Schneehöhe: muß man einmalig was angebn, dann taucht sie auf (natürlich gleich wieder entfernt).

Danke für die Hinweise, Jörg! Mir ging es um das eklatante Danebenliegen der Werte, nicht um die große Exaktheit – diese Werte werden ja auch von anderen als mir angesehen und ev. sogar für bare Münze gehalten. Wenn es an AWEKAS liegt, kann ja hier programmiertechnisch eingegriffen werden (nicht speziell bei mir sondern allgemein), ansonsten gehört halt der Prognoseanbieter auf solch eklatante Fehler aufmerksam gemacht. Hier mal ein Vergleich der nächsten drei Tage:

stationswebtest (UND stationsweb):

wetteronline.de:

meteoblue:

pwsweather.com:

meteo-services.com:

wetter.zone (ZAMG):

usw.

Was dabei auffällt: Nur bei AWEKAS sind die Tiefstwerte so eklatant daneben, und darauf wollte ich aufmerksam machen.

Nebenbei warte ich noch auf eine Reaktion bezüglich Schneehöhe – Anzeige und Meldung (siehe # 122).

Wo habt Ihr eure (Wetter-)Vorhersage her? Bei mir zeigt es:

wobei heute die tiefste Temperatur +1,7°C war und Di+Mi sicher KEINE TIEFEN Minusgrade auftreten werden, schlechtestenfalls -0,x°C (die +13,6°C für Mi sind auch äußerst optimistisch).

Mich würde eine bessere Vorhersage freuen.

Was mir gerade aufgefallen ist: Bei »Wetter melden« fehlt die Schneehöhe – im »alten« Stationsweb ist sie sehr wohl vorhanden.

Edit: Auch die Anzeige der Schneehöhe fehlt.

Edit 2: Ich meine die Desktopversion des (Test-)Stationswebs: Im Stationsweb ist die Anzeige der Schneehöhe vorhanden und die Schneehöhe meldbar; in der Testversion fehlt beides.
In der Androidversion fehlt auch beim »alten« Stationsweb die Anzeige der Schneehöhe, sie ist jedoch meldbar.

Eine Kleinigkeit: GALERIE (in: »Stationsbetreiber Einstellungen« – bei »GALLERIE & HINTERGRUND«) schreibt man richtig mit EINEM »L«.

LG Gerald

Hallo Bernd, Du weißt aber schon, dass der Wert für z.B. 16:00 aus den Meldungen von 15:05 bis 16:00 gebildet wird (EXCLUSIVE 15:00, das gehört zur Stunde davor)?

Noch ein »Gimmick«: Unter Link (englisch) kannst Du nachlesen, wie Du sogar DIREKTEN Zugriff auf die Ordnerstruktur Deiner SD in der Nano erhätlst.

Aber Achtung! – Vorsicht in diesen Ordnern, Du kannst Dir sogar die Software zerschießen! (Lesezugriff ist aber harmlos)

Interessant ist sowieso nur die Datei »lastexport.exp« im Ordner »export«, die kannst Du auf Deinen PC kopieren und mit einer Tabellenkalkulation Deiner Wahl öffnen (ist vom Format eine ».csv«). Dort sind sogar die minütliche Werte drin.

Ich bereite diese immer monatsweise am PC auf (2023-12.csv, 2024-01.csv, …).

Und wenn Du Dich traust (Vorsicht!), kannst Du auch die Daten des AKTUELLEN Monats (wenn die Vormonate schon auf der HD sind) – bereinigt von den Vormonatsdaten – vom PC auf die SD der Nano zurückkopieren (ersetzen), natürlich mit dem Namen »lastexport.exp«. Achtung: Die erste Zeile mit den Sensorzahlen (leer/ leer = Datum/Uhrzeit, 1, 2, 3, …) NICHT löschen! Damit ist die »lastexport.exp« auf der SD immer angenehm klein (unter 5 MB), nächstes Monat kanns Du dasselbe wiederholen …

Hi zusammen, heute Nacht fiel mein WLAN zwischen 03:29 und 09:30 aus – nach Neustart geht's wieder.

In der Konsole sind alle Werte vorhanden, nun wollte ich meine Stundenwerte nachtragen, dabei ergeben sich aber folgende Probleme:

• Ich habe auf meinen PCs (außer dem System selbst) keine Mirkosaft-Zwangsprodukte wie Office, damit ist ein Datenupload im Menu »Datenimport -export« nicht möglich: Speichern als »xls« in OpenOffice hilft nicht, da im AWEKAS-Menu beim Datenimport die Datei wegen Fehlern nicht angenommen wird;
• im Datenarchiv lassen sich nur vorhandene Daten ausbessern, nicht jedoch FEHLENDE Daten nachtragen;
• auf der Hauptseite lassen sich nur Tageswerte, nicht jedoch Stundenwerte ausbessern.

Welche Möglichkeiten – außer Beibehaltung der Lücke – bleiben mir da noch?

Es geht mir dabei vorrangig um die Regendaten, die nach Wiederaktivierung gesammelt als »0,8mm um 09:00-09:59« angezeigt werden – wo aber leichter Sonnenschein herrschte–, die sich jedoch aus 2 x 0,2mm und 1 x 0,4mm zwischen 03:00 und 06:00 zusammensetzen.

Außerdem wäre natürlich eine allgemeine Lösung (abseits von / zusätzlich zu MS-Office!) erfreulich!

Vielen Dank für Hilfe/Auskunft!

EDIT!

Die Umwandlung OpenOffice-odt zu Office-xlsx hat doch funktioniert! Anscheinend hat sich die letzten Jahre bei Office/OO/AWEKAS was geändert. Wichtig dabei ist die richtige Um-Formatierung von »Datum« und »Uhrzeit« – die werden in OO im Original als Text angezeigt.

Damit hat sich das Problem erledigt.

Danke, Udo! Jetzt geht's.

Das komische ist, ich habe meine WS NICHT umgetauft, die hieß schon immer so (mit »/«). Muss irgendwann im Zuge der letzten Updates passiert sein, dass der Slash »/« plötzlich verboten ist. Daher habe ich das auch gar nicht im Fokus gehabt.

Hi Admins / Othi, was ist bei den Benutzerdaten los?

Ich wollte meine Windmesser-Höhe von 7m auf 8m zurückändern (Im Winter ist rund herum viel Schnee zusammengeschoben, der jetzt zum Großteil wieder weg ist), aber im Menu ist bei den Standort-Einstellungen angeblich ein Fehler drin, was aber nicht der Fall ist: Ich bin angemeldet, der Standort und die Seehöhe stimmen auf den Meter genau (siehe Bild).

Solange dieser angebliche Standortfehler besteht, lassen sich NIRGENDS Änderungen abspeichern.

Bitte um Hilfe bei diesem Problem.

Obergaimberg

#23638 zeigt einen um ca. 10hPa zu tiefen LD an.

St. Georgen/Salzach

#26838 zeigt einen um ca. 13hPa zu tiefen LD an.

Hallo BKynast,

Du musst zwischen ABSOLUTEM und RELATIVEM Luftdruck (LD) unterscheiden. Übertragen und angezeigt wird fast überall der RELATIVE LD, das ist der umgerechnete LD der Station, wenn sie auf Meereshöhe stehen WÜRDE. Das heißt auch, dass (bis etwa 800 m) die tatsächliche Höhe der betreffenden (Vergleichs-)Stationen egal ist, da sie ALLE »fiktiv« auf 0 m stehen. Damit kannst Du Dich dann auch mit Stationen in ANDERER Höhe vergleichen, OHNE eine höhenbedingte LD-Korrektur vornehmen zu müssen, ruhige Wetterlage mit weit auseinander liegenden Isobaren vorausgesetzt.

Vorschlag: Warte so eine ruhige Wetterlage ab, vergleiche dann Deinen LD mit MEHREREN (möglichst auch offiziellen) Stationen in Deinem Umkreis, nimm den LD-Korrekturwert auf Deiner Seite raus und korrigiere Deine Station auf den mittleren Wert der Umkreis-Stationen. Natürlich gehört der LD regelmäßig kontrolliert, er driftet – je nach Qualität der Hardware – mehr oder weniger schnell und stark ab.

Zum LD kannst Du ja auch mal DAS durchlesen, da wurde wegen dieses Themas auch schon »scharf geschossen« .

Obergaimberg

# 23638 zeigt einen um 12hPa zu hohen LD an.

Hi Dietmar, ganz so »schlimm« ist es nicht (ich hab ja auch vor kurzem »nachgelegt«). Es geht halt um eine gewisse Grundqualität.

Im Flachland – weit ab von höheren Bergen (z.B.: D Richtung N/NO/NW) und mit vielen Vergleichsstationen – ist es leichter, den LD relativ genau zu halten. Je näher man jedoch zum Alpenhauptkamm kommt und je weniger Vergleichsstationen vorhanden sind, desto schwieriger wird das Ganze.

Zur Zeit ist der LD-Verlauf im Alpenbereich sehr kompliziert und eigentlich nicht vergleichbar (besonders in größeren Höhen) – eingeklemmt zw. H und HTK, da heißt es: abwarten und stillhalten. Bei einer »flachen« LD-Verteilung (große Isobarenspreizung) kann man (notfalls auch die Admins) dann effizient eingreifen, und vielleicht gibt es auch mal eine Einbindung einiger offizieller Wetterstationen zum besseren Abgleich, damit wir uns nicht nur selbst kontrollieren/vergleichen. Othi hat mit den Vergleichen – glaube ich – weniger zu tun, er ist der Programmierer.

Über 1000m würde ich nicht herausnehmen sondern eine größere Toleranz zulassen.

Momentan haben sich die Isobaren aber etwas auseinander gespreizt (Link), deswegen meine Meldung mit Tabelle.

Bei Forstau (ID 23078) sehe ich aber keinen Knick nach oben (noch nicht? – oder nicht mehr?).

Meine Tabelle setze ich natürlich noch fort.

So, jetzt habe ich 2 Seiten in der Vergleichstabelle fertig:

LD-Daten.pdf

Die Zellen auffälliger WS habe ich rotbraun eingefärbt, Zeiten mit hohen LD-Differenzen (enge Isobaren) habe ich zwar grün/kursiv eingetragen aber ansonsten ignoriert (Vergleich nur eingeschränkt möglich), und 29./30.11. habe ich meinen LD um 0,5 hPa erhöht. Damit bin ich noch weiter über dem AWEKAS-Schnitt (+2 hPa), aber trotzdem noch immer unter dem ZAMG-Schnitt (-1 hPa).

Die Tendenz, dass AWEKAS immer einige hPa unter ZAMG ist (von -1,7 bis -4,3 hPa), bleibt im Schnitt gleich.

gelöscht — falsche Info!

Also ich bin kein Admin geschweige den Programmierer dieses Portals. Vielleicht wäre da ein Direktkontakt mit Othi effizienter?

HSH-Frosch

Das mit der Nichtüberwachung wusste ich nicht, verstehe ich jedoch, aber UweL meinte ja z.B.: seine Anfrage bezüglich zweimaliger Datenlücke (Link), die er am 1.11. gestellt hatte.

ICH PERSÖNLICH glaube an eine kleine Inkonsistenz bei der Programmierung (Zeitumstellung am 30.10., und 02:00 – 03:00 ist dadurch zweimal vorhanden), aber UweL erhielt dort keine wirklich befriedigende Antwort. Deswegen seine Bemerkung zur Mitarbeit der Mitglieder.

Mich persönlich würde diese Inkosistenz nicht stören, das passiert dann ja nur einmal Jährlich zur Zeitumstellung.

UweL

Am 31.10. 2021 gab's das selbe Problem zur selben Zeit (auch zur Zeitumstellung) – das dürfte die Lösung sein. Wenns programmtechnisch möglich ist und Othi davon weiß…