Halaman utama Jelajahi Bantuan
Masuk
patrick
/
Trixy7
1
0
Fork 0
Berkas Masalah 0 Tarik Permintaan 0 Wiki
Pohon: 7969a1e9ff
Ranting Tag
Trixy7
/
docs
/
project_notes
/
issues.md

issues.md 66 KB
Riwayat Mentahan

Work Log - Trixy Voice Assistant

Protokoll der abgeschlossenen Arbeiten. Kurze Referenz - Details in Ticket-System.

Format

  • Datum (YYYY-MM-DD)
  • Ticket-ID (falls vorhanden)
  • Kurze Beschreibung
  • Status
  • Notizen

2026-03-15 — Installer Build-System mit TUI

Status: Abgeschlossen

Beschreibung: Professionelles Installer-System mit Textual-basierter TUI. Baut Installer fuer 4 Modi (server/client/standalone/config) als .tar.gz Pakete. Eigenstaendiges Projekt ohne trixy_core-Import.

Neue Dateien:

  • make_installer/common.sh — Gemeinsame Build-Funktionen (Version parsen, tar erstellen, install.sh generieren)
  • make_installer/make_installer_{server,client,standalone,config}.sh — 4 modus-spezifische Build-Scripts
  • make_installer/exclude_patterns.txt — tar-Excludes (Trainings-/Modelldaten, Cache, Tests)
  • make_installer/installer/app.py — InstallerApp(textual.App) mit F-Key-Navigation
  • make_installer/installer/config.py — InstallerConfig Dataclass mit Validierung
  • make_installer/installer/steps.py — Gewichtete InstallationStep-Definitionen pro Modus
  • make_installer/installer/runner.py — InstallRunner mit async Subprocess, Progress, Abbruch
  • make_installer/installer/menu_context.py — Standalone-Kopie von trixy_core MenuContext/MenuBinding
  • make_installer/installer/views/{system,network,plugins,requirements,agreement,install}_view.py — 6 Tab-Views (F1-F6)
  • make_installer/installer/widgets/{header,footer,log_field}.py — TUI-Widgets
  • make_installer/installer/css/installer.tcss — TUI-Styling
  • make_installer/installer/{agreement.md,plugins.json,requirements.txt} — Ressourcen

Build-Output pro Modus:

  • trixy-{mode}-{version}.tar.gz — Quellcode (Server: 375M, Client: 132M, Config: 512K)
  • trixy-installer-{mode}-{version}.tar.gz — Installer TUI (15K)
  • install-{mode}.sh — Bootstrap-Script (3K)

Notizen:

  • tar-Excludes: trainer/assets (17GB), models/.onnx/pth/pt/bin/gguf, plugins//models, pycache, tests
  • install.sh: Prueft Python >= 3.10, erstellt temporaeres venv fuer textual/rich, startet TUI
  • 9 Server-Schritte (Gewicht=100): extract, apt, hostname, wifi_ap, venv, plugin_deps, dirs, systemd, verify

2026-03-06 — Plugin-basiertes Trainer-Framework

Status: Abgeschlossen

Beschreibung: Einheitliches ML-Trainer-Framework mit ITrainer ABC, TrainerRegistry (Core + Plugin Discovery), TrainerService (multiprocessing.Process mit Queue-Polling), 18 Netzwerk-Commands (9 Request/Response-Paare), 9 ConfigListener-Handler, ConfigConnection-API (9 Methoden), LossChart-Widget (Braille U+2800-U+28FF, Bresenham-Linien, Downsampling), 7 TUI-Views (Trainer-Liste + 6 Sub-Navigation: Info/Settings/Dataset/Optional/Validate/Training).

Neue Dateien:

  • trixy_core/trainer/__init__.py — Package-Init mit Exports (inkl. TrainerApplication-Migration)
  • trixy_core/trainer/enums.py — TrainingState (IDLE→FAILED), TrainerType (CORE/PLUGIN)
  • trixy_core/trainer/dataclasses.py — TrainerInfo, TrainingProgress, ValidationResult, FormSchema
  • trixy_core/trainer/itrainer.py — ITrainer ABC mit Schema/Train/Validate-Methoden
  • trixy_core/trainer/registry.py — Discovery aus core/.py + plugins//trainer.py
  • trixy_core/trainer/service.py — TrainerService(IService) mit Subprocess-Training
  • trixy_core/trainer/application.py — TrainerApplication (migriert aus trainer.py)
  • trixy_core/trainer/core/__init__.py — Core-Trainer Package
  • trixy_core/trainer/core/wakeword_trainer.py — PoC WakewordTrainer mit Settings/Dataset-Schema
  • trixy_core/tui/widgets/loss_chart.py — Braille-Loss-Chart (Train=cyan, Val=magenta)
  • trixy_core/tui/css/trainer.tcss — Trainer-Styles
  • trixy_core/tui/views/trainer_view.py — F7 Trainer-Liste (DataTable)
  • trixy_core/tui/views/trainer_info_view.py — F1 TrainerInfo (StatusTable)
  • trixy_core/tui/views/trainer_settings_view.py — F2 Schema-basiertes Formular
  • trixy_core/tui/views/trainer_dataset_view.py — F3 Dataset-Info + Formular
  • trixy_core/tui/views/trainer_optional_view.py — F4 Optionale Daten (ausblendbar)
  • trixy_core/tui/views/trainer_validate_view.py — F5 Validierung + GPU-Info
  • trixy_core/tui/views/trainer_training_view.py — F6 Start/Pause/Stop/Resume + LossChart

Geaenderte Dateien:

  • trixy_core/network/cmd/config_cmd.py — 18 neue Trainer-Command-Dataclasses
  • trixy_core/network/cmd/__init__.py — Import + Export der Trainer-Commands
  • trixy_core/network/config_listener.py — 9 Trainer-Handler + Imports
  • trixy_core/server.py — TrainerService instanziiert und registriert
  • trixy_core/config_app.py — 9 Trainer-API-Methoden, Trainer-Views-Setup
  • trixy_core/tui/app.py — Trainer-Kontext (TRAINER_SUBVIEW_IDS, F7, Sub-Navigation)

2026-03-07 — Wakeword Trainer v3: Erweiterte Augmentation + Background-Mix

Status: Abgeschlossen

Beschreibung: Wakeword-Trainer v3 mit umfassender Audio-Augmentation nach OpenWakeWord-Vorbild (data.py). Komma-separierte Wakeword-Aliase, Pitch-Shifting, Klangfarbe-/Prosodie-Variation (Piper noise_scale/noise_w_scale), Lautstaerke-Variation, Rausch-Augmentation (white/pink/brown), Background-Mix mit Musik aus assets/ (ffmpeg-Konvertierung in Temp-Dateien), TTS-Engine-Discovery.

Neue Features (gegenueber v2):

  • Komma-separierte Aliase: "Hey Trixy, Trixy, Hallo Trixy, Servus Trixy"
  • Pitch-Shifting per Resampling-Trick (±N Halbtoene)
  • Piper noise_scale → Klangfarbe/Timbre-Variation
  • Piper noise_w_scale → Prosodie/Rhythmus-Variation
  • Lautstaerke-Variation (30%-100%)
  • Rausch-Augmentation: white/pink/brown Noise bei 15-30 dB SNR
  • Background-Mix: Musik aus assets/*/music/ wird per ffmpeg auf 16kHz/16-bit/mono konvertiert, dann mit positiven Samples bei 5-20 dB SNR gemischt
  • TTS-Engine-Discovery: Piper-Modelle + Plugin-TTS-Modelle auflisten
  • 60 deutsche Negativ-Saetze (erweitert von 40)

Geaenderte Dateien:

  • trixy_core/trainer/core/wakeword_trainer.py — v3: Alle Augmentations, Background-Mix, Engine-Discovery

2026-03-06 — Wakeword Trainer (OpenWakeWord + TTS-Datengenerierung)

Status: Superseded by v3 (2026-03-07)

Beschreibung: Realer Wakeword-Trainer basierend auf dem OpenWakeWord Custom-Verifier-Ansatz. Verwendet OWW-Preprocessor fuer Feature-Extraktion (Mel-Spectrogram + Embeddings) und scikit-learn LogisticRegression-Pipeline als Classifier. TTS-Datengenerierung via Piper TTS im F4 Optional Tab fuer synthetische Trainings-Samples.

Architektur:

  1. Positive WAV-Clips (eigene Aufnahmen + TTS-generierte) → OWW-Feature-Extraktion
  2. Negative WAV-Clips (andere Sprache) → OWW-Feature-Extraktion
  3. LogisticRegression auf flattened Features → Pipeline mit StandardScaler
  4. Export als pickle (.pkl) + metafile.json

Neue Features:

  • ITrainer.execute_action(action, params) — Erweiterungspunkt fuer Trainer-Aktionen
  • ConfigTrainerActionRequest/Response — Netzwerk-Commands fuer Trainer-Aktionen
  • TTS-Datengenerierung (Piper TTS): Wakeword-Synthese mit Geschwindigkeitsvariation, Stille-Padding, Resampling auf 16kHz
  • Negativ-Datengenerierung: 40 deutsche Alltagssaetze als TTS-Samples
  • F4 Optional View: Aktions-Buttons (field_type="action") fuer "TTS-Daten generieren" und "Negativ-Daten generieren"

Geaenderte Dateien:

  • trixy_core/trainer/core/wakeword_trainer.py — Komplett neu: Real OWW Training + TTS-Generierung
  • trixy_core/trainer/itrainer.py — execute_action() Methode hinzugefuegt
  • trixy_core/trainer/service.py — execute_action() Delegation
  • trixy_core/network/cmd/config_cmd.py — ConfigTrainerActionRequest/Response
  • trixy_core/network/cmd/__init__.py — Neue Command-Exports
  • trixy_core/network/config_listener.py — _handle_trainer_action() Handler
  • trixy_core/config_app.py — execute_trainer_action() API-Methode
  • trixy_core/tui/views/trainer_optional_view.py — Aktions-Buttons + Status-Anzeige

2026-03-06 — Template-Formatter Erweiterung (PrintText-Port)

Status: Abgeschlossen

Beschreibung: Template-Formatter komplett ueberarbeitet und um Features aus dem C++ PrintText-Projekt erweitert. 5-Phasen-Pipeline: Platzhalter → Math → Logic → String-Ops → Zahlenformat.

Neue Dateien:

  • trixy_core/utils/math_eval.py — Recursive-Descent-Parser fuer mathematische Ausdruecke (+, -, *, /, %, ^, &, |, xor, not, nand, nor). Hex, Scientific Notation, Klammern.
  • trixy_core/utils/logic_eval.py — Ternary-Evaluator (cond ? true : false), Else-If (::), Vergleiche (==, !=, <, >, <=, >=), Typ-Pruefung (===), Versionen, Boolean-Keywords.

Geaenderte Dateien:

  • trixy_core/utils/template_formatter.py — Komplett neu: 5 Phasen, {app.*} Namespace fuer magische Klassenkonstanten, String-Ops (, , , , , , , ), Zahlenformat (, , , )
  • trixy_core/scheduler/service.py — application + event_manager in Scheduler-Kontext injiziert
  • trixy_core/scheduler/action/tts.py — format_template() erhaelt application fuer {app.*}

    • 2026-03-06 — TTSSpeakAction + SchedulerService + Timing-Fixes

    Status: Abgeschlossen

    Beschreibung: Neue Scheduler-Action fuer TTS-Sprachausgabe. SchedulerService in Server registriert. Timing-Bugs in IntervalTrigger/CronTrigger behoben (feuerten jede Sekunde statt konfiguriertem Intervall). TTS-Event-API korrigiert (emit→trigger mit TTSRequest). DuplicateIds in Config-Tool Schedule-Views behoben.

    Neue Dateien:

    • trixy_core/scheduler/action/tts.py — TTSSpeakAction mit Template-Support, Server/Standalone-Modus

    Geaenderte Dateien:

    • trixy_core/scheduler/scheduler.py — TTSSpeakAction registriert, last_fire_time in TriggerContext
    • trixy_core/scheduler/trigger/cron.py — Doppel-Ausfuehrung in gleicher Sekunde verhindert
    • trixy_core/scheduler/service.py — IService-konform (start/stop, Dependencies, application)
    • trixy_core/server.py — SchedulerService registriert
    • trixy_core/tui/views/schedule_trigger_view.py — Container-Replace statt remove_children()
    • trixy_core/tui/views/schedule_action_view.py — Container-Replace (3 Stellen)
    • trixy_core/tui/views/schedule_condition_view.py — Container-Replace (2 Stellen)

    2026-03-05 — Satellite-Config Remote-Editing + Scrolling

    Status: Abgeschlossen

    Beschreibung: Satellite F4 (Konfiguration) ermoeglicht jetzt das Lesen und Schreiben der Client-Config via Server-Proxy. Der Server leitet Config-Anfragen an den Satellite weiter (request_and_wait mit Future-Korrelation). Typ-spezifische Editoren (Select, Bool-Switch, Zahlen mit Validierung) funktionieren wie beim Haupt-Config-View. Ausserdem: PageUp/PageDown scrollt ±5 Zeilen, Mausrad scrollt ±1 Zeile.

    Neue Commands:

    • ConfigSatelliteConfigReadRequest/Response — Config-Lese-Proxy
    • ConfigSatelliteConfigWriteRequest/Response — Config-Schreib-Proxy

    Geaenderte Dateien:

    • trixy_core/satellite/satellite.py — +_pending_responses, +request_and_wait(), +resolve_pending()
    • trixy_core/network/service.py — ClientHandler._handle_message prueft pending responses vor dispatch
    • trixy_core/client.py — +_handle_config_read_proxy(), +_handle_config_write_proxy(), config_listener_enabled Flag
    • trixy_core/config/datasets/client.py — +config_listener_enabled: bool
    • config/client_config.json — config_listener_enabled: false (gleicher Rechner)
    • trixy_core/network/config_listener.py — +_handle_satellite_config_read/write (Proxy-Handler)
    • trixy_core/config_app.py — +request_satellite_config(), +write_satellite_config()
    • trixy_core/tui/views/sat_config_view.py — Komplett umgebaut: Tree + ConfigEditorPanel via Proxy
    • trixy_core/tui/app.py — PageUp/PageDown Bindings, scroll_sensitivity_y=1.0

    Notizen:

    • Config-Proxy: ConfigTool → Server → Satellite → Response → Server → ConfigTool
    • Client handelt ConfigReadRequest/ConfigWriteRequest auf Command-Socket
    • request_and_wait nutzt message_id Korrelation + asyncio.Future
    • config_listener_enabled=false verhindert Port-Konflikt bei Server+Client auf gleichem Rechner

    2026-03-05 — Typ-spezifische Config-Editoren mit Validierung

    Status: Abgeschlossen

    Beschreibung: Config-View (F2) verwendet jetzt typ-spezifische Editoren statt einfachem Text-Input. Jedes Feld bekommt den passenden Editor: Select-Dropdown (Log-Level, Sample-Rate, Channels), Boolean-Switch, validiertes Zahlenfeld (Min/Max), Multi-Select (Wakeword-Modelle, STT-Layer), IP-Adressen-Validierung, Readonly fuer Dicts. Dynamische Optionen (installierte Wakeword-Modelle) werden vom Server abgefragt.

    Neue Dateien:

    • trixy_core/tui/config/__init__.py — Package-Init
    • trixy_core/tui/config/field_registry.py — FieldMeta Dataclass, EditorType Enum, Registry-Builder fuer Server/Standalone/Client, Auto-Inferenz Fallback
    • trixy_core/tui/widgets/config_editors.py — ConfigEditorPanel (dynamischer Editor mit Validierung, emittiert Submitted-Message)

    Geaenderte Dateien:

    • trixy_core/network/cmd/config_cmd.py — +ConfigFieldOptionsRequest, +ConfigFieldOptionsResponse
    • trixy_core/network/cmd/__init__.py — Neue Exports
    • trixy_core/network/config_listener.py — +_handle_field_options(), +_scan_wakeword_models(), List-Typ-Konvertierung in _handle_config_write()
    • trixy_core/config_app.py — +request_field_options() auf ConfigConnection
    • trixy_core/tui/views/config_view.py — Komplett umgebaut: Registry+dynamische Optionen laden, ConfigEditorPanel statt Input+Button
    • trixy_core/tui/css/config.tcss — Neue Styles fuer #config-editor
    • trixy_core/tui/widgets/__init__.py — +ConfigEditorPanel Export

    Notizen:

    • Server: 60 Registry-Felder, Standalone: 65, Client: 31
    • Felder die nicht in der Registry sind werden per Python-Typ inferiert (bool/int/float/list/dict/str)
    • Validierung: IP-Oktett 0-255, Port 1024-65535, Float-Bereiche, Integer-Bereiche
    • requires_restart Flag wird im Editor-Label und bei Speichern angezeigt

    2026-03-05 — F3 Satellites View + Satellite Sub-Main Views

    Status: Abgeschlossen

    Beschreibung: F3-Taste im Config-Tool zeigt je nach Instanz-Typ unterschiedliche Ansichten. Bei Server-Verbindung: Satellites-Liste mit Verbindungsstatus, Buttons fuer Registrierung/Trennen/Loeschen, Auto-Update alle 10s. Selektion oeffnet Satellite Sub-Navigation mit 5 eigenen F-Tasten-Views. Bei Client/Satellite-Verbindung: SubViews direkt als Haupt-Navigation.

    Satellite Sub-Main Views:

    • F1 Info: Alias, Raum, MAC, Version, Hostname, OS, Uptime, Ping
    • F2 Verbindung: 4 Socket-Streams (Command, Audio In/Out, Music) mit Status/Adresse
    • F3 Konversation: Wakeword-Modell/letzte Erkennung, VoiceRec, Konversations-Status (live)
    • F4 Konfiguration: Uebersicht (vorerst readonly, Verwaltung ueber Satellite-eigenes Config-Tool)
    • F5 Updates: Buttons fuer Modell-Updates, Script-Update, Reboot, Assets, Plugins, Test/Diagnose

    Neue Dateien:

    • trixy_core/tui/views/satellites_view.py — SatellitesView (ListView, Aktions-Buttons, periodisches Refresh)
    • trixy_core/tui/views/sat_info_view.py — Satellite F1: Allgemeine Infos
    • trixy_core/tui/views/sat_connection_view.py — Satellite F2: Socket-Verbindungen
    • trixy_core/tui/views/sat_conversation_view.py — Satellite F3: Wakeword/VoiceRec/Konversation
    • trixy_core/tui/views/sat_config_view.py — Satellite F4: Client-Konfiguration
    • trixy_core/tui/views/sat_updates_view.py — Satellite F5: Update-Buttons
    • trixy_core/tui/css/satellites.tcss — Styles fuer Satellite-Views

    Geaenderte Dateien:

    • trixy_core/tui/app.py — Komplett umgebaut: Dual-Modus (Haupt vs Satellite-Kontext), F1-F5/F9/F10 kontextabhaengig, MenuContext-Wechsel im Footer
    • trixy_core/tui/menu_context.py — Numerische Sortierung (f10 nach f9)
    • trixy_core/config_app.py — 5 Satellite-SubViews erstellen, bedingt nach Instanz-Typ
    • trixy_core/network/cmd/config_cmd.py — +ConfigSatelliteDetailRequest/Response (detaillierte Satellite-Infos)
    • trixy_core/network/cmd/__init__.py — Neue Exports
    • trixy_core/network/config_listener.py — +_handle_satellite_detail() (Info/Sockets/Conversation Daten)
    • trixy_core/config_app.py — +request_satellite_detail() auf ConfigConnection

    Notizen:

    • Server: SatellitesView (F3) → Satellite auswählen → Sub-Navigation (F1-F5) → F10 zurueck
    • Client: Satellite SubViews direkt als Haupt-Navigation (F1-F5)
    • Satellite-Detail-Daten per ConfigSatelliteDetailRequest (Socket-Status, Ping, OS-Info)
    • Conversation-View refresht alle 4s statt 10s fuer Live-Status

    2026-03-04 — Config-Tool mit TUI-Framework und Remote-Management

    Status: Abgeschlossen

    Beschreibung: Neuer main.py config Modus — Textual-TUI die sich per TRXI-Protokoll mit einer laufenden Server/Client/Standalone-Instanz verbindet. Alle Instanzen bekommen einen ConfigListener auf Port 2105 fuer eingehende Config-Tool-Verbindungen. F1=Health (System-Metriken, periodisch aktualisiert), F2=Config (Remote-Config lesen/schreiben), F9=Log (Platzhalter).

    Neue Dateien:

    • trixy_core/network/cmd/config_cmd.py — 9 CommandMessage-Dataclasses (ConfigConnect/Accepted/Denied, StatusRequest/Response, ReadRequest/Response, WriteRequest/Response)
    • trixy_core/network/config_listener.py — ConfigClientHandler + ConfigListener IService (Port 2105, Handshake, Status/Config-Handling mit psutil)
    • trixy_core/config_app.py — ConfigConnection (TCP+TRXI Request/Response-Korrelation) + ConfigApplication (Textual-TUI Hauptschleife)
    • trixy_core/config/datasets/config_tool.py — ConfigToolConfig Dataclass
    • config/config_tool_config.json — Default-Konfiguration
    • trixy_core/tui/ — Komplettes TUI-Framework:
      • app.py — TrixyTUI (Textual App, F-Tasten, periodisches Refresh)
      • menu_context.py — MenuContext + MenuBinding
      • views/base.py — MainView / SubMainView Basisklassen
      • views/health_view.py — System-Metriken mit farbigen ASCII-Balken
      • views/config_view.py — Config-Baum mit Inline-Editing
      • views/log_view.py — Platzhalter fuer Live-Logs
      • widgets/header.py — TrixyHeader (Titel + Verbindungsinfo)
      • widgets/footer.py — TrixyFooter (F-Tasten-Leiste)
      • widgets/status_table.py — Key-Value-Tabelle
      • widgets/popup.py — PopupWindow (Modal)
      • css/base.tcss, health.tcss, config.tcss, popup.tcss — Styling

    Geaenderte Dateien:

    • main.py — Neuer config Subparser + run_config() + Docstring aktualisiert
    • trixy_core/network/cmd/__init__.py — 9 neue Config-Exports
    • trixy_core/config/datasets/server.py — config_port: int = 2105 in NetworkConfig
    • trixy_core/config/datasets/standalone.py — config_port: int = 2105 in StandaloneConfig
    • trixy_core/config/datasets/client.py — config_port: int = 2105 in ClientConfig
    • trixy_core/config/datasets/__init__.py — ConfigToolConfig Export
    • config/server_config.json — "config_port": 2105 hinzugefuegt
    • config/standalone_config.json — "config_port": 2105 hinzugefuegt
    • trixy_core/server.py — ConfigListener Import + Instanziierung + Service-Registrierung
    • trixy_core/standalone.py — ConfigListener Import + Instanziierung + Service-Registrierung
    • trixy_core/client.py — ConfigListener Import + Instanziierung + Service-Registrierung

    Abhaengigkeiten: textual, psutil (fuer System-Metriken)

    2026-02-28 — Standalone ↔ Server Datensynchronisation

    Status: Abgeschlossen

    Beschreibung: Bidirektionaler Daten-Sync zwischen Standalone und Server implementiert. Standalone verbindet sich automatisch zum Server wenn WLAN verfuegbar (Probe-Loop). Daten werden per Last-Write-Wins synchronisiert. Erster Consumer: Notes-Plugin.

    Neue Dateien:

    • trixy_core/sync/models.py — SyncItem Dataclass
    • trixy_core/sync/store.py — SyncStore (JSON-per-Entity Persistenz in ./sync_data/)
    • trixy_core/sync/__init__.py — Paket-Exports
    • trixy_core/sync/connection.py — SyncConnection (Command-Only TCP, Port 2101)
    • trixy_core/sync/service.py — SyncService (Standalone-seitig, Probe-Loop + periodischer Sync)
    • trixy_core/sync/handler.py — SyncHandler (Server-seitig, SyncPush/SyncRequest Verarbeitung)
    • trixy_core/network/cmd/sync.py — SyncPush, SyncRequest, SyncResponse, SyncAck Commands
    • plugins/notes/main.py — NotesPlugin (create/list/search/delete Notizen per Sprache)
    • plugins/notes/config.json — Plugin-Konfiguration

    Geaenderte Dateien:

    • trixy_core/application.py — _sync_store Feld + sync_store Property auf IApplication
    • trixy_core/config/datasets/standalone.py — SyncConfig Dataclass + Feld in StandaloneConfig
    • config/standalone_config.json — Neuer sync Abschnitt
    • trixy_core/standalone.py — SyncStore + SyncService Lifecycle
    • trixy_core/server.py — SyncStore + SyncHandler + Message-Handler Registrierung
    • trixy_core/network/cmd/__init__.py — Sync-Commands exportiert

    Architektur:

    • Nur Command-Socket (Port 2101), keine Audio-Ports
    • Handshake identisch zum Client (TRXYHELO → SatelliteConnect → SatelliteAccepted)
    • SyncStore: JSON-per-Entity analog zu Scheduler (./cron/*.json)
    • Last-Write-Wins Merge per updated_at ISO 8601 Vergleich
    • Probe-Loop alle 30s, Sync alle 5min (konfigurierbar)

    2026-03-03 — File-Logging mit ContextVar-Routing und Plugin-Schutz

    Status: Abgeschlossen

    Beschreibung: Automatisches File-Logging-System implementiert mit separaten Log-Dateien pro Plugin und fuer Core-Komponenten.

    Aenderungen:

    • Neue Datei trixy_core/utils/logging/file_router.py: FileLogRouter-Klasse mit ContextVar-basiertem Routing, log_as() Context-Manager, init_file_router()/shutdown_file_router() Funktionen
    • LoggingConfig erweitert: file_log_level, plugin_timeout_seconds, plugin_max_failures
    • debug.py: _output() routet jetzt zusaetzlich zum FileLogRouter (in beiden Modi)
    • IApplication: _init_file_logging() und _shutdown_file_logging() Methoden
    • ServerApplication/StandaloneApplication: File-Logging in initialize()/stop() integriert
    • PluginManager: Timeout-Schutz via _call_plugin() mit asyncio.wait_for(), Auto-Disable nach N Fehlschlaegen, alle Plugin-Lifecycle-Calls in log_as() gewrappt
    • EventManager: component_name Feld in EventHandler, automatische Plugin-Erkennung in register_object(), Handler-Invocation in log_as() gewrappt
    • Config-JSONs aktualisiert mit neuen Feldern

    Ergebnis: logs/core.log fuer Core, logs/plugins/<name>.log pro Plugin

    2026-02-27 — Keyword Intent Matcher (Pre-Filter vor LLM)

    Status: Abgeschlossen

    Beschreibung: LLM-basierte Intent-Erkennung (~9s) durch Keyword-Matcher Pre-Filter ergaenzt. Eindeutige Befehle werden jetzt in <5ms erkannt, LLM nur noch als Fallback.

    Neue Dateien:

    • trixy_core/nlp/keyword_matcher.py — Kern-Matcher mit Pattern-Parsing, Fuzzy-Matching, Sentiment-Analyse

    Architektur:

    • Neue Dekoratoren: @pattern() (stackbar), @example(), Signatur-basierte Slot-Erkennung
    • Pattern-Syntax: (a|b) Pflicht, [a|b] optional, {slot} Slot, {a|b|} inline-optional
    • Doppel-Strategie: Patterns (hochpraezise) + Example-Fuzzy-Match (Fallback)
    • Sentiment: polite/neutral/rude + urgent-Erkennung ueber Floskel-Listen
    • Slots werden automatisch aus Funktionssignatur erkannt (Default = optional)
    • Kompilierte Patterns werden gecached, Refresh nur bei Plugin-Load/Reload
    • Plugins nutzen @intent/@pattern/@example Dekoratoren direkt auf Handler-Methoden

    Einträge

    2026-01-31 - TRIXY-001: Core Framework Implementation

    • Status: Abgeschlossen
    • Beschreibung: Komplettes Trixy Core Framework implementiert
    • Komponenten:
      • Utils (debug, version)
      • Service Container (IService, ServiceContainer)
      • Event System (EventManager, Decorators, EventData)
      • Config System (ConfigManager, Dataclasses)
      • Network Protocol (TrixyProtocol, Encryption)
      • Satellite Management (Satellite, SatelliteManager, RegistrationManager)
      • Plugin System (TrixyPlugin, PluginManager)
      • Application Classes (Server, Client, Standalone, Trainer)
      • CLI Entry Point (main.py)
    • Dateien: 37 Python-Dateien, 4 JSON-Configs
    • Notizen: Alle Module getestet und verifiziert

    2026-01-31 - TRIXY-002: Unit Test Suite

    • Status: Abgeschlossen
    • Beschreibung: Umfassende Unit-Tests für alle Komponenten
    • Details:
      • 244 Tests in 8 Testdateien
      • pytest + pytest-asyncio
      • 100% Testabdeckung für Core-Funktionalität
    • Testdateien:
      • test_utils.py (19 Tests)
      • test_service.py (25 Tests)
      • test_events.py (32 Tests)
      • test_config.py (25 Tests)
      • test_network.py (35 Tests)
      • test_satellite.py (48 Tests)
      • test_plugins.py (33 Tests)
      • test_application.py (27 Tests)
    • Notizen: Alle Tests bestanden

    2026-01-31 - TRIXY-003: Project Knowledge System

    • Status: Abgeschlossen
    • Beschreibung: Projekt-Wissensbasis eingerichtet
    • Dateien:
      • .claude/project-knowledge/ (7 Knowledge-Dateien)
      • docs/project_notes/ (4 Memory-Dateien)
    • Notizen: CLAUDE.md aktualisiert mit Memory-Protokollen

    2026-01-31 - TRIXY-004: Enterprise Extensions Phase 1-4

    • Status: Abgeschlossen
    • Beschreibung: Enterprise-Grade Erweiterungen für Core-Components
    • Komponenten:
      • Utils Extensions: Structured Logging, Decorators (timed, cached, retry, deprecated, validate, rate_limit), Validation, Rate-Limiting
      • Service Extensions: ServiceScopes (Singleton/Transient/Scoped), LazyService, Metrics, CircuitBreaker, GracefulShutdown, DependencyGraph
      • Event Extensions: Middleware (Logging/Timing/Validation), Throttling, Persistence, DLQ, Filtering, Batching, AsyncQueue
      • Network Extensions: Security (AccessController, Rate-Limiting, DDoS-Schutz), TLS (Config, Manager, CertificateGenerator), ConnectionPool
      • Satellite Extensions: High-Level Plugin API (SatelliteAPI, SatelliteProxy, SatelliteCollection, StreamSession)
    • Neue Dateien: ~60 Python-Dateien
    • Notizen: Alle Tests bestanden, imports verifiziert

    2026-02-01 - TRIXY-005: Enterprise Extensions Phase 5

    • Status: Abgeschlossen
    • Beschreibung: Satellite Extensions für Enterprise-Deployments
    • Komponenten:
      • Groups/Zones: SatelliteGroup, GroupConfig, Zone, ZoneManager
      • Load-Balancing: LoadBalancingStrategy, RoundRobinStrategy, LeastConnectionsStrategy, WeightedStrategy, LoadBalancer
      • Failover: FailoverManager, FailoverResult, FailoverPolicy
      • Health-Scoring: HealthMetrics, HealthScorer, ViolationSeverity
    • Neue Dateien: 12 Python-Dateien
    • Tests: 71 Tests in test_satellite_extensions.py
    • Notizen: Zone-Truthiness-Bug behoben, alle Tests bestanden

    2026-02-01 - TRIXY-006: Enterprise Extensions Phase 6

    • Status: Abgeschlossen
    • Beschreibung: Plugin Extensions für Versionierung, Dependencies, Hot-Reload und Testing
    • Komponenten:
      • Versioning: SemanticVersion, VersionRange, VersionChecker, CompatibilityLevel
      • Dependencies: DependencyGraph, DependencyNode, DependencyResolver, CycleError
      • Registry: PluginManifest, PluginCapability, PluginDiscovery, PluginRegistry
      • Hooks: PluginHook, HookPriority, HookResult, HookHandler, HookRegistry
      • Hot-Reload: FileWatcher, WatchEvent, PluginHotReloader, ReloadConfig
      • Testing: PluginTestHarness, TestContext, MockApplication, MockEventManager, MockSatelliteManager, MockPlugin, PluginTestFixture
    • Neue Dateien: 15 Python-Dateien
    • Tests: 65 Tests in test_plugin_extensions.py
    • Notizen: Alle Tests bestanden, Server startet korrekt

    2026-02-01 - TRIXY-007: API-Dokumentation

    • Status: Abgeschlossen
    • Beschreibung: Vollständige API-Dokumentation für alle Core-Module
    • Dokumentations-Dateien:
      • docs/api/README.md - Index mit Architektur-Übersicht
      • docs/api/utils.md - Debug, Logging, Decorators, Validation, Rate-Limiting
      • docs/api/service.md - IService, ServiceContainer, CircuitBreaker, Scopes, Metrics
      • docs/api/events.md - EventManager, Middleware, Throttling, Persistence, DLQ
      • docs/api/config.md - ConfigManager, Environment, Secrets, Migration
      • docs/api/network.md - TrixyProtocol, Encryption, Security, TLS, ConnectionPool
      • docs/api/satellite.md - Satellite, Groups, LoadBalancing, Health, Failover
      • docs/api/plugins.md - TrixyPlugin, Versioning, Dependencies, Hooks, Hot-Reload, Testing
    • Neue Dateien: 8 Markdown-Dateien
    • Notizen: Deutsche Dokumentation mit Code-Beispielen

    2026-02-01 - TRIXY-008: Wakeword-Arbitration

    • Status: Abgeschlossen
    • Beschreibung: Core-Modul für Multi-Satellite Wakeword-Arbitration
    • Komponenten:
      • Candidate: ArbitrationCandidate, CandidateState
      • Window: ArbitrationWindow, WindowConfig, WindowState (1-Sekunden-Zeitfenster)
      • Strategies: LoudestStrategy, ConfidenceStrategy, CombinedStrategy, ProximityStrategy
      • Arbitrator: WakewordArbitrator, ArbitrationConfig, ArbitrationResult
    • Neue Dateien:
      • trixy_core/arbitration/__init__.py
      • trixy_core/arbitration/candidate.py
      • trixy_core/arbitration/window.py
      • trixy_core/arbitration/arbitrator.py
      • trixy_core/arbitration/strategies/__init__.py
      • trixy_core/arbitration/strategies/base.py
      • trixy_core/arbitration/strategies/loudest.py
      • trixy_core/arbitration/strategies/confidence.py
      • trixy_core/arbitration/strategies/combined.py
      • trixy_core/arbitration/strategies/proximity.py
    • Tests: 42 Tests in test_arbitration.py
    • Notizen: Austauschbare Strategien, Deadlock-freies Lock-Handling

    2026-02-01 - TRIXY-009: Enterprise Extensions - Network & Satellite

    • Status: Abgeschlossen
    • Beschreibung: Zusätzliche Enterprise-Komponenten für Network und Satellite
    • Komponenten:
      • Network Retry: NetworkRetry, RetryConfig, RetryStrategy (Exponential/Linear/Constant/Fibonacci/Decorrelated), @with_retry Decorator
      • Network KeepAlive: KeepAliveManager, KeepAliveSession, ConnectionState, RTT-Berechnung
      • Network Compression: Compressor ABC, ZlibCompressor, GzipCompressor, CompressionRegistry
      • Network RPC: CorrelationManager, PendingRequest, RequestState für Request-Response Matching
      • Satellite Capability: CapabilityRegistry, Capability, CapabilityInfo, CapabilityDiscovery, Probes
      • Satellite Metrics: SatelliteMetricsCollector, MetricsAggregator, AggregationType, TimeWindow
    • Neue Dateien: 10 Python-Dateien, 6 Test-Dateien
    • Tests: 188 Tests für neue Komponenten
    • Notizen: ExtensionPoint truthiness Bug behoben

    2026-02-01 - TRIXY-010: API-Dokumentation Update

    • Status: Abgeschlossen
    • Beschreibung: API-Dokumentation für neue Enterprise-Komponenten
    • Aktualisierte Dateien:
      • docs/api/network.md - Retry, KeepAlive, Compression, RPC
      • docs/api/satellite.md - Capability Discovery, Metrics (vollständig)
      • docs/api/README.md - Architektur-Diagramm aktualisiert
    • Notizen: Deutsche Dokumentation mit vollständigen Code-Beispielen

    2026-02-01 - TRIXY-011: Wakeword Detection & Conversation System

    • Status: Abgeschlossen
    • Beschreibung: Vollständiges Wakeword-Detection und Conversation-Tracking System
    • Wakeword-Modul (trixy_core/wakeword/):
      • detector.py: WakewordDetector (OpenWakeWord-Wrapper), WakewordDetection, DetectorConfig
      • audio_buffer.py: AudioBuffer, AudioChunk, AudioBufferPool für Aufnahmen im RAM
      • vad.py: VoiceActivityDetector für Sprach-/Stille-Erkennung
      • service.py: WakewordService (IService) mit vollständigem Workflow
    • Conversation-Modul (trixy_core/conversation/):
      • session.py: ConversationSession mit Turn-Tracking, Follow-Ups, Timeouts
      • manager.py: ConversationManager (IService) für Session-Lifecycle
      • context.py: ConversationContext mit Scopes (Turn, Session, User, Global)
    • Network-Commands (erweitert in trixy_core/network/cmd/wakeword.py):
      • WakewordDetected (mit Audio-Chunks, Wakeword-Type)
      • WakewordSelected, WakewordAbort
      • RecordingComplete, RecordingAck
      • FollowUpRequest, FollowUpResponse
      • ConversationEnd, AssistantResponse, TranscriptionResult, IntentResult
    • Workflow:
      1. Wakeword erkannt → Pause Detection → Arbitration-Request mit Lautstärke
      2. Audio-Aufnahme im RAM während Arbitration-Warte
      3. Bei Auswahl: Aufnahme bis Silence (3s) oder Timeout (60s)
      4. Audio an Server → Verarbeitung → ggf. Rückfragen
      5. Bei Rückfragen: Neue Aufnahme, bis keine Rückfragen mehr
      6. Session beenden → Wakeword Detection fortsetzen
    • Standalone: Immer "ausgewählt", keine Arbitration
    • Tests: 74 Tests in test_wakeword.py und test_conversation.py
    • Notizen: OpenWakeWord-basiert, 16kHz Mono PCM, ONNX-Support

    2026-02-01 - TRIXY-013: Network Transport Layer

    • Status: Abgeschlossen
    • Beschreibung: TCP-Netzwerk-Transport-Schicht für Server-Client-Kommunikation
    • Komponenten:
      • NetworkService (trixy_core/network/service.py):
      • TCP-Server auf 4 Ports (2101-2104)
      • ClientHandler für Command-Verbindungen mit Handshake
      • AudioStreamHandler für Audio-In/Out/Music-Streams
      • KeepAlive-Integration, Broadcast, send_to_satellite
      • ClientConnection (trixy_core/network/client_connection.py):
      • Client-seitige Verbindung mit Handshake
      • Automatische Audio-Port-Verbindung nach Accept
      • Callbacks: on_connected, on_disconnected, on_message, on_audio_out, on_music
      • get_mac_address() Hilfsfunktion
      • MessageHandler (trixy_core/network/message_handler.py):
      • Zentrales Dispatching für Nachrichten
      • EventBridge: Konvertiert Nachrichten zu Events
      • setup_default_event_bridge() mit Standard-Mappings
    • Geänderte Dateien:
      • trixy_core/server.py - NetworkService Integration
      • trixy_core/client.py - ClientConnection statt TODO
      • trixy_core/network/__init__.py - Neue Exports
    • Tests: 30 Tests in test_network_transport.py
      • Integration: Server-Client Verbindung, Handshake, Registrierung
      • Commands: Senden/Empfangen, Broadcast
      • KeepAlive: Ping/Pong-Session
      • Fehlerbehandlung: Timeout, Disconnect-Callback
    • Notizen: Problem behoben wo Server "läuft auf Ports 2101-2104" sagte aber keine echten Socket-Verbindungen existierten

    2026-02-01 - TRIXY-012: Scheduler-System (Cronjob)

    • Status: Abgeschlossen
    • Beschreibung: Flexibles Job-Scheduling-System mit Cron-ähnlicher Syntax
    • Komponenten:
      • Triggers (trixy_core/scheduler/trigger/):
      • CronTrigger: Cron-Ausdrücke (*/5 * * * *, 0 9-17 * * 1-5)
      • IntervalTrigger: Feste Intervalle (Sekunden, Minuten, Stunden)
      • DateTimeTrigger: Einmaliger Zeitpunkt
      • EventTrigger: Reagiert auf EventManager-Events
      • AndTrigger, OrTrigger: Composite Triggers
      • Conditions (trixy_core/scheduler/condition/):
      • Zeit: TimeRangeCondition, DayOfWeekCondition, DateRangeCondition
      • Aktivität: RecentActivityCondition, ActivityCountCondition
      • Sensor: SensorThresholdCondition, SensorChangeCondition, ComparisonOperator
      • State: StateCondition, BooleanCondition, ExistsCondition
      • Composite: AndCondition, OrCondition, NotCondition, XorCondition
      • Actions (trixy_core/scheduler/action/):
      • EmitEventAction, MultiEventAction: Event-Emittierung
      • CallbackAction, MethodAction: Python-Funktionen
      • CommandAction, ScriptAction: Shell-Befehle/Scripts
      • Scheduler (trixy_core/scheduler/scheduler.py):
      • Job-Verwaltung mit Persistierung in ./cron/*.json
      • Automatisches Laden/Speichern
      • Kontext-Management für Conditions
      • Event-Integration
      • Service (trixy_core/scheduler/service.py):
      • SchedulerService (IService) für ServiceContainer
    • Neue Dateien: 18 Python-Dateien
    • Tests: 66 Tests in test_scheduler.py
    • Notizen: Jobs werden als individuelle JSON-Dateien in ./cron/*.json gespeichert

    2026-02-01 - TRIXY-014: Event-basierte Integration

    • Status: Abgeschlossen
    • Beschreibung: TODOs für Event-basierte Warte-Logik implementiert
    • Komponenten:
      • Satellite.speak(): Event-Manager Zugriff über Application-Referenz, löst tts_request Event aus
      • Satellite.play(): Löst stream_start Event aus für Audio/Musik-Wiedergabe
      • Satellite.stop_playback(): Löst stream_stop Event aus
      • SatelliteAPI.say(): Warte-Logik mit asyncio.Future für tts_completed Event
      • WakewordService._wait_for_processing_result(): Event-basiertes Warten für Standalone-Modus
    • Neue Event-Datenklassen (trixy_core/events/event_data/basic.py):
      • TTSRequest: TTS-Anfrage mit request_id, satellite_id, text, voice, speed, volume
      • TTSCompleted: TTS-Abschluss mit success, audio_duration, error
      • StreamStart: Audio-Stream starten mit source, volume, stream_type
      • StreamStop: Audio-Stream stoppen
      • ProcessingResult: Verarbeitungsergebnis für Standalone-Modus
    • Geänderte Dateien:
      • trixy_core/satellite/satellite.py - Application-Referenz, speak(), play(), stop_playback()
      • trixy_core/satellite/satellite_manager.py - Setzt Application-Referenz bei add()
      • trixy_core/satellite/api.py - Warte-Logik mit Future und Handler
      • trixy_core/wakeword/service.py - _wait_for_processing_result() implementiert
      • trixy_core/events/event_data/basic.py - Neue Event-Klassen
      • trixy_core/events/event_data/__init__.py - Neue Exports
    • Tests: 24 Tests in test_event_integration.py
    • Notizen: ML-Trainer TODOs bleiben (wird später implementiert)

    2026-02-01 - TRIXY-015: Client Audio Player & Audio Processing Pipeline

    • Status: Abgeschlossen
    • Beschreibung: Streaming-Audio-Player für Client/Satellite und Audio-Processing-Pipeline für Plugins
    • Komponenten:
      • Streaming Audio Player (trixy_core/audio/player.py):
      • StreamingAudioPlayer: Queue-basierter Audio-Player mit PyAudio
      • AudioOutputManager: Verwaltet TTS und Musik getrennt
      • Sofortiger Playback bei erstem Chunk, Stop-Command-Unterstützung
      • Dynamische Audio-Format-Konfiguration (Sample-Rate, Channels, Sample-Width)
      • Audio Processing Pipeline (trixy_core/audio/processing/):
      • AudioProcessingContext: Kontext mit Position, Track, Wakeword-Status, etc.
      • AudioProcessor: Abstract Base Class für Prozessoren
      • ProcessorPriority: Enum für Pipeline-Reihenfolge (DUCKING, CROSSFADE, VOLUME, etc.)
      • AudioProcessingPipeline: Thread-safe Pipeline-Manager
      • Hilfsfunktionen: apply_volume(), mix_chunks(), fade_chunk()
      • Extension Point (trixy_core/plugins/extensions/points/audio.py):
      • AUDIO_PROCESSOR_POINT: Extension Point für Audio-Prozessoren
      • AudioProcessorExtension: Basis-Extension für Plugins
      • Netzwerk-Befehle (trixy_core/network/cmd/satellite.py):
      • SatelliteAccepted erweitert um TTS/Musik Audio-Format
      • AudioConfigUpdate: Neue Nachricht für TTS-Plugin-Wechsel
    • Geänderte Dateien:
      • trixy_core/client.py - AudioOutputManager Integration, Audio-Format-Handling
      • trixy_core/network/client_connection.py - Audio-Format aus SatelliteAccepted
      • trixy_core/music/player.py - Pipeline-Integration in Playback-Loop
      • trixy_core/music/queue.py - peek_next() Methode
      • trixy_core/music/playlist/playlist.py - peek_next() Methode
      • trixy_core/plugins/extensions/points/__init__.py - Audio Exports
    • Neue Dateien:
      • trixy_core/audio/player.py
      • trixy_core/audio/processing/__init__.py
      • trixy_core/audio/processing/context.py
      • trixy_core/audio/processing/processor.py
      • trixy_core/audio/processing/pipeline.py
      • trixy_core/plugins/extensions/points/audio.py
    • Tests:
      • 57 Tests in test_audio_player.py
      • 43 Tests in test_audio_processing.py
    • Notizen:
      • TTS: 22050 Hz Mono (Piper Standard), Musik: 44100 Hz Stereo
      • Audio-Format wird vom Server bei Connect und Plugin-Wechsel mitgeteilt
      • Pipeline ermöglicht Plugins: Ducking, Crossfade, Equalizer, Effekte

    2026-02-01 - TRIXY-016: Music System Tests

    • Status: Abgeschlossen
    • Beschreibung: Umfassende Unit-Tests für das Musik-System
    • Testbereiche:
      • Track & Metadata (16 Tests): TrackMetadata, Track Datenklassen, Zustandsübergänge
      • Audio Formate (10 Tests): AudioFormat, AudioInfo, DecodedAudio, MP3Decoder
      • LocalFileSource (9 Tests): Scan, Pfad-Management, echte Musikdateien
      • DecoderRegistry (4 Tests): Decoder-Lookup, Extensions
      • Streaming (19 Tests): StreamConfig, StreamStats, StreamSession, AudioStreamer
      • PlayQueue (17 Tests): Queue-Management, Navigation, Play-Next
      • Playlist (15 Tests): Shuffle, Repeat-Modi, Navigation, peek_next
      • Integration (3 Tests): Scan→Queue, Scan→Playlist, Full Pipeline
      • Performance (3 Tests): Scan, Queue, Shuffle mit 1000 Tracks
    • Testdateien: tests/test_music.py
    • Tests: 100 Tests (1 übersprungen wenn kein Decoder)
    • Notizen:
      • Tests mit echten MP3-Dateien aus assets/default/music/
      • Graceful handling wenn pydub/mutagen/ffmpeg nicht verfügbar
      • Performance-Tests bestätigen < 2s für 1000-Track-Operationen

    2026-02-01 - TRIXY-017: Zeit-basiertes Puffer-Management

    • Status: Abgeschlossen
    • Beschreibung: Client-seitiges Puffer-Management mit 2-3 Sekunden Limit für Musik-Streaming
    • Änderungen:
      • PlayerConfig (erweitert):
      • max_buffer_ms: Maximale Pufferzeit in Millisekunden (Standard: 2000ms)
      • prebuffer_ms: Vor-Pufferung bevor Wiedergabe startet (Standard: 200ms)
      • __post_init__(): Berechnet max_queue_size und start_threshold automatisch
      • bytes_per_second Property für Audio-Format-Berechnung
      • buffer_ms Property für aktuelle Queue-Kapazität in ms
      • StreamingAudioPlayer (erweitert):
      • buffer_ms: Aktuelle Pufferzeit in Millisekunden
      • buffer_level: Puffer-Füllstand (0.0 - 1.0)
      • buffer_full: True wenn Puffer >90% voll (Backpressure-Signal)
      • buffer_low: True wenn Puffer <20% (Nachfüll-Signal)
      • stats erweitert um buffer_ms, buffer_level, max_buffer_ms
      • AudioOutputManager (erweitert):
      • TTS: 1 Sekunde max_buffer, 50ms prebuffer (geringe Latenz)
      • Musik: 3 Sekunden max_buffer, 500ms prebuffer (User: "2-3 seconds")
      • Sample-Rate für Musik auf 48kHz geändert
      • Backpressure-Properties: music_buffer_full, music_buffer_low, music_buffer_ms
      • Methoden: can_accept_music_chunk(), can_accept_tts_chunk()
    • Geänderte Dateien:
      • trixy_core/audio/player.py
      • tests/test_audio_player.py (17 neue Tests)
    • Tests: 74 Tests in test_audio_player.py (vorher 57)
    • Notizen:
      • Server-seitige StreamSession hat bereits Backpressure (feed() returns False)
      • Chunk-Cleanup passiert automatisch via queue.get() im Playback-Loop
      • Kontinuierliches Streaming mit Flow-Control durch buffer_full/buffer_low Properties

    2026-02-01 - TRIXY-018: Crossfade-Plugin

    • Status: Abgeschlossen
    • Beschreibung: Plugin für nahtlose Übergänge zwischen Musik-Tracks
    • Plugin-Struktur:
      • plugins/crossfade/main.py - CrossfadePlugin (TrixyPlugin)
      • plugins/crossfade/processor.py - CrossfadeProcessor (AudioProcessor)
      • plugins/crossfade/config.json - Konfiguration
      • plugins/crossfade/tests/test_crossfade.py - 34 Tests
      • plugins/crossfade/tests/generate_test_mixes.py - Demo-Generator
    • Komponenten:
      • CrossfadeConfig: duration_ms, fade_curve, min_track_duration_ms, prebuffer_duration_ms
      • CrossfadeProcessor:
      • Integriert in AudioProcessingPipeline (Priorität: 400/CROSSFADE)
      • Erkennt Track-Ende via context.is_near_end und context.has_next_track
      • Pre-buffert nächsten Track (6 Sekunden Standard)
      • Mischt Chunks mit mix_chunks() Hilfsfunktion
      • Fade-Kurven: linear, cosine, exponential
      • Nur Crossfade wenn nächster Track vorhanden
      • Standalone-Funktionen:
      • crossfade_audio(): Mischt zwei Audio-Bytestreams
      • save_wav(): Speichert PCM als WAV
      • load_wav(): Lädt WAV-Datei
    • Test-Audio-Dateien (in assets/default/music/crossfade_tests/):
      • frequency_crossfade_*.wav - Sinuswellen mit verschiedenen Kurven
      • duration_crossfade_*.wav - Verschiedene Crossfade-Dauern
      • sweep_crossfade.wav - Frequenz-Sweeps
      • beat_crossfade.wav - Beat-Übergänge
      • chain_crossfade_4_tracks.wav - 4-Track Demo-Mix
    • Tests: 34 Tests (29 passed, 5 skipped ohne ffmpeg)
    • Notizen:
      • Für MP3-Tests: ffmpeg/ffprobe installieren
      • Generator-Script: python plugins/crossfade/tests/generate_test_mixes.py
      • Mit echten Musikdateien: --with-music Flag (erfordert ffmpeg)

    2026-02-01 - TRIXY-019: Asset-Manager

    • Status: Abgeschlossen
    • Beschreibung: Profil-basiertes Asset-Management-System für Trixy
    • Komponenten:
      • AssetManager (trixy_core/assets/manager.py):
      • Pfad-Auflösung mit Profil-Fallback auf "default"
      • Asset-Typ-Erkennung (Audio, Music, Image, Video, Config, Data, Model)
      • LRU-Cache mit konfigurierbarem TTL für Performance
      • Thread-safe Implementierung
      • Statistik-Funktionen und Asset-Listing
      • Profil-Wechsel mit automatischer Cache-Invalidierung
      • Asset-Kopieren zwischen Profilen
      • AssetService (trixy_core/assets/service.py):
      • IService-Implementation für ServiceContainer
      • ServicePriority.CRITICAL für frühen Start
      • Delegierte Methoden für einfachen Zugriff
      • Konfiguration aus Application.config (assets_directory, profile)
      • AssetInfo: Detaillierte Asset-Metadaten (Pfad, Größe, Typ, Checksum, MIME)
      • AssetType: Enum für Asset-Kategorisierung
      • AssetNotFoundError: Spezifische Exception mit Suchpfad-Details
    • Features:
      • manager.get("audio/success.wav") → Sucht in Profil, Fallback auf Default
      • manager.get_audio("success.wav") → Typ-spezifischer Zugriff
      • manager.list_assets(AssetType.AUDIO) → Alle Audio-Assets
      • manager.get_stats() → Statistiken über alle Assets
      • manager.copy_to_profile("audio/error.wav") → Asset in Profil kopieren
    • Neue Dateien:
      • trixy_core/assets/__init__.py
      • trixy_core/assets/manager.py
      • trixy_core/assets/service.py
      • tests/test_assets.py
    • Tests: 72 Tests in test_assets.py
    • Notizen: Profil "default" wird immer als Fallback verwendet

    2026-02-01 - TRIXY-020: NLP Plugin System

    • Status: Abgeschlossen
    • Beschreibung: Pluggable NLP-System für Intent-Erkennung und Antwortgenerierung
    • Komponenten:
      • trixy_core/nlp/ - Core NLP-Infrastruktur
      • provider.py - NLPProvider, NLPConfig, NLPContext, NLPResult, NLPState
      • intent_registry.py - IntentRegistry (Singleton), IntentDefinition, IntentSlot
      • decorators.py - @intent Decorator für Plugin-Methoden
      • handler.py - IntentReceivedData, IntentResult Datenklassen
      • plugins/nlp_llm/ - LLM-basiertes NLP-Plugin
      • Unterstützt llama-cpp-python und Ollama Backends
      • Optimiert für Raspberry Pi 5 (4GB RAM)
      • Dual-Backend: lokal (llama-cpp) oder Server (Ollama)
      • Event-System erweitert: CreateOutputText, OutputTextCreated
      • PluginManager: Automatische Intent-Handler-Entdeckung via @intent
    • Tests: 38 Tests in tests/test_nlp.py (alle bestanden)
    • Event-Flow:
      1. speech_recognized → NLP Plugin
      2. NLP verarbeitet → intent_received (mit optionalem response_text)
      3. Intent-Handler ausführen
      4. Falls keine Antwort → create_output_text → Response Generator → TTS
    • Notizen:
      • Empfohlene Modelle für Pi 5: Llama 3.2 1B (~800MB), Qwen2.5-0.5B (~400MB)
      • System-Prompt baut verfügbare Intents dynamisch ein

    Nach Woche gruppiert

    Woche 2026-01-27 bis 2026-02-01

    Abgeschlossen:

    • TRIXY-001: Core Framework Implementation
    • TRIXY-002: Unit Test Suite
    • TRIXY-003: Project Knowledge System
    • TRIXY-004: Enterprise Extensions Phase 1-4
    • TRIXY-005: Enterprise Extensions Phase 5
    • TRIXY-006: Enterprise Extensions Phase 6
    • TRIXY-007: API-Dokumentation
    • TRIXY-008: Wakeword-Arbitration
    • TRIXY-009: Enterprise Extensions - Network & Satellite
    • TRIXY-010: API-Dokumentation Update
    • TRIXY-011: Wakeword Detection & Conversation System
    • TRIXY-012: Scheduler-System (Cronjob)
    • TRIXY-013: Network Transport Layer
    • TRIXY-014: Event-basierte Integration
    • TRIXY-015: Client Audio Player & Audio Processing Pipeline
    • TRIXY-016: Music System Tests
    • TRIXY-017: Zeit-basiertes Puffer-Management
    • TRIXY-018: Crossfade-Plugin
    • TRIXY-019: Asset-Manager
    • TRIXY-020: NLP Plugin System

    2026-02-21 - TRIXY-021: Client Wakeword Detection

    • Status: Abgeschlossen
    • Beschreibung: Wakeword-Erkennung auf Client/Satellite mit Mikrofon, Audio-Streaming und Server-Arbitration
    • Neue Dateien:
      • trixy_core/audio/microphone.py - MicrophoneCapture (sounddevice-basiert, 16kHz mono, 80ms Frames)
    • Geänderte Dateien:
      • trixy_core/config/datasets/client.py - ClientWakewordConfig um enabled, silence_timeout, max_recording, pre_buffer erweitert
      • trixy_core/wakeword/service.py - DEPENDENCIES Fix, Mikrofon-Integration, Audio-Streaming via Port 2102, Future-basierte Arbitration, handle_wakeword_selected/abort/conversation_end, setup_for_client()
      • trixy_core/client.py - WakewordService + MicrophoneCapture Integration, Command-Routing (WakewordSelected/Abort/RecordingStop)
    • Workflow:
      1. Mikrofon (sounddevice-Thread) → asyncio.Queue → WakewordService._audio_loop
      2. LISTENING: WakewordDetector erkennt Wakeword → PAUSED → WAITING_RESPONSE
      3. WakewordDetected Command → Server, Future wartet auf Arbitration
      4. WakewordSelected → RECORDING: Pre-Buffer + Live-Audio via Port 2102
      5. 3s Stille oder 60s Timeout → RecordingDone Command → LISTENING
      6. WakewordAbort → Buffer leeren → LISTENING
    • Notizen: OpenWakeWord optional (graceful degradation), Keyboard-Input funktioniert weiterhin

    2026-02-21 - TRIXY-016: Fix Arbitration-Timeout (Wakeword)

    • Status: Abgeschlossen
    • Beschreibung: Client erhielt sofort "Arbitration-Timeout" nach Wakeword-Erkennung
    • Ursachen (3 Bugs):
      1. WakewordArbitrator wurde nie in server.py erstellt/gestartet → niemand hörte auf wakeword_detected Event
      2. Arbitrator nutzte falsche Property-Namen: event_manager statt events, satellite_manager statt satellites
      3. Arbitrator nutzte self.logger (Python logging) statt pinfo/pdebug/perror/pwarn (TUI-Output)
    • Geänderte Dateien:
      • trixy_core/server.py - WakewordArbitrator erstellen, starten und stoppen
      • trixy_core/arbitration/arbitrator.py - Property-Namen Fix, self.logger → pinfo/pdebug/perror/pwarn, fehlender await bei emit()

    2026-02-22 - TRIXY-022: Live-Audio-Streaming zwischen Satellites

    • Status: Abgeschlossen
    • Beschreibung: Live-Audio-Streaming von Satellite A (Mikrofon) zu Satellite B (Lautsprecher) für Debugging/Wartung
    • Komponenten:
      • EventData-Klassen: SatelliteStreamStarted, SatelliteStreamStopped, SatelliteStreamRecordStarted, SatelliteStreamRecordStopped
      • Satellite-Streaming: start_stream(), stop_stream(), start_record_stream(), stop_record_stream()
      • Handler: _on_stream_audio_received (Audio-Weiterleitung), _on_stream_record_stopped_event (Wakeword-Stop), _on_stream_timeout
      • Mutual Exclusion: Recording und Streaming schließen sich gegenseitig aus
      • Guards: disconnect() stoppt Stream, start_recording() blockiert bei Stream
    • Architektur: Keine neuen Network-Commands — nutzt bestehende SatelliteRecordStart/Stop. Unterscheidung rein server-seitig.
    • Audio-Pfad: Satellite A Mikrofon → Port 2102 → Server (audio_input_received) → Socket-Write auf Satellite B audio_out (Port 2103)
    • Stop-Wege: manual, timeout, wakeword, target_disconnect
    • Geänderte Dateien:
      • trixy_core/events/event_data/basic.py — 4 neue EventData-Klassen
      • trixy_core/events/event_data/__init__.py — Exports erweitert
      • trixy_core/satellite/satellite.py — Attribute, Properties, 4 Methoden, 3 Handler, Guards
    • Tests: 64 Tests in tests/test_satellite_streaming.py (alle bestanden)
    • Notizen: Optional parallele WAV-Aufnahme des Streams via start_record_stream()

    2026-02-22 — Wakeword-Audio aus STT-Input trimmen

    • Status: Abgeschlossen
    • Beschreibung: Wakeword-Audio (Pre-Buffer + Wakeword-Tail) wurde ungefiltert an STT gesendet → "davis spiele musik" statt "spiele musik"
    • Lösung: Server-seitiges Trimmen im AudioAccumulatorService — erste N Sekunden (default 1.0s) werden abgeschnitten
    • Konfigurierbar: wakeword_trim_seconds in WakewordConfig (0.0 = kein Trim)
    • Geänderte Dateien: config/datasets/server.py, audio/accumulator.py, server.py
    • Tests: 102 Tests bestanden

    In Arbeit:

    • Keine

    Blockiert:

    • Keine

    2026-02-22 — Bugfix: Silence-Detection + Server-seitige Audio-Verarbeitung

    Status: Abgeschlossen

    • VAD: NO_SPEECH State + no_speech_timeout_ms (5s) — bricht ab wenn keine Sprache erkannt wird
    • WakewordService: sendet jetzt RecordingComplete (statt RecordingDone) mit speech_detected, ended_by, vad_stats
    • Neuer AudioAccumulatorService: sammelt gestreamte Audio-Frames pro Conversation, emittiert raw_audio_input_received bei Recording-Ende
    • No-Speech → ConversationEnd an Satellite (reason="no_speech")
    • Config: no_speech_timeout_seconds in ClientWakewordConfig konfigurierbar
    • Geänderte Dateien: vad.py, wakeword/service.py, config/datasets/client.py, client.py, server.py, audio/accumulator.py (neu)

    2026-02-22 — Music Plugin Phase 1 (MVP)

    Status: Abgeschlossen

    • Neues Music-Plugin (plugins/music/) mit YouTube-Suche (yt-dlp) und lokaler Musikbibliothek
    • YouTubeSource: Suche, Download, Cache-Management, graceful degradation ohne yt-dlp
    • Intent-Handler: play_music, next_track, previous_track, what_is_playing (via IntentRegistry)
    • Neue System-Intents: stop, pause, resume (in system_intents.py)
    • IntentDispatcher: stop/pause/resume emittieren Events; Volume-Handler auf async Events umgebaut (_handle_volume_intent entfernt)
    • MusicPlayerService: music_volume_change Event-Handler (set_volume/mute/unmute)
    • "Stop" aus cancel-Examples entfernt (Disambiguierung stop vs cancel)
    • Neue Dateien: plugins/music/{config.json, init.py, main.py, sources/init.py, sources/youtube.py, tests/test_music_plugin.py}
    • Geänderte Dateien: trixy_core/nlp/system_intents.py, trixy_core/nlp/intent_dispatcher.py, trixy_core/music/service.py
    • 17 Tests, alle bestehen

    2026-02-27 — STT → NLP Event-Brücke

    Status: Abgeschlossen

    • Problem: Nach STT-Transkription brach die Pipeline ab — NLP wurde nie aufgerufen
    • Ursache: STT-Plugins emittierten stt_completed (dict via emit()), aber NLP-Plugin lauscht auf speech_recognized (EventData via trigger())
    • Lösung: Nach stt_completed zusätzlich speech_recognized Event mit SpeechRecognized EventData emittieren (nur bei nicht-leerem Text)
    • session_id: Wird via metadata["session_id"] transportiert (SpeechRecognized hat kein eigenes session_id-Feld)
    • Geänderte Dateien: plugins/stt_vosk/main.py, plugins/stt_whisper/main.py, plugins/stt_deepspeech/main.py
    • Tests: py_compile OK, Event/NLP-Tests bestanden

    2026-02-27 — Download-System Refactoring auf EventData-Events

    Status: Abgeschlossen

    • Beschreibung: Download-Events von unstrukturierten Dicts (emit()) auf typisierte EventData-Klassen (trigger()) umgestellt
    • Neue Datei: trixy_core/events/event_data/download.py — 6 EventData-Klassen (BeforeDownload, DownloadProgress, DownloadCompleted, DownloadFailed, BeforeExtract, ExtractCompleted)
    • Entfernt: progress_callback Parameter aus allen Download-Funktionen, default_progress_callback(), DownloadProgress.callback Feld
    • Plugin-Einfluss: Plugins koennen Downloads jetzt redirecten, verbieten, Speicherort aendern oder eigene Extraktoren nutzen (via cancel/modify auf BeforeDownload/BeforeExtract)
    • Klasse umbenannt: DownloadProgress → DownloadProgressTracker (Alias beibehalten fuer Kompatibilitaet)
    • Geaenderte Dateien: trixy_core/events/event_data/download.py (neu), trixy_core/events/event_data/init.py, trixy_core/utils/download.py, tests/utils/test_download.py
    • Plugins benoetigen keine Aenderung: Vosk, DeepSpeech, Piper uebergeben bereits kein progress_callback; Whisper nutzt eigenen Download-Mechanismus
    • Tests: py_compile OK, 9 passed + 6 skipped (async ohne pytest-asyncio)

    2026-02-27 — Calendar Cloud Plugin

    Status: Abgeschlossen

    • Beschreibung: Kalender-Anbindung an Cloud-Dienste (Microsoft Outlook, Google Calendar, CalDAV/Nextcloud) per Sprache
    • Plugin-Struktur (plugins/calendar/):
      • main.py — CalendarPlugin (Orchestrator): Provider-Init, Sync, Notifications, Intent-Handler
      • models.py — CalendarEvent, CalendarInfo, NotificationRecord, EventStatus
      • utils.py — Datums-/Zeit-Parsing (deutsch), TTS-Formatierung
      • providers/base.py — CalendarProvider ABC (connect, disconnect, fetch_events, create_event, health_check)
      • providers/microsoft.py — Microsoft Graph API (Client Credentials + Device Code Flow, httpx + msal)
      • providers/google.py — Google Calendar API (Service Account + OAuth2, google-auth + google-api-python-client)
      • providers/caldav_provider.py — CalDAV (caldav + icalendar Libraries)
      • mapping.py — SatelliteCalendarMapper (Satellite ↔ Kalender per Alias/Room, globale Kalender)
      • sync.py — CalendarSyncManager (periodischer Sync via Scheduler, In-Memory Cache, asyncio.Lock)
      • notifications.py — NotificationManager (60s Check-Loop, Reminder + Start-Sounds, Quiet Hours, Duplikat-Vermeidung)
      • intents.py — 6 Intent-Definitionen (next/search/attendees/person/create/list appointments)
      • config.json — Provider-Credentials, Kalender-Definitionen, Satellite-Mapping, Sync/Notification-Optionen
    • Features:
      • Optionale Dependencies per try/import (Plugin laeuft auch ohne spezifische Libraries)
      • Automatischer Token-Refresh bei 401 (Microsoft)
      • Retry-Logik mit Backoff beim Sync
      • Standalone-Modus: Fallback auf ersten Mapping-Eintrag, TTS via Event
      • Scheduler-Integration: IntervalTrigger + CallbackAction fuer periodischen Sync
    • Neue Dateien: 12 Python-Dateien + config.json
    • Tests: py_compile OK fuer alle Dateien, JSON valide
    • Notizen: Sounds erwartet in assets/default/audio/ (calender.wav, calender_remember.wav)

    2026-02-28 — Standalone-Modus Grundfunktionalitaet

    Status: Abgeschlossen

    Beschreibung: Standalone-Modus (python3 main.py standalone) hatte keine funktionierende Audio-Pipeline — WakewordService, MicrophoneCapture und AudioOutputManager fehlten.

    Aenderungen:

    • Bugfix wakeword/service.py:767: self.application.event_manager.emit() → await self._application.events.emit()
    • Config-Fix config/datasets/standalone.py: WakewordConfig (Server) → ClientWakewordConfig (hat model_directory, use_onnx, enabled, etc.)
    • standalone.py: WakewordService (standalone_mode=True), MicrophoneCapture, AudioOutputManager integriert + TTS-Handler fuer lokale Wiedergabe via tts_completed Event

    Neue Event-Pipeline: Mikrofon → WakewordService → raw_audio_received → STT → speech_recognized → NLP → intent_received → IntentDispatcher → output_text_created → TTS → tts_completed → AudioOutputManager

    2026-02-28 — Notes-Plugin Rewrite + Reminders-Plugin

    Status: Abgeschlossen

    Beschreibung: Notes-Plugin v2.0 komplett ueberarbeitet und neues Reminders-Plugin erstellt. Dazu Standalone Follow-Up-Bruecke und Recording-Config-Override implementiert.

    Phase 1 — Infrastruktur:

    • trixy_core/wakeword/service.py: recording_config_override Event-Handler — Plugins koennen Silence-Timeout und Max-Recording temporaer aendern. Werte werden in _complete_session() automatisch zurueckgesetzt.
    • trixy_core/standalone.py: _setup_standalone_followup() — Bruecke fuer followup_expected Event → WakewordService _handle_follow_up(). Ermoeglicht Multi-Turn-Dialoge im Standalone-Modus mit Sprachaufnahme.

    Phase 2 — Notes-Plugin v2.0 (plugins/notes/):

    • 11 Intents: create_note, record_note, record_note_content, list_notes, get_note_today, get_note_yesterday, get_note_by_date, play_note_audio, search_notes, delete_note, delete_all_notes, note_count
    • Audio-Mitschnitt: PCM-Dateien neben JSON in ./sync_data/notes.note/{item_id}.pcm
    • Multi-Turn fuer record_note (Rueckfrage "Was moechtest du notieren?") und delete_all_notes (Rueckfrage "Bist du sicher?")
    • Datumsabfragen: heute, gestern, Wochentage, DD.MM.YYYY
    • Audio-Wiedergabe via tts_completed Event

    Phase 3 — Reminders-Plugin (plugins/reminders/):

    • 6 Intents: create_reminder, create_reminder_full, list_reminders, list_reminders_today, delete_reminder, delete_all_reminders, confirm_delete_all_reminders
    • Multi-Turn-Dialog: Was? → Wann? → VM/NM-Klaerung (bis zu 3 Rueckfragen)
    • Zeitparser (time_parser.py): "morgen", "in 2 Stunden", "naechsten Montag", "heute Abend", VM/NM-Erkennung
    • Timer-Loop: Prueft alle 60s auf faellige Erinnerungen, TTS-Benachrichtigung
    • Dialog-State intern im Plugin (nicht Session-abhaengig)

    Neue Dateien:

    • plugins/notes/main.py (Rewrite), plugins/notes/config.json
    • plugins/reminders/__init__.py, plugins/reminders/main.py, plugins/reminders/config.json, plugins/reminders/time_parser.py

    Geaenderte Dateien:

    • trixy_core/wakeword/service.py — recording_config_override Event + Reset
    • trixy_core/standalone.py — followup_expected Bridge

    2026-02-28 — STT Post-Correction Service

    Status: Abgeschlossen

    Beschreibung: Konfigurierbarer, mehrstufiger STT-Nachkorrektur-Service als IService. Registriert sich mit HIGH-Prioritaet auf speech_recognized und korrigiert Text in-place, bevor das NLP-Plugin (NORMAL-Prioritaet) ihn verarbeitet. Ersetzt die primitive _correct_stt_text() im NLP-Plugin.

    Architektur-Entscheidung: Event-Prioritaet statt neues Event. STTCorrectorService nutzt EventPriority.HIGH, NLP-Plugin hat default NORMAL. Korrektur per in-place Modifikation von event_data.text.

    6 optionale Korrektur-Schichten:

    1. SymSpell — Wort-Segmentierung, Nicht-Wort-Fehler (symspellpy)
    2. Phonetic — Domain-Vokabular schuetzen via Koelner Phonetik (cologne_phonetics)
    3. KenLM — Kontextuelle N-Gram Kandidatenauswahl (kenlm)
    4. JamSpell — Neuronaler kontextueller Spellchecker (jamspell)
    5. Hunspell — Woerterbuch-basierte Korrektur (pyhunspell)
    6. LanguageTool — Volle Grammatik-Korrektur (language_tool_python)

    Jede Schicht graceful skip per try/import. Default-Layers: symspell, phonetic, kenlm.

    Neue Dateien:

    • trixy_core/stt/__init__.py — Paket-Exports
    • trixy_core/stt/corrector.py — STTCorrectorService (IService)
    • trixy_core/stt/layers/__init__.py — Layer-Registry
    • trixy_core/stt/layers/base.py — CorrectionLayer ABC
    • trixy_core/stt/layers/symspell_layer.py — SymSpell-Korrektur
    • trixy_core/stt/layers/phonetic_layer.py — Cologne Phonetics
    • trixy_core/stt/layers/kenlm_layer.py — KenLM N-Gram
    • trixy_core/stt/layers/jamspell_layer.py — JamSpell Neural
    • trixy_core/stt/layers/hunspell_layer.py — Hunspell-Woerterbuch
    • trixy_core/stt/layers/languagetool_layer.py — LanguageTool Grammatik

    Geaenderte Dateien:

    • trixy_core/config/datasets/server.py — STTCorrectionConfig Dataclass + Feld in ServerConfig
    • trixy_core/config/datasets/standalone.py — STTCorrectionConfig Import + Feld in StandaloneConfig
    • config/standalone_config.json — stt_correction Abschnitt
    • config/server_config.json — stt_correction Abschnitt
    • trixy_core/standalone.py — STTCorrectorService erstellt + registriert
    • trixy_core/server.py — STTCorrectorService erstellt + registriert

    2026-03-06 — Schedule Sub-Views interaktiv gemacht

    Beschreibung: Die 4 Schedule Sub-Views (F1-F4 im Schedule-Kontext) waren nur lesend. Jetzt sind alle Views interaktiv mit Eingabefeldern, Typ-Auswahl und dynamischen Formularen.

    Geaenderte Dateien:

    • trixy_core/tui/views/schedule_info_view.py — Input-Felder fuer Name, Beschreibung, Config + Speichern-Button
    • trixy_core/tui/views/schedule_trigger_view.py — Typ-Select + dynamische FormField-Widgets
    • trixy_core/tui/views/schedule_condition_view.py — DataTable + Add/Remove + Edit-Bereich mit dynamischen Feldern
    • trixy_core/tui/views/schedule_action_view.py — DataTable + Add/Remove/Hoch/Runter + Edit-Bereich
    • trixy_core/tui/app.py — FormMeta-Laden beim Betreten des Schedule-Kontexts + save_schedule_job()
    • trixy_core/tui/css/schedule.tcss — Styles fuer neue Formular-Elemente

    2026-03-06 — TTSSpeakAction + Template-Formatter

    Status: Abgeschlossen

    Neue Scheduler-Action TTSSpeakAction fuer TTS-Sprachausgabe auf Satellites. Unterstuetzt Template-Platzhalter ({date.now.hour}, {sys.hostname}, {env.USER}, etc.) und kann an einen bestimmten Satellite oder alle verbundenen Satellites senden.

    Neue Dateien:

    • trixy_core/utils/template_formatter.py — Platzhalter-System mit date/sys/env/ctx-Namespaces
    • trixy_core/scheduler/action/tts.py — TTSSpeakAction mit FormField-Definitionen

    Geaenderte Dateien:

    • trixy_core/scheduler/action/__init__.py — TTSSpeakAction exportiert
    • trixy_core/scheduler/scheduler.py — In ACTION_TYPES registriert
    • trixy_core/scheduler/service.py — satellite_manager automatisch in Kontext injiziert

    2026-03-14 — Multi-Engine TTS + Voice-Morphing + Bug-Fix fuer Wakeword-Trainer

    Status: Abgeschlossen

    Wakeword-Trainer unterstuetzt nun 7 TTS-Engines statt nur Piper, plus DSP-basiertes Voice-Morphing (8 Presets) und optionale KI-Voice-Cloning. Bug-Fix: abgehackte Enden bei generierten Samples durch Fade-In/Out behoben.

    Neue Dateien:

    • trixy_core/trainer/core/tts_engines/__init__.py — Exports, get_all_engines()
    • trixy_core/trainer/core/tts_engines/base.py — ITTSEngine ABC, TTSVoice, TTSResult
    • trixy_core/trainer/core/tts_engines/piper_engine.py — PiperTTSEngine
    • trixy_core/trainer/core/tts_engines/gtts_engine.py — GoogleTranslateTTSEngine
    • trixy_core/trainer/core/tts_engines/edge_engine.py — EdgeTTSEngine (ThreadPoolExecutor)
    • trixy_core/trainer/core/tts_engines/coqui_engine.py — CoquiTTSEngine (Thorsten)
    • trixy_core/trainer/core/tts_engines/espeak_engine.py — EspeakTTSEngine
    • trixy_core/trainer/core/tts_engines/bark_engine.py — BarkTTSEngine (GPU)
    • trixy_core/trainer/core/tts_engines/clone_engine.py — VoiceCloningEngine (XTTS/YourTTS)
    • trixy_core/trainer/core/tts_engines/voice_morph.py — DSP Voice-Morphing (VTLP + LPC + Breathiness + Jitter/Shimmer)

    Geaenderte Dateien:

    • trixy_core/trainer/core/wakeword_trainer.py — Engine-agnostisch, Voice-Morph, Fade-Fix
    • trixy_core/tui/views/trainer_optional_view.py — Button-Variant, Schema-Refresh
    • install_requirements.sh — --tts-engines Flag

    Tipps

    • Beschreibungen kurz halten (1-2 Zeilen)
    • Immer Ticket-URL angeben wenn verfügbar
    • Status aktualisieren wenn blockiert
    • Optional: Nach Woche oder Sprint gruppieren
    • Sehr alte Einträge (3+ Monate) aufräumen