Files
Infinity_Vis_Rust/README.md
JFly02 8e19f535ae Die gemeinsame Plattform ist jetzt softwareseitig deutlich vollständiger. Der Host-Core hat mit [show_store.rs](</C:/Users/janni/Documents/RFP/Infinity_Vis _Rust/crates/infinity_host/src/show_store.rs>) eine echte Runtime-Bibliothek und Persistenz für aktive Szene, Runtime-Presets, Runtime-Gruppen und kreative Varianten bekommen; die Simulation in [simulation.rs](</C:/Users/janni/Documents/RFP/Infinity_Vis _Rust/crates/infinity_host/src/simulation.rs>) liefert jetzt typisierte Command-Ergebnisse, saubere Fehlercodes und persistiert nach data/runtime_state.json. Dazu kommt das generische External-Show-Control-Interface in [external_control.rs](</C:/Users/janni/Documents/RFP/Infinity_Vis _Rust/crates/infinity_host/src/external_control.rs>), damit spätere Adapter nur auf definierte Commands und Snapshot-/Preset-/Parameter-Flächen zugreifen.
Die API v1 ist als Produktgrenze geschärft in [dto.rs](</C:/Users/janni/Documents/RFP/Infinity_Vis _Rust/crates/infinity_host_api/src/dto.rs>) und [server.rs](</C:/Users/janni/Documents/RFP/Infinity_Vis _Rust/crates/infinity_host_api/src/server.rs>): getrennte Modelle für `state`, `preview`, `snapshot`, `command response`, `event stream` und stabile Fehlerobjekte mit echten Codes statt generischem Fallback. Dazu kamen `GET /api/v1/state` und `GET /api/v1/preview`, neue persistenzbezogene Commands wie `save_preset`, `save_creative_snapshot`, `recall_creative_snapshot`, `set_transition_style` und `upsert_group`, plus serverseitige Durchreichung der echten Fehlercodes. Die kreative Web-UI in [index.html](</C:/Users/janni/Documents/RFP/Infinity_Vis _Rust/web/v1/index.html>), [app.js](</C:/Users/janni/Documents/RFP/Infinity_Vis _Rust/web/v1/app.js>) und [styles.css](</C:/Users/janni/Documents/RFP/Infinity_Vis _Rust/web/v1/styles.css>) nutzt jetzt genau diese API für Preset-Speichern/Überschreiben, Varianten, Transition-Style, filterbaren Eventfeed und klarere Preview-Darstellung, ohne Parallelarchitektur.

Die Doku ist auf den neuen Stand gezogen in [docs/host_api.md](</C:/Users/janni/Documents/RFP/Infinity_Vis _Rust/docs/host_api.md>), [README.md](</C:/Users/janni/Documents/RFP/Infinity_Vis _Rust/README.md>), [docs/build_and_deploy.md](</C:/Users/janni/Documents/RFP/Infinity_Vis _Rust/docs/build_and_deploy.md>) und [docs/architecture.md](</C:/Users/janni/Documents/RFP/Infinity_Vis _Rust/docs/architecture.md>). Verifiziert habe ich `cargo check -q` und `cargo test -q`; dabei laufen die erweiterten Contract- und Persistenztests in [contract.rs](</C:/Users/janni/Documents/RFP/Infinity_Vis _Rust/crates/infinity_host_api/tests/contract.rs>) sowie neue Core-Tests in [show_store.rs](</C:/Users/janni/Documents/RFP/Infinity_Vis _Rust/crates/infinity_host/src/show_store.rs>) und [simulation.rs](</C:/Users/janni/Documents/RFP/Infinity_Vis _Rust/crates/infinity_host/src/simulation.rs>). Nicht separat verifiziert habe ich einen echten Browserlauf der Web-UI; die JS-Datei wurde hier nicht mit `node` geprüft, weil `node` in dieser Umgebung nicht installiert ist.
2026-04-17 12:34:03 +02:00

52 lines
2.4 KiB
Markdown

# Infinity Vis Rust
Production-oriented greenfield architecture for a low-latency LED control system that targets:
- 6 ESP32-N16R8 nodes
- 3 physical LED outputs per node
- 106 LEDs per output
- 18 logical panels and 1908 LEDs total
The repository is intentionally structured around hard separation of concerns:
- `crates/infinity_config`: versioned project configuration and validation
- `crates/infinity_protocol`: shared control and realtime protocol model
- `crates/infinity_host`: host-side core library, simulation engine, scene/preset API, and CLI
- `crates/infinity_host_ui`: native Rust desktop engineering GUI for mapping, diagnostics, and admin
- `firmware/esp32_node`: ESP-IDF firmware skeleton with explicit driver abstraction
- `docs/`: architecture, protocol, validation, deployment, testing, and acceptance artifacts
- `config/`: example configuration files
Current software priority:
- stable host-core first
- shared host API for every surface
- simulation and mock-first creative workflow
- web UI as the primary creative surface
- engineering GUI for technical operation
- grandMA planned later as an external show-control adapter, not as the system core
The current baseline is intentionally strict about unresolved hardware facts. `UART 6`, `UART 5`, and `UART 4` are treated as unvalidated labels until the real electrical meaning is confirmed.
## Quick Start
1. Install a current Rust toolchain.
2. Review the open validation checklist in [docs/validation_open_points.md](docs/validation_open_points.md).
3. Start from [config/project.example.toml](config/project.example.toml).
4. Inspect the software-first host snapshot with `cargo run -p infinity_host -- snapshot --config config/project.example.toml`.
5. Start the versioned host API plus creative web UI with `cargo run -p infinity_host_api -- --config config/project.example.toml --bind 127.0.0.1:9001 --runtime-state data/runtime_state.json`.
6. Open `http://127.0.0.1:9001/` for the creative surface.
7. Start the engineering GUI with `cargo run -p infinity_host_ui`.
8. Use the host CLI to validate the project config before attempting activation.
## Docs
- [Architecture](docs/architecture.md)
- [Host API](docs/host_api.md)
- [Protocol](docs/protocol.md)
- [Config Schema](docs/config_schema.md)
- [Build and Deploy](docs/build_and_deploy.md)
- [Testing](docs/testing.md)
- [Acceptance Template](docs/acceptance_template.md)
- [Legacy XML Reference](docs/legacy_xml_reference.md)