Moin.
Eines vorneweg, dieses stundenlange reinschauen und vergleichen der Dateien um zu verstehen, wie was funktioniert gleicht gelegendlich einem Schwein, welches ins Uhrwerk schaut.
Dies und die weiter fallende Lernkurve sind verärgernd und fliessen gelegendlich, was nicht sein sollte, in meine geschriebenen Worte. Dafür entschuldige ich mich.
Das Wissen und die Hilfsbereitschaft der Teilnehmer hier, besonders Ollies, Werners und auch Deine, Gyvate, wissen ich und auch andere zu schätzen.
Sollte mal erwähnt werden.
was heißt dieser Satz ? "erstellt" ? eine DB Spalte angelegt ? SoilTemp1-SoilTemp4 existieren bereits im wview_extended DB Schema ... (genau wie SoilMoist1-4).
Oder meinst Du mit "erstellt" das existierende Datenbankfeld umgewidmet (Englisch: repurposed), was manche etwas unscharf "mapping" nennen ?
Das wäre der praktische und schnelle Weg.
Ja, habe einfach zusätzliche Spalten mit extraTemp9-12 erstellt, die werden jetzt mit Daten gefüttert.
In [StdCalibrate] [[Corrections]] den Eintrag SoilTemp1 = extraTemp9 vornehmen und das war's, da die SoilTemp Felder der gleichen Einheitengruppe wie die ExtraTemp Felder angehören.
Man kann natürlich die weewx fieldmap und deren Bezeichnungen übernehmen; dann werden die gesammelten Sensorwerte direkt in die Datenbank geschrieben (sofern es dort Felder, Spalten gleichen Namens gibt).
Genau das meinte ich mit mappen, die weewx.conf fieldmap nutzen, nicht die Spalten umbenennen.
Leider funzt der Eintag unter "[StdCalibrate] [[Corrections]" nicht, die Spalte soilTemp bleibt leer.
Übrigens sind die WN34 Sensoren in der Ecowitt-Nomenklatur keine ExtraTemp Sensoren sondern UserTemp Sensoren.
Hier ein Auszug von Weewx im Debug Modus:
Code: Alles auswählen
Feb 20 10:51:27 testing weewxd[597]: INFO user.gw1000: GatewayDriver: Packet 2024-02-20 10:51:27 CET (1708422687): {'dateTime': '1708422687', 'daymaxwind': '7.7', 'dayRain': '0.3', 'extraHumid1': '43', 'extraHumid2': '41', 'extraHumid3': '72',
'extraHumid4': '85', 'extraHumid5': '44', 'extraHumid6': '43', 'extraHumid7': '54', 'extraHumid8': '52', 'extraTemp1': '22.2', 'extraTemp2': '22.1', 'extraTemp3': '10.5', 'extraTemp4': '7.8', 'extraTemp5': '23.1', 'extraTemp6': '21.3', 'extraTemp7': '21.9', 'extraTemp8': '14.9', 'extraTemp9': '23.0', 'extraTemp10': '7.8', 'extraTemp11': '8.1', 'extraTemp12': '8.2', 'heap_free': '27944',
'inHumidity': '42', 'inTemp': '22.1', 'leak1': '0', 'lightning_distance': '27', 'lightning_last_det_time': '1707725948', 'lightning_strike_count': '0', 'lightningcount': '0', 'luminosity': '21180.7', 'monthRain': '66.8', 'outHumidity': '78', 'outTemp': '8.1', 'pressure': '1014.3', 'rain': '0.0', 'rainRate': '0.0', 'relbarometer': '1026.3', 'soilMoist1': '82', 'soilMoist2': '80', 'stormRain': '14.5', 'usUnits': '17',
'UV': '1', 'uvradiation': '48.9', 'weekRain': '9.6', 'wh31_ch1_batt': '0', 'wh31_ch1_sig': '4', 'wh31_ch2_batt': '0', 'wh31_ch2_sig': '4', 'wh31_ch3_batt': '0', 'wh31_ch3_sig': '4', 'wh31_ch4_batt': '0', 'wh31_ch4_sig': '4', 'wh31_ch5_batt': '0', 'wh31_ch5_sig': '4', 'wh31_ch6_batt': '0', 'wh31_ch6_sig': '4', 'wh31_ch7_batt': '0', 'wh31_ch7_sig': '4', 'wh31_ch8_batt': '0', 'wh31_ch8_sig': '4',
'wh51_ch1_batt': '1.3', 'wh51_ch1_sig': '4', 'wh51_ch2_batt': '1.7', 'wh51_ch2_sig': '4', 'wh51_ch3_batt': 'None', 'wh51_ch3_sig': '0', 'wh55_ch1_batt': '3', 'wh55_ch1_sig': '4', 'wh57_batt': '2', 'wh57_sig': '4', 'wh65_batt': '0', 'wh65_sig': '4', 'windDir': '255',
'windGust': '3.1', 'windSpeed': '2.2', 'wn34_ch1_batt': '1.28', 'wn34_ch1_sig': '4', 'wn34_ch2_batt': '1.18', 'wn34_ch2_sig': '4', 'wn34_ch3_batt': '1.22', 'wn34_ch3_sig': '4', 'wn34_ch4_batt': '1.22', 'wn34_ch4_sig': '4', 'yearRain': '111.7'}
Da steht nichts von userTemp, extraTemp 9-12 sind die 4 WN34 hier.
Das wview_extended Datenbankbankschema beruht auf einer Vorlage, die sich an einer Davis VP2 orientiert.
Wäre die mittlerweile bekannte maximale Anzahl von Ecowitt Sensoren die Vorlage gewesen, wäre das DB-Schema "größer".
Ist aber nicht so.
Meines Wissens hat Werner Skripte erstellt, mit denen man das wview_extended zu einem "wview_ecowitt" machen kann; d.h. es werden alle "fehlenden" Felder (die nicht im wview_extended DB-Schema enthalten sind) angelegt und auch die entsprechenden Einheitengruppen definiert. Werner hat das für eine maximale Ausprägung des Custom Server Ecowitt-Protokolls gemacht (nicht für das lokale Ecowitt Gate API a.k.a. GW1000 oder telnet API). Also z.B. für einen GW1x00, an dem die maximale Anzahl aller gleichzeitig möglichen Sensoren registriert ist. (siehe Tabelle WiKi).
Das mit der Vorlage der Davis VP2 wuste ich nicht, danke.
Da unsere WeeWX installation ja > 2 Jahre alt ist und mehre Treiberwechsel statt fand inkl. Änderungen etlicher Configs, *.tmpl und *.inc, da wollte ich sauber mit ner nagelneuen Installation anfangen.
Schaut Euch mal die originale current.inc der Seasons und die von Werner an, da sind Welten zwischen... für mich. Ich wüsste gar nicht, wo ich was einfügen sollte.
Eigentlich ist das m.M.n. nicht verwirrend sondern das Ergebnis eines entsprechend durchdachten Datenbankdesigns, das übrigens in der weewx-Doku beschrieben ist.
Ohne Frage. Spreche nicht für die Allgemeinheit, sondern für mich. Und das "meine" Installation nicht funktioniert ist für "mich" verwirrend. Nur so am Rande.
Wenn in der Seasons Skin die aktuelle Wertetabelle (das "Teil" links) nicht (ganz) gefüllt wird, dann sind entweder in der skin.conf oder in der index.html.tmpl (mit current.inc) die Sensoren ("observations") nicht definiert/aktiviert.
Das kommt auf die weewx-Version an; 3.9 bis 4.5 sind anders als 4.10 oder etwa 5.0
Schaue ich mir noch an. Wie erwähnt, die Unterschiede der orig. WeeWX und Werners Dateien sind für einen Python Laien, der nur ein bisschen drag und drop hinbekommt, echt heavy.
Ich sehe z.Zt. eigentlich keinen Mehrwert in der weewx 5.0. Meine produktiven weewx Installationen laufen alle mit 3.9/4.5 skin.conf und index.html.tmpl Definitionen - und das wunderbar mit allen möglichen Ecowitt-Sensoren.
Eine Testinstallation läuft mit weewx 4.10.
Natürlich kann man die skin.conf und index.html.tmpl bis "zum Anschlag" parametrisieren, wie das auch früh mit der neowx-material Skin gemacht wurde. Nachteil: das ganze Coding ist zwar "elegant" aber auch hochgradig undurchsichtig.
Aber jedem Tierchen sein Pläsierchen.
Und warum soll ich mir die Kinderkrankheiten von 5.0 antun ?
Alle benötigten Treiber (Interceptor, Ecowitt Gateway Treiber) laufen auch mit dem "alten" weewx. Die Treiber <--> weewx Schnittstelle hat sich ja nicht geändert.
Hast wahrscheinlich recht damit. Habe zum Glück noch ein altes Backup gefunden, wo es so weit funktioniert.
.