ich muss jetzt doch noch mal etwas nachfragen ... bin noch nicht so sattelfest in der weewx Welt. Ich hab in einem Linux-Container einer neue Weewx Instanz mit Simulator installiert und im Anschluss den gw1000 Treiber von hier https://github.com/gjr80/weewx-gw1000/releases in der Version v0.5.0b5 heruntergeladen und mit
weewx vom Simulator auf den gw1000 Treiber umkonfiguriert.
Wird mit dem wee_config schon die Datenbank angepasst - ich denke ja, denn im HTML Export von weewx sehe ich meine Sensoren. Aber die Felder aus add_ecowitt_to_wview_database.sh fehlen noch in der weewx Sqlite DB.
Auf deiner Webseite findet sich ja die Versin 0.5.0b6 des gw1000 Treibers. Ist die DB Anpassung erst für diese neuere Version notwendig? Ich steige da irgendwie nicht durch - sorry.
Wird mit dem wee_config schon die Datenbank angepasst - ich denke ja,
Nein.
Der GW1000-Treiber liefert nur die Daten/Werte, wie diese dann in eine Datenbank kommen liegt am Anwender.
Ausser man nutzt mein konfiguriertes Datenbank-Schema weewx_ecowitt.schema.
Wenn man dann Weewx erstmalig startet mit diesen Einstellungen in der weewx.conf
ohne vorhandene sdb-Datei oder man löscht/umbenennt die vorhandene sdb-Datei
[DataBindings]
[[wx_binding]]
# The database must match one of the sections in [Databases].
# This is likely to be the only option you would want to change.
database = archive_sqlite
table_name = archive
manager = weewx.manager.DaySummaryManager
schema = schemas.wview_ecowitt.schema
dann erzeugt Weewx die Datenbank mit eben allen Werten für eine Ecowitt-Station.
Bei einer vorhandenen normalen Weewx-Datenbank muss man die Datenbank mit meinen Script erweitern!
Ist die DB Anpassung erst für diese neuere Version notwendig?
Die Datenbank-Anpassung ist immer notwendig - ausser siehe vorher.
vielen Dank für deine Antwort - das hat jetzt geholfen. Ich hab das mal alles konfiguriert und mit einer neuen Datenbank begonnen. Die wurde dann auch vollständig eingerichtet.
Zu den Daten die von einer Wetterstation kommen noch eine Frage - eher eine Grundlagenfrage: Woher weiß weewx, wohin z.B. die Daten des Bodenfeuchtesensors des gw2000 in der Tabelle archive in der sqlite Datenbank geschrieben werden sollen. Ist das Aufgabe der field_map in der Datei/dem Treiber gw1000.py - dort findet ja ein mapping statt: "WeeWX field name: Gateway device field name". Und WeeWX field name ist dann gleich dem Namen der Tabellenspalte?
Ist das irgendwo in der WeeWX Doku beschrieben und ich finde es nur nicht?
speerwerfer hat geschrieben: ↑26 Jan 2023, 14:33
eher eine Grundlagenfrage: Woher weiß weewx, wohin z.B. die Daten des Bodenfeuchtesensors des gw2000 in der Tabelle archive in der sqlite Datenbank geschrieben werden sollen. Ist das Aufgabe der field_map in der Datei/dem Treiber gw1000.py - dort findet ja ein mapping statt: "WeeWX field name: Gateway device field name". Und WeeWX field name ist dann gleich dem Namen der Tabellenspalte?
Ist das irgendwo in der WeeWX Doku beschrieben und ich finde es nur nicht?
Martin
Ja, es ist in der weewx Doku beschrieben - Google Stichwort github, gw1000, wiki bringt Dir https://github.com/gjr80/weewx-gw1000/wiki
Zunächst ist es zielführend, den Datenfluß zu verstehen:
Im WiKi findest Du die Fieldmap - die Fieldmap des Ecowitt Gateway API interfaces (das, was der Ecowitt-Gateway-Treiber als API Antwort vom der GW1000, GW1100, GW2000, WN19x0, WH2650 Konsole erhält, das dann einem weewx Feld (intern) zugeordnet wird).
Es gibt nun mehrere Wege, die weewx Felder einem Datenbankfeld zuzuordnen kann (sollte entweder im Ecowitt Gateway WiKi, s.o., oder in der weewx HauptDoku (www.weewx.com/docs.html) beschrieben sein.
Wenn eine solche Zuweisung existiert (z.B. via FieldMap in weewx.conf), füllt weewx am Ende eines Loop-Intervalls (Konsolenabfrageintervalls, in dem mehrere Abfragen stattfinden können und dann gemäss der sogenannten Akkumulatoren zusammengefasst werden [z.B. min, max, avg, sum, ....]) die interne Datenbankschnittstelle und speichert diesen Datensatz ab - d.h. jedes zugeordnete Feld wird mit den Intervalldaten gefüllt, mit dem Zeitstempel versehen, und in die Datenbankfelder des Datenbankdatensatzes übertragen (abgespeichert, archiviert).
Im WiKi findest Du die Fieldmap - die Fieldmap des Ecowitt Gateway API interfaces (das, was der Ecowitt-Gateway-Treiber als API Antwort vom der GW1000, GW1100, GW2000, WN19x0, WH2650 Konsole erhält, das dann einem weewx Feld (intern) zugeordnet wird).
OK, der Datenfluss war mir schon klar. Und die Fieldmap im Ecowitt Treiber gw1000.py hatte ich ja auch gefunden. Ich war nur davon ausgegangen, das mit "WeeWX field name" bei dieser Fieldmapp schon ein Datenbankfeld in der Archivtabelle gemeint ist. Das scheint aber nicht der Fall zu sein. Wenn ich dich richtig verstanden habe, kann dieses weewx Feld (intern), welches über den Loop in WeeWX landet, innerhalb von weewx noch mal auf ein Datenbankfeld gemappt werden. Dass muss ich mir noch mal genauer ansehen.
Da in der Fieldmap in der gw1000.py aber als "WeeWX Field" Bezeichner auftauchen, die sicher Ecowittspezifisch sind und in einer nackten WeeWX Installation unbekannt sein dürften, scheint es so zu sein, das ich mir beliebige WeeWX Feldnamen (intern) in einem Treiber ausdenken kann und damit dann Daten an die Loop weitergereicht werden. Die Daten werden ja vom Treiber per Python Dictionary an WeeWX in den Loop übergeben. Wenn das stimmt müsste WeeWX dann generisch alle im Dictionary vorhandenen Wertepaare versuchen in die Datenbank zu schreiben. Und dazu muss ja dann auch ein mapping vorhanden sein. Ich werde mir die WeeWX Doku noch mal genauer ansehen. Bisher hab ich dazu nicht das richtige gefunden.
speerwerfer hat geschrieben: ↑26 Jan 2023, 19:23
Ich war nur davon ausgegangen, das mit "WeeWX field name" bei dieser Fieldmapp schon ein Datenbankfeld in der Archivtabelle gemeint ist. Das scheint aber nicht der Fall zu sein. Wenn ich dich richtig verstanden habe, kann dieses weewx Feld (intern), welches über den Loop in WeeWX landet, innerhalb von weewx noch mal auf ein Datenbankfeld gemappt werden. Dass muss ich mir noch mal genauer ansehen.
Richtig - weewx hält ja durchaus Daten vor [kann vorhalten] ($current), die nicht in der Datenbank abgespeichert werden (müssen), sich aber in einem Report (Skin) sehr wohl darstellen lassen.
Erst wenn ein Mapping (z.B. FieldMap Extension in weewx.conf - wobei es für jede Ebene eine FieldMap gibt/geben kann - hier ist die in weewx.conf gemeint, die das Mapping macht. StdCalculate wäre auch eine Möglichkeit) existiert, werden die Akkumulator-Daten auch in die/der Datenbank abgespeichert.
Wenn man keine neuen/eigenen DB-Felder in der DB anlegt sondern vorhandene umwidmet (repurpose), findet die Zuweisung in [StdCalculate] statt.
Ich habe das bei meinen Sensoren so gemacht - es gibt ja genügend Felder im wview_extendend DB-Schema.
Allerdings ist ein neues Schema mit den jeweils passenden Feldern sicherlich übersichtlicher und sozusagen state-of-the-art
Zuletzt geändert von Gyvate am 26 Jan 2023, 19:58, insgesamt 2-mal geändert.
[StdCalibrate]
[[Corrections]]
hail = rain_piezo if rain_piezo is not None else None
hailRate = rrain_piezo if rrain_piezo is not None else None
signal1 = ws80_sig * 25 if ws80_sig is not None else None
signal2 = wh31_ch1_sig * 25 if wh31_ch1_sig is not None else None
signal3 = wn34_ch1_sig * 25 if wn34_ch1_sig is not None else None
signal4 = wh40_sig * 25 if wh40_sig is not None else None
signal5 = wh45_sig * 25 if wh45_sig is not None else None
signal6 = wh57_sig * 25 if wh57_sig is not None else None
signal7 = wh51_ch1_sig * 25 if wh51_ch1_sig is not None else None
signal8 = wn35_ch1_sig * 25 if wn35_ch1_sig is not None else None
notwendig.
Einige Einträge davon (z.B. raingain) gehen von dem von mir abgeänderten GW1000-Treiber bzw. Interceptor-Treiber (z.B. runtime) aus.
Werners Darstellung ist ein gutes (real existierendes) Beispiel für die Kombination von neuen DB-Feldern mit Hilfe von field map extensions und StdCalibrate (weil hier der Hagel in piezo-Regen umgewidmet wird).
In der pure and applied approach hätte man für den Piezo-Regen ebenfalls neue Felder angelegt - aber so geht's natürlich auch - und gesonderte Hagelsensoren haben wir bislang bei Ecowitt noch nicht.
Ich danke Euch für Eure Antworten. Das ist jetzt auch alles soweit klar.
Was mich etwas wundert: Die Doku von weewx ist ja sehr umfangreich. Aber zu dem Thema Mapping schweigt sie sich meiner Meinung nach doch aus. Ich hab jetzt noch einmal gezielt in der Doku gesucht und mit den Begriffen mapping und fieldmap bzw. field_map nicht wirklich erleuchtendes gefunden. Da es sich hier ja um einen grundlegenden Mechanismus in weewx handelt, den man verstehen muss, wenn man über die Standardinstallation hinaus etwas anpassen will, hätte ich schon erwartet, das dazu etwas niedergeschrieben ist. Oder suche ich mit den falschen Begriffen?