WH57 und Anzeige WeeWX

[vulpax]

Guten Abend.

Heute habe ich einen WH57 bekommen und mit einem GW1101 verbunden. Die Anzeige in der Webgui des GW ist in Ordnung. Gerne möchte ich die Daten des WH57 auch Richtung WeeWX bekommen. Die interceptor.py habe ich angepasst wie bei Github unter https://github.com/matthewwall/weewx-in ... /issues/69 beschrieben.

Die Anzeige bleibt aber weiterhin aus. Hat jemand eventuell eine gleiche Konstellation und hat einen Rat, warum die Daten des WH57 nicht Richtung WeeWX (neowx-material Skin) gesendet bzw. dort angezeigt werden? Ich vermute, dass ich noch einige Einstellungen bzw. Anpassungen in der .py sowie der weewx.conf vornehmen muss, unklar aber welche genau.

Edit, sollte das in der falschen Rubrik gelandet sein, gerne verschieben. War mir nicht sicher ob Hardware (Ecowitt) oder Software.

[Gyvate]

die Matthew Wall Version (sofern sich das nicht mittlerweile geändert hat) ist nur eine Basisversion, in der die Zusatzsensoren nicht berücksichtigt sind.
@Werner hat einen erweiterten Interceptor Treiber (mittlerweile unter einem anderen Namen) erstellt und auch die dazu benötigten Einheitenbeschreibung in der extensions.py erstellt. Der Treiber heisst jetzt Ecowittcustom
Diese Erweiterungen kannst Du von
https://www.pc-wetterstation.de/weewx/w ... custom.zip
herunterladen, die ReadMe Datei lesen und den Ecowittcustom Treiber analog zum Interceptor-Treiber installieren.
Die extensions.py ist im ZIP-Archiv enthalten.
Ein Installationsprogramm ebenso.

[vulpax]

Der Treiber läuft und angepasst ist auch alles, jedoch weiterhin keine Anzeige. Ich muss da noch etwas weiter schauen. Doch etwas komplexer als angenommen Vielen Dank auf jeden Fall für die Informationen, damit komme ich ans Ziel

[Gyvate]

Der Treiber läuft und angepasst ist auch alles, jedoch weiterhin keine Anzeige. Ich muss da noch etwas weiter schauen. Doch etwas komplexer als angenommen Vielen Dank auf jeden Fall für die Informationen, damit komme ich ans Ziel

Im Zweifelsfall sich mal die Beispiele im englischsprachigen WiKi zu weewx anschauen und verifizieren, dass die richtigen Einträge und Referenzen in weewx.conf, skin.conf und extensions.py gemacht wurden.
weewx Einträge in weewx.conf, skin.conf etc.

[mitschke]

Sind in der Datenbank (in der Tabelle "archive") Einträge in den Spalten "lightning_distance" und "lightning_strike_count" in den Zeilen mit dateTime-Werten zum fraglichen Zeitpunkt?

[Gyvate]

Der Treiber läuft und angepasst ist auch alles, jedoch weiterhin keine Anzeige. Ich muss da noch etwas weiter schauen. Doch etwas komplexer als angenommen Vielen Dank auf jeden Fall für die Informationen, damit komme ich ans Ziel

läuft weewx denn mit dem Simulator-Treiber und zeigt, auch in den Bildern, in der Seasons-Skin etwas an ?
Wenn ja, sind die grundlegenden Dinge richtig konfiguriert.
Dann geht es weiter ins "Eingemachte".
Erscheinen denn in der Seasons-Skin in der Tabelle der aktuellen Daten (current) Werte ? (linke Seite - Bsp. s.u.)
Dort müsste für einen WH57, sofern die Anzeige in index.html.tmpl definiert ist (ggf. in einer Includedatei), ein Eintrag für Anzahl, Entfernung und Zeitstempel zu sehen sein.
Diese sind datenbankunabhängig und stammen aus der aktuellen Kopie der letzten Loop-Tabelle.

weewx-current-20250912.jpg (91.25 KiB) 84 mal betrachtet

[mitschke]

Es gibt keine LOOP Tabelle. In jedem Archivintervall kommen LOOP Pakete, die am Ende des Intervalls akkumuliert in die Datenbank geschrieben werden, sofern Spalten für den jeweiligen Typ existieren.

Die aktuellen Daten des Season Skin stammen aus dem Tag $current, das Daten aus diesem akkumulierten "NEW_ARCHIVE_RECORD" enthält.

So weit zum für den Themeneröffner wahrscheinlich relativ sinnlosen und wenig hilfreichen Blabla, was im Seasons Skin passiert, wenn er den neowx-material Skin verwendet, ist eher belanglos.

Die wichtigste Frage also: kommen Werte von WH57 überhaupt in die Datenbank? Wenn ja, dann wird etwas in der Konfiguration für den Skin anzupassen sein, wenn nicht sogar im skin selbst etwas, ich kenne diesen nur oberflächlich.

Falls keine Daten vom WH57 in der Datenbank sind, würde ich mir erlauben, die Frage zu stellen, warum der Interceptor Treiber verwendet wird und nicht etwa der ecowitt gateway Treiber.

[Gyvate]

Es gibt keine LOOP Tabelle. In jedem Archivintervall kommen LOOP Pakete, die am Ende des Intervalls akkumuliert in die Datenbank geschrieben werden, sofern Spalten für den jeweiligen Typ existieren.

Das stelle ich aber erheblich in Frage.
In weewx gibt es (jedenfalls war das so) zwei Python dictionaries (das sind Tabellen) für die zu sammelnden und die zu speichernden Daten.
#1 sammelt die Loop-Pakete und die darauf angewendeten Akkumulationen
#2 erhält eine Kopie von #1 wenn der Sammelzyklus beendet ist und der neue beginnt
Während #1 im neuen Zyklus neu befüllt wird, dient #2 der Abspeicherung in der Datenbank und der Bereitstellung der aktuellen Daten (Current) in den Reports, die der Imagegenerator in Bilder umsetzt.
Abgespeichert wird allerdings nur, wofür auch ein Datenfeld im Datenbankschema definiert ist.
Ich glaube nicht, dass sich daran in der Zwischenzeit etwas geändert hat - aber man weiss ja nie.

Ich lasse mein Wissen gerne aktualisieren, wenn man mir den Python-Code von weewx zeigt, in dem das (jetzt) anders läuft.

[mitschke]

Wir weichen vom Thema ab, aber: es gibt keine LOOP-Tabelle, nur "archive" und die jeweiligen "archive_day" Tabellen sowie die "archive_day__metadata". Alles andere ist flüchtig, ob $current als fallback aus Werten der Datenbank befüllt wird, weiß ich jetzt nicht auswendig, nehme ich aber auf Grund der Formulierung in der Doku an.

Wie gesagt: das alles hilft dem Fragesteller nicht weiter und ist im Kontext der Frage ohne Belang.

Den Code muss dir niemand zeigen, er ist vollständig und jederzeit auf Github verfügbar. Im übrigen hättest du dir dein Posting sparen können, es enthält im Wesentlichen nichts, was nicht schon in meinem Posting darüber zu lesen ist.

[Gyvate]

Wir weichen vom Thema ab, aber: es gibt keine LOOP-Tabelle, nur "archive" und die jeweiligen "archive_day" Tabellen sowie die "archive_day__metadata". Alles andere ist flüchtig, ob $current als fallback aus Werten der Datenbank befüllt wird, weiß ich jetzt nicht auswendig, nehme ich aber auf Grund der Formulierung in der Doku an.

Aha, es gibt also keine Tabelle, in der die Loop-Daten gesammelt werden, die ich jetzt der Einfachheit halber "Loop-Tabelle" genannt habe. Vermutlich werden dann nach Deiner Darstellung die Daten an einem Siemens-Lufthaken befestigt im freien RAM-Raum gesammelt. Wußte ich noch nicht. Aber, man lernt ja nie aus.
Und ob Daten flüchtig sind oder nicht, macht hier hier ggf. durchaus einen Unterschied. Aber, Du scheinst es ja besser zu wissen.
Übrigens:
"In WeeWX, the $current data you see in templates (like $current.outTemp, $current.barometer, etc.) is not read from the database but instead comes from the in-memory data_binding object that WeeWX maintains while it is running."
upps - die genannte Tabelle ...

Wie gesagt: das alles hilft dem Fragesteller nicht weiter und ist im Kontext der Frage ohne Belang.

Da bin ich eben anderer Meinung ...

Den Code muss dir niemand zeigen, er ist vollständig und jederzeit auf Github verfügbar.

Ach - das hätte ich jetzt nicht gewußt. Auf GitHub. Oh jeh ... Wie konnte ich das nur übersehen ...
Mein Satz bezog sich allerdings darauf, mir die Codestelle(n) zu zeigen, wo das angeblich anders ist.
Vielleicht auch die Stelle, wo genannte dictionaries nicht mehr da sind ...
Ach, die gibt es ja doch (s.o.)

Im übrigen hättest du dir dein Posting sparen können, es enthält im Wesentlichen nichts, was nicht schon in meinem Posting darüber zu lesen ist.

Und, vielen Dank, dass Du Du Dir solche Mühe gibst, meinen Posting-Fußabdruck zu minimieren. Nur schade, dass es dafür keine Zertifikate wie beim CO₂ gibt.