diff --git a/docs/BEDIENUNG.md b/docs/BEDIENUNG.md index 172f4dd..f7e4015 100644 --- a/docs/BEDIENUNG.md +++ b/docs/BEDIENUNG.md @@ -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 diff --git a/docs/BETRIEB.md b/docs/BETRIEB.md index 335a7b5..7b6d896 100644 --- a/docs/BETRIEB.md +++ b/docs/BETRIEB.md @@ -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: ; Zweitweg: ): `, + 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=" "` 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 ` (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//`, 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 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 +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) | diff --git a/docs/wissen/OFFENE-FAEDEN.md b/docs/wissen/OFFENE-FAEDEN.md index 3e79c06..778b69c 100644 --- a/docs/wissen/OFFENE-FAEDEN.md +++ b/docs/wissen/OFFENE-FAEDEN.md @@ -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).