doku: Einstellungen, Stand-Datei, Zeitfenster und Radar-Schalter

- BEDIENUNG.md: Meldungen mit Telegram-Test, Update-Zeitfenster, Modell-Radar,
  Software-Stand, Altreste im Aufräumen, Telegram-Tabelle.
- BETRIEB.md: Einstellungsdatei, Drop-in und Stempel gegen das Nachholen,
  Neustart-Fenster, Radar-Schalter im Deploy, Stand-Datei, FALLBACK mit Grund.
- OFFENE-FAEDEN.md: Altreste stehen jetzt im Aufräumen; was bewusst nicht in
  der Liste steht; tote crontab-Zeile (curator-idle-watchdog.sh).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Hitonabi
2026-09-24 20:37:30 +02:00
co-authored by Claude Opus 5.5
parent 3d8df1c6fd
commit bff8478203
3 changed files with 96 additions and 18 deletions
+22 -4
View File
@@ -41,8 +41,8 @@ Wichtige Knöpfe fragen vorher nach. Was du auslöst, bestätigt eine kurze Meld
- Jede Zeile ist ein Baustein: Betriebssystem, Motor (llama.cpp), llama-swap, Hermes. Du siehst, was läuft, was neu
wäre und was sich ändert.
- Jeden Sonntag um 04:30 aktualisiert sich die Box von selbst; vorher sichert sie, danach prüft sie. Du musst nichts
tun.
- Einmal pro Woche aktualisiert sich die Box von selbst, ab Werk sonntags um 04:30 (verschieben lässt es sich unter
Einstellungen → Update-Zeitfenster); vorher sichert sie, danach prüft sie. Du musst nichts tun.
- „Nach Neuem suchen" schaut sofort nach. „Aktualisieren" spielt einen Baustein sofort ein, „Alles jetzt
aktualisieren" alle nacheinander. Lucy ist dabei ein paar Minuten nicht erreichbar.
- **Festgehalten:** Ging ein Update schief, hat die Box die alte Version zurückgeholt und hält den Baustein fest. Sie
@@ -69,6 +69,9 @@ Wichtige Knöpfe fragen vorher nach. Was du auslöst, bestätigt eine kurze Meld
- **Weitere Einträge:** alle übrigen Modelle. „Modelle selbst suchen" findet Modelle auf Hugging Face und lädt sie.
- **Aufräumen:** Modelle und Ordner, die gerade niemand nutzt, mit Größe und Hinweis. Die Box löscht nie von selbst.
„Löschen" ist endgültig; zurück ginge es nur mit einem neuen Download.
- **Altreste neben dem Betrieb** (unten im Aufräumen): Test-Ordner, alte Umgebungen, alte Arbeitskopien und
abgeschaltete Alt-Units, die nichts mehr nutzt. Die Box kennt sie aus einer festen Liste und zeigt nur, was noch da
ist und von keinem laufenden Dienst gebraucht wird. „Löschen" fragt nach und ist endgültig.
## Dienste und Protokolle
@@ -81,6 +84,20 @@ Absicht; die Android-App wird sie später wieder brauchen.
- **Hugging-Face-Zugang:** nötig für gesperrte Modelle und für schnellere Downloads. Eintragen, speichern, bei Bedarf
löschen.
- **Meldungen:** „Test senden" schickt eine kurze Testmeldung an Telegram, je einen Knopf für die KI-Box und für den
Homelab-Teil. Sie geht über denselben Weg wie jede echte Meldung und als dringend, kommt also auch nachts sofort.
Darunter steht, ob sie raus ist (über Hermes oder direkt an Telegram) oder warum nicht, etwa „Zugangsdatei fehlt"
oder „Telegram lehnt ab". Höchstens ein Test alle 20 Sekunden.
- **Update-Zeitfenster:** an welchem Wochentag und um welche Uhrzeit sich die Box aktualisiert (ab Werk Sonntag
04:30), dazu der nächste Lauf. Neu starten darf sie sich danach nur in den drei Stunden ab der vollen Stunde, also
ab Werk Sonntag 04:00–06:59. Am besten nachts nach der Sicherung (03:30) und vor der Morgenmeldung (07:00).
„Speichern" fragt nach. Ein Termin, der dadurch schon vorbei wäre, wird nicht nachgeholt; der erste Lauf ist der
nächste reguläre. Während eines Update-Laufs lässt sich das Fenster nicht ändern.
- **Modell-Radar:** ob das Radar nachts nach besseren Modellen sucht. „Ausschalten" legt es schlafen, bis du es
wieder einschaltest; auch ein Deploy weckt es nicht. Ein Nachttest, der gerade läuft, endet noch. „Einschalten"
holt keinen verpassten Lauf nach, tagsüber lädt es also nichts.
- **Software-Stand:** welche Version des Orchestrators auf der KI-Box und im Homelab-Teil läuft und seit wann. Laufen
beide mit verschiedenen Ständen, steht ein Hinweis darunter; der nächste Deploy der Box zieht den Homelab-Teil mit.
- **Hermes-Dashboard:** öffnet die eigene Oberfläche von Hermes (Chat, Sitzungen, Cron-Jobs). Hermes fragt nach
seiner eigenen Anmeldung.
@@ -96,8 +113,8 @@ Commander. Heute Nacht gab es …"). Sofort kommen nachts nur dringende Nachrich
| „[Box-Update] Commander, die Wochenpflege der Box ist durch" | Sonntagsbericht, eine Zeile je Baustein | lesen |
| „[Box-Update] … fehlgeschlagen … zurückgerollt … GEPINNT" | Update ging schief, die alte Version läuft wieder, der Baustein ist festgehalten | nichts nötig; bei Gelegenheit unter Updates „Freigeben" |
| „[Box-Update] KRITISCH: …" (sofort, auch nachts) | Update und Rückweg sind gescheitert | Box ansehen (unten), Hilfe holen |
| „[Box-Update] Neustart steht an … Wartungsfenster" | ein Neustart wartet auf Sonntag früh | nichts |
| „[Box-Update] Die Box startet jetzt neu …" | geplanter Neustart am Sonntag früh | nichts; sie ist ein paar Minuten weg |
| „[Box-Update] Neustart steht an … Wartungsfenster (…)" | ein Neustart wartet auf das Wartungsfenster (ab Werk Sonntag früh) | nichts |
| „[Box-Update] Die Box startet jetzt neu …" | geplanter Neustart im Wartungsfenster | nichts; sie ist ein paar Minuten weg |
| „[Box-Update] Sonntags-Update mit Fehler beendet" oder „Auto-Update abgebrochen" | der Update-Lauf selbst ist abgebrochen, nichts wurde eingespielt | Seite Updates ansehen, Hilfe holen |
| „[Box-Problem] …" | der Wächter hat etwas Rotes gefunden | Startseite öffnen, in der Checkliste den Knopf drücken |
| „[Box wieder ok] Erledigt: …" | das Problem ist weg | nichts |
@@ -105,6 +122,7 @@ Commander. Heute Nacht gab es …"). Sofort kommen nachts nur dringende Nachrich
| „[Stack-Radar] …" (samstags) | Wochenbericht über die Box und Neuigkeiten | lesen |
| Daily News (07:00, Text und Sprachnachricht) | die Nachrichten des Tages von Lucy | lesen oder hören |
| „[Alarm] Deploy …" (sofort) | eine neue Version des Box-Warts ließ sich nicht einspielen, die alte läuft wieder | nichts sofort; Bescheid geben |
| „[Test] Testmeldung aus den Einstellungen …" (sofort) | du hast unter Einstellungen „Test senden" gedrückt | nichts; der Meldeweg funktioniert |
## Wenn etwas hakt
+62 -8
View File
@@ -17,7 +17,9 @@ curl -s http://127.0.0.1:9001/api/partner # Lebenszeichen der ande
curl -s http://127.0.0.1:9010/gw/health # Gateway und Motor
bash -lc 'hermes cron list' # Hermes-Jobs (hermes ist über SSH nicht im PATH)
tail -n 50 ~/mc2-notify.log # was zuletzt gemeldet wurde
tail -n 5 /srv/models/mc2-deploy.log # welcher Stand seit wann live ist
tail -n 5 /srv/models/mc2-deploy.log # welche Stände wann live gingen
cat /srv/models/mc2-stand.json # welcher Stand gerade live ist (seit 24.09.)
cat /srv/models/mc2-einstellungen.json # Update-Zeitfenster und Radar-Schalter der Oberfläche
sudo journalctl -u llama-swap -n 100 # Motor (System-Dienst)
```
@@ -39,9 +41,16 @@ sudo journalctl -u llama-swap -n 100 # Motor (System-Dienst)
Morgenmeldung. Zuletzt Gesendetes: `night-queue.txt.zuletzt-gesendet`. Das Skript kürzt außerdem
`~/mc2-notify.log` ab 3 MB auf die letzten 2 MB.
- **Scheitern beide Wege,** steht die Meldung mit `FALLBACK` im Protokoll und geht per `wall` an die
Box-Konsolen (`MC_NOTIFY_OHNE_WALL=1` schaltet `wall` ab).
- **Testen:** `bash ~/mission-control-v2/deploy/notify.sh -s "[Test]" "Testmeldung"`; nachts landet sie in der
Warteschlange, mit `-d` kommt sie sofort.
Box-Konsolen (`MC_NOTIFY_OHNE_WALL=1` schaltet `wall` ab). Seit 24.09. steht im `FALLBACK`-Eintrag auch, warum der
Zweitweg scheiterte: `FALLBACK (telegram fehlgeschlagen: <Ausgabe von hermes send>; Zweitweg: <Grund>): <Text>`,
etwa „Zugangsdatei … fehlt oder ist nicht lesbar“ oder „Telegram lehnt ab, HTTP-Fehler“ (ohne Klammern, damit
`update_verlauf.py` den Eintrag weiter trennen kann).
- **Testen:** Einstellungen → Meldungen → „Test senden“ (je Instanz; `POST /api/einstellungen/telegram-test` bzw.
`/api/homelab/einstellungen/telegram-test`). Der Knopf ruft `notify.sh -d -s "[Test]" …` mit
`MC_NOTIFY_NO_ANNOUNCE=1` (Lucy spricht den Test nicht) und liest das Ergebnis samt Grund über eine Kennung aus dem
Melde-Log (`services/einstellungen.py`). Höchstens ein Test alle 20 s. Von Hand:
`bash ~/mission-control-v2/deploy/notify.sh -s "[Test]" "Testmeldung"`; nachts landet sie in der Warteschlange,
mit `-d` kommt sie sofort.
| Betreff | Absender | Inhalt |
|---|---|---|
@@ -76,7 +85,9 @@ In der Rolle `homelab` prüft der Wächter bisher nur Platte und Partner und mel
- **Selbstreparatur:** Nur ein abgestürzter Dienst (`ActiveState=failed`) wird neu gestartet, höchstens 2× je Stunde
und Hinweis. Ein gestoppter Dienst (`inactive`) wird nur gemeldet. Ein schlafender Dienst (`inactive` und
`disabled`) ist kein Befund.
`disabled`) ist kein Befund. Bei Timer-Läufen schläft der Timer, nicht der Dienst dahinter (der ist `static`):
Ist `mc2-radar.timer` abgeschaltet (Einstellungen → Radar aus), ist ein alter Fehlschlag von `mc2-radar` kein
Befund mehr.
- **Während eines Updates** (ein Prozess `autoupdate.sh`, `update-engine.sh`, `update-swap.sh` oder `hermes … update`
läuft) prüft er Dienste und Kern nicht und repariert nichts. Die Oberfläche zeigt dann „Update läuft".
- **Meldungen:** Rote Hinweise gehen an Telegram und in den Briefkasten, bei Fortbestand alle 6 h erneut; nachts gilt
@@ -88,6 +99,45 @@ In der Rolle `homelab` prüft der Wächter bisher nur Platte und Partner und mel
- Der Wächter ist der einzige Schreiber von `/srv/models/mc2-waechter.json`. Ist sein letzter Takt älter als
5 Minuten, zeigt die Startseite „Wächter schweigt".
## Einstellungen der Oberfläche (Zeitfenster, Radar-Schalter)
Seit 24.09.2026, Logik in `backend/services/einstellungen.py`, Schnittstellen unter `/api/einstellungen`.
- **Eine Datei:** `/srv/models/mc2-einstellungen.json` (`update_fenster: {tag: 1–7, uhrzeit: "HH:MM"}`,
`radar: {an}`). Nur MC2 schreibt sie; `deploy.sh` und `autoupdate.sh` lesen sie. Fehlt sie, gilt So 04:30 und
Radar an. Sie steckt in jeder Sicherung (`mc2-*.json`).
- **Update-Zeitfenster:** Speichern schreibt das Drop-in
`~/.config/systemd/user/mc2-autoupdate.timer.d/zeitfenster.conf` (`OnCalendar=` leer, dann der neue Plan). Ablauf:
Timer stoppen → Drop-in → `daemon-reload` → Stempel `~/.local/share/systemd/timers/stamp-mc2-autoupdate.timer`
auf jetzt → Timer starten. Grund: Der Timer hat `Persistent=true`. Ein laufender Timer rechnet beim Reload mit
seinem letzten Lauf und dem neuen Plan, ein frisch gestarteter mit dem Stempel. Beides hätte einen schon vorbei
gewesenen Termin sofort nachgeholt (so am 24.09. mittags passiert). Scheitert ein Schritt, kommt das alte Drop-in
zurück, und der Timer läuft wieder. Während `mc2-autoupdate.service` läuft, lehnt MC2 das Ändern ab.
- **Neustart-Fenster:** `deploy/wartungsfenster.sh` (von `autoupdate.sh` eingebunden) erlaubt den Neustart nur in
den drei Stunden ab der vollen Stunde des Beginns: So 04:30 → So 04:00–06:59, Sa 23:30 → Sa 23:00 – So 01:59.
Es liest das Fenster mit `jq` aus der Einstellungsdatei; `MC_WARTUNGSFENSTER="<Tag> <HH:MM>"` und
`MC_FENSTER_JETZT` sind Test-Schalter. `MC_AUTOUPDATE_REBOOT_JETZT=1` erzwingt den Neustart wie bisher.
- **Radar-Schalter:** Aus = `systemctl --user disable --now mc2-radar.timer` (ein laufender Nachttest endet noch).
An = `enable`, Stempel `stamp-mc2-radar.timer` auf jetzt, `start` — kein Nachholen, also tagsüber kein Laden.
- **Deploy:** Das Drop-in fasst `deploy.sh` nie an. Steht das Radar auf aus, lässt der Deploy den Timer aus
(`disable --now`) statt ihn wie früher einzuschalten; steht es auf an und läuft der Timer nicht, startet ihn der
Deploy mit Stempel, also ohne Nachholen.
- **Wächter:** Ein ausgeschaltetes Radar schläft (Timer `inactive` und `disabled`) und ist kein Befund; die
Oberfläche zeigt unter Einstellungen „Schläft“.
- **Prüfen auf der Box:**
`systemctl --user cat mc2-autoupdate.timer`, `systemctl --user list-timers mc2-autoupdate.timer mc2-radar.timer`,
`systemctl --user is-enabled mc2-radar.timer`.
## Software-Stand
- **Stand-Datei:** Nach dem Umschalten schreibt `deploy.sh` (nach der Nachprüfung) `/srv/models/mc2-stand.json`:
`commit` (kurz), `betreff`, `commit_datum`, `deploy_zeit`. `deploy/homelab/ausrollen.sh` schreibt dasselbe nach
erfolgreichem `einrichten.sh` in den Container (`/var/lib/mc2/mc2-stand.json`, Eigentümer `mc2`). Beide nutzen
`deploy/stand-schreiben.py` (nur Standardbibliothek, atomar). Scheitert nur das Schreiben, gilt der Deploy trotzdem.
- **Anzeige:** `/api/instanz` liefert `stand` mit, `/api/partner/instanz` den der anderen Instanz; Einstellungen →
Software-Stand zeigt beide und einen Hinweis, wenn sie abweichen. Ohne Stand-Datei liest MC2 den Stand aus git
(`quelle: "git"`, ohne Deploy-Zeit), sonst `unbekannt`.
## Dienste schlafen legen und wecken
- Schlafen legen: `systemctl --user disable --now <unit>` (seit 24.09.: `box-console`, `voice-service`).
@@ -119,7 +169,9 @@ systemd-Einheiten und überleben den Neustart von MC2. Dann den alten Stand merk
`--watch-config` selbst neu. Weicht die lebende Datei nur ab, gibt es einen Hinweis und sonst nichts.
4. Alle Repo-Units nach `~/.config/systemd/user/`, dazu die Drop-ins `mc2-steward.service.d/warmset.conf` und
`mission-control-2.service.d/override.conf`; `daemon-reload`; `enable` für die Units in `AKTIV`; Timer starten
(den Update-Timer nur, wenn er noch nicht läuft).
(den Update-Timer nur, wenn er noch nicht läuft). Das Drop-in `mc2-autoupdate.timer.d/zeitfenster.conf` gehört
der Oberfläche und bleibt unangetastet. Den Radar-Timer schaltet der Deploy nach dem Schalter in
`mc2-einstellungen.json`: aus = `disable --now`, an = `enable` und, falls er nicht läuft, Start mit Stempel.
5. Cron-Skripte `deploy/jobs/*.sh` und `*.py` nach `~/.hermes/scripts/`.
6. Skills `deploy/skills/*` nach `~/.hermes/skills/<name_mit_unterstrich>/`, abgelöste Skills nach
`~/.hermes/skills-archiv/`. Plugins `deploy/hermes-plugins/*` nach `~/.hermes/plugins/`; aktiviert werden sie
@@ -127,7 +179,8 @@ systemd-Einheiten und überleben den Neustart von MC2. Dann den alten Stand merk
7. Neustart von `mc2-gateway`, `mission-control-2` und `mc2-steward`, dann bis zu 60 s Nachprüfung: `/api/health`,
`/gw/health`, Steward aktiv.
Erfolg: eine Zeile in `/srv/models/mc2-deploy.log` und „Deploy <commit> ist live". Danach (Schritt 8) zieht der Deploy den
Erfolg: eine Zeile in `/srv/models/mc2-deploy.log`, die Stand-Datei `/srv/models/mc2-stand.json` und „Deploy <commit>
ist live". Danach (Schritt 8) zieht der Deploy den
Homelab-Teil mit, sobald `box-partner.sh` einen Partner eingerichtet hat: `deploy/homelab/ausrollen.sh` mit der IP aus
`partner.conf`. Scheitert das, bleibt die Box live und es kommt „[Alarm] Deploy"; `MC_DEPLOY_OHNE_HOMELAB=1` lässt
den Schritt aus. Scheitert ein Schritt:
@@ -251,7 +304,8 @@ Update erneut.
| `~/mission-control-v2` | Checkout von `main` (nur über `deploy.sh` ändern) |
| `~/mission-control-v2/backend/.venv` | Python-Umgebung des Box-Warts (Python 3.14) |
| `~/.config/systemd/user/` | User-Units und Drop-ins |
| `/srv/models/` | Modelle, Box-Wart-Zustand (`mc2-*.json`), Sicherungen (`mc2-backups/`), Radar-Downloads (`radar/`) |
| `/srv/models/` | Modelle, Box-Wart-Zustand (`mc2-*.json`, darunter `mc2-einstellungen.json` und `mc2-stand.json`), Sicherungen (`mc2-backups/`), Radar-Downloads (`radar/`) |
| `~/.config/systemd/user/mc2-autoupdate.timer.d/zeitfenster.conf` | Update-Zeitfenster aus der Oberfläche (nur MC2 schreibt es) |
| `/etc/llama-swap/config.yaml` | lebende llama-swap-Config (+ `.bak-*`) |
| `/opt/llamacpp-vulkan/`, `/usr/local/bin/llama-server` | Motor (llama.cpp Vulkan) |
| `/usr/local/bin/llama-swap`, `/usr/local/bin/llama-swap-warmup.sh` | Router und Vorwärm-Skript (Root-Kopie) |
+12 -6
View File
@@ -57,17 +57,23 @@ Technik: [ARCHITEKTUR.md](../ARCHITEKTUR.md), Abschnitt „Der Homelab-Teil“;
- Modelle ohne Rolle (Modelle-Seite, „Aufräumen"): gpt-oss-120b (60 GB), Qwen3-VL-30B-A3B (19 GB), Muse-Glimmer-30B,
alte Drafts. Die Originale von Hirn und Coder sind der Rückweg, Nemotron ist Reserve: beides bewusst entscheiden.
- Reste neben dem Betrieb (Prüfbericht 24.09.): rund 10 GB Test- und venv-Ordner im Home-Verzeichnis, alte Skripte in
`~/.hermes/scripts` (`deploy.sh` legt neue dazu, räumt alte nicht weg), das inaktive Plugin `mc2-memory`,
`~/.hermes/PINNED_VERSION` (veraltet; Pins stehen in `/srv/models/mc2-pins.json`), zwei fremde Dateien im
Hermes-Quellbaum, alte Worktrees unter `~/.hermes/worktrees` und `~/projekte/mc2-referenz`, abgeschaltete
Alt-Units in `~/.config/systemd/user`.
- Reste neben dem Betrieb stehen seit 24.09. im selben Panel unter „Altreste“ (feste Liste in
`backend/services/aufraeumen.py`, am 24.09. auf der Box gemessen, zusammen gut 11 GB): TTS-Test, alter ROCm-Build,
mem0, Kanban-Arbeitsordner, alte venvs, audio.cpp-Test, Avatar, alte Worktrees, Test-Reste, fremde Dateien im
Hermes-Quellbaum, alte Skripte in `~/.hermes/scripts`, Plugin `mc2-memory`, `PINNED_VERSION`, abgeschaltete
Alt-Units. Löschen je Eintrag per Klick.
- Bewusst nicht in der Liste, weil nicht klar tot (bei Gelegenheit von Hand entscheiden): `~/.voice` (die
Spracherkennung schläft nur), `~/.cache`, `~/.opencode` (steht in `~/.bashrc`), `~/.hermes/kanban.db` (Hermes öffnet
sie), die Archive `profiles-archive-20260819.tar.gz`, `~/archiv-aufraeumen-20260820`, `~/wissens-vault`,
`~/.hermes/state-snapshots`, der PBS-Weg, `ampel-waechter.sh`, `night-cron-wrapper.sh` und `pc_path_lookup.*`
(aktive Skills nennen sie).
- Die crontab ruft sonntags `~/.hermes/scripts/curator-idle-watchdog.sh` auf; das Skript gibt es nicht mehr.
## Beobachten
- **25.09. 00:30:** Radar-Neutest Ornith-1.5-35B-A3B (Hirn), jetzt mit Draft-Varianten. **01.10.:** Qwen3.8-Flash-Next
(Coder, passt nur knapp).
- **So 27.09. 04:30:** erster regulärer Sonntagslauf über den Timer; der Bericht kommt mit der Morgenmeldung um 07:00,
der Verlauf steht auf der Updates-Seite.
der Verlauf steht auf der Updates-Seite. Wird das Zeitfenster vorher in den Einstellungen verschoben, gilt das neue.
- **Daily News 07:00:** Die `web_extract`-Werkzeugfehler sollten mit dem Plugin `mc2-web-lesen` verschwunden sein
(Hermes am 24.09. neu gestartet).