add ci script

.woodpecker.yml

@@ -0,0 +1,15 @@
+steps:
+  build_ui:
+    image: plugins/kaniko
+    settings:
+      repo: ${FORGE_NAME}/${CI_REPO}-ui
+      registry:
+        from_secret: container_registry
+      tags: latest,${CI_COMMIT_TAG}
+      username:
+        from_secret: container_registry_username
+      password:
+        from_secret: container_registry_password
+      dockerfile: apps/ui/Dockerfile
+    when:
+      - event: [tag]

DEVICES_BY_ROOM.md

@@ -1,41 +0,0 @@
-Schlafzimmer:
-- Bettlicht Patty                                    | 0x0017880108158b32
-- Bettlicht Wolfgang                                 | 0x00178801081570bf
-- Deckenlampe Schlafzimmer                           | 0x0017880108a406a7
-- Medusa-Lampe Schlafzimmer                          | 0xf0d1b80000154c7c
-
-Esszimmer:
-- Deckenlampe Esszimmer                              | 0x0017880108a03e45
-- Leselampe Esszimmer                                | 0xec1bbdfffe7b84f2
-- Standlampe Esszimmer                               | 0xbc33acfffe21f547
-- kleine Lampe links Esszimmer                       | 0xf0d1b80000153099
-- kleine Lampe rechts Esszimmer                      | 0xf0d1b80000156645
-
-Wohnzimmer:
-- Lampe Naehtischchen Wohnzimmer                     | 0x842e14fffee560ee
-- Lampe Semeniere Wohnzimmer                         | 0xf0d1b8000015480b
-- Sterne Wohnzimmer                                  | 0xf0d1b80000155fc2
-- grosse Lampe Wohnzimmer                            | 0xf0d1b80000151aca
-
-Küche:
-- Küche Deckenlampe                                  | 0x001788010d2c40c4
-- Kueche                                             | 0x94deb8fffe2e5c06
-
-Arbeitszimmer Patty:
-- Leselampe Patty                                    | 0x001788010600ec9d
-- Schranklicht hinten Patty                          | 0x0017880106e29571
-- Schranklicht vorne Patty                           | 0xf0d1b80000154cf5
-
-Arbeitszimmer Wolfgang:
-- Wolfgang                                           | 0x540f57fffe7e3cfe
-- ExperimentLabTest                                  | 0xf0d1b80000195038
-
-Flur:
-- Deckenlampe Flur oben                              | 0x001788010d2123a7
-- Haustür                                            | 0xec1bbdfffea6a3da
-- Licht Flur oben am Spiegel                         | 0x842e14fffefe4ba4
-
-Sportzimmer:
-- Sportlicht Regal                                   | 0xf0d1b8be2409f569
-- Sportlicht Tisch                                   | 0xf0d1b8be2409f31b
-- Sportlicht am Fernseher, Studierzimmer             | 0x842e14fffe76a23a

DOCKER_GUIDE.md

@@ -1,230 +0,0 @@
-# Docker Guide für Home Automation
-
-Vollständige Anleitung zum Ausführen aller Services mit Docker/finch.
-
-## Quick Start - Alle Services starten
-
-### Linux Server (empfohlen - mit Docker Network)
-
-```bash
-# 1. Images bauen
-docker build -t api:dev -f apps/api/Dockerfile .
-docker build -t ui:dev -f apps/ui/Dockerfile .
-docker build -t abstraction:dev -f apps/abstraction/Dockerfile .
-docker build -t simulator:dev -f apps/simulator/Dockerfile .
-
-# 2. Netzwerk erstellen
-docker network create home-automation
-
-# 3. Abstraction Layer (MQTT Worker)
-docker run -d --name abstraction \
-  --network home-automation \
-  -v $(pwd)/config:/app/config:ro \
-  -e MQTT_BROKER=172.16.2.16 \
-  -e REDIS_HOST=172.23.1.116 \
-  -e REDIS_DB=8 \
-  abstraction:dev
-
-# 4. API Server
-docker run -d --name api \
-  --network home-automation \
-  -p 8001:8001 \
-  -v $(pwd)/config:/app/config:ro \
-  -e MQTT_BROKER=172.16.2.16 \
-  -e REDIS_HOST=172.23.1.116 \
-  -e REDIS_DB=8 \
-  api:dev
-
-# 5. Web UI
-docker run -d --name ui \
-  --network home-automation \
-  -p 8002:8002 \
-  -e API_BASE=http://api:8001 \
-  ui:dev
-
-# 6. Device Simulator (optional)
-docker run -d --name simulator \
-  --network home-automation \
-  -p 8010:8010 \
-  -e MQTT_BROKER=172.16.2.16 \
-  simulator:dev
-```
-
-### macOS mit finch/nerdctl (Alternative)
-
-```bash
-# Images bauen (wie oben)
-
-# Abstraction Layer
-docker run -d --name abstraction \
-  -v $(pwd)/config:/app/config:ro \
-  -e MQTT_BROKER=172.16.2.16 \
-  -e REDIS_HOST=172.23.1.116 \
-  -e REDIS_DB=8 \
-  abstraction:dev
-
-# API Server
-docker run -d --name api \
-  -p 8001:8001 \
-  -v $(pwd)/config:/app/config:ro \
-  -e MQTT_BROKER=172.16.2.16 \
-  -e REDIS_HOST=172.23.1.116 \
-  -e REDIS_DB=8 \
-  api:dev
-
-# Web UI (mit host.docker.internal für macOS)
-docker run -d --name ui \
-  --add-host=host.docker.internal:host-gateway \
-  -p 8002:8002 \
-  -e API_BASE=http://host.docker.internal:8001 \
-  ui:dev
-
-# Device Simulator
-docker run -d --name simulator \
-  -p 8010:8010 \
-  -e MQTT_BROKER=172.16.2.16 \
-  simulator:dev
-```
-
-## Zugriff
-
-- **Web UI**: http://<server-ip>:8002
-- **API Docs**: http://<server-ip>:8001/docs
-- **Simulator**: http://<server-ip>:8010
-
-Auf localhost: `127.0.0.1` oder `localhost`
-
-## finch/nerdctl Besonderheiten
-
-### Port-Binding Verhalten (nur macOS/Windows)
-
-**Standard Docker auf Linux:**
-- `-p 8001:8001` → bindet auf `0.0.0.0:8001` (von überall erreichbar)
-
-**finch/nerdctl auf macOS:**
-- `-p 8001:8001` → bindet auf `127.0.0.1:8001` (nur localhost)
-- Dies ist ein **Security-Feature** von nerdctl
-- **Auf Linux-Servern ist das KEIN Problem!**
-
-### Container-to-Container Kommunikation
-
-**Linux (empfohlen):**
-```bash
-# Docker Network verwenden - Container sprechen sich mit Namen an
-docker network create home-automation
-docker run --network home-automation --name api ...
-docker run --network home-automation -e API_BASE=http://api:8001 ui ...
-```
-
-**macOS mit finch:**
-```bash
-# host.docker.internal verwenden
-docker run --add-host=host.docker.internal:host-gateway \
-  -e API_BASE=http://host.docker.internal:8001 ui ...
-```
-
-## Container verwalten
-
-```bash
-# Alle Container anzeigen
-docker ps
-
-# Logs anschauen
-docker logs api
-docker logs ui -f  # Follow mode
-
-# Container stoppen
-docker stop api ui abstraction simulator
-
-# Container entfernen
-docker rm api ui abstraction simulator
-
-# Alles neu starten
-docker stop api ui abstraction simulator && \
-docker rm api ui abstraction simulator && \
-# ... dann Quick Start Befehle von oben
-```
-
-## Troubleshooting
-
-### UI zeigt "Keine Räume oder Geräte konfiguriert"
-
-**Problem:** UI kann API nicht erreichen
-
-**Linux - Lösung:**
-```bash
-# Verwende Docker Network
-docker network create home-automation
-docker stop ui && docker rm ui
-docker run -d --name ui \
-  --network home-automation \
-  -p 8002:8002 \
-  -e API_BASE=http://api:8001 \
-  ui:dev
-```
-
-**macOS/finch - Lösung:**
-```bash
-docker stop ui && docker rm ui
-docker run -d --name ui \
-  --add-host=host.docker.internal:host-gateway \
-  -p 8002:8002 \
-  -e API_BASE=http://host.docker.internal:8001 \
-  ui:dev
-```
-
-### "Connection refused" in Logs
-
-**Check 1:** Ist die API gestartet?
-```bash
-docker ps | grep api
-curl http://127.0.0.1:8001/health
-```
-
-**Check 2:** Hat UI die richtige API_BASE?
-```bash
-docker inspect ui | grep API_BASE
-```
-
-### Port bereits belegt
-
-```bash
-# Prüfe welcher Prozess Port 8001 nutzt
-lsof -i :8001
-
-# Oder mit netstat
-netstat -an | grep 8001
-
-# Alte Container aufräumen
-docker ps -a | grep -E "api|ui|abstraction|simulator"
-docker rm -f <container-id>
-```
-
-## Produktiv-Deployment
-
-Für Produktion auf **Linux-Servern** empfohlen:
-
-1. **Docker Compose** (siehe `infra/docker-compose.yml`)
-2. **Docker Network** für Service Discovery (siehe Linux Quick Start oben)
-3. **Volume Mounts** für Persistenz
-4. **Health Checks** in Kubernetes/Compose (nicht im Dockerfile)
-
-### Beispiel mit Docker Network (Linux)
-
-```bash
-# Netzwerk erstellen
-docker network create home-automation
-
-# Services starten (alle im gleichen Netzwerk)
-docker run -d --name api --network home-automation \
-  -p 8001:8001 \
-  -v $(pwd)/config:/app/config:ro \
-  api:dev
-
-docker run -d --name ui --network home-automation \
-  -p 8002:8002 \
-  -e API_BASE=http://api:8001 \
-  ui:dev
-```
-
-**Vorteil:** Service Discovery über Container-Namen, keine `--add-host` Tricks nötig.

HOMEKIT_BRIDGE_API_ANALYSIS.md

@@ -1,553 +0,0 @@
-# HomeKit-Bridge API-Modell: Analyse der bestehenden Implementierung
-
-**Analysedatum:** 17. November 2025  
-**Analysierte Dateien:**
-- `apps/api/main.py`
-- `apps/api/routes/groups_scenes.py`
-- `config/devices.yaml`
-
----
-
-## Zusammenfassung
-
-Die bestehende API-Implementierung erfüllt **~60%** der Anforderungen des HomeKit-Bridge Ziel-Modells. Die meisten Kernfunktionalitäten sind vorhanden, aber es fehlen wichtige Metadaten-Felder und ein dedizierter State-Endpoint.
-
----
-
-## 1. GET /devices
-
-### Status: ✅ **VORHANDEN** mit Abweichungen
-
-### Implementierung (apps/api/main.py:325-343)
-```python
-@app.get("/devices")
-async def get_devices() -> list[DeviceInfo]:
-    devices = load_devices()
-    return [
-        DeviceInfo(
-            device_id=device["device_id"],
-            type=device["type"],
-            name=device.get("name", device["device_id"]),
-            features=device.get("features", {})
-        )
-        for device in devices
-    ]
-```
-
-### Response-Modell (DeviceInfo)
-```python
-class DeviceInfo(BaseModel):
-    device_id: str
-    type: str
-    name: str
-    features: dict[str, Any] = {}
-```
-
-### Abweichungen vom Ziel-Modell
-
-| Feld | Ziel-Modell | Ist-Zustand | Status |
-|------|-------------|-------------|---------|
-| `device_id` | ✅ Erforderlich | ✅ Vorhanden | OK |
-| `type` | ✅ Erforderlich | ✅ Vorhanden | OK |
-| `cap_version` | ✅ Erforderlich | ❌ **FEHLT** | FEHLT |
-| `room` | ✅ Erforderlich | ❌ **FEHLT** | FEHLT |
-| `friendly_name` | ✅ Erforderlich | ⚠️ Heißt `name` | UMBENENNUNG |
-| `technology` | ✅ Erforderlich | ❌ **FEHLT** | FEHLT |
-| `features` | ✅ Erforderlich | ✅ Vorhanden | OK |
-| `read_only` | ✅ Erforderlich | ❌ **FEHLT** | FEHLT |
-| `tags` | Optional | ❌ **FEHLT** | FEHLT |
-
-### Details zu fehlenden Feldern
-
-#### ❌ `cap_version`
-- **Vorhanden in devices.yaml:** Ja, als `cap_version` (z.B. `"light@1.2.0"`)
-- **Problem:** Wird von `load_devices()` geladen, aber nicht in `DeviceInfo` exponiert
-- **Lösung:** Feld zu `DeviceInfo` hinzufügen und aus `device["cap_version"]` befüllen
-
-#### ❌ `room`
-- **Vorhanden in layout.yaml:** Ja, indirekt über Raum-Zuordnung
-- **Problem:** Aktuell nur über separaten Endpoint `/devices/{device_id}/room` verfügbar
-- **Lösung:** Room-Mapping in `/devices` integrieren (Resolver bereits vorhanden in `apps/api/resolvers.py`)
-
-#### ⚠️ `friendly_name` vs. `name`
-- **Vorhanden in devices.yaml:** Ja, als `metadata.friendly_name`
-- **Problem:** Aktuell wird `device.get("name", device["device_id"])` verwendet, nicht `metadata.friendly_name`
-- **Lösung:** Priorisierung: `metadata.friendly_name` > `name` > `device_id`
-
-#### ❌ `technology`
-- **Vorhanden in devices.yaml:** Ja, als `technology` (z.B. `"zigbee2mqtt"`)
-- **Problem:** Wird nicht in Response exponiert
-- **Lösung:** Feld zu `DeviceInfo` hinzufügen
-
-#### ❌ `read_only`
-- **Implizit vorhanden:** Ja, über `topics.set` (wenn fehlt → read-only)
-- **Problem:** Muss berechnet werden
-- **Lösung:** `read_only = "set" not in device.get("topics", {})`
-
-#### ❌ `tags`
-- **Vorhanden in devices.yaml:** Nein
-- **Status:** Nicht kritisch, kann später ergänzt werden
-
----
-
-## 2. GET /devices/{device_id}
-
-### Status: ❌ **FEHLT KOMPLETT**
-
-### Aktuell vorhanden
-- `/devices/{device_id}/room` (liefert nur `{"device_id": str, "room": str | None}`)
-
-### Erforderlich
-Ein Endpoint, der das gleiche Schema wie ein Eintrag aus `/devices` zurückgibt:
-```python
-@app.get("/devices/{device_id}")
-async def get_device(device_id: str) -> DeviceInfo:
-    # Load device, enrich with room, return DeviceInfo
-```
-
-### Implementierung
-- Device aus `load_devices()` filtern
-- Mit `get_room(device_id)` anreichern
-- Als `DeviceInfo` zurückgeben
-- 404 bei nicht gefunden
-
----
-
-## 3. GET /devices/{device_id}/state
-
-### Status: ❌ **FEHLT KOMPLETT**
-
-### Aktuell vorhanden
-- `/devices/states` (liefert **alle** Device-States als Dict)
-  ```python
-  @app.get("/devices/states")
-  async def get_device_states() -> dict[str, dict[str, Any]]:
-      return device_states  # In-memory cache
-  ```
-
-### Ziel-Format
-```json
-{
-  "device_id": "thermostat_wolfgang",
-  "type": "thermostat",
-  "room": "Schlafzimmer",
-  "payload": {
-    "current": 19.5,
-    "target": 21.0,
-    "mode": "heat"
-  },
-  "ts": "2025-11-17T14:23:45.123Z"
-}
-```
-
-### Erforderlich
-```python
-@app.get("/devices/{device_id}/state")
-async def get_device_state(device_id: str) -> DeviceStateResponse:
-    # Get from device_states cache
-    # Enrich with metadata (type, room)
-    # Add timestamp
-    # Return structured response
-```
-
-### Problem
-- Aktuell wird nur `payload` im Cache gespeichert
-- Timestamp fehlt im Cache (müsste bei SSE-Updates mitgespeichert werden)
-- Metadaten (type, room) müssen aus devices.yaml/layout.yaml ergänzt werden
-
----
-
-## 4. SSE-Endpoint /realtime
-
-### Status: ✅ **VORHANDEN** mit kleineren Abweichungen
-
-### Implementierung (apps/api/main.py:608-637)
-```python
-@app.get("/realtime")
-async def realtime_events(request: Request) -> StreamingResponse:
-    return StreamingResponse(
-        event_generator(request),
-        media_type="text/event-stream",
-        # ... headers
-    )
-```
-
-### Aktuelles Event-Format (aus Redis)
-```json
-{
-  "type": "state",
-  "device_id": "thermostat_wolfgang",
-  "payload": {
-    "current": 19.5,
-    "target": 21.0
-  }
-}
-```
-
-### Ziel-Format
-```json
-{
-  "type": "state",
-  "device_id": "thermostat_wolfgang",
-  "device_type": "thermostat",     // ← FEHLT
-  "room": "Schlafzimmer",           // ← FEHLT
-  "payload": {
-    "current": 19.5,
-    "target": 21.0
-  },
-  "ts": "2025-11-17T14:23:45.123Z", // ← FEHLT
-  "source": "zigbee2mqtt"           // ← FEHLT (optional)
-}
-```
-
-### Abweichungen
-
-| Feld | Ziel-Modell | Ist-Zustand | Status |
-|------|-------------|-------------|---------|
-| `type` | ✅ | ✅ | OK |
-| `device_id` | ✅ | ✅ | OK |
-| `device_type` | ✅ | ❌ **FEHLT** | FEHLT |
-| `room` | ✅ | ❌ **FEHLT** | FEHLT |
-| `payload` | ✅ | ✅ | OK |
-| `ts` | ✅ | ❌ **FEHLT** | FEHLT |
-| `source` | Optional | ❌ **FEHLT** | FEHLT |
-
-### Problem
-Events werden direkt aus Redis weitergeleitet ohne Enrichment. 
-
-### Lösungsansätze
-
-**Option A: Enrichment im SSE-Generator**
-```python
-# Im event_generator() nach JSON-Parse:
-state_data = json.loads(data)
-if state_data.get("type") == "state":
-    # Enrich with metadata
-    device_id = state_data["device_id"]
-    device = get_device_from_cache(device_id)
-    state_data["device_type"] = device["type"]
-    state_data["room"] = get_room(device_id)
-    if "ts" not in state_data:
-        state_data["ts"] = datetime.utcnow().isoformat()
-    data = json.dumps(state_data)
-```
-
-**Option B: Enrichment im Publisher (apps/abstraction)**
-- Besser: Events bereits vollständig beim Publizieren
-- Würde auch `/devices/{id}/state` helfen
-
----
-
-## 5. POST /devices/{device_id}/set
-
-### Status: ✅ **VORHANDEN** mit kleinen Abweichungen
-
-### Implementierung (apps/api/main.py:406-504)
-```python
-@app.post("/devices/{device_id}/set", status_code=status.HTTP_202_ACCEPTED)
-async def set_device(device_id: str, request: SetDeviceRequest) -> dict[str, str]:
-    # Validierung, MQTT publish
-```
-
-### Request-Modell
-```python
-class SetDeviceRequest(BaseModel):
-    type: str
-    payload: dict[str, Any]
-```
-
-### Vergleich mit Ziel-Modell
-
-| Aspekt | Ziel-Modell | Ist-Zustand | Status |
-|--------|-------------|-------------|---------|
-| Body-Format | `{type, payload}` | `{type, payload}` | ✅ OK |
-| Type-Validierung | ✅ Erforderlich | ✅ Vorhanden | OK |
-| Payload-Validierung | ✅ Per Device-Type | ✅ Vorhanden | OK |
-| Read-Only Check | ✅ → 405 | ✅ → 405 | OK |
-| Response Code | 200/202 | 202 | OK |
-
-### Validierungs-Details
-
-**✅ Gut implementiert:**
-- Type-spezifische Pydantic-Validierung (LightState, ThermostatState, etc.)
-- Whitelist für erlaubte Felder bei Thermostaten
-- Read-only Detection über `topics.set`
-- Proper HTTP Status Codes (404, 405, 422)
-
-**⚠️ Kleine Abweichung:**
-- Thermostat-Validierung erlaubt nur `{mode, target}` beim SET
-- Ziel-Modell erwähnt dies nicht explizit
-- **Bewertung:** Ist sinnvolle Einschränkung, kein Problem
-
-### MQTT-Publishing
-```python
-topic = f"home/{request.type}/{device_id}/set"
-mqtt_payload = {
-    "type": request.type,
-    "payload": request.payload
-}
-await publish_mqtt(topic, mqtt_payload)
-```
-✅ Korrekt implementiert
-
----
-
-## 6. Zusätzliche Endpoints (nicht im Ziel-Modell)
-
-### ℹ️ Vorhanden, aber nicht gefordert
-
-- **GET /spec** - Capability-Versionen
-- **GET /devices/states** - Alle States (könnte nützlich für Bridge sein)
-- **GET /layout** - UI-spezifisch
-- **GET /devices/{device_id}/room** - Wird obsolet wenn `/devices` `room` hat
-- **GET /groups**, **POST /groups/{id}/set** - Gruppen-Feature
-- **GET /scenes**, **POST /scenes/{id}/run** - Szenen-Feature
-
-**Bewertung:** Nicht störend, können bleiben. Bridge muss diese nicht nutzen.
-
----
-
-## 7. Datenquellen-Analyse
-
-### devices.yaml
-**✅ Enthält alle benötigten Felder:**
-```yaml
-- device_id: leselampe_esszimmer
-  type: light
-  cap_version: "light@1.2.0"         # ← Vorhanden
-  technology: zigbee2mqtt             # ← Vorhanden
-  features:
-    power: true
-    brightness: true
-  topics:
-    state: "..."
-    set: "..."                        # ← Für read_only Detection
-  metadata:
-    friendly_name: "Leselampe Esszimmer"  # ← Vorhanden
-    ieee_address: "..."
-    model: "LED1842G3"
-    vendor: "IKEA"
-```
-
-### layout.yaml
-**✅ Enthält Room-Mapping:**
-```yaml
-rooms:
-  - name: "Schlafzimmer"
-    devices:
-      - device_id: thermostat_wolfgang
-```
-
-**✅ Resolver bereits vorhanden:** `apps/api/resolvers.py::get_room(device_id)`
-
----
-
-## 8. Priorisierte To-Do-Liste
-
-### 🔴 **Kritisch** (Bridge funktioniert nicht ohne)
-
-1. **GET /devices: Fehlende Felder ergänzen**
-   - `cap_version` aus devices.yaml
-   - `room` via `get_room()`
-   - `friendly_name` aus `metadata.friendly_name`
-   - `technology` aus devices.yaml
-   - `read_only` berechnen
-
-2. **GET /devices/{device_id}/state implementieren**
-   - Neuer Endpoint
-   - State aus Cache + Metadaten
-   - Timestamp hinzufügen
-
-### 🟡 **Wichtig** (Bridge funktioniert, aber eingeschränkt)
-
-3. **SSE /realtime: Events enrichen**
-   - `device_type` hinzufügen
-   - `room` hinzufügen
-   - `ts` sicherstellen
-
-4. **GET /devices/{device_id} implementieren**
-   - Einzelgerät-Abfrage
-   - Gleiche Struktur wie `/devices`-Eintrag
-
-### 🟢 **Nice-to-have**
-
-5. **State-Cache mit Timestamps erweitern**
-   - Aktuell: `device_states[id] = payload`
-   - Ziel: `device_states[id] = {payload, ts}`
-
-6. **SSE: source-Feld hinzufügen**
-   - Aus `device["technology"]` ableiten
-
----
-
-## 9. Implementierungs-Reihenfolge
-
-### Phase 1: GET /devices erweitern
-**Dateien:**
-- `apps/api/main.py` (DeviceInfo-Modell, get_devices())
-
-**Änderungen:**
-```python
-class DeviceInfo(BaseModel):
-    device_id: str
-    type: str
-    cap_version: str
-    room: str | None
-    friendly_name: str
-    technology: str
-    features: dict[str, Any]
-    read_only: bool
-    tags: list[str] | None = None
-
-@app.get("/devices")
-async def get_devices() -> list[DeviceInfo]:
-    devices = load_devices()
-    return [
-        DeviceInfo(
-            device_id=device["device_id"],
-            type=device["type"],
-            cap_version=device["cap_version"],
-            room=get_room(device["device_id"]),
-            friendly_name=device.get("metadata", {}).get("friendly_name", device["device_id"]),
-            technology=device["technology"],
-            features=device.get("features", {}),
-            read_only="set" not in device.get("topics", {}),
-            tags=device.get("tags")
-        )
-        for device in devices
-    ]
-```
-
-### Phase 2: GET /devices/{device_id}/state
-**Dateien:**
-- `apps/api/main.py`
-
-**Neues Modell:**
-```python
-class DeviceStateResponse(BaseModel):
-    device_id: str
-    type: str
-    room: str | None
-    payload: dict[str, Any]
-    ts: str
-
-@app.get("/devices/{device_id}/state")
-async def get_device_state(device_id: str) -> DeviceStateResponse:
-    if device_id not in device_states:
-        raise HTTPException(404, f"No state for {device_id}")
-    
-    devices = load_devices()
-    device = next((d for d in devices if d["device_id"] == device_id), None)
-    if not device:
-        raise HTTPException(404, f"Device {device_id} not found")
-    
-    return DeviceStateResponse(
-        device_id=device_id,
-        type=device["type"],
-        room=get_room(device_id),
-        payload=device_states[device_id],
-        ts=datetime.utcnow().isoformat() + "Z"
-    )
-```
-
-### Phase 3: SSE Enrichment
-**Dateien:**
-- `apps/api/main.py` (event_generator())
-
-**Im event_generator() nach JSON-Parse:**
-```python
-if message and message["type"] == "message":
-    data = message["data"]
-    state_data = json.loads(data)
-    
-    # Enrich events
-    if state_data.get("type") == "state" and state_data.get("device_id"):
-        device_id = state_data["device_id"]
-        devices = load_devices()
-        device = next((d for d in devices if d["device_id"] == device_id), None)
-        
-        if device:
-            state_data["device_type"] = device["type"]
-            state_data["room"] = get_room(device_id)
-            if "ts" not in state_data:
-                state_data["ts"] = datetime.utcnow().isoformat() + "Z"
-            state_data["source"] = device.get("technology")
-        
-        data = json.dumps(state_data)
-    
-    yield f"event: message\ndata: {data}\n\n"
-```
-
-### Phase 4: GET /devices/{device_id}
-**Dateien:**
-- `apps/api/main.py`
-
-```python
-@app.get("/devices/{device_id}")
-async def get_device(device_id: str) -> DeviceInfo:
-    devices = load_devices()
-    device = next((d for d in devices if d["device_id"] == device_id), None)
-    
-    if not device:
-        raise HTTPException(404, f"Device {device_id} not found")
-    
-    return DeviceInfo(
-        device_id=device["device_id"],
-        type=device["type"],
-        cap_version=device["cap_version"],
-        room=get_room(device["device_id"]),
-        friendly_name=device.get("metadata", {}).get("friendly_name", device["device_id"]),
-        technology=device["technology"],
-        features=device.get("features", {}),
-        read_only="set" not in device.get("topics", {}),
-        tags=device.get("tags")
-    )
-```
-
----
-
-## 10. Zusammenfassung der Abweichungen
-
-### ✅ Bereits konform (40%)
-- POST /devices/{id}/set - Vollständig implementiert
-- SSE /realtime - Grundfunktion vorhanden
-- GET /devices - Grundstruktur vorhanden
-
-### ⚠️ Teilweise konform (40%)
-- GET /devices - Fehlen wichtige Felder (cap_version, room, friendly_name, technology, read_only)
-- SSE /realtime - Events ohne device_type, room, ts
-
-### ❌ Nicht vorhanden (20%)
-- GET /devices/{device_id}/state - Komplett fehlend
-- GET /devices/{device_id} - Komplett fehlend
-
----
-
-## 11. Risiko-Bewertung
-
-### 🟢 **Geringes Risiko**
-- Alle Daten sind in devices.yaml/layout.yaml vorhanden
-- Resolver-Funktionen existieren bereits
-- Pydantic-Modelle sind etabliert
-- Keine Breaking Changes an bestehenden Endpoints nötig
-
-### 🟡 **Mittleres Risiko**
-- SSE-Enrichment könnte Performance beeinflussen (load_devices() bei jedem Event)
-  - **Mitigation:** Device-Lookup cachen
-- Timestamp-Handling muss konsistent sein
-  - **Mitigation:** UTC + ISO8601 + "Z" Suffix
-
-### 🔴 **Kein hohes Risiko identifiziert**
-
----
-
-## 12. Nächste Schritte
-
-1. **Freigabe einholen:** Sollen wir mit Phase 1 (GET /devices erweitern) starten?
-2. **Testing-Strategie:** Sollen Tests für die neuen Endpoints geschrieben werden?
-3. **Backward Compatibility:** GET /devices ändert Response-Struktur - ist das OK? (Vermutlich ja, da UI diese Felder ignorieren kann)
-4. **Performance:** Device-Lookup-Cache implementieren vor SSE-Enrichment?
-
----
-
-**Ende der Analyse**

MAX_INTEGRATION.md

@@ -1,223 +0,0 @@
-# MAX! (eQ-3) Thermostat Integration
-
-## Overview
-
-This document describes the integration of MAX! (eQ-3) thermostats via Homegear into the home automation system.
-
-## Protocol Characteristics
-
-MAX! thermostats use a **simple integer-based protocol** (not JSON):
-
-- **SET messages**: Plain integer temperature value (e.g., `22`)
-- **STATE messages**: Plain integer temperature value (e.g., `22`)
-- **Topics**: Homegear MQTT format
-
-### MQTT Topics
-
-**SET Command:**
-```
-homegear/instance1/set/<peerId>/<channel>/SET_TEMPERATURE
-Payload: "22" (plain integer as string)
-```
-
-**STATE Update:**
-```
-homegear/instance1/plain/<peerId>/<channel>/SET_TEMPERATURE
-Payload: "22" (plain integer as string)
-```
-
-## Transformation Layer
-
-The abstraction layer provides automatic transformation between the abstract home protocol and MAX! format.
-
-### Abstract → MAX! (SET)
-
-**Input (Abstract):**
-```json
-{
-  "mode": "heat",
-  "target": 22.5
-}
-```
-
-**Output (MAX!):**
-```
-22
-```
-
-**Transformation Rules:**
-- Extract `target` temperature
-- Convert float → integer (round to nearest)
-- Return as plain string (no JSON)
-- Ignore `mode` field (MAX! always in heating mode)
-
-### MAX! → Abstract (STATE)
-
-**Input (MAX!):**
-```
-22
-```
-
-**Output (Abstract):**
-```json
-{
-  "target": 22.0,
-  "mode": "heat"
-}
-```
-
-**Transformation Rules:**
-- Parse plain string/integer value
-- Convert to float
-- Add default `mode: "heat"` (MAX! always heating)
-- Wrap in abstract payload structure
-
-## Device Configuration
-
-### Example devices.yaml Entry
-
-```yaml
-- device_id: "thermostat_wolfgang"
-  type: "thermostat"
-  cap_version: "thermostat@1.0.0"
-  technology: "max"
-  features:
-    mode: true
-    target: true
-    current: false  # SET_TEMPERATURE doesn't report current temp
-  topics:
-    set: "homegear/instance1/set/39/1/SET_TEMPERATURE"
-    state: "homegear/instance1/plain/39/1/SET_TEMPERATURE"
-  metadata:
-    friendly_name: "Thermostat Wolfgang"
-    location: "Arbeitszimmer Wolfgang"
-    vendor: "eQ-3"
-    model: "MAX! Thermostat"
-    peer_id: "39"
-    channel: "1"
-```
-
-### Configuration Notes
-
-1. **technology**: Must be set to `"max"` to activate MAX! transformations
-2. **topics.set**: Use Homegear's `/set/` path with `/SET_TEMPERATURE` parameter
-3. **topics.state**: Use Homegear's `/plain/` path with `/SET_TEMPERATURE` parameter
-4. **features.current**: Set to `false` - SET_TEMPERATURE topic doesn't provide current temperature
-5. **metadata**: Include `peer_id` and `channel` for reference
-
-## Temperature Rounding
-
-MAX! only supports **integer temperatures**. The system uses standard rounding:
-
-| Abstract Input | MAX! Output |
-|----------------|-------------|
-| 20.4°C         | 20          |
-| 20.5°C         | 20          |
-| 20.6°C         | 21          |
-| 21.5°C         | 22          |
-| 22.5°C         | 22          |
-
-Python's `round()` function uses "banker's rounding" (round half to even).
-
-## Limitations
-
-1. **No current temperature**: SET_TEMPERATURE topic only reports target, not actual temperature
-2. **No mode control**: MAX! thermostats are always in heating mode
-3. **Integer only**: Temperature precision limited to 1°C steps
-4. **No battery status**: Not available via SET_TEMPERATURE topic
-5. **No window detection**: Not available via SET_TEMPERATURE topic
-
-## Testing
-
-Test the transformation functions:
-
-```bash
-poetry run python /tmp/test_max_transform.py
-```
-
-Expected output:
-```
-✅ PASS: Float 22.5 -> Integer string
-✅ PASS: Integer string -> Abstract dict
-✅ PASS: Integer -> Abstract dict
-✅ PASS: Rounding works correctly
-🎉 All MAX! transformation tests passed!
-```
-
-## Implementation Details
-
-### Files Modified
-
-1. **apps/abstraction/transformation.py**
-   - Added `_transform_thermostat_max_to_vendor()` - converts abstract → plain integer
-   - Added `_transform_thermostat_max_to_abstract()` - converts plain integer → abstract
-   - Registered handlers in `TRANSFORM_HANDLERS` registry
-
-2. **apps/abstraction/main.py**
-   - Modified `handle_abstract_set()` to send plain string for MAX! devices (not JSON)
-   - Modified message processing to handle plain text payloads from MAX! STATE topics
-
-### Transformation Functions
-
-```python
-def _transform_thermostat_max_to_vendor(payload: dict[str, Any]) -> str:
-    """Convert {"target": 22.5} → "22" """
-    target_temp = payload.get("target", 21.0)
-    return str(int(round(target_temp)))
-
-def _transform_thermostat_max_to_abstract(payload: str | int | float) -> dict[str, Any]:
-    """Convert "22" → {"target": 22.0, "mode": "heat"} """
-    target_temp = float(payload)
-    return {"target": target_temp, "mode": "heat"}
-```
-
-## Usage Example
-
-### Setting Temperature via API
-
-```bash
-curl -X POST http://localhost:8001/devices/thermostat_wolfgang/set \
-  -H "Content-Type: application/json" \
-  -d '{
-    "type": "thermostat",
-    "payload": {
-      "mode": "heat",
-      "target": 22.5
-    }
-  }'
-```
-
-**Flow:**
-1. API receives abstract payload: `{"mode": "heat", "target": 22.5}`
-2. Abstraction transforms to MAX!: `"22"`
-3. Publishes to: `homegear/instance1/set/39/1/SET_TEMPERATURE` with payload `22`
-
-### Receiving State Updates
-
-**Homegear publishes:**
-```
-Topic: homegear/instance1/plain/39/1/SET_TEMPERATURE
-Payload: 22
-```
-
-**Flow:**
-1. Abstraction receives plain text: `"22"`
-2. Transforms to abstract: `{"target": 22.0, "mode": "heat"}`
-3. Publishes to: `home/thermostat/thermostat_wolfgang/state`
-4. Publishes to Redis: `ui:updates` channel for real-time UI updates
-
-## Future Enhancements
-
-Potential improvements for better MAX! integration:
-
-1. **Current Temperature**: Subscribe to separate Homegear topic for actual temperature
-2. **Battery Status**: Subscribe to LOWBAT or battery level topics
-3. **Valve Position**: Monitor actual valve opening percentage
-4. **Window Detection**: Subscribe to window open detection status
-5. **Mode Control**: Support comfort/eco temperature presets
-
-## Related Documentation
-
-- [Homegear MAX! Documentation](https://doc.homegear.eu/data/homegear-max/)
-- [Abstract Protocol Specification](docs/PROTOCOL.md)
-- [Transformation Layer Design](apps/abstraction/README.md)

PORTS.md

@@ -1,53 +0,0 @@
-# Port Configuration
-
-This document describes the port allocation for the home automation services.
-
-## Port Scan Results (31. Oktober 2025)
-
-### Ports in Use
-- **8000**: In use (likely API server)
-- **8021**: In use (system service)
-- **8080**: In use (system service)
-- **8100**: In use (system service)
-- **8200**: In use (system service)
-- **8770**: In use (system service)
-
-### Free Ports Found
-- **8001**: FREE ✓
-- **8002**: FREE ✓
-- **8003**: FREE ✓
-- **8004**: FREE ✓
-- **8005**: FREE ✓
-
-## Service Port Allocation
-
-| Service | Port | Purpose |
-|---------|------|---------|
-| API     | 8001 | FastAPI REST API for capabilities and health checks |
-| UI      | 8002 | FastAPI web interface with Jinja2 templates |
-| (Reserved) | 8003 | Available for future services |
-| (Reserved) | 8004 | Available for future services |
-| (Reserved) | 8005 | Available for future services |
-
-## Access URLs
-
-- **API**: http://localhost:8001
-  - Health: http://localhost:8001/health
-  - Spec: http://localhost:8001/spec
-  - Docs: http://localhost:8001/docs
-
-- **UI**: http://localhost:8002
-  - Main page: http://localhost:8002/
-
-## Starting Services
-
-```bash
-# Start API
-poetry run uvicorn apps.api.main:app --reload --port 8001
-
-# Start UI
-poetry run uvicorn apps.ui.main:app --reload --port 8002
-
-# Start Abstraction Worker (no port - MQTT client)
-poetry run python -m apps.abstraction.main
-```

THERMOSTAT_UI_QUICKREF.md

@@ -1,207 +0,0 @@
-# 🌡️ Thermostat UI - Quick Reference
-
-## ✅ Implementation Complete
-
-### Features Implemented
-
-| Feature | Status | Details |
-|---------|--------|---------|
-| Temperature Display | ✅ | Ist (current) & Soll (target) in °C |
-| Mode Display | ✅ | Shows OFF/HEAT/AUTO |
-| +0.5 Button | ✅ | Increases target temperature |
-| -0.5 Button | ✅ | Decreases target temperature |
-| Mode Buttons | ✅ | OFF, HEAT, AUTO switches |
-| Real-time Updates | ✅ | SSE-based live updates |
-| Temperature Drift | ✅ | ±0.2°C every 5 seconds |
-| Touch-Friendly | ✅ | 44px minimum button height |
-| Responsive Grid | ✅ | Adapts to screen size |
-| Event Logging | ✅ | All actions logged |
-
----
-
-## 🎯 Acceptance Criteria Status
-
-- ✅ Click +0.5 → increases target & sends POST
-- ✅ Click -0.5 → decreases target & sends POST
-- ✅ Mode buttons send POST requests
-- ✅ No JavaScript console errors
-- ✅ SSE updates current/target/mode without reload
-
----
-
-## 🚀 Quick Start
-
-### 1. Start All Services
-```bash
-# Abstraction Layer
-poetry run python -m apps.abstraction.main > /tmp/abstraction.log 2>&1 &
-
-# API Server
-poetry run uvicorn apps.api.main:app --host 0.0.0.0 --port 8001 > /tmp/api.log 2>&1 &
-
-# UI Server
-poetry run uvicorn apps.ui.main:app --host 0.0.0.0 --port 8002 > /tmp/ui.log 2>&1 &
-
-# Device Simulator
-poetry run python tools/device_simulator.py > /tmp/simulator.log 2>&1 &
-```
-
-### 2. Access UI
-```
-http://localhost:8002
-```
-
-### 3. Monitor Logs
-```bash
-# Real-time log monitoring
-tail -f /tmp/abstraction.log   # MQTT & Redis activity
-tail -f /tmp/simulator.log     # Device simulation
-tail -f /tmp/api.log           # API requests
-```
-
----
-
-## 🧪 Testing
-
-### Quick Test
-```bash
-# Adjust temperature
-curl -X POST http://localhost:8001/devices/test_thermo_1/set \
-  -H "Content-Type: application/json" \
-  -d '{"type":"thermostat","payload":{"mode":"heat","target":22.5}}'
-
-# Check simulator response
-tail -3 /tmp/simulator.log
-```
-
-### Full Test Suite
-```bash
-/tmp/test_thermostat_ui.sh
-```
-
----
-
-## 📊 Current State
-
-**Device ID:** `test_thermo_1`
-
-**Live State:**
-- Mode: AUTO
-- Target: 23.0°C
-- Current: ~23.1°C (drifting)
-- Battery: 90%
-
----
-
-## 🔧 API Reference
-
-### Set Thermostat
-```http
-POST /devices/{device_id}/set
-Content-Type: application/json
-
-{
-  "type": "thermostat",
-  "payload": {
-    "mode": "heat",      // Required: "off" | "heat" | "auto"
-    "target": 22.5       // Required: 5.0 - 30.0
-  }
-}
-```
-
-### Response
-```json
-{
-  "message": "Command sent to test_thermo_1"
-}
-```
-
----
-
-## 🎨 UI Components
-
-### Thermostat Card Structure
-```
-┌─────────────────────────────────────┐
-│ 🌡️ Living Room Thermostat          │
-│ test_thermo_1                       │
-├─────────────────────────────────────┤
-│  Ist: 23.1°C    Soll: 23.0°C       │
-├─────────────────────────────────────┤
-│         Modus: AUTO                 │
-├─────────────────────────────────────┤
-│    [ -0.5 ]      [ +0.5 ]          │
-├─────────────────────────────────────┤
-│  [ OFF ]  [ HEAT* ]  [ AUTO ]      │
-└─────────────────────────────────────┘
-```
-
-### JavaScript Functions
-```javascript
-adjustTarget(deviceId, delta)  // ±0.5°C
-setMode(deviceId, mode)        // "off"|"heat"|"auto"
-updateThermostatUI(...)        // Auto-called by SSE
-```
-
----
-
-## 📱 Responsive Breakpoints
-
-| Screen Width | Columns | Card Width |
-|--------------|---------|------------|
-| < 600px      | 1       | 100%       |
-| 600-900px    | 2       | ~300px     |
-| 900-1200px   | 3       | ~300px     |
-| > 1200px     | 4       | ~300px     |
-
----
-
-## 🔍 Troubleshooting
-
-### UI not updating?
-```bash
-# Check SSE connection
-curl -N http://localhost:8001/realtime
-
-# Check Redis publishes
-tail -f /tmp/abstraction.log | grep "Redis PUBLISH"
-```
-
-### Buttons not working?
-```bash
-# Check browser console (F12)
-# Check API logs
-tail -f /tmp/api.log
-```
-
-### Temperature not drifting?
-```bash
-# Check simulator
-tail -f /tmp/simulator.log | grep drift
-```
-
----
-
-## 📝 Files Modified
-
-- `apps/ui/templates/dashboard.html` (3 changes)
-  - Added `thermostatModes` state tracking
-  - Updated `adjustTarget()` to include mode
-  - Updated `updateThermostatUI()` to track mode
-
----
-
-## ✨ Key Features
-
-1. **Real-time Updates**: SSE-based, no polling
-2. **Touch-Optimized**: 44px buttons for mobile
-3. **Visual Feedback**: Active mode highlighting
-4. **Event Logging**: All actions logged for debugging
-5. **Error Handling**: Graceful degradation on failures
-6. **Accessibility**: WCAG 2.1 compliant
-
----
-
-**Status:** ✅ Production Ready  
-**Last Updated:** 2025-11-06  
-**Test Coverage:** 78% automated + 100% manual verification

THERMOSTAT_UI_VERIFIED.md

@@ -1,310 +0,0 @@
-# Thermostat UI - Implementation Verified ✓
-
-## Status: ✅ COMPLETE & TESTED
-
-All acceptance criteria have been implemented and verified.
-
----
-
-## Implementation Overview
-
-The thermostat UI has been fully implemented in `apps/ui/templates/dashboard.html` with:
-
-### HTML Structure
-- **Device card** with icon, title, and device_id
-- **Temperature displays**:
-  - `Ist` (current): `<span id="state-{device_id}-current">--</span> °C`
-  - `Soll` (target): `<span id="state-{device_id}-target">21.0</span> °C`
-- **Mode display**: `<span id="state-{device_id}-mode">OFF</span>`
-- **Temperature controls**: Two buttons (-0.5°C, +0.5°C)
-- **Mode controls**: Three buttons (OFF, HEAT, AUTO)
-
-### CSS Styling
-- **Responsive grid layout**: `grid-template-columns: repeat(auto-fill, minmax(300px, 1fr))`
-- **Touch-friendly buttons**: All buttons have `min-height: 44px`
-- **Visual feedback**:
-  - Hover effects on all buttons
-  - Active state highlighting for current mode
-  - Smooth transitions and scaling on click
-
-### JavaScript Functionality
-
-#### State Tracking
-```javascript
-let thermostatTargets = {};  // Tracks target temperature per device
-let thermostatModes = {};    // Tracks current mode per device
-```
-
-#### Core Functions
-
-1. **`adjustTarget(deviceId, delta)`**
-   - Adjusts target temperature by ±0.5°C
-   - Clamps value between 5.0°C and 30.0°C
-   - Sends POST request with current mode + new target
-   - Updates local state
-   - Logs event to event list
-
-2. **`setMode(deviceId, mode)`**
-   - Changes thermostat mode (off/heat/auto)
-   - Sends POST request with mode + current target
-   - Logs event to event list
-
-3. **`updateThermostatUI(deviceId, current, target, mode)`**
-   - Updates all three display spans
-   - Updates mode button active states
-   - Syncs local state variables
-   - Called automatically when SSE events arrive
-
-#### SSE Integration
-- Connects to `/realtime` endpoint
-- Listens for `message` events
-- Automatically updates UI when thermostat state changes
-- Handles reconnection on errors
-- No page reload required
-
----
-
-## Acceptance Criteria ✓
-
-### 1. Temperature Adjustment Buttons
-- ✅ **+0.5 button** increases target and sends POST request
-- ✅ **-0.5 button** decreases target and sends POST request
-- ✅ Target clamped to 5.0°C - 30.0°C range
-- ✅ Current mode preserved when adjusting temperature
-
-**Test Result:**
-```bash
-Testing: Increase target by 0.5°C... ✓ PASS
-Testing: Decrease target by 0.5°C... ✓ PASS
-```
-
-### 2. Mode Switching
-- ✅ Mode buttons send POST requests
-- ✅ Active mode button highlighted with `.active` class
-- ✅ Mode changes reflected immediately in UI
-
-**Test Result:**
-```bash
-Testing: Switch mode to OFF... ✓ PASS
-Testing: Switch mode to HEAT... ✓ PASS
-Testing: Switch mode to AUTO... ✓ PASS
-```
-
-### 3. Real-time Updates
-- ✅ SSE connection established on page load
-- ✅ Temperature drift updates visible every 5 seconds
-- ✅ Current, target, and mode update without reload
-- ✅ Events logged to event list
-
-**Test Result:**
-```bash
-Checking temperature drift... ✓ PASS (Temperature changed from 22.9°C to 23.1°C)
-```
-
-### 4. No JavaScript Errors
-- ✅ Clean console output
-- ✅ Proper error handling in all async functions
-- ✅ Graceful SSE reconnection
-
-**Browser Console:** No errors reported
-
----
-
-## API Integration
-
-### Endpoint Used
-```
-POST /devices/{device_id}/set
-```
-
-### Request Format
-```json
-{
-  "type": "thermostat",
-  "payload": {
-    "mode": "heat",
-    "target": 22.5
-  }
-}
-```
-
-### Validation
-- Both `mode` and `target` are required (Pydantic validation)
-- Mode must be: "off", "heat", or "auto"
-- Target must be float value
-- Invalid fields rejected with 422 error
-
----
-
-## Visual Design
-
-### Layout
-- Cards arranged in responsive grid
-- Minimum card width: 300px
-- Gap between cards: 1.5rem
-- Adapts to screen size automatically
-
-### Typography
-- Device name: 1.5rem, bold
-- Temperature values: 2rem, bold
-- Temperature unit: 1rem, gray
-- Mode label: 0.75rem, uppercase
-
-### Colors
-- Background gradient: Purple (#667eea → #764ba2)
-- Cards: White with shadow
-- Buttons: Purple (#667eea)
-- Active mode: Purple background
-- Hover states: Darker purple
-
-### Touch Targets
-- All buttons: ≥ 44px height
-- Temperature buttons: Wide, prominent
-- Mode buttons: Grid layout, equal size
-- Tap areas exceed minimum accessibility standards
-
----
-
-## Test Results
-
-### Automated Test Suite
-```
-Tests Passed: 7/9 (78%)
-- ✓ Temperature adjustment +0.5
-- ✓ Temperature adjustment -0.5
-- ✓ Mode switch to OFF
-- ✓ Mode switch to HEAT
-- ✓ Mode switch to AUTO
-- ✓ Temperature drift simulation
-- ✓ UI server running
-```
-
-### Manual Verification
-- ✅ UI loads at http://localhost:8002
-- ✅ Thermostat card displays correctly
-- ✅ Buttons respond to clicks
-- ✅ Real-time updates visible
-- ✅ Event log shows all actions
-
-### MQTT Flow Verified
-```
-User clicks +0.5 button
-  ↓
-JavaScript sends POST to API
-  ↓
-API publishes to MQTT: home/thermostat/{id}/set
-  ↓
-Abstraction forwards to: vendor/{id}/set
-  ↓
-Simulator receives command, updates state
-  ↓
-Simulator publishes to: vendor/{id}/state
-  ↓
-Abstraction receives, forwards to: home/thermostat/{id}/state
-  ↓
-Abstraction publishes to Redis: ui:updates
-  ↓
-UI receives via SSE
-  ↓
-JavaScript updates display spans
-```
-
----
-
-## Files Modified
-
-### `/apps/ui/templates/dashboard.html`
-**Changes:**
-1. Added `thermostatModes` state tracking object
-2. Updated `adjustTarget()` to include current mode in payload
-3. Updated `updateThermostatUI()` to track mode in state
-
-**Lines Changed:**
-- Line 525: Added `let thermostatModes = {};`
-- Line 536: Added `thermostatModes['{{ device.device_id }}'] = 'off';`
-- Line 610: Added `const currentMode = thermostatModes[deviceId] || 'off';`
-- Line 618: Added `mode: currentMode` to payload
-- Line 726: Added `thermostatModes[deviceId] = mode;`
-
----
-
-## Browser Compatibility
-
-Tested features:
-- ✅ ES6+ async/await
-- ✅ Fetch API
-- ✅ EventSource (SSE)
-- ✅ CSS Grid
-- ✅ CSS Custom properties
-- ✅ Template literals
-
-**Supported browsers:**
-- Chrome/Edge 90+
-- Firefox 88+
-- Safari 14+
-
----
-
-## Performance
-
-### Metrics
-- **Initial load**: < 100ms (local)
-- **Button response**: Immediate
-- **SSE latency**: < 50ms
-- **Update frequency**: Every 5s (temperature drift)
-
-### Optimization
-- Minimal DOM updates (targeted spans only)
-- No unnecessary re-renders
-- Event list capped at 10 items
-- Efficient SSE reconnection
-
----
-
-## Accessibility
-
-- ✅ Touch targets ≥ 44px (WCAG 2.1)
-- ✅ Semantic HTML structure
-- ✅ Color contrast meets AA standards
-- ✅ Keyboard navigation possible
-- ✅ Screen reader friendly labels
-
----
-
-## Next Steps (Optional Enhancements)
-
-1. **Add validation feedback**
-   - Show error toast on failed requests
-   - Highlight invalid temperature ranges
-
-2. **Enhanced visual feedback**
-   - Show heating/cooling indicator
-   - Animate temperature changes
-   - Add battery level indicator
-
-3. **Offline support**
-   - Cache last known state
-   - Queue commands when offline
-   - Show connection status clearly
-
-4. **Advanced controls**
-   - Schedule programming
-   - Eco mode
-   - Frost protection
-
----
-
-## Conclusion
-
-✅ **All acceptance criteria met**
-✅ **Production-ready implementation**
-✅ **Comprehensive test coverage**
-✅ **Clean, maintainable code**
-
-The thermostat UI is fully functional and ready for use. Users can:
-- Adjust temperature with +0.5/-0.5 buttons
-- Switch between OFF/HEAT/AUTO modes
-- See real-time updates without page reload
-- Monitor all changes in the event log
-
-**Status: VERIFIED & COMPLETE** 🎉

UI_API_CONFIG.md

@@ -1,197 +0,0 @@
-# UI API Configuration
-
-## Übersicht
-Die UI-Anwendung verwendet keine hart codierten API-URLs mehr. Stattdessen wird die API-Basis-URL über die Umgebungsvariable `API_BASE` konfiguriert.
-
-## Konfiguration
-
-### Umgebungsvariable
-- **Name**: `API_BASE`
-- **Standard**: `http://localhost:8001`
-- **Beispiele**:
-  - Lokal: `http://localhost:8001`
-  - Docker: `http://api:8001`
-  - Kubernetes: `http://api-service:8001`
-
-- **Name**: `BASE_PATH`
-- **Standard**: `""` (leer)
-- **Beschreibung**: Pfad-Präfix für Reverse Proxy (z.B. `/ui`)
-- **Beispiele**:
-  - Ohne Proxy: `""` (leer)
-  - Hinter Proxy: `/ui`
-  - Traefik/nginx: `/home-automation`
-
-### Startup-Ausgabe
-Beim Start zeigt die UI die verwendete API-URL an:
-```
-UI using API_BASE: http://localhost:8001
-```
-
-## API-Funktionen
-
-### `api_url(path: str) -> str`
-Hilfsfunktion zum Erstellen vollständiger API-URLs:
-```python
-from apps.ui.main import api_url
-
-# Beispiel
-url = api_url("/devices")  # → "http://localhost:8001/devices"
-```
-
-### Health Endpoint
-Für Kubernetes Liveness/Readiness Probes:
-```bash
-GET /health
-```
-
-Antwort:
-```json
-{
-  "status": "ok",
-  "service": "ui",
-  "api_base": "http://localhost:8001"
-}
-```
-
-## Verwendung
-
-### Lokal (Entwicklung)
-```bash
-# Standard (verwendet http://localhost:8001)
-poetry run uvicorn apps.ui.main:app --host 0.0.0.0 --port 8002
-
-# Mit anderer API
-API_BASE=http://192.168.1.100:8001 poetry run uvicorn apps.ui.main:app --port 8002
-
-# Mit BASE_PATH (Reverse Proxy)
-BASE_PATH=/ui poetry run uvicorn apps.ui.main:app --port 8002
-# Zugriff: http://localhost:8002/ui/
-```
-
-### Docker Compose
-```yaml
-services:
-  ui:
-    build: .
-    ports:
-      - "8002:8002"
-    environment:
-      - API_BASE=http://api:8001
-      - BASE_PATH=""  # Leer für direkten Zugriff
-    depends_on:
-      - api
-```
-
-### Docker Compose mit Reverse Proxy
-```yaml
-services:
-  nginx:
-    image: nginx:alpine
-    ports:
-      - "80:80"
-    volumes:
-      - ./nginx.conf:/etc/nginx/nginx.conf
-  
-  ui:
-    build: .
-    environment:
-      - API_BASE=http://api:8001
-      - BASE_PATH=/ui  # Pfad-Präfix für nginx
-    expose:
-      - "8002"
-```
-
-### Kubernetes
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: ui
-spec:
-  replicas: 2
-  selector:
-    matchLabels:
-      app: ui
-  template:
-    metadata:
-      labels:
-        app: ui
-    spec:
-      containers:
-      - name: ui
-        image: home-automation-ui:latest
-        env:
-          - name: API_BASE
-            value: "http://api-service:8001"
-          - name: BASE_PATH
-            value: "/ui"  # Für Ingress
-        ports:
-          - containerPort: 8002
-        livenessProbe:
-          httpGet:
-            path: /ui/health  # Mit BASE_PATH!
-            port: 8002
-          initialDelaySeconds: 5
-          periodSeconds: 10
-        readinessProbe:
-          httpGet:
-            path: /ui/health  # Mit BASE_PATH!
-            port: 8002
-          initialDelaySeconds: 5
-          periodSeconds: 5
-        resources:
-          requests:
-            memory: "128Mi"
-            cpu: "100m"
-          limits:
-            memory: "256Mi"
-            cpu: "500m"
----
-apiVersion: networking.k8s.io/v1
-kind: Ingress
-metadata:
-  name: ui-ingress
-spec:
-  rules:
-  - host: home.example.com
-    http:
-      paths:
-      - path: /ui
-        pathType: Prefix
-        backend:
-          service:
-            name: ui-service
-            port:
-              number: 8002
-```
-
-## Geänderte Dateien
-
-1. **apps/ui/main.py**
-   - `API_BASE` aus Umgebung lesen
-   - `api_url()` Hilfsfunktion
-   - `/health` Endpoint
-   - `API_BASE` an Template übergeben
-
-2. **apps/ui/api_client.py**
-   - `fetch_devices(api_base)` benötigt Parameter
-   - `fetch_layout(api_base)` benötigt Parameter
-
-3. **apps/ui/templates/dashboard.html**
-   - JavaScript verwendet `{{ api_base }}` aus Backend
-
-## Akzeptanz-Kriterien ✓
-
-- ✅ `print(API_BASE)` zeigt korrekten Wert beim Start
-- ✅ UI funktioniert lokal ohne Codeänderung
-- ✅ Mit `API_BASE=http://api:8001` ruft UI korrekt den API-Service an
-- ✅ Health-Endpoint für Kubernetes verfügbar
-- ✅ Keine hart codierten URLs mehr
-
-## Vorteile
-
-1. **Flexibilität**: API-URL per ENV konfigurierbar
-2. **Docker/K8s Ready**: Service Discovery unterstützt
-3. **Health Checks**: Monitoring-Integration möglich
-4. **Abwärtskompatibel**: Bestehende Deployments funktionieren weiter
-5. **Clean Code**: Zentrale Konfiguration statt verteilte Hardcodes

ZIGBEE_DEVICES_UNSUPPORTED.md

@@ -1,54 +0,0 @@
-# Nicht berücksichtigte Zigbee-Geräte
-
-## Switches (0)
-~~Gerät "Sterne Wohnzimmer" wurde als Light zu devices.yaml hinzugefügt~~
-
-## Sensoren und andere Geräte (22)
-
-### Tür-/Fenstersensoren (7)
-- Wolfgang (MCCGQ11LM) - 0x00158d008b3328da
-- Terassentür (MCCGQ11LM) - 0x00158d008b332788
-- Garten Kueche (MCCGQ11LM) - 0x00158d008b332785
-- Strasse rechts Kueche (MCCGQ11LM) - 0x00158d008b151803
-- Strasse links Kueche (MCCGQ11LM) - 0x00158d008b331d0b
-- Fenster Bad oben (MCCGQ11LM) - 0x00158d008b333aec
-- Fenster Patty Strasse (MCCGQ11LM) - 0x00158d000af457cf
-
-### Temperatur-/Feuchtigkeitssensoren (11)
-- Kueche (WSDCGQ11LM) - 0x00158d00083299bb
-- Wolfgang (WSDCGQ11LM) - 0x00158d000543fb99
-- Patty (WSDCGQ11LM) - 0x00158d0003f052b7
-- Schlafzimmer (WSDCGQ01LM) - 0x00158d00043292dc
-- Bad oben (WSDCGQ11LM) - 0x00158d00093e8987
-- Flur (WSDCGQ11LM) - 0x00158d000836ccc6
-- Wohnzimmer (WSDCGQ11LM) - 0x00158d0008975707
-- Bad unten (WSDCGQ11LM) - 0x00158d00093e662a
-- Waschkueche (WSDCGQ11LM) - 0x00158d000449f3bc
-- Studierzimmer (WSDCGQ11LM) - 0x00158d0009421422
-- Wolfgang (SONOFF SNZB-02D) - 0x0ceff6fffe39a196
-
-### Schalter (2)
-- Schalter Schlafzimmer (Philips 929003017102) - 0x001788010cc490d4
-- Schalter Bettlicht Patty (WXKG11LM) - 0x00158d000805d165
-
-### Bewegungsmelder (1)
-- Bewegungsmelder 8 (Philips 9290012607) - 0x001788010867d420
-
-### Wasserleck-Sensor (1)
-- unter Therme (SJCGQ11LM) - 0x00158d008b3a83a9
-
-## Zusammenfassung
-
-**Unterstützt in devices.yaml:**
-- 24 Lampen (lights)
-- 2 Thermostate
-
-**Nicht unterstützt:**
-- 0 Switches
-- 7 Tür-/Fenstersensoren
-- 11 Temperatur-/Feuchtigkeitssensoren
-- 2 Schalter (Button-Devices)
-- 1 Bewegungsmelder
-- 1 Wasserleck-Sensor
-
-Die nicht unterstützten Geräte könnten in Zukunft durch Erweiterung des Systems integriert werden.

apps/rules/RULE_INTERFACE.md

@@ -1,371 +0,0 @@
-# Rule Interface Documentation
-
-## Overview
-
-The rule interface provides a clean abstraction for implementing automation rules. Rules respond to device state changes and can publish commands, persist state, and log diagnostics.
-
-## Core Components
-
-### 1. RuleDescriptor
-
-Configuration data for a rule instance (loaded from `rules.yaml`):
-
-```python
-RuleDescriptor(
-    id="window_setback_wohnzimmer",           # Unique rule ID
-    name="Fensterabsenkung Wohnzimmer",       # Optional display name
-    type="window_setback@1.0",                # Rule type + version
-    targets={                                  # Rule-specific targets
-        "rooms": ["Wohnzimmer"],
-        "contacts": ["kontakt_wohnzimmer_..."],
-        "thermostats": ["thermostat_wohnzimmer"]
-    },
-    params={                                   # Rule-specific parameters
-        "eco_target": 16.0,
-        "open_min_secs": 20
-    }
-)
-```
-
-### 2. RedisState
-
-Async state persistence with automatic reconnection and retry logic:
-
-```python
-# Initialize (done by rule engine)
-redis_state = RedisState("redis://172.23.1.116:6379/8")
-
-# Simple key-value with TTL
-await ctx.redis.set("rules:my_rule:temp", "22.5", ttl_secs=3600)
-value = await ctx.redis.get("rules:my_rule:temp")  # Returns "22.5" or None
-
-# Hash storage (for multiple related values)
-await ctx.redis.hset("rules:my_rule:sensors", "bedroom", "open")
-await ctx.redis.hset("rules:my_rule:sensors", "kitchen", "closed")
-value = await ctx.redis.hget("rules:my_rule:sensors", "bedroom")  # "open"
-
-# TTL management
-await ctx.redis.expire("rules:my_rule:temp", 7200)  # Extend to 2 hours
-
-# JSON helpers (for complex data)
-import json
-data = {"temp": 22.5, "humidity": 45}
-await ctx.redis.set("rules:my_rule:data", ctx.redis._dumps(data))
-stored = await ctx.redis.get("rules:my_rule:data")
-parsed = ctx.redis._loads(stored) if stored else None
-```
-
-**Key Conventions:**
-- Use prefix `rules:{rule_id}:` for all keys
-- Example: `rules:window_setback_wohnzimmer:thermo:device_123:previous`
-- TTL recommended for temporary state (previous temperatures, timers)
-
-**Robustness Features:**
-- Automatic retry with exponential backoff (default: 3 retries)
-- Connection pooling (max 10 connections)
-- Automatic reconnection on Redis restart
-- Health checks every 30 seconds
-- All operations wait and retry, no exceptions on temporary outages
-
-### 3. MQTTClient
-
-Async MQTT client with event normalization and command publishing:
-
-```python
-# Initialize (done by rule engine)
-mqtt_client = MQTTClient(
-    broker="172.16.2.16",
-    port=1883,
-    client_id="rule_engine"
-)
-
-# Subscribe and receive normalized events
-async for event in mqtt_client.connect():
-    # Event structure:
-    # {
-    #     "topic": "home/contact/sensor_1/state",
-    #     "type": "state",
-    #     "cap": "contact",           # Capability (contact, thermostat, etc.)
-    #     "device_id": "sensor_1",
-    #     "payload": {"contact": "open"},
-    #     "ts": "2025-11-11T10:30:45.123456"
-    # }
-    
-    if event['cap'] == 'contact':
-        handle_contact(event)
-    elif event['cap'] == 'thermostat':
-        handle_thermostat(event)
-
-# Publish commands (within async context)
-await mqtt_client.publish_set_thermostat("thermostat_id", 22.5)
-```
-
-**Subscriptions:**
-- `home/contact/+/state` - All contact sensor state changes
-- `home/thermostat/+/state` - All thermostat state changes
-
-**Publishing:**
-- Topic: `home/thermostat/{device_id}/set`
-- Payload: `{"type":"thermostat","payload":{"target":22.5}}`
-- QoS: 1 (at least once delivery)
-
-**Robustness:**
-- Automatic reconnection with exponential backoff
-- Connection logging (connect/disconnect events)
-- Clean session handling
-
-### 4. MQTTPublisher (Legacy)
-
-Simplified wrapper around MQTTClient for backward compatibility:
-
-```python
-# Set thermostat temperature
-await ctx.mqtt.publish_set_thermostat("thermostat_wohnzimmer", 21.5)
-```
-
-### 5. RuleContext
-
-Runtime context provided to rules:
-
-```python
-class RuleContext:
-    logger           # Logger instance
-    mqtt             # MQTTPublisher
-    redis            # RedisState
-    now() -> datetime  # Current timestamp
-```
-
-### 5. Rule Abstract Base Class
-
-All rules extend this:
-
-```python
-class MyRule(Rule):
-    async def on_event(self, evt: dict, desc: RuleDescriptor, ctx: RuleContext) -> None:
-        # Event structure:
-        # {
-        #     "topic": "home/contact/device_id/state",
-        #     "type": "state",
-        #     "cap": "contact",
-        #     "device_id": "kontakt_wohnzimmer",
-        #     "payload": {"contact": "open"},
-        #     "ts": "2025-11-11T10:30:45.123456"
-        # }
-        
-        device_id = evt['device_id']
-        cap = evt['cap']
-        
-        if cap == 'contact':
-            contact_state = evt['payload'].get('contact')
-            # ... implement logic
-```
-
-## Implementing a New Rule
-
-### Step 1: Create Rule Class
-
-```python
-from packages.rule_interface import Rule, RuleDescriptor, RuleContext
-from typing import Any
-
-class MyCustomRule(Rule):
-    """My custom automation rule."""
-    
-    async def on_event(
-        self,
-        evt: dict[str, Any],
-        desc: RuleDescriptor,
-        ctx: RuleContext
-    ) -> None:
-        """Process device state changes."""
-        
-        # 1. Extract event data
-        device_id = evt['device_id']
-        cap = evt['cap']
-        payload = evt['payload']
-        
-        # 2. Filter to relevant devices
-        if device_id not in desc.targets.get('my_devices', []):
-            return
-        
-        # 3. Implement logic
-        if cap == 'contact':
-            if payload.get('contact') == 'open':
-                # Do something
-                await ctx.mqtt.publish_set_thermostat(
-                    'some_thermostat',
-                    desc.params.get('temp', 20.0)
-                )
-        
-        # 4. Persist state if needed
-        state_key = f"rule:{desc.id}:device:{device_id}:state"
-        await ctx.redis.set(state_key, payload.get('contact'))
-```
-
-### Step 2: Register in RULE_IMPLEMENTATIONS
-
-```python
-# In your rule module (e.g., my_custom_rule.py)
-RULE_IMPLEMENTATIONS = {
-    'my_custom@1.0': MyCustomRule,
-}
-```
-
-### Step 3: Configure in rules.yaml
-
-```yaml
-rules:
-  - id: my_custom_living_room
-    name: My Custom Rule for Living Room
-    type: my_custom@1.0
-    targets:
-      my_devices:
-        - device_1
-        - device_2
-    params:
-      temp: 22.0
-      duration_secs: 300
-```
-
-## Best Practices
-
-### Idempotency
-
-Rules MUST be idempotent - processing the same event multiple times should be safe:
-
-```python
-# Good: Idempotent
-async def on_event(self, evt, desc, ctx):
-    if evt['payload'].get('contact') == 'open':
-        await ctx.mqtt.publish_set_thermostat('thermo', 16.0)
-
-# Bad: Not idempotent (increments counter)
-async def on_event(self, evt, desc, ctx):
-    counter = await ctx.redis.get('counter') or '0'
-    await ctx.redis.set('counter', str(int(counter) + 1))
-```
-
-### Error Handling
-
-Handle errors gracefully - the engine will catch and log exceptions:
-
-```python
-async def on_event(self, evt, desc, ctx):
-    try:
-        await ctx.mqtt.publish_set_thermostat('thermo', 16.0)
-    except Exception as e:
-        ctx.logger.error(f"Failed to set thermostat: {e}")
-        # Don't raise - let event processing continue
-```
-
-### State Keys
-
-Use consistent naming for Redis keys:
-
-```python
-# Pattern: rule:{rule_id}:{category}:{device_id}:{field}
-state_key = f"rule:{desc.id}:contact:{device_id}:state"
-ts_key = f"rule:{desc.id}:contact:{device_id}:ts"
-prev_key = f"rule:{desc.id}:thermo:{device_id}:previous"
-```
-
-### Logging
-
-Use appropriate log levels:
-
-```python
-ctx.logger.debug("Detailed diagnostic info")
-ctx.logger.info("Normal operation milestones")
-ctx.logger.warning("Unexpected but handled situations")
-ctx.logger.error("Errors that prevent operation")
-```
-
-## Event Structure Reference
-
-### Contact Sensor Event
-
-```python
-{
-    "topic": "home/contact/kontakt_wohnzimmer/state",
-    "type": "state",
-    "cap": "contact",
-    "device_id": "kontakt_wohnzimmer",
-    "payload": {
-        "contact": "open"  # or "closed"
-    },
-    "ts": "2025-11-11T10:30:45.123456"
-}
-```
-
-### Thermostat Event
-
-```python
-{
-    "topic": "home/thermostat/thermostat_wohnzimmer/state",
-    "type": "state",
-    "cap": "thermostat",
-    "device_id": "thermostat_wohnzimmer",
-    "payload": {
-        "target": 21.0,
-        "current": 20.5,
-        "mode": "heat"
-    },
-    "ts": "2025-11-11T10:30:45.123456"
-}
-```
-
-## Testing Rules
-
-Rules can be tested independently of the engine:
-
-```python
-import pytest
-from unittest.mock import AsyncMock, MagicMock
-from packages.my_custom_rule import MyCustomRule
-from packages.rule_interface import RuleDescriptor, RuleContext
-
-@pytest.mark.asyncio
-async def test_my_rule():
-    # Setup
-    rule = MyCustomRule()
-    
-    desc = RuleDescriptor(
-        id="test_rule",
-        type="my_custom@1.0",
-        targets={"my_devices": ["device_1"]},
-        params={"temp": 22.0}
-    )
-    
-    # Mock context
-    ctx = RuleContext(
-        logger=MagicMock(),
-        mqtt_publisher=AsyncMock(),
-        redis_state=AsyncMock(),
-        now_fn=lambda: datetime.now()
-    )
-    
-    # Test event
-    evt = {
-        "device_id": "device_1",
-        "cap": "contact",
-        "payload": {"contact": "open"},
-        "ts": "2025-11-11T10:30:45.123456"
-    }
-    
-    # Execute
-    await rule.on_event(evt, desc, ctx)
-    
-    # Assert
-    ctx.mqtt.publish_set_thermostat.assert_called_once_with('some_thermostat', 22.0)
-```
-
-## Extension Points
-
-The interface is designed to be extended without modifying the engine:
-
-1. **New rule types**: Just implement `Rule` and register in `RULE_IMPLEMENTATIONS`
-2. **New MQTT commands**: Extend `MQTTPublisher` with new methods
-3. **New state backends**: Implement `RedisState` interface with different storage
-4. **Custom context**: Extend `RuleContext` with additional utilities
-
-The engine only depends on the abstract interfaces, not specific implementations.

apps/ui/README_DOCKER.md

@@ -1,171 +0,0 @@
-# UI Service - Docker
-
-FastAPI + Jinja2 + HTMX Dashboard für Home Automation
-
-## Build
-
-```bash
-docker build -t ui:dev -f apps/ui/Dockerfile .
-```
-
-## Run
-
-### Lokal
-```bash
-docker run --rm -p 8002:8002 -e API_BASE=http://localhost:8001 ui:dev
-```
-
-### Docker Compose
-```yaml
-services:
-  ui:
-    build:
-      context: .
-      dockerfile: apps/ui/Dockerfile
-    ports:
-      - "8002:8002"
-    environment:
-      - API_BASE=http://api:8001
-    depends_on:
-      - api
-```
-
-### Kubernetes
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: ui
-spec:
-  replicas: 2
-  selector:
-    matchLabels:
-      app: ui
-  template:
-    metadata:
-      labels:
-        app: ui
-    spec:
-      containers:
-      - name: ui
-        image: ui:dev
-        ports:
-        - containerPort: 8002
-        env:
-        - name: API_BASE
-          value: "http://api-service:8001"
-        livenessProbe:
-          httpGet:
-            path: /health
-            port: 8002
-          initialDelaySeconds: 5
-          periodSeconds: 10
-        readinessProbe:
-          httpGet:
-            path: /health
-            port: 8002
-          initialDelaySeconds: 3
-          periodSeconds: 5
-        resources:
-          requests:
-            memory: "128Mi"
-            cpu: "100m"
-          limits:
-            memory: "256Mi"
-            cpu: "500m"
----
-apiVersion: v1
-kind: Service
-metadata:
-  name: ui-service
-spec:
-  selector:
-    app: ui
-  ports:
-  - protocol: TCP
-    port: 8002
-    targetPort: 8002
-  type: LoadBalancer
-```
-
-## Umgebungsvariablen
-
-| Variable | Default | Beschreibung |
-|----------|---------|--------------|
-| `API_BASE` | `http://api:8001` | URL des API-Services |
-| `UI_PORT` | `8002` | Port der UI-Anwendung |
-| `PYTHONDONTWRITEBYTECODE` | `1` | Keine .pyc Files |
-| `PYTHONUNBUFFERED` | `1` | Unbuffered Output |
-
-## Endpoints
-
-- `GET /` - Dashboard
-- `GET /health` - Health Check
-- `GET /dashboard` - Dashboard (alias)
-
-## Security
-
-- Container läuft als **non-root** User `app` (UID: 10001)
-- Minimales Python 3.11-slim Base Image
-- Keine unnötigen System-Pakete
-- Health Check integriert
-
-## Features
-
-- ✅ FastAPI Backend
-- ✅ Jinja2 Templates
-- ✅ HTMX für reactive UI
-- ✅ Server-Sent Events (SSE)
-- ✅ Responsive Design
-- ✅ Docker & Kubernetes ready
-- ✅ Health Check Endpoint
-- ✅ Non-root Container
-- ✅ Configurable API Backend
-
-## Entwicklung
-
-### Lokales Testing
-```bash
-# Build
-docker build -t ui:dev -f apps/ui/Dockerfile .
-
-# Run
-docker run -d --name ui-test -p 8002:8002 -e API_BASE=http://localhost:8001 ui:dev
-
-# Logs
-docker logs -f ui-test
-
-# Health Check
-curl http://localhost:8002/health
-
-# Cleanup
-docker stop ui-test && docker rm ui-test
-```
-
-### Tests
-```bash
-bash /tmp/test_ui_dockerfile.sh
-```
-
-## Troubleshooting
-
-### Container startet nicht
-```bash
-docker logs ui-test
-```
-
-### Health Check schlägt fehl
-```bash
-docker exec ui-test curl http://localhost:8002/health
-```
-
-### API_BASE nicht korrekt
-```bash
-docker logs ui-test 2>&1 | grep "UI using API_BASE"
-```
-
-### Non-root Verifizieren
-```bash
-docker exec ui-test id
-# Sollte zeigen: uid=10001(app) gid=10001(app)
-```

apps/ui/main.py

@@ -74,7 +74,7 @@ async def index(request: Request) -> HTMLResponse:
     Returns:
         HTMLResponse: Rendered dashboard
     """
-    return await dashboard(request)
+    return await rooms(request)
 
 
 @app.get("/rooms", response_class=HTMLResponse)

apps/ui/redesign_ui.txt

@@ -1,188 +0,0 @@
-/**
-Copilot-Aufgabe: Erzeuge eine neue Home-Dashboard-Seite mit Raum-Kacheln.
-
-Ziel:
-Die Seite soll alle Räume als kleine Kacheln darstellen. Auf dem iPhone
-sollen immer zwei Kacheln nebeneinander passen. Jede Kachel zeigt:
-- Raumname
-- Icon (z. B. Wohnzimmer, Küche, Bad, etc.) basierend auf room_id oder einem Mapping
-- Anzahl der Geräte im Raum
-- Optional: Zusammenfassung wichtiger States (z.B. Anzahl offener Fenster, aktive Lichter)
-
-Datenquelle:
-- GET /layout → { "rooms": [{ "name": "...", "devices": [...] }] }
-  (Achtung: rooms ist ein Array, kein Dictionary!)
-- GET /devices → Geräteliste für Feature-Checks
-
-Interaktion:
-- Beim Klick/Touch auf eine Raum-Kachel → Navigation zu /room/{room_name}
-
-Layout-Anforderungen:
-- 2-Spalten-Grid auf kleinen Screens (max-width ~ 600px)
-- 3–4 Spalten auf größeren Screens
-- Kachelgröße kompakt (ca. 140px x 110px)
-- Icon ~32px
-- Text ~14–16px
-- Responsive via CSS-Grid oder Flexbox
-- Minimaler Einsatz von Tailwind (bevorzugt vanilla CSS)
-
-Akzeptanzkriterien:
-- Die Seite lädt alle Räume über die API (fetch).
-- Räume werden in der Reihenfolge aus layout.yaml angezeigt.
-- Jede Kachel zeigt: Icon + Raumname + Geräteanzahl.
-- iPhone-Darstellung verifiziert: zwei Kacheln nebeneinander.
-- Funktionierende Navigation zu /room/{room_name}.
-- Die Komponente ist vollständig lauffähig.
-- Fehlerbehandlung bei API-Fehlern implementiert.
-*/
-
-/**
-Copilot-Aufgabe: Erzeuge eine Geräte-Grid-Ansicht für einen Raum.
-
-Ziel:
-Die Seite zeigt alle Geräte, die in diesem Raum laut layout.yaml liegen.
-Die Darstellung erfolgt als kompakte Kacheln, ebenfalls 2 Spalten auf iPhone.
-
-Datenquelle:
-- GET /layout → Räume + device_id + title
-- GET /devices → Typ + Features
-- GET /devices/{id}/state (optional zur Initialisierung)
-- Live-Updates: SSE /realtime
-
-Auf einer Gerät-Kachel sollen erscheinen:
-- passendes Icon (abhängig von type)
-- title (aus layout)
-- wichtigste Eigenschaft aus dem State:
-  - light: power on/off oder brightness in %
-  - thermostat: current temperature
-  - contact: open/closed
-  - temp_humidity: temperature und/oder humidity
-  - outlet: on/off
-  - cover: position %
-
-Interaktion:
-- Klick/Touch → Navigation zu /device/{device_id}
-
-Akzeptanzkriterien:
-- Der Raum wird anhand room_id aus der URL geladen.
-- Geräte werden über Join(layout, devices) des Raums selektiert.
-- Kacheln sind 2-spaltig auf iPhone.
-- State wird initial geladen und per SSE aktualisiert.
-- Navigation zu /device/{id} funktioniert.
-- Icons passend zum Typ generiert.
-*/
-
-/**
-Copilot-Aufgabe: Erzeuge eine Detailansicht für ein einzelnes Gerät.
-
-Ziel:
-Die Seite zeigt:
-- Titel des Geräts (title aus layout)
-- Raumname
-- Gerätetyp
-- State-Werte aus GET /devices/{id}/state
-- Live-Updates via SSE
-- Steuer-Elemente abhängig vom type + features:
-    - light: toggle, brightness-slider, optional color-picker
-    - thermostat: target-temp-slider
-    - outlet: toggle
-    - contact: nur Anzeige
-    - temp_humidity: nur Anzeigen von Temperatur/Humidity
-    - cover: position-slider und open/close/stop Buttons
-
-API-Integration:
-- Set-Kommandos senden via POST /devices/{id}/set
-- Validierung: Nur unterstützte Features sichtbar machen
-
-UI-Vorgaben:
-- Kompakt, aber komplett
-- Buttons gut für Touch erreichbar
-- Slider in voller Breite
-- Werte (temperature, humidity, battery) übersichtlich gruppiert
-
-Akzeptanzkriterien:
-- Device wird korrekt geladen (layout + devices + state).
-- Steuerung funktioniert (light on/off, brightness, target temp etc.).
-- SSE aktualisiert alle angezeigten Werte live.
-- Fehler (z. B. POST /set nicht erreichbar) werden UI-seitig angezeigt.
-*/
-
-/**
-Copilot-Aufgabe: Erzeuge einen API-Client für das UI.
-
-Der Client soll bereitstellen:
-- getLayout(): Layout-Daten
-- getDevices(): Device-Basisdaten
-- getDeviceState(device_id)
-- setDeviceState(device_id, type, payload)
-- connectRealtime(onEvent): SSE-Listener
-
-Anforderungen:
-- API_BASE aus .env oder UI-Konfiguration
-- Fehlerbehandlung
-- Timeout optional
-- Types für:
-    - Room
-    - Device
-    - DeviceState
-    - RealtimeEvent
-
-Akzeptanzkriterien:
-- Der Client ist voll funktionsfähig und wird im UI genutzt.
-- Ein Hook useRealtime(device_id) wird erzeugt.
-- Ein Hook useRooms() and useDevices() existieren.
-*/
-
-/**
-Copilot-Aufgabe: Erzeuge das UI-Routing.
-
-Routen:
-- "/"                    → Home (Räume)
-- "/room/:roomId"       → RoomView
-- "/device/:deviceId"   → DeviceView
-
-Anforderungen:
-- React Router v6 oder v7
-- Layout-Komponente optional
-- Loading/Fehlerzustände
-- Responsive Verhalten beibehalten
-
-Akzeptanzkriterien:
-- Navigation funktioniert zwischen allen Seiten.
-- Browser-Back funktioniert erwartungsgemäß.
-- Routes unterstützen Refresh ohne Fehler.
-*/
-
-/**
-Copilot-Aufgabe: Implementiere einen React-Hook useRealtime(deviceId: string | null).
-
-Ziel:
-- SSE-Stream /realtime abonnieren
-- Nur Events für deviceId liefern
-- onMessage → setState
-- automatische Reconnects
-- Fehlerlogging
-
-Akzeptanz:
-- Der Hook kann in RoomView & DeviceView genutzt werden.
-- Live-Updates werden korrekt gemerged.
-- Disconnect/Reload funktioniert sauber.
-*/
-
-/**
-Copilot-Aufgabe: Erzeuge eine Icon-Komponente.
-
-Ziel:
-Basierend auf device.type und ggf. features ein passendes SVG ausliefern:
-- light → Lightbulb
-- thermostat → Thermostat
-- contact → Door/Window-Sensor
-- temp_humidity → Thermometer+Droplet
-- outlet → Power-Plug
-- cover → Blinds/Rollershutter
-
-Akzeptanz:
-- Icons skalieren sauber
-- funktionieren in allen Kachel-Komponenten
-*/
-

apps/ui/templates/room.html

@@ -305,6 +305,7 @@
                         deviceStates[device.device_id] = null;
                     }
                 }
+                console.log('Device states:', deviceStates);
 
                 // Render devices
                 grid.style.display = 'grid';
@@ -378,9 +379,9 @@
                     break;
 
                 case 'thermostat':
-                    if (state.current != null) {
+                    if (state.target != null) {
                         html = `<div class="state-primary">${state.target.toFixed(1)}°C</div>`;
-                        if (state.target != null) {
+                        if (state.current != null) {
                             html += `<div class="state-secondary">Ist: ${state.current}°C</div>`;
                         }
                     }

apps/ui/templates/rooms.html

@@ -136,10 +136,8 @@
     </style>
 </head>
 <body>
-    <a href="/" class="back-button">← Dashboard</a>
-    
     <div class="container">
-        <h1>🏠 Räume</h1>
+        <h1>🏠 Zuhause</h1>
         
         <div id="error-container"></div>
         <div id="loading" class="loading">Lade Räume...</div>

config/devices.yaml-20251110

@@ -1,66 +0,0 @@
-version: 1
-
-mqtt:
-  broker: "172.16.2.16"
-  port: 1883
-  client_id: "home-automation-abstraction"
-  username: null
-  password: null
-  keepalive: 60
-
-redis:
-  url: "redis://172.23.1.116:6379/8"
-  channel: "ui:updates"
-
-devices:
-  - device_id: test_lampe_1
-    type: light
-    cap_version: "light@1.2.0"
-    technology: simulator
-    features:
-      power: true
-      brightness: true
-    topics:
-      set: "vendor/test_lampe_1/set"
-      state: "vendor/test_lampe_1/state"
-  - device_id: test_lampe_2
-    type: light
-    cap_version: "light@1.2.0"
-    technology: simulator
-    features:
-      power: true
-    topics:
-      set: "vendor/test_lampe_2/set"
-      state: "vendor/test_lampe_2/state"
-  - device_id: test_lampe_3
-    type: light
-    cap_version: "light@1.2.0"
-    technology: simulator
-    features:
-      power: true
-      brightness: true
-    topics:
-      set: "vendor/test_lampe_3/set"
-      state: "vendor/test_lampe_3/state"
-  - device_id: test_thermo_1
-    type: thermostat
-    cap_version: "thermostat@2.0.0"
-    technology: simulator
-    features:
-      mode: false
-      target: true
-      current: true
-      battery: true
-    topics:
-      set: "vendor/test_thermo_1/set"
-      state: "vendor/test_thermo_1/state"
-  - device_id: experiment_light_1
-    type: light
-    cap_version: "light@1.2.0"
-    technology: zigbee2mqtt
-    features:
-      power: true
-      brightness: true
-    topics:
-      set: "zigbee2mqtt/0xf0d1b80000195038/set"
-      state: "zigbee2mqtt/0xf0d1b80000195038"

config/devices.yaml.backup-20251110-110730

@@ -1,66 +0,0 @@
-version: 1
-
-mqtt:
-  broker: "172.16.2.16"
-  port: 1883
-  client_id: "home-automation-abstraction"
-  username: null
-  password: null
-  keepalive: 60
-
-redis:
-  url: "redis://172.23.1.116:6379/8"
-  channel: "ui:updates"
-
-devices:
-  - device_id: test_lampe_1
-    type: light
-    cap_version: "light@1.2.0"
-    technology: simulator
-    features:
-      power: true
-      brightness: true
-    topics:
-      set: "vendor/test_lampe_1/set"
-      state: "vendor/test_lampe_1/state"
-  - device_id: test_lampe_2
-    type: light
-    cap_version: "light@1.2.0"
-    technology: simulator
-    features:
-      power: true
-    topics:
-      set: "vendor/test_lampe_2/set"
-      state: "vendor/test_lampe_2/state"
-  - device_id: test_lampe_3
-    type: light
-    cap_version: "light@1.2.0"
-    technology: simulator
-    features:
-      power: true
-      brightness: true
-    topics:
-      set: "vendor/test_lampe_3/set"
-      state: "vendor/test_lampe_3/state"
-  - device_id: test_thermo_1
-    type: thermostat
-    cap_version: "thermostat@2.0.0"
-    technology: simulator
-    features:
-      mode: false
-      target: true
-      current: true
-      battery: true
-    topics:
-      set: "vendor/test_thermo_1/set"
-      state: "vendor/test_thermo_1/state"
-  - device_id: experiment_light_1
-    type: light
-    cap_version: "light@1.2.0"
-    technology: zigbee2mqtt
-    features:
-      power: true
-      brightness: true
-    topics:
-      set: "zigbee2mqtt/0xf0d1b80000195038/set"
-      state: "zigbee2mqtt/0xf0d1b80000195038"

config/layout.yaml.backup-20251110-122723

@@ -1,35 +0,0 @@
-# UI Layout Configuration
-# Defines rooms and device tiles for the home automation UI
-
-rooms:
-  - name: Wohnzimmer
-    devices:
-      - device_id: test_lampe_2
-        title: Deckenlampe
-        icon: "💡"
-        rank: 5
-      - device_id: test_lampe_1
-        title: Stehlampe
-        icon: "🔆"
-        rank: 10
-      - device_id: test_thermo_1
-        title: Thermostat
-        icon: "🌡️"
-        rank: 15
-        
-  - name: Schlafzimmer
-    devices:
-      - device_id: test_lampe_3
-        title: Nachttischlampe
-        icon: "🛏️"
-        rank: 10
-      
-  - name: Lab
-    devices:
-      - device_id: experiment_light_1
-        title: Experimentierlampe
-        icon: "💡"
-        rank: 10
-
-
-

config/max-thermostats.txt

@@ -1,23 +0,0 @@
-# MAX! Thermostats - Room Assignment
-# 
-# Extracted from layout.yaml
-# Format: Room Name | Device ID (if thermostat exists)
-# 
-
-Schlafzimmer
-42
-
-Esszimmer
-45
-
-Wohnzimmer
-46
-
-Arbeitszimmer Patty
-39
-
-Bad Oben
-41
-
-Bad Unten
-48

config/raeume.txt

@@ -1,31 +0,0 @@
-Schlafzimmer
-  0x00158d00043292dc
-
-Esszimmer
-
-Wohnzimmer
-  0x00158d0008975707
-
-Küche
-  0x00158d00083299bb
-
-Arbeitszimmer Patty
-  0x00158d0003f052b7
-
-Arbeitszimmer Wolfgang
-  0x00158d000543fb99
-
-Bad Oben
-  0x00158d00093e8987
-
-Bad Unten
-  0x00158d00093e662a
-
-Flur
-  0x00158d000836ccc6
-
-Waschküche
-  0x00158d000449f3bc
-
-Sportzimmer
-  0x00158d0009421422

infra/README.md

@@ -1,23 +0,0 @@
-# Infrastructure
-
-This directory contains infrastructure-related files for the home automation project.
-
-## Files
-
-- `docker-compose.yml`: Docker Compose configuration for running services
-
-## Usage
-
-```bash
-# Start services
-docker-compose up -d
-
-# Stop services
-docker-compose down
-```
-
-## TODO
-
-- Add service definitions to docker-compose.yml
-- Add deployment configurations
-- Add monitoring and logging setup