Files

JFly02 dde35551be Der minimale GUI-Vertical-Slice ist jetzt als eigenes Crate umgesetzt. Die Desktop-App liegt in crates/infinity_host_ui/src/main.rs und crates/infinity_host_ui/src/app.rs: lokales Fenster per eframe, globale Controls für Blackout, Master Brightness und Pattern, eine 6-Node-Übersicht, die 18er Mapping-Tabelle mit Node, top/middle/bottom, physischem Output/Kanal, 106 LEDs, direction, color_order, enable_flag, plus Walk 106-Testtrigger pro Panel und einen Status-/Event-Bereich für online/offline, letzter Kontakt und Fehlerstatus.

Damit die UI sauber getrennt bleibt, habe ich infinity_host zu einer wiederverwendbaren Core-Schicht ausgebaut: crates/infinity_host/src/lib.rs, control.rs und mock.rs definieren Snapshot-/Command-Typen und einen Mock-Simulationsdienst mit Hintergrundthread. Die UI pollt nur Snapshots über HostUiPort; sie treibt keine Realtime-Logik. Den Workspace und die Build-Hinweise habe ich in Cargo.toml, README.md und docs/build_and_deploy.md ergänzt.

Verifikation war hier nur eingeschränkt möglich: cargo und rustc sind in dieser Umgebung nicht installiert, daher konnte ich die App nicht kompilieren oder starten. Der nächste sinnvolle Schritt wäre erst nach deinem Go, den vorhandenen HostUiPort statt des Mock-Backends an echten Transportstatus anzubinden.

2026-04-17 01:45:30 +02:00

1.2 KiB

Raw Blame History

Build and Deploy

Host Side

Required tools:

Rust stable toolchain
cargo

Suggested commands:

cargo test
cargo run -p infinity_host_ui
cargo run -p infinity_host -- validate --config config/project.example.toml --mode structural
cargo run -p infinity_host -- plan-boot-scene --config config/project.example.toml --preset-id safe_static_blue

The native UI currently runs against the host-core mock service so the operator workflow can be exercised before transport and firmware integration are complete.

Before any live activation, run:

cargo run -p infinity_host -- validate --config config/project.example.toml --mode activation

Activation mode is expected to fail until the hardware mapping has been confirmed and the config is updated from pending_validation to concrete driver references.

Firmware Side

Required tools:

ESP-IDF
Xtensa or RISC-V toolchain matching the actual ESP32 variant

Suggested layout:

firmware/esp32_node/
build with idf.py build
flash with idf.py -p <serial-port> flash monitor

The firmware skeleton is intentionally conservative. It will not silently select a backend for UART 6, UART 5, or UART 4.

1.2 KiB Raw Blame History

Build and Deploy

Host Side

Firmware Side

1.2 KiB

Raw Blame History