Doku: das Meteogramm beschrieben, falsche Quellenangabe richtiggestellt

doku/meteogramm.md: der Weg der Daten, welche Groessen links vom Jetzt-Strich
gemessen und welche vorhergesagt sind, die vier Tabellen samt der Regel, dass
nichts geloescht wird, das Tupel-Schema des Endpunkts, das Katalog-Vokabular
mit dem Dreizeiler "so kommt eine Spur dazu", und die beiden Entscheidungen
beim Zeichnen (ein SVG ueber alle Felder, Wolkenband als Farbverlauf statt
als Raster).

Dazu zwei Fallen, die sonst niemand wiederfindet: die Archiv-Schnittstelle
von Open-Meteo rechnet alle Zeiten mit dem heute gueltigen Zeitzonenversatz
um, und die Spaltenlage des Endpunkts steht an zwei Stellen und muss
zueinander passen.

Richtiggestellt: doku/datenbank.md und README.md nannten Open-Meteo als
Quelle von weatherHours/weatherDays. Das war nie so - es war OpenWeatherMap,
und seit dem 27.10.2024 gar nichts mehr. Beide Zeilen warfen ausserdem
Messung und Vorhersage in einen Topf; sie sind jetzt getrennt, mit dem
richtigen Schreiber je Tabelle.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

doku/datenbank.md

@@ -98,9 +98,11 @@ Stand heute rund 170 MB, verteilt auf wenige große Reihen:
 | `puffertemp` | ~247.000 | Puffertemperaturen | `solarManager.py` |
 | `wasser`, `zisterne` | ~300.000 | Wasserzähler und Zisterne | `gatherWaterData.py` |
 | `windrad`, `kiga_windrad` | ~255.000 | Windräder | `solarManager.py` |
-| `weatherStation`, `weatherHours`, `weatherDays` | ~220.000 | eigene Wetterstation, Vorhersage | Wetterbrücke, Open-Meteo |
-| `daylight` | 663 | Sonnenauf- und -untergang je Tag | Vorhersage-Job |
-| `simPower` | ~82.000 | Ertragsprognose | Prognose-Job |
+| `weatherStation` | ~195.000 | die eigene Wetterstation, alle 5 min | die Station selbst, über `/volume1/web/weatherStation.php` |
+| `weatherHours`, `weatherDays` | ~40.000 / 1.600 | Wettervorhersage **und Archiv**, stündlich bzw. täglich (→ [meteogramm.md](meteogramm.md)) | `gatherForecastData.py` (Open-Meteo) |
+| `weatherTilted`, `weatherForecastLog` | je nach Nutzung | Einstrahlung in Modulebene; die erste Vorhersage je Stunde | `gatherForecastData.py` |
+| `daylight` | 663 | Sonnenauf- und -untergang, nur bis morgen | `solarManager.py` (gerechnet, nicht abgerufen) |
+| `simPower` | ~82.000 | Ertragsprognose, 7 Tage voraus | Solcast, 4×/Tag über `/volume1/web/gatherSolar.php` |
 | `byd`, `byd_zellen` | 1.559 / 492 | BYD-Speicher: alle 5 min Ladestand, SOH, Temperaturen; alle 15 min 128 Zellspannungen und 64 Temperaturen (→ [byd.md](byd.md)) | `gatherBYDData.py` |
 | `skoda`, `skoda_raw`, `skoda_ladepunkte` | ~1.900 | Fahrzeugzustand, Rohantwort, Ladeverlauf im Minutentakt | `gatherSkodaData.py` |
 | `gridCosts`, `gasCosts`, `fuelCosts` | 13 | Preiszeitreihen | Einstellungsseite |
@@ -146,7 +148,10 @@ Wichtig beim Auswerten:
 | `status` | zeigt, bis wohin aggregiert und ab wann ausgedünnt ist |
 
 Ausgedünnt werden `EnergyFlow`, `Heater` und `weatherStation`; das Zielraster
-beträgt 15 Minuten. Was man beim Rechnen auf den Rohdaten wissen muss, steht
+beträgt 15 Minuten. **`weatherHours` und `weatherDays` stehen bewusst nicht
+dabei** — sie sind schon stündlich, und ihre Strahlungswerte sind die eine
+Hälfte des Datenpaares für eine künftige Ertragsprognose (die andere ist
+`EnergyFlow_hourly.pv_kwh`). Was man beim Rechnen auf den Rohdaten wissen muss, steht
 ausführlich im Kopf der SQL-Datei — die wichtigsten Punkte:
 
 * **Alles sind Momentanleistungen**, gemittelt über rund fünf Minuten. kWh