Doku auf den Stand gebracht: Vorabend, skoda.conf, Wecker-Reste

- autoActions/README: Rahmen gilt heute oder am Vorabend fuer morgen,
  vorabend.sql beim Einrichten, startSolarServer.sh startet drei Prozesse,
  Beispiel der Verkettung wie die echten Automatiken, Neustart ueber SSH
- README: skoda_ladepunkte und skoda.conf, Werkzeuge-Tabelle, Datenbank
  alarm ist geloescht
- config.ini.example: [alarm] und zeit.py entfernt, die gibt es nicht mehr
- Runner-Kopfkommentar verweist nicht mehr auf auto_watering.py

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

autoActions/README.md

@@ -93,8 +93,7 @@ kostete jeder Aussetzer die Automatik für den ganzen Tag — und Aussetzer gab
 es reichlich, weil die Uhr am Geräte-Poll hing und jede dritte Minute
 übersprang. Jetzt gilt die Bedingung fünf Minuten lang (einstellbar), die
 Flanke sorgt weiterhin für genau einen Lauf, und ein Neustart mitten im
-Fenster holt den Lauf nach. Die breiten Zeitfenster in `auto_watering.py`
-folgen derselben Überlegung.
+Fenster holt den Lauf nach.
 
 Beim Sonnenauf- und -untergang ist der Wert ein Versatz, und der kann davor
 oder danach liegen — deshalb dieselben drei Fälle mal zwei: `+ 00:30` eine
@@ -116,7 +115,8 @@ das Fenster zugeht und in diesem Fenster noch nichts passiert ist.
 
 ## Der Rahmen
 
-Vor jeder Auswertung fragt `tag_passt()`, ob der heutige Tag überhaupt zählt.
+Vor jeder Auswertung fragt `tag_passt()`, ob der Tag überhaupt zählt — heute,
+oder bei einer Vorabend-Regel morgen (siehe [Am Vorabend](#am-vorabend)).
 Drei Dinge entscheiden das: die Wochentagsmaske (`weekdays`, ein Bit je Tag,
 Montag ist Bit 0), und Ferien und Feiertage aus `calendar_days`.
 
@@ -222,9 +222,10 @@ vorhandenen „Zeitpunkt". Jede Automatik ist dort ein Messwert, ihr Wert ist
 der Zeitpunkt der letzten Auslösung:
 
 ```
-Wecker Magdalena        um 05:50                    → Licht auf Wakeup
-Rollladen Magdalena     Wecker Magdalena + 00:10
-                        UND Sonnenaufgang ab + 00:00 → Rollladen auf
+Wecker Magdalena          um 05:50                        → Licht auf Wakeup
+Wecker Magdalena Rollos   Wecker Magdalena ab + 00:10
+                          UND Sonne Ost > 200 Lux         → Rollläden auf
+Schlafzimmer morgens      Wecker Magdalena Rollos ab + 00:00 → Rollladen auf
 ```
 
 Der Editor braucht dafür keine Zeile Änderung. Er listet Geräte und deren
@@ -387,6 +388,7 @@ Parameter dort keine eigene URL — ihr Name *ist* der Platzhalter.
 cp config.ini.example config.ini      # ausfüllen: Datenbank, MQTT, Tahoma
 mysql -h 127.0.0.1 -P 3310 -u homeMesh -p homeMesh < automatik_ausloeser.sql
 mysql -h 127.0.0.1 -P 3310 -u homeMesh -p homeMesh < rahmen_erweitern.sql
+mysql -h 127.0.0.1 -P 3310 -u homeMesh -p homeMesh < vorabend.sql
 python3 fetch_calendar.py             # Feiertage und Ferien holen
 python3 autoaction_runner.py --once --dry-run --verbose   # Probelauf
 ```
@@ -398,8 +400,9 @@ Messwerte darunter legt der Runner selbst an. Ohne das Skript läuft alles
 wählen.
 
 `rahmen_erweitern.sql` gehört zum Rahmen: es beschriftet `on_vacation` und
-`on_holiday` mit ihren drei Bedeutungen und legt `once_per_day` an. Beide
-Skripte sind idempotent — ein zweiter Lauf schadet nicht.
+`on_holiday` mit ihren drei Bedeutungen und legt `once_per_day` an.
+`vorabend.sql` legt `next_day` an. Alle drei Skripte sind idempotent — ein
+zweiter Lauf schadet nicht.
 
 `--dry-run` schaltet nichts, protokolliert aber jedes Kommando, das geschickt
 würde. `--once` macht einen einzigen Durchlauf.
@@ -412,13 +415,15 @@ nicht im Web-Verzeichnis:
 ```
 /volume1/homes/wagner/SolarManager/
 ├── solarManager.py
-├── startSolarServer.sh          startet beide, siehe unten
+├── gatherRainData.py
+├── startSolarServer.sh          startet alle drei, siehe unten
 └── autoActions/
     ├── autoaction_runner.py
     ├── transports.py
     ├── fetch_calendar.py
     ├── automatik_ausloeser.sql  einmalig, siehe Einrichten
     ├── rahmen_erweitern.sql     einmalig, siehe Einrichten
+    ├── vorabend.sql             einmalig, siehe Einrichten
     └── config.ini               Zugangsdaten, nicht im Git
 ```
 
@@ -427,10 +432,13 @@ Das Web-UI kennt diesen Pfad nicht — Browser und Runner reden ausschließlich
 sobald im Browser etwas gespeichert wurde; ein Neustart nach jeder Änderung ist
 nicht nötig.
 
-`startSolarServer.sh` startet `solarManager.py` und den Runner gemeinsam und
-beendet vorher, was schon läuft. Aufgerufen wird es beim Booten (auf der
+`startSolarServer.sh` startet `solarManager.py`, den Runner und
+`gatherRainData.py` gemeinsam und beendet vorher, was schon läuft. Aufgerufen wird es beim Booten (auf der
 Synology über den Aufgabenplaner, Ereignis „Hochfahren", als root); dasselbe
-Skript von Hand aufzurufen ist der normale Weg, den Runner neu zu starten.
+Skript von Hand aufzurufen ist der normale Weg, den Runner neu zu starten —
+als `wagner` genügt, ohne sudo. Über SSH abgekoppelt, damit die Prozesse das
+Abmelden überleben:
+`setsid nohup bash startSolarServer.sh > /tmp/restart_solar.out 2>&1 < /dev/null &`.
 Zwei Instanzen dürfen nie gleichzeitig laufen — sie würden jedes Kommando
 doppelt schicken und sich gegenseitig vom MQTT-Broker werfen, weil beide
 dieselbe Client-Kennung benutzen. Genau davor schützt das Beenden am Anfang.