WeeWX, Wechsel von Debian 11 auf 12 die 2te

[Gyvate]

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.

der Eintrag lautet
SoilTemp1 = ExtraTemp9
wenn natürlich eine fieldmap_extension parallel etwas anderes behauptet, geht's natürlich nicht: entweder - oder

Übrigens sind die WN34 Sensoren in der Ecowitt-Nomenklatur keine ExtraTemp Sensoren sondern UserTemp Sensoren.

Hier ein Auszug von Weewx im Debug Modus:
......
Da steht nichts von userTemp, extraTemp 9-12 sind die 4 WN34 hier.

das sind die weewx Namen, nicht die Ecowitt-Namen - ExtraTemp9 ist ja nicht sonderlich aussagekräftig ...
Bei Ecowitt sind ExtraTemp die WH31 Extra-T/RH Sensoren (8 pro Konsole) und UserTemp die WN34 nur Temp Sensoren.
Im Grunde sind die Namen egal, wenn man weiss, was was ist und das richtig anspricht.
Ich stehe halt auf sprechende Namen wo es geht.
Und bei neuen Datenbankspalten bin ich frei in der Namenswahl. Man kann auch bereits bestehende umbenennen ...

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.

Schau Dir mal die weewx Sektion im WiKi an - dort habe ich die Zusammenhänge auf 3.9/4.0 Level beschrieben.
Und klar, wenn man keine Programmierkenntnisse hat, sind Werners Dateien schon schwierig zu verstehen.

[mike69]

der Eintrag lautet
SoilTemp1 = ExtraTemp9
wenn natürlich eine fieldmap_extension parallel etwas anderes behauptet, geht's natürlich nicht: entweder - oder

Damn...

Kann es sein, das seit v5 von WeeWX "[[field_map_extensions]]" nicht mehr unterstützt wird? Sachen wie

Code: Alles auswählen

    [[field_map_extensions]]
        outTempBatteryStatus = wh65_batt

werden ignoriert, das gleiche unter "[StdCalibrate] [[Corrections]" erzeugt Daten.
Habe hier quasi fast alles eingefügt, was früher unter field_map_extensions stand und die fehlenden Spalten erstellt, inkl. soilTempBattx und noch paar andere.

Bei

Code: Alles auswählen

        batteryStatus1 = wh31_ch1_batt
        ...
        batteryStatus8 = wh31_ch8_batt
        outTempBatteryStatus = wh65_batt

 

wird der Batteriestatus links angezeigt. Nur die Spannungen von den WN34 leider noch nicht.
Und das ohne Hand an die ganzen conf, inc und tmpl unter "skins/Seasons/" anzulegen. Sobald die DB Daten hat, werden sie angezeigt und die Grafiken erstellt.

[Werner]

Und klar, wenn man keine Programmierkenntnisse hat, sind Werners Dateien schon schwierig zu verstehen.

Da muss ich jetzt widersprechen!.
Die einzig etwas komplizierte Datei ist die sensors.inc, weil hier alle Station (Davis, Ecowitt usw. ) unterstützt werden.

In den anderen Dateien (current.inc, hilo.inc usw.) braucht der Anwender nur die einzelnen Array-Zeilen ändern.
Im Auswertungsbereich ist nichts zu ändern:
Hier die Hilfe (in Englisch) zum Array = welche Sensoren angezeigt werden.

## The list of observations determines which database fields will be shown in
## the summary as well as the order in which they will be displayed.

## observ-Array ->
## (1:value, 2:labelcolor, ''=black, 3:current or day or yesterday or aqiepa or aqieea or trend or deltatime or wx_binding?, 4:'1')
## 3: = current -> default
## 3: = day -> show avages of the day
## 3: = yesterday -> show avages of the last day
## 3: = 3:yesterday -> at 1:radiation -> radiation.energy_integral.kilowatt_hour_per_meter_squared for yesterday and day
## 3: = trend -> show additonal to value the 24hr trend or 3 hr trend (barometer)
## 3: = deltatime -> for sunShineDur or rainDur or hailDur
## 3: = 'wx_binding?' -> example: 'wx_binding3, WS90' Data are from the Database settings 'wx_binding3' and here additional to the label is ' WS90' added
## 3: = 'daywx_bindig?' or 'trendwx_bindging?' are also allowed. example: 'daywx_binding3, Ultrasonic'
## 3: = aqiepa -> computes pm2_5 Air quality Index EPA
## 3: = aqieea -> computes pm2_5 Air quality Index EEA
## 4: = 1 show, 4: = 0 don't show, although values are available, 4: = 3 Textinformation or Separation

## labelcolor can be general disabled -> #set $usefontcolor = 0

zum Array selbst - hier nur ein paar Einträge davon:

Code: Alles auswählen

#set $observ = [('outTemp','#e85d0d','trend','1'),
('outTemp','#e85d0d','day','1'),
('outTemp','#e85d0d','yesterday','1'),
('outTemp','','wx_binding3','1'),
('heatindex','#b44242','current','1'),
 ...
  ('yearRain_2','','current','1'),
('- - - - - - - - - - - - - - - - - - - - -','','','3'),
($gettext('Data other'),'','','3'),
('outVaporP','','current','1'),
('outSVP','','current','1'),
('outMixingRatio','','current','1'),
('outEquiTemp','','current','1'),
('outThetaE','','current','1'),
('outHumAbs','','current','1'),
('boilingTemp','','current','1'),
]
 

Und damit kann man super einfach testen, ob es diesen Wert und/oder Mapping dazu gibt.
Wenn ein Wert dafür vorhanden erfolgt eine Darstellung, ansonsten nicht, außer man setzt in Array, dass keine Anzeige erfolgen soll.
z.B.: ('windchill','#4282b4','current','0'), damit erfolgt keine Anzeige für Windchill!
Der Array-Eintrag 3 ist für spezial-Darstellungen (andere Datenbank, Gestern, usw.) und muss überhaupt nicht benutz werden.
In der Regel sollte hier "current" stehen, für aktuell gelesenen Wert.

so sind es dann aus

currentinc.png (9.87 KiB) 2466 mal betrachtet

[Gyvate]

unter weewx 4.5 - 4.10 und 5.0 sind die Anzeigen (im Rahmen des verwendeten Datenbankschemas) automatisiert, d.h. gibt es Sensorwerte, werden sie angezeigt.
Man muss jetzt zwei Dinge unterscheiden (--> unser weewx WiKi oder die weewx Doku):

die laufenden, aktuellen Werte ($current, Tabelle links oben in der Seasons Skin) und die Min/Max und Periodenwerte (Tabelle links Mitte und links unten). Für die laufenden Werte braucht man keine Datenbank, die kommen aus der internen Loop-Tabelle.
Für die anderen ($day, $week, ... min/max und die Zeichnungen) werten die Datenbankeinträge genommen.
Es gibt dann im Coding immer solche Abfragen wie z.B.
#if $day.observation has_data
erzeuge das Bild
#end if
Also nur wenn es für den angeforderten Zeitraum auch Daten für die Variable (observation) in der DB gibt, wird etwas gezeichnet.

Analog ist das für die laufenden Werte unter $current - daher wird auch dort nur angezeigt, wo der Treiber etwas im Archivierungsintervall geliefert hat.
Abgespeichert/archiviert wird nur das, wofür es ein Datenbankfeld gibt.
Die field_map oder die field_map_extensions kommen nur fürs Archivieren zum Zuge.

Ausserdem muss für die anzuzeigenden Werte (observations) die Anzeige auch (in entweder skin.conf oder index.html.tmpl) aktiviert sein - sonst wird nichts angezeigt, selbst wenn Daten in der DB sind:

Siehe dazu nachstehender Auszug aus einer skin.conf für die Seasons Skin weewx 4.9.1
(sollte im Prinzip auch bei weewx 5.0 so sein)
###############################################################################
# SEASONS SKIN CONFIGURATION FILE #
# Copyright (c) 2018-2021 Tom Keffer <tkeffer@gmail.com> and Matthew Wall #
# See the file LICENSE.txt for your rights. #
###############################################################################
SKIN_NAME = Seasons
SKIN_VERSION = 4.9.1
###############################################################################
.................................................................................
# The CheetahGenerator creates files from templates. This section
# specifies which files will be generated from which template.
# The following section contains variables that determine which observations
# and plots will be shown in the template files, and their order. Like other
# configuration options, these can be overridden in the weewx config file.

[DisplayOptions]

# Show link to RSS feed?
show_rss = True

# Show link to NOAA-style summary reports?
show_reports = True

# This list determines which types will appear in the "current conditions"
# section, as well as in which order.
observations_current = outTemp, heatindex, windchill, dewpoint, outHumidity, barometer, windSpeed, rain, rainRate, UV, radia>

# This list determines which types will appear in the "statistics" and
# "statistical summary" sections, as well as in which order.
observations_stats = outTemp, heatindex, windchill, dewpoint, outHumidity, barometer, windSpeed, rain, rainRate, ET, hail, h>

# This list determines which types will appear in the RSS feed.
observations_rss = outTemp, inTemp, barometer, windSpeed, rain, rainRate, windchill, heatindex, dewpoint, outHumidity, inHum>

# Some observations display a sum rather than min/max values
obs_type_sum = rain, ET, hail, snow, lightning_strike_count

# Some observations display only the max value
obs_type_max = rainRate, hailRate, snowRate, UV

# The sensor status information is used in the sensor pages. These lists
# determine which database fields will be shown, as well as the order in
# which they will be displayed.
sensor_connections = rxCheckPercent, signal1, signal2, signal3, signal4, signal5, signal6, signal7, signal8
sensor_batteries = outTempBatteryStatus, inTempBatteryStatus, rainBatteryStatus, hailBatteryStatus, snowBatteryStatus, windB>
sensor_voltages = consBatteryVoltage, heatingVoltage, supplyVoltage, referenceVoltage

# This list determines which plots will be shown, as well as the order in
# which they will be displayed. The names refer to the plots defined in
# the ImageGenerator section, without any time span prefix. For example,
# the name 'wind' refers to 'daywind', 'weekwind', 'monthwind', and
# 'yearwind'.
plot_groups = barometer, tempdew, tempfeel, hum, wind, winddir, windvec, rain, ET, UV, radiation, lightning, tempin, humin, >
telemetry_plot_groups =rx, volt

# The list of time spans used within the skin
periods = day, week, month, year

das heisst, unter
observations_current =
observations_stats =
observations_rss =
sensor_connections =
sensor_batteries =
sensor_voltages =
müssen die weewx Variablennamen eingetragen sein
Beispiele s.o. bzw. in der Auslieferungs-skin.conf

im obigen Beispiel sind die Einträge unvollständig, da die Zeile länger als eine Konsolenzeile war und der Nano-Editor die Zeile nicht für die Anzeige umbricht sondern ein ">" Zeichen verwendet.

Übrigens werden Änderungen in der skin.conf direkt nach dem Abspeichern wirksam und werden bei der nächsten Reporterzeugung (Skin-Erzeugung) berücksichtigt. Nur Änderungen in weewx.conf erfordern einen Neustart, da dort weewx die Änderungen kennen muss und nicht nur der Cheetah- bzw. Imagegenerator.

[Gyvate]

Und klar, wenn man keine Programmierkenntnisse hat, sind Werners Dateien schon schwierig zu verstehen.

Da muss ich jetzt widersprechen!.
Die einzig etwas komplizierte Datei ist die sensors.inc, weil hier alle Station (Davis, Ecowitt usw. ) unterstützt werden.

Tut mir leid, dass ich das jetzt sagen muss -
Das sagt meiner Meinung (und Erfahrung) nach der Fachmann, der sich, wie es scheint, nicht mehr in einen normalen Benutzer ohne Programmierkenntnisse hineinversetzen kann.

Weewx ist ein hochkomplexes Programm und auch die Steuerdateien sind für einen Laien nicht einfach zu verstehen und zu durchblicken. Wenn man mal weiss, wie alles geht, ist natürlich alles einfach und unkompliziert.

Das war ja auch nicht als Kritik gemeint sondern einfach eine Feststellung aus dem Alltagsleben.
Ich kann Dir beliebig viele Benutzer bringen, die dort keinen Durchblick haben (und ggf. auch nicht haben müssen).

Programme wie CumulusMX und Meteobridge sind da viel pflegeleichter für den Benutzer. - Allerdings auch nicht so mächtig.

Für Tüftler und Programmierer ist weewx natürlich ein tolles Produkt, gar keine Frage.

Honni soit qui mal y pense

[mike69]

Moin.

Kann es sein, das seit v5 von WeeWX "[[field_map_extensions]]" nicht mehr unterstützt wird? Sachen wie

Code: Alles auswählen

[[field_map_extensions]]
outTempBatteryStatus = wh65_batt

werden ignoriert, das gleiche unter "[StdCalibrate] [[Corrections]" erzeugt Daten.

Es gibt einen fix:
Hier

[Gyvate]

nun denn, wenn der Treiber etwas nicht liefert, kann es weewx auch nicht anzeigen ....
was ein Glück für mich, dass ich nicht mit (eigener) field_map bzw. field_map_extensions arbeite sondern mit einfachen Zuweisungen in der [StdCalibrate] - dann fällt so ein Fehler nicht auf bzw. kommt nicht zum Zuge
Wenngleich eine eigene field_map bzw. ..extensions programmiertechnisch eleganter wären.

[Ton_vanN]

WeeWX4.4 läuft bei mir sehr zuverlässig, und weil keine (signifikante) Änderungen in der Konfiguration, eigentlich kein Bedarf an 'Modernisierung' , aber man muss doch Mitmachen, weil mal in Zukunft für Unterstützung die Stecker gezogen wird .........

Diese Forumberichte überzeugen mir dass vielleicht praktisch ist um Übergang nach WeeWX5.x in einer getrennten Neben-Aufbau zu machen, mit einer 'eigene' Raspberry, ausgestattet mit letzter Version von Raspian und mit letzter Version von WeeWX. Alle Sensor-Schnittstellen sind bei mir drahtlos, also einfache Konfiguration.
Parallelbetrieb bis alles richtig funktioniert,.
Vielleicht in Parallelbetrieb lassen, aus Sicht von Redundanz/Backup:
Raspberry sind nicht teuer, und 'doppel' schadet nicht ......

[mike69]

Klar, warum nicht. Aktuell laufen hier 2 Instanzen von WeeWX.

Was anderes, habe wie oben beschrieben soilTempBattx und soilMoistBattx in der skin.conf unter "sensor_voltages" hinzugefügt.

Jetzt kommt sowas:

Screenshot 2024-02-22 at 12-36-32 Test City.png (20.23 KiB) 2423 mal betrachtet

Zwei Stellen hinter dem Komma reichen eigendlich.

[mitschke]

Ich persönlich kann nur jedem empfehlen, weewx ab Version 5 mit pip in einem venv zu betreiben, wie im quickstart guide beschrieben: https://weewx.com/docs/5.0/quickstarts/pip/

Es kann natürlich sein, dass man für die Migration einer bestehenden Installation ein bisschen Zeit investieren muss, ist man aber mal so weit, ist jede weitere Migration/Wieerherstellung eine Sache von wenigen Minuten.