OODA als Architektur für ein intelligentes Smart Home

Autor: Tobias Müller, ispringen.dev

Das Problem: Warum klassische Smart Home-Automation scheitert

Smart Homes versprechen Komfort, Energieeffizienz und Sicherheit. Die Realität sieht anders aus. Die meisten Systeme sind entweder manuell gesteuert oder nutzen einfache Regelwerke, die keinen Kontext verstehen. Sie reagieren, statt zu agieren. Sie lernen nicht, sondern wiederholen stumpf dieselben Aktionen.

Klassische Regelwerke ignorieren Nutzerkontext wie Anwesenheit, Tageszeit oder Stimmung und führen zu falschen Entscheidungen.

Ich habe drei klassische Ansätze analysiert und ihre Grenzen identifiziert.

IFTTT und Home Assistant Automations: Der Kontext fehlt

Klassische Regelwerke folgen einem einfachen Muster:

IF motion_sensor == ON:
  THEN light.turn_on()

Diese Logik ignoriert grundlegende Fragen: Ist der Nutzer überhaupt zuhause? Wie spät ist es? Wie hell ist es draußen? Wie ist die Stimmung des Nutzers?

Das Ergebnis sind Systeme, die ständig falsche Entscheidungen treffen. Ein Licht, das um 14 Uhr bei Sonnenschein angeht. Eine Heizung, die läuft, obwohl niemand da ist. Keine Lernfähigkeit, keine Anpassung an Gewohnheiten.

Monolithische KI-Agenten: Die Kostenfalle

Ein großer KI-Agent, der alle Sensoren auswertet und für alles entscheidet, klingt verlockend. Die Realität ist jedoch ernüchternd. Da ein Smart Home täglich unzählige Events generiert, summieren sich die Aufrufe eines LLMs (Large Language Model) massiv. Konkrete Kosten lassen sich zwar schwer vorab berechnen, da die Nutzung stark schwankt, aber die Tendenz ist eindeutig.

Die kontinuierliche Auswertung jedes kleinen Sensor-Events durch eine KI treibt die monatlichen Kosten schnell in Höhen, die für Single-User-Systeme völlig inakzeptabel sind.

Zudem macht eine Latenz von mehreren Sekunden pro Entscheidung das System unbrauchbar für zeitkritische Aktionen.

Event-Bus-Microservices: Overhead für Single-User-Systeme

Ein Event-Bus mit Microservices ist skalierbar und entkoppelt. Für ein Single-User-System ist der Overhead jedoch unnötig. Die Komplexität steigt, ohne dass ein Nutzen entsteht. State-Synchronisation zwischen Services wird zur Herausforderung.

Ich habe mich gegen diese Architektur entschieden, weil sie nicht zu meinen Constraints passt: Minimales MVP-Budget Single-User-System Keine externe Infrastruktur

Boyds zentrale These: Geschwindigkeit entscheidet

John Boyd, der Entwickler des OODA-Loops, analysierte im Koreakrieg, warum amerikanische F-86 Sabre-Piloten gegen technisch überlegene MiG-15 Jets erfolgreicher waren. Seine Erkenntnis: Die Geschwindigkeit der Entscheidungsfindung ist wichtiger als technische Überlegenheit.

Diese These überträgt sich direkt auf Smart Homes. Ein System, das schneller entscheidet als der Nutzer manuell eingreifen kann, schafft echten Mehrwert. Es muss nicht der beste Algorithmus sein, sondern der schnellste Loop.

Die Lösung: OODA als Architektur-Pattern für autonome Systeme

OODA steht für Observe, Orient, Decide, Act. Es ist ein erprobtes Muster aus der Militärstrategie, das ich auf Smart Homes übertragen habe. Jeder Flow durchläuft alle vier Phasen, ohne Abkürzungen.

Die vier Phasen im Detail

Observe ist die passive Wahrnehmung der Umgebung. Keine Interpretation, keine Filterung. Alle Signale werden erfasst, mit Zeitstempel versehen. Im Smart Home bedeutet das: Sensoren, APIs, Nutzerinteraktionen.

Orient ist die komplexeste Phase und die einzige, die in spezifische Domains aufgeteilt ist. Hier entsteht das Situationsbild. Boyd definierte fünf Faktoren, die Orientation formen: Cultural Traditions: Nutzerpräferenzen, Gewohnheiten Genetic Heritage: Bio-Rhythmus, Komfortpräferenzen New Information: Aktuelle Sensordaten Previous Experiences: Historie, gelerntes Verhalten Analysis & Synthesis: Kontextualisierung, Mustererkennung

Ein Beispiel aus meinem System: Input: Motion Sensor triggered Orient verarbeitet in der Presence-Domain: Aktueller presence_state: “away” GPS: matching home coordinates Uhrzeit: 18:45, typische Heimkehrzeit Wetter: regnerisch Bio-Daten: niedriger Mood-Score Output: “User is arriving home, likely needs comfort, warm light, heating”

Decide ist strategisch, nicht taktisch. Es geht um das “Was”, nicht um das “Wie”. Diese Phase ist universell aufgebaut. Sie sammelt die Ergebnisse der verschiedenen Orient-Domains über einheitliche Schnittstellen und trifft zentrale Entscheidungen (entweder schnell und regelbasiert oder KI-basiert).

Act ist die physische Ausführung der Entscheidung. Auch dieser Schritt ist universell. Jede Action ist atomar, wird zentral durch einen Technical Executor gesteuert und erzeugt neue Observations, die den Loop schließen.

OODA in autonomen Fahrzeugen und Cybersecurity

OODA ist kein theoretisches Konstrukt. Es wird in autonomen Fahrzeugen und Cybersecurity eingesetzt.

Autonome Fahrzeuge:

Phase	Umsetzung
Observe	Kameras, Lidar, Radar, GPS
Orient	Objekterkennung, Verkehrslage-Analyse, Routenplanung
Decide	”Bremsen? Ausweichen? Beschleunigen?”
Act	Motorsteuerung, Lenkung, Bremse

Cybersecurity:

Phase	Umsetzung
Observe	IDS/IPS Alerts, Log-Analyse, Network Traffic
Orient	Threat Intelligence, Kontextbewertung
Decide	”Block? Investigate? Escalate?”
Act	Firewall-Regel, Isolierung, Alert an Team

Die Übertragbarkeit auf Smart Homes ist offensichtlich. Die Loop-Zeit ist länger (Sekunden bis Minuten), aber das Prinzip bleibt gleich.

Warum OODA für Smart Homes funktioniert

Klassische Event-Automation ist zu simpel:

IF motion_sensor == ON:
  THEN light.turn_on()

OODA-basierte Automation ist kontextbewusst:

OBSERVE: Motion sensor triggered
ORIENT (Domain-spezifisch):
  User presence: arriving, GPS plus WiFi confirm
  Weather: cold plus rainy
  Time: evening
  Bio-data: low mood score
  Historical: User likes warm light when arriving in winter
DECIDE (Universell):
  Turn on light, warm, 70 Prozent
  Set heating to 22 Grad Celsius
  Send welcome message
ACT (Universell):
  Execute all actions
  Log for learning

Die Vorteile sind klar: Kontextbewusst Cross-Domain Lernfähig (via RAG und History) Adaptiv

Das Zwei-Ebenen-Modell: Kosten sparen

Ein zentrales Problem ist die Kostenkontrolle. Nicht jedes Event benötigt eine teure KI-Entscheidung.

Meine Lösung: Zwei-Ebenen-OODA. Universelle Basis-Ebene: Filtert regelbasiert und entscheidet anhand der Orient-Daten, ob ein State-Update reicht oder das Main Brain nötig ist. System-Ebene: Cross-Domain-Entscheidungen mit KI für komplexe Situationen.

Ein Beispiel: Motion Sensor feuert. Die Basis-Ebene prüft die Orient-Daten der Presence-Domain (“User kommt an”, confidence 0,95) und triggert erst daraufhin die System-Ebene für die komplexe Entscheidung (“Licht plus Heizung plus Nachricht”).

Die meisten irrelevanten Events werden so vorab gefiltert, was die Kosten extrem reduziert.

Die Umsetzung: n8n, JSONB und Shared State als technische Säulen

Ich habe mich für n8n als Plattform entschieden. Die Gründe: Visual Workflow Editor für schnelle Iteration Execute Workflow Node passt perfekt zu OODA Native Integrationen (Home Assistant, Telegram, Postgres) Self-hosted, Datenschutz, keine Cloud-Kosten

Das zentralisierte Modell in n8n

Die Architektur besteht aus zielgerichteten Workflows: 5 Generic Observers (Motion, GPS, Temperature, Telegram, Schedule) 5 Domain Workflows (ausschließlich für die Orient-Phase, z. B. Presence, Light, Security) Universelle Workflows für Decide und Act (System Decide, Technical Executor Act)

Zwei-Ebenen OODA Architektur für Smart Homes. Grafik: Tobias Müller, 16.02.2026.

Generic Observer: Ein Event, mehrere Domains

Ein Motion Sensor kann mehrere Domains betreffen: Presence: User kommt an Light: Raum wird betreten Security: Bewegung während Abwesenheit

Meine Lösung: Observer sind nicht domain-spezifisch. Ein Observer triggert mehrere Domain-Orient-Workflows parallel. Jeder Orient entscheidet selbst, ob das Event für seine Domain relevant ist.

Beispiel: WF_Observer_Motion

[1] Webhook Node
  Method: POST
  Path: /motion

[2] Function Node: Normalize Event
  const event = $input.item.json;
  return {
    json: {
      type: "motion",
      location: event.sensor.replace('motion_', ''),
      state: event.state,
      timestamp: event.timestamp || new Date().toISOString()
    }
  };

[3a] Execute Workflow Node: Presence Orient
  Workflow: WF_Orient_Presence
  Input: {{$json}}

[3b] Execute Workflow Node: Light Orient (parallel)
  Workflow: WF_Orient_Light
  Input: {{$json}}

[3c] Execute Workflow Node: Security Orient (parallel)
  Workflow: WF_Orient_Security
  Input: {{$json}}

Repository verfügbar unter https://ispringen.dev/repos/smart-home-ooda

JSONB als State-Speicher

Jede Domain hat einen eigenen State-Eintrag als JSONB. Das ermöglicht flexible Schema-Evolution ohne DB-Migration.

Beispiel: Presence Domain State

{
  "state": "home",
  "location": "living_room",
  "confidence": 0.95,
  "arrival_time": "2026-02-15T18:45:00Z",
  "gps_coordinates": {
    "lat": 48.xxxx,
    "lon": 8.xxxx
  }
}

SQL-Query zum Lesen des Presence States:

SELECT state_data->>'state' as presence_state,
       state_data->>'confidence' as confidence
FROM domain_states
WHERE domain = 'presence';

SQL-Query zum Aktualisieren des Light Status:

UPDATE domain_states
SET state_data = jsonb_set(
  jsonb_set(state_data, '{on}', 'true'),
  '{brightness}', '70'
)
WHERE domain = 'light';

Shared State statt Event Queue

Ich habe mich für Shared State entschieden, weil n8n keinen nativen Event Bus hat. Die Alternative wäre eine Event Queue gewesen:

Observer → Queue (DB Table) → Aggregator (Cron) → Decide

Das Problem: Wann ist ein Batch “fertig”? Wie lange warten?

Shared State ist einfacher:

Observer → Domain Orient → Universal Decide (Write State) → Universal Act
System Decide liest State bei Bedarf über einheitliche Schnittstellen

Der State ist die Single Source of Truth. Es gibt keine Timing-Probleme.

n8n-spezifische Best Practices

Execute Workflow über Workflow-Name:

//  Gut: Workflow-Name
Execute Workflow: "WF_Orient_Presence"

//  Schlecht: Workflow-ID (bricht bei Export und Import)
Execute Workflow: "12345"

Error Handling in jedem Workflow:

On Error: "Continue"
→ [Error Handler Node]
  Log zu DB
  Sende Telegram Alert
  Return: {status: "error", ...}

Workflow-Naming-Convention:

WF_{Phase}_{Domain/Function}
WF_Observer_Motion
WF_Orient_Presence
WF_Decide_Universal
WF_Act_TechnicalExecutor

Die Trade-offs: Was OODA nicht kann (und wie man damit umgeht)

Keine Architektur ist perfekt. Ich habe die Grenzen und Risiken analysiert und Lösungen entwickelt.

Kosten-Nutzen-Dilemma: Universelle Basis-Entscheidungen

OODA spart KI-Kosten, aber die vorgeschalteten regelbasierten Entscheidungen sind weniger flexibel als dauerhaft mitlaufende LLMs. Das ist ein Trade-off für das MVP.

Beispiel: Ein LLM könnte bei jedem Motion-Event entscheiden, ob Licht angehen soll. Mein System nutzt stattdessen universelle Regeln:

IF motion_sensor == ON AND time == "evening" AND light_state == "off":
  THEN act.turn_on_light()

Die Regel ist weniger flexibel, aber kostengünstig.

Concurrency-Problem bei Shared State

Shared State ist für Single-User-Systeme unkritisch. Bei Multi-User-Households wird es zum Risiko.

Ein Beispiel: Nutzer A kommt nach Hause (Presence State: “home”). Nutzer B verlässt das Haus (Presence State: “away”). Race Condition: Welcher State wird geschrieben?

Meine Lösung für das MVP: Shared State ist nur für Single-User-Systeme geeignet. Für Multi-User-Households müsste ich auf einen Event Bus umsteigen.

RAG als fehlendes Puzzleteil

Das Material erwähnt “Previous Experiences” in der Orient-Phase. Eine konkrete RAG-Implementierung fehlt jedoch.

Meine Roadmap:

1. Action History in der DB speichern:

CREATE TABLE action_history (
  id SERIAL PRIMARY KEY,
  timestamp TIMESTAMP DEFAULT NOW(),
  trigger_source VARCHAR(50),
  trigger_type VARCHAR(50),
  context JSONB,
  decision JSONB,
  actions JSONB
);

2. Bei Universal Decide die letzten 5 ähnlichen Aktionen abfragen:

SELECT action, reasoning
FROM action_history
WHERE trigger_source = 'presence'
  AND trigger_type = 'arrival'
ORDER BY timestamp DESC
LIMIT 5;

3. Die Historie in den GPT-4 Prompt injizieren:

"In ähnlichen Situationen (5 vergangene Ankünfte) hast du diese Aktionen gewählt: [history]"

n8n-Limits: Kein Event Bus

n8n ist pragmatisch für das MVP, aber nicht skalierbar für über 100 Geräte. Die Alternative wäre ein Event Bus wie Kafka oder Bull Queue.

Meine Empfehlung für die Zukunft: n8n für Workflows nutzen Event Bus für State-Synchronisation Beide Systeme entkoppeln

---

Cite this article

Tobias Müller, 2026: OODA als Architektur für ein intelligentes Smart Home. https://ispringen.dev Lizenz: CC BY 4.0 (Namensnennung erforderlich).

Quellen

• OODA-Loop Beispiele – OODA.de
• Schnelle Entscheidungen in chaotischen Situationen – ybwasdez.elementor.cloud
• OODA Loop Aufbau – Consulting LIFE
• OODA-Loop – Wikipedia
• OODA Loop Theorie – Forms.app
• John Boyd Strategie – Bundeswehr Führungsakademie