- Architektur-Refactor: Kein querySelectorAll mehr, 100% Lit-Property-Flow
- Plan-Versionierung: Sofortige UI-Updates bei jeder State-Änderung, ohne DOM-Neuaufbau
- Lazy Rendering: Pläne werden erst bei Sichtbarkeit gebaut (IntersectionObserver)
- HASS Slicing: Card reagiert nur noch auf relevante Entity-Änderungen
- Maximale Performance auch bei vielen Plänen
- Plan-Versionierung: Sofortige UI-Updates bei jeder State-Änderung, ohne DOM-Neuaufbau
- Lazy Rendering: Pläne werden erst bei Sichtbarkeit gebaut (IntersectionObserver)
- Kein querySelectorAll mehr nötig, 100% Lit-Property-Flow
- HASS Slicing: Card reagiert nur noch auf relevante Entity-Änderungen
- Maximale Performance auch bei vielen Plänen
- Bugfix: Lit Timing – hass-Propagation erfolgt jetzt nach dem Render mit updateComplete
- Child Cards erhalten garantiert immer den aktuellen State
- Kein Dashboard Reload mehr nötig, sofortige Live-Updates
- Bugfix: hass-Propagation in PlanNode jetzt exakt wie im stabilen Stand (Commit 1242a6c)
- Child Cards werden bei jeder Entity-Änderung zuverlässig aktualisiert
- Dashboard-Reload nicht mehr nötig
- Architektur entspricht dem optimalen HA-Pattern
Eine hochperformante, reaktive Home Assistant Custom Card für wiederkehrende Ladepläne – 100% Entity-Driven, keine Polls, keine Backend-WS nötig.
- 100% Entity-Driven: Card erkennt neue/löschte Pläne sofort (Entity-Prefix-Detection, keine Scans)
- Zero-Scan Architektur: keine Polls, keine Backend-WS, keine Events nötig
- Echtzeit-Updates: State- und Entity-Änderungen werden sofort reflektiert
- Modular: PlanNode-Komponenten, Shared Styles
- Statische, performante CSS-Styles (keine dynamische Injektion)
- Kompatibel mit HA Core Patterns (wie Energy Dashboard, Mushroom Auto Entities)
- repeating-scheduler-card.js – Hauptkomponente
- repeating-plan-node.js – PlanNode-Komponente (Child Cards)
- repeating-scheduler-styles.js – Zentrale Styles
- Dateien nach
config/www/repeating_scheduler/kopieren - Ressource in Home Assistant einbinden:
url: /local/repeating_scheduler/repeating-scheduler-card.js type: module
- Card im Dashboard hinzufügen:
type: custom:repeating-scheduler-card vehicle_entity: select.evcc_garage_vehicle_name # vehicle_attribute: vehicle.evccName # optional, falls Entity-State nicht gewünschtes Fahrzeug liefert pattern: weekdays: text.evcc_{vehicle}_repeating_plan_{index}_weekdays time: time.evcc_{vehicle}_repeating_plan_{index}_time soc: number.evcc_{vehicle}_repeating_plan_{index}_soc active: switch.evcc_{vehicle}_repeating_plan_{index}_active # Optional für maximale Flexibilität (Standard siehe Code): # add_service: evcc_scheduler.set_repeating_plan # delete_service: evcc_scheduler.del_repeating_plan
- Architektur-Update: hass-Objekt wird jetzt immer korrekt an Child Cards propagiert (über updated()), unabhängig von Topologie-Änderungen
- Kein Flicker, keine unnötigen DOM-Rebuilds – UI bleibt stabil und reaktiv
- Lovelace-konformes, hass-driven Update-Pattern (wie HA-Core Cards)
- Topologie- und State-Updates sauber getrennt
- Bugfix: Child Cards werden bei Entity-Änderungen wieder zuverlässig aktualisiert
```
- Entity-Prefix-Detection: Card prüft nur Entities mit passendem Prefix (z.B. evcc_{vehicle}repeating_plan), kein globaler Entity-Scan mehr
- State-Änderungen werden wie gewohnt über hass-Objekt propagiert (Home Assistant WebSocket API)
- Fahrzeugerkennung: vehicle_attribute optional, sonst Entity-State
- Hinzufügen/Löschen: Services können optional in der Config überschrieben werden (add_service, delete_service)
- Styles werden als JS-Konstanten in den Komponenten verwaltet
Die Card ist stateless, aber die dynamisch erzeugten Card-Elemente (PlanNode) werden intern gecached und nur bei relevanter Änderung neu gebaut. Dadurch bleibt das UI stabil und performant – card_mod wird nicht unnötig neu angewendet.
MIT