morz-infoboard/README.md
Jesko Anschütz aff12a4d81 Doku-Sync: README, TODO, DEVELOPMENT und API-Docs auf Implementierungsstand nachgezogen
README, DEVELOPMENT und TODO spiegelten noch den Stand vor Ebene 1+2 wider.
Checkboxen in TODO von ~18 auf ~70 aktualisiert, drei neue API-Dokumentationsdateien ergänzt.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-23 09:55:36 +01:00

3.2 KiB

Info-Board Neu

Dieses Verzeichnis enthaelt die Planung und spaetere Umsetzung der neuen Info-Board-Plattform.

Die Trennung von /srv/docker/infoboard-netboot ist sinnvoll, damit:

  • die bestehende produktive Netboot-Struktur unangetastet bleibt
  • Planung, Prototypen und neue Deployments sauber getrennt sind
  • Server-, Player- und Ansible-Artefakte nicht mit Altbestand vermischt werden

Aktueller Stand

  • Architekturplan: PLAN.md
  • Umsetzungs-Todo: TODO.md
  • Datenmodell: DATENMODELL.md
  • Schema-Entwurf: docs/SCHEMA.md
  • API- und MQTT-Vertrag: API-MQTT-VERTRAG.md
  • Technologieentscheidungen: TECH-STACK.md
  • Entwicklungsleitfaden: DEVELOPMENT.md
  • Erste Dev-Testliste: docs/TEST-CHECKLIST-DEV.md
  • Template-/Kampagnenkonzept: docs/TEMPLATE-KONZEPT.md
  • layout_json fuer message_wall: docs/LAYOUT-JSON.md
  • Player-Agent-Lifecycle und Health-Modell: docs/PLAYER-AGENT-LIFECYCLE.md
  • Erster HTTP-Statuspfad fuer den Player-Agent: docs/PLAYER-STATUS-HTTP.md
  • Provisionierungskonzept: docs/PROVISIONIERUNGSKONZEPT.md
  • Player-Konzept: docs/PLAYER-KONZEPT.md
  • Server-Konzept: docs/SERVER-KONZEPT.md
  • Offene Architekturfragen: docs/OFFENE-ARCHITEKTURFRAGEN.md

Projektstruktur

  • docs/ fuer weitere Architektur- und Betriebsdokumente
  • server/ fuer Backend, Frontends und Compose-Dateien
  • player/ fuer Agent, UI und lokale Startlogik
  • ansible/ fuer Rollen, Inventories und Deployments
  • compose/ fuer Container-Definitionen und Stack-Bausteine
  • scripts/ fuer Hilfsskripte

Aktueller Implementierungsstand

Backend (server/backend/)

  • Vollstaendiges PostgreSQL-Backend mit Datenbank-Migrations
  • Store-Layer fuer Datenverwaltung
  • REST-API mit Endpunkten:
    • message_wall fuer Kampagnenausgabe
    • player/status fuer Player-Statusverwaltung
    • /manage/ API fuer Media-Upload, Playlist-Verwaltung und Vorlagen
    • /meta fuer Systemmetadaten
  • HTML-Statusseiten fuer Diagnose
  • Admin-UI mit Medien-Upload und Playlist-Management
  • Tenant-aware Architektur mit Lebenszyklusverwaltung

Player-Agent (player/agent/)

  • Funktionaler Go-Agent mit:
    • Selbstregistrierung beim Backend
    • Playlist-Rotation mit Heartbeat
    • Dateibasierter/env-basierter Konfiguration
    • Strukturierte Logs mit journald-Integration
    • Internes Health-Modell fuer Diagnosewerte
    • HTTP-Status-Reporter mit Lebenszyklusstatus
    • MQTT-Integration (optional) mit Authentifizierung
  • Binaries fuer Linux ARM64 vorhanden

Ansible-Automatisierung (ansible/)

  • Zwei funktionale Rollen:
    • signage_player: Agent-Deployment mit Systemd-Units, Tasks, Templates und Handlers
    • signage_display: Display-Kiosk-Setup mit Systemd-Units, Tasks, Templates und Handlers
  • Konfigurierbare Defaults und Host-Variablen
  • Unterstützung für Bildschirm-Setup mit Ansible-Anleitung

Infrastruktur (compose/)

  • Docker Compose Setup mit:
    • PostgreSQL-Datenbank
    • Mosquitto MQTT-Broker
    • Backend-Service Integration

Implementierte Features

  • DB-Migrations und Schema-Management
  • Media-Upload und Speicherverwaltung
  • Playlist-Management und Rotation
  • Player-Registrierung und Status-Tracking
  • Admin-UI für Screensetup
  • Ansible-automatisiertes Deployment auf Raspberry Pi
  • Kiosk-Display-Modus
  • MQTT-basierte Kommunikation
  • HTML-Diagnoseseiten