Betriebsprofile¶
Kamerplanter ist modular aufgebaut. Du entscheidest selbst, welche Komponenten du brauchst — von einer schlanken Installation auf dem Raspberry Pi bis zum vollständigen Multi-Tenant-Setup auf Kubernetes. Diese Seite hilft dir, das richtige Bündel aus Komponenten für deinen Anwendungsfall zu finden.
Vollständige Feature-für-Feature-Referenz
Diese Seite zeigt fünf empfohlene Bündel für typische Anwendungsfälle. Für eine erschöpfende Tabelle aller ~40 Funktionen mit exakter Umgebungsvariable, Pflicht-Secrets und Ressourcenauswirkung siehe die Konfigurationsmatrix.
Komponentenübersicht¶
Jede Kamerplanter-Installation besteht aus einem Kern (immer erforderlich) und optionalen Komponenten, die du je nach Bedarf aktivierst.
Kern (immer aktiv)¶
| Komponente | Aufgabe |
|---|---|
| Backend (FastAPI) | REST-API, Geschäftslogik, Phasensteuerung, Düngeplanе |
| Frontend (React) | Web-Oberfläche |
| ArangoDB | Primäre Datenbank (Dokumente + Graph-Abfragen) |
| Valkey (Redis-kompatibel) | Cache und Celery-Broker |
| Celery Worker + Beat | Hintergrundaufgaben (Pflegeerinnerungen, Datenanreicherung, KI-Tipps) |
Optionale Komponenten¶
| Komponente | Aufgabe | Ressourcenbedarf | Konfiguration |
|---|---|---|---|
| Betriebsmodus | light = kein Login, ein Nutzer; full = JWT-Auth, Multi-Tenant | — | KAMERPLANTER_MODE |
| KI-Assistent (Backend-Seite) | Freischaltung der /ai/*-Endpunkte, Pflegetipps, Diagnosen, Glossar | 128 MB – 2 GB RAM (Backend, ohne LLM) | AI_FEATURES_ENABLED + KNOWLEDGE_SERVICE_ENABLED/KNOWLEDGE_SERVICE_URL |
| Ollama | Lokale Ausführung von Sprachmodellen (kein Datentransfer) | 4--16 GB RAM, optional GPU | Docker-Profil ollama; LLM_PROVIDER=ollama am Knowledge Service |
| Knowledge Service | RAG-Pipeline: Wissensbasis durchsuchen, LLM-Provider anbinden, Kontext anreichern | 128 MB – 512 MB RAM | Eigener Helm-Controller (controllers.knowledge-service), kein vorgefertigtes enabled-Flag in values.yaml — Operator liefert den vollständigen Block |
| VectorDB (pgvector) | Vektorspeicher für RAG-Embeddings und für den Bilderkennungs-Referenzindex (REQ-029-A) | 128 MB – 512 MB RAM | controllers.vectordb.enabled (in values.yaml vordefiniert, Default false) |
| Embedding Service | ONNX-basierte Embedding-Berechnung (kein PyTorch) | 1,5–4 GB RAM | Eigener Helm-Controller (controllers.embedding-service), kein vorgefertigtes enabled-Flag |
| Reranker Service | Cross-Encoder Re-Ranking für höhere RAG-Präzision (ADR-007) | 1,5–4 GB RAM | RERANKER_URL am Knowledge Service (leer = deaktiviert) |
| TimescaleDB | Zeitreihendaten von Sensoren, automatisches Downsampling | 256--512 MB RAM | TIMESCALEDB_ENABLED |
| Home Assistant | Sensor- und Aktor-Integration (Temperatur, Luftfeuchte, Lampen) | Extern | HA_URL + HA_ACCESS_TOKEN |
| Externe Datenanreicherung | Pflanzendaten von GBIF und Perenual automatisch ergänzen | — | PERENUAL_API_KEY |
KI-Assistent — Betreiber-Schalter und Provider-Wahl sind getrennt
AI_FEATURES_ENABLED ist ein reiner Backend-Schalter (Stufe 1 des dreistufigen Freischalt-Mechanismus, siehe Für technische Nutzer / Self-Hoster): false lässt alle /ai/*-Endpunkte mit HTTP 404 antworten. Er bestimmt nicht, welches Sprachmodell verwendet wird — das ist LLM_PROVIDER (ollama, anthropic, openai_compatible) am eigenständigen Knowledge Service (src/knowledge-service/), nicht am Backend. Es gibt kein AI_DEFAULT_PROVIDER, kein AI_OLLAMA_URL/AI_OLLAMA_MODEL und kein AI_FALLBACK_PROVIDER im Backend — diese früher hier dokumentierten Variablen existieren im Code nicht. Details: KI-Provider einrichten, Umgebungsvariablen — KI-Assistent.
Profile im Überblick¶
Die folgende Matrix zeigt fünf vordefinierte Profile. Jedes Profil ist eine Empfehlung — du kannst jederzeit einzelne Komponenten hinzufügen oder weglassen.
| Minimal | Hobby | Standard | Profi | SaaS | |
|---|---|---|---|---|---|
| Infrastruktur | Docker Compose | Docker Compose | Docker Compose / K8s | Kubernetes | Kubernetes |
| Betriebsmodus | Light | Light | Full | Full | Full |
| KI-Assistent | — | Ollama (lokal) | Ollama (lokal) | Ollama (lokal) | Cloud (OpenAI / Anthropic) |
| Knowledge Service + Embedding Service + VectorDB | — | Ja (Pflicht-Bündel für Ollama) | Ja (Pflicht-Bündel für Ollama) | Ja | Ja |
| Reranker Service | — | — | Optional | Optional | Ja |
| TimescaleDB | — | — | Optional | Ja | Ja |
| Home Assistant | — | Optional | Optional | Ja | Optional |
| Externe Anreicherung | — | Optional | Ja | Ja | Ja |
| Celery Worker | Ja | Ja | Ja | Ja | Ja |
| Zielgruppe | Raspberry Pi, Ausprobieren | Hobby-Gärtner, Home-Server | Engagierte Hobbyisten, kleine Gemeinschaftsgärten | Indoor-Growing, große Gemeinschaftsgärten | Managed Hosting, mehrere Mandanten |
| RAM gesamt | ~1 GB | ~3 GB | ~4 GB | ~6 GB | ~8 GB |
Minimal¶
Zielgruppe¶
Du willst Kamerplanter schnell ausprobieren oder hast nur wenige Zimmerpflanzen. Ein Raspberry Pi ⅘ oder ein alter Laptop reicht aus. Du brauchst weder Login noch KI.
Voraussetzungen¶
- Docker + Docker Compose
- 1 GB freier RAM, 2 GB Speicherplatz
- Raspberry Pi 4 (2 GB), Raspberry Pi 5, NUC, Laptop
Aktivierte Komponenten¶
- Backend + Frontend
- ArangoDB + Valkey
- Celery Worker + Beat
- KI-Assistent
- TimescaleDB
- Home Assistant
- Knowledge Service / RAG
Beispielkonfiguration¶
services:
arangodb:
image: arangodb:3.11
# ...
valkey:
image: valkey/valkey:8-alpine
# ...
backend:
build: ./src/backend
environment:
KAMERPLANTER_MODE: light
AI_FEATURES_ENABLED: "false"
TIMESCALEDB_ENABLED: "false"
depends_on: [arangodb, valkey]
celery-worker:
build: ./src/backend
command: celery -A app.tasks worker --loglevel=info
depends_on: [arangodb, valkey]
celery-beat:
build: ./src/backend
command: celery -A app.tasks beat --loglevel=info
depends_on: [arangodb, valkey]
frontend:
build: ./src/frontend
environment:
KAMERPLANTER_MODE: light
depends_on: [backend]
Was fehlt im Vergleich zum nächsten Profil?¶
Ohne KI-Assistent bekommst du keine automatischen Pflegetipps und Diagnosen. Du kannst Ollama jederzeit später hinzufügen, ohne Daten zu verlieren.
Hobby¶
Zielgruppe¶
Du hast 10--50 Pflanzen und einen Home-Server (NAS, alter Desktop, NUC). Du möchtest KI-gestützte Pflegetipps, aber deine Daten sollen dein Netzwerk nicht verlassen. Login brauchst du nicht — du bist der einzige Nutzer.
Voraussetzungen¶
- Docker + Docker Compose
- 6–8 GB freier RAM für den KI-Stack (Ollama-Modell + Knowledge/Embedding-Service/VectorDB-Overhead — siehe Konfigurationsmatrix), mehr bei einem 7B-Modell, optional GPU
- Home-Server, NUC, Desktop-PC
Aktivierte Komponenten¶
- Backend + Frontend
- ArangoDB + Valkey
- Celery Worker + Beat
- Ollama (lokales Sprachmodell)
- Knowledge Service + Embedding Service + VectorDB (nötig, damit Ollama vom KI-Assistenten überhaupt erreicht wird)
- TimescaleDB
- Home Assistant (optional)
- Externe Anreicherung (optional)
Ollama allein reicht nicht
Das Backend spricht nie direkt mit Ollama. Die Provider-Anbindung (LLM_PROVIDER) liegt am Knowledge Service — er ruft Ollama auf und liefert das Ergebnis über KNOWLEDGE_SERVICE_URL an das Backend zurück. Ohne laufenden Knowledge Service (+ Embedding Service für die Ähnlichkeitssuche, + VectorDB als Vektorspeicher) bleiben die KI-Endpunkte funktionslos, selbst wenn Ollama läuft.
Beispielkonfiguration¶
services:
# ... Kern wie Minimal ...
backend:
build: ./src/backend
environment:
KAMERPLANTER_MODE: light
AI_FEATURES_ENABLED: "true"
KNOWLEDGE_SERVICE_ENABLED: "true"
KNOWLEDGE_SERVICE_URL: http://knowledge-service:8000
INTERNAL_SERVICE_TOKEN: ${INTERNAL_SERVICE_TOKEN} # openssl rand -hex 32
TIMESCALEDB_ENABLED: "false"
depends_on: [arangodb, valkey]
knowledge-service:
build: ./src/knowledge-service
environment:
LLM_PROVIDER: ollama
LLM_API_URL: http://ollama:11434
LLM_MODEL: gemma3:4b
EMBEDDING_SERVICE_URL: http://embedding-service:8080
VECTORDB_HOST: vectordb
INTERNAL_SERVICE_TOKEN: ${INTERNAL_SERVICE_TOKEN}
depends_on: [ollama, embedding-service, vectordb]
embedding-service:
build: ./docker/embedding-service
vectordb:
build: ./docker/vectordb
ollama:
image: ollama/ollama:latest
volumes:
- ollama_models:/models
# GPU-Passthrough (optional):
# deploy:
# resources:
# reservations:
# devices:
# - capabilities: [gpu]
Modellwahl
Starte mit gemma3:4b — das läuft auf den meisten Rechnern ab 2020 ohne GPU. Details zur Modellwahl findest du unter KI-Provider einrichten.
Was fehlt im Vergleich zum nächsten Profil?¶
Ohne Full-Modus kannst du keine weiteren Nutzer einladen. Ohne TimescaleDB werden Sensordaten nicht langfristig gespeichert. Beides lässt sich später aktivieren.
Standard¶
Zielgruppe¶
Du bist engagierter Hobbyist oder betreibst einen kleinen Gemeinschaftsgarten. Mehrere Personen sollen eigene Konten haben. Du möchtest KI-Tipps und optional Sensordaten langfristig speichern.
Voraussetzungen¶
- Docker Compose oder Kubernetes-Cluster
- 6--8 GB freier RAM (KI-Stack wie im Hobby-Profil, siehe oben)
- Server, NUC oder kleiner K8s-Cluster
Aktivierte Komponenten¶
- Backend + Frontend
- ArangoDB + Valkey
- Celery Worker + Beat
- Ollama + Knowledge Service + Embedding Service + VectorDB (KI-Stack als Bündel, siehe Hobby-Profil)
- Externe Anreicherung (GBIF + Perenual)
- Reranker Service (optional — höhere RAG-Präzision)
- TimescaleDB (optional)
- Home Assistant (optional)
Beispielkonfiguration¶
services:
# ... Kern + Ollama + Knowledge Service + Embedding Service + VectorDB (siehe Hobby-Profil) ...
backend:
build: ./src/backend
environment:
KAMERPLANTER_MODE: full
AI_FEATURES_ENABLED: "true"
KNOWLEDGE_SERVICE_ENABLED: "true"
KNOWLEDGE_SERVICE_URL: http://knowledge-service:8000
INTERNAL_SERVICE_TOKEN: ${INTERNAL_SERVICE_TOKEN}
JWT_SECRET_KEY: ${JWT_SECRET_KEY} # openssl rand -hex 32
PERENUAL_API_KEY: ${PERENUAL_API_KEY}
TIMESCALEDB_ENABLED: ${TIMESCALEDB_ENABLED:-false}
depends_on: [arangodb, valkey]
controllers:
backend:
containers:
main:
env:
KAMERPLANTER_MODE: full
AI_FEATURES_ENABLED: "true"
KNOWLEDGE_SERVICE_ENABLED: "true"
KNOWLEDGE_SERVICE_URL: "http://kamerplanter-knowledge-service:8000"
TIMESCALEDB_ENABLED: "false"
knowledge-service:
enabled: true
containers:
main:
env:
LLM_PROVIDER: ollama
LLM_API_URL: "http://kamerplanter-ollama:11434"
LLM_MODEL: gemma3:4b
TimescaleDB nur bei Sensoren nötig
Wenn du keine Sensoren oder Home-Assistant-Anbindung planst, kannst du TimescaleDB weglassen. Manuelle Messwerte werden in ArangoDB gespeichert. TimescaleDB lohnt sich erst bei automatischer, hochfrequenter Datenerfassung.
Was fehlt im Vergleich zum nächsten Profil?¶
Ohne TimescaleDB kein automatisches Downsampling von Sensordaten. Ohne Home Assistant keine automatische Sensorerfassung und Aktorsteuerung. Ohne Reranker Service ist die Trefferqualität der RAG-Antworten etwas niedriger (reine Hybrid-Search statt Cross-Encoder-Re-Ranking).
Profi¶
Zielgruppe¶
Du betreibst professionelles Indoor-Growing oder einen großen Gemeinschaftsgarten mit Rollenverwaltung. Sensoren und Aktoren sind über Home Assistant angebunden. Du willst lückenlose Zeitreihen und KI-gestützte Diagnosen mit vollem RAG-Kontext (Re-Ranking für höhere Trefferqualität).
Kein automatischer Cloud-Fallback
Der Knowledge Service verwendet einen konfigurierten LLM_PROVIDER (ollama, anthropic oder openai_compatible) — es gibt keinen automatischen Laufzeit-Fallback von Ollama auf einen Cloud-Provider bei Nichterreichbarkeit. Ein Wechsel des Providers ist eine bewusste Konfigurationsänderung (Redeploy des Knowledge Service). Ist Ollama nicht erreichbar, meldet der KI-Assistent einen Fehler — die übrige Anwendung bleibt unbeeinflusst.
Voraussetzungen¶
- Kubernetes-Cluster (3+ Nodes empfohlen)
- 6--8 GB RAM für Kamerplanter-Pods
- Home Assistant Instanz im Netzwerk
- Optional: GPU-Node für schnellere KI-Inferenz
Aktivierte Komponenten¶
- Backend + Frontend
- ArangoDB + Valkey
- Celery Worker + Beat
- Ollama (lokales Sprachmodell,
mistral:7b) - Knowledge Service + VectorDB + Embedding Service
- Reranker Service (Cross-Encoder Re-Ranking)
- TimescaleDB
- Home Assistant
- Externe Anreicherung (GBIF + Perenual)
Beispielkonfiguration¶
controllers:
backend:
containers:
main:
env:
KAMERPLANTER_MODE: full
AI_FEATURES_ENABLED: "true"
KNOWLEDGE_SERVICE_ENABLED: "true"
KNOWLEDGE_SERVICE_URL: "http://kamerplanter-knowledge-service:8000"
TIMESCALEDB_ENABLED: "true"
TIMESCALEDB_HOST: timescaledb
HA_URL: http://homeassistant.home:8123
HA_ACCESS_TOKEN:
secretKeyRef:
name: kamerplanter-secrets
key: ha-access-token
PERENUAL_API_KEY:
secretKeyRef:
name: kamerplanter-secrets
key: perenual-api-key
envFrom:
- secret: kamerplanter-secrets # trägt u.a. INTERNAL_SERVICE_TOKEN (Pflicht ab hier)
timescaledb:
enabled: true
knowledge-service:
enabled: true
containers:
main:
env:
LLM_PROVIDER: ollama
LLM_API_URL: "http://kamerplanter-ollama:11434"
LLM_MODEL: mistral:7b
RERANKER_URL: "http://kamerplanter-reranker-service:8081"
RERANKER_INITIAL_K: "20"
RERANKER_TOP_K: "5"
reranker-service:
enabled: true
containers:
main:
env:
RERANKER_MODEL: "bge-reranker-v2-m3"
embedding-service:
enabled: true
vectordb:
enabled: true
Secrets nicht in values.yaml
API-Keys und Tokens gehören in Kubernetes Secrets oder einen externen Secret-Manager (z.B. Sealed Secrets, External Secrets Operator). Verwende secretKeyRef in den Helm Values.
Was fehlt im Vergleich zum nächsten Profil?¶
Im Profi-Profil betreibst du eine einzelne Instanz für deine Organisation und ein lokales Sprachmodell. Das SaaS-Profil fügt Multi-Mandanten-Isolation, horizontale Skalierung und einen Cloud-Sprachmodell-Provider anstelle von Ollama hinzu.
SaaS / Multi-Tenant¶
Zielgruppe¶
Du betreibst Kamerplanter als Plattform für mehrere unabhängige Mandanten (Gärten, Betriebe, Gemeinschaften). Jeder Mandant hat eigene Daten, Rollen und Einstellungen. Du brauchst horizontale Skalierung und zuverlässige Cloud-KI.
Voraussetzungen¶
- Kubernetes-Cluster mit Autoscaling
- 8+ GB RAM für Kamerplanter-Pods
- Managed-Datenbank-Dienste empfohlen (ArangoDB Oasis, Managed PostgreSQL)
- Cloud-KI-Provider-Konto (OpenAI oder Anthropic)
Aktivierte Komponenten¶
- Backend + Frontend (mehrere Replicas)
- ArangoDB + Valkey
- Celery Worker (mehrere Replicas) + Beat
- Cloud-Sprachmodell (Anthropic oder OpenAI-kompatibler Endpunkt) statt Ollama
- Knowledge Service + VectorDB + Embedding Service
- TimescaleDB
- Externe Anreicherung (GBIF + Perenual)
- Home Assistant (optional, mandantenspezifisch)
Beispielkonfiguration¶
controllers:
backend:
replicas: 3
containers:
main:
env:
KAMERPLANTER_MODE: full
AI_FEATURES_ENABLED: "true"
KNOWLEDGE_SERVICE_ENABLED: "true"
KNOWLEDGE_SERVICE_URL: "http://kamerplanter-knowledge-service:8000"
TIMESCALEDB_ENABLED: "true"
knowledge-service:
enabled: true
containers:
main:
env:
LLM_PROVIDER: openai_compatible
LLM_API_URL: "https://api.openai.com/v1"
LLM_MODEL: gpt-4o-mini
LLM_API_KEY:
secretKeyRef:
name: kamerplanter-secrets
key: llm-api-key
celery-worker:
replicas: 2
frontend:
replicas: 2
Anthropic als Alternative
Für Anthropic direkt (statt eines OpenAI-kompatiblen Endpunkts) LLM_PROVIDER: anthropic setzen — LLM_API_URL entfällt dann, LLM_API_KEY bleibt Pflicht. Gültige Werte für LLM_PROVIDER sind ausschließlich ollama, anthropic und openai_compatible; ein bloßes openai ist kein gültiger Wert.
Managed Datenbanken
Im SaaS-Betrieb empfiehlt sich der Einsatz von Managed-Datenbank-Diensten statt selbst betriebener Container. Das reduziert den Betriebsaufwand für Backups, Updates und Hochverfügbarkeit erheblich.
Eigenes Profil zusammenstellen¶
Die Profile oben sind Empfehlungen. Du kannst jede Komponente einzeln aktivieren oder deaktivieren, indem du die entsprechenden Umgebungsvariablen setzt:
| Entscheidung | Variable | Werte |
|---|---|---|
| Login und Multi-Tenant? | KAMERPLANTER_MODE | light / full |
| KI-Assistent instanzweit freischalten? (Backend) | AI_FEATURES_ENABLED | true / false |
| KI-Assistent mit dem Knowledge Service verbinden? (Backend) | KNOWLEDGE_SERVICE_ENABLED + KNOWLEDGE_SERVICE_URL | true/false + HTTP-URL |
| Welches Sprachmodell? (Knowledge Service, nicht Backend) | LLM_PROVIDER | ollama, anthropic, openai_compatible |
| Sensordaten-Zeitreihen? | TIMESCALEDB_ENABLED | true / false |
| Re-Ranking (höhere Präzision)? (Knowledge Service) | RERANKER_URL | HTTP-URL des Reranker-Service (leer = deaktiviert) |
| Home Assistant? | HA_URL + HA_ACCESS_TOKEN | URL + Token (leer = deaktiviert) |
| Pflanzendaten-Anreicherung? | PERENUAL_API_KEY | API-Key (leer = nur GBIF) |
VECTORDB_ENABLED ist kein Backend-Schalter
VECTORDB_ENABLED taucht in .env.example als reines Docker-Compose-Profil-Flag auf (docker-compose --profile vectordb up) — es ist keine vom Kamerplanter-Backend gelesene Umgebungsvariable und steuert dort nichts. Das Backend aktiviert die Anbindung an die KI-/RAG-Kette ausschließlich über KNOWLEDGE_SERVICE_ENABLED (KI-Assistent) und INFERENCE_SERVICE_ENABLED (Pflanzen-/Schädlings-Bilderkennung, siehe Bilderkennung in Betrieb nehmen).
In Docker Compose aktivierst du optionale Dienste über Profile:
# Nur Kern:
docker compose up -d
# Mit Ollama und TimescaleDB:
docker compose --profile ollama --profile timescaledb up -d
# Mit RAG (Knowledge Service + VectorDB + Reranker):
docker compose --profile ollama --profile timescaledb --profile vectordb up -d
Reranker im Docker-Compose-Profil vectordb
Der reranker-service ist dem Docker-Compose-Profil vectordb zugeordnet und wird zusammen mit Knowledge Service und VectorDB gestartet. Der Reranker ist ressourcenintensiver als Embedding Service und VectorDB — auf schwacher Hardware kann RERANKER_URL leer gelassen werden, um nur Hybrid Search ohne Re-Ranking zu nutzen.
Eine vollständige Liste aller Umgebungsvariablen findest du unter Umgebungsvariablen.
Entscheidungshilfe¶
Das folgende Flussdiagramm hilft dir, ein passendes Profil zu finden:
flowchart TD
A[How many users?] -->|Just me| B{Do you need AI tips?}
A -->|2-10 people| D{Kubernetes available?}
A -->|10+ / tenants| G[SaaS / Multi-Tenant]
B -->|No| C[Minimal]
B -->|Yes| E[Hobby]
D -->|No| F[Standard<br/>Docker Compose]
D -->|Yes| H{Sensors / HA?}
H -->|No| F2[Standard<br/>Kubernetes]
H -->|Yes| I[Professional] Häufige Fragen¶
Kann ich später auf ein größeres Profil wechseln?¶
Ja. Alle Profile nutzen dieselbe Datenbank. Du kannst jederzeit Komponenten hinzufügen (z.B. Ollama aktivieren, TimescaleDB starten, von Light auf Full wechseln), ohne Daten zu verlieren. Beim Wechsel von Light auf Full musst du einmalig ein Passwort für den bestehenden System-Benutzer setzen.
Kann ich Ollama auf einem Raspberry Pi ausführen?¶
Ja, ab dem Raspberry Pi 5 mit 8 GB RAM. Verwende ein kleines Modell wie llama3.2:3b. Die Antwortzeiten liegen bei 15--30 Sekunden pro Tipp — akzeptabel, aber nicht schnell. Auf dem Raspberry Pi 4 ist die Leistung für größere Modelle nicht ausreichend.
Brauche ich TimescaleDB, wenn ich keine Sensoren habe?¶
Nein. Ohne automatische Sensordatenerfassung (IoT/MQTT oder Home Assistant) bringt TimescaleDB keinen Vorteil. Manuelle Messwerte (pH, EC) werden in ArangoDB gespeichert. Du kannst TimescaleDB später aktivieren, wenn du Sensoren anbindest.
Was passiert, wenn ich keinen KI-Provider konfiguriere?¶
Kamerplanter funktioniert vollständig ohne KI. Der Standardwert AI_FEATURES_ENABLED=false lässt sämtliche /ai/*-Endpunkte mit HTTP 404 antworten, als gäbe es sie nicht — die KI-Tipp-Karten, das Glossar und die KI-Diagnose erscheinen dann nicht in der Oberfläche. Alle regelbasierten Funktionen (Phasensteuerung, Düngepläne, Pflegeerinnerungen) arbeiten unabhängig davon.
Siehe auch¶
- Konfigurationsmatrix — Erschöpfende Referenz aller Funktionen mit Schalter, Pflicht-Secrets und Ressourcenauswirkung
- Light-Modus — Details zum Betrieb ohne Authentifizierung
- KI-Provider einrichten — Ollama, OpenAI, Anthropic und andere Provider konfigurieren
- Home Assistant Integration — Sensor- und Aktor-Anbindung
- Umgebungsvariablen — Vollständige Variablenreferenz
- Kubernetes — Cluster-Setup und Deployment
- Infrastruktur — Skaffold-Profile — Skaffold-Module (
-m ki) für den KI-Stack