Home Assistant: „Message malformed – extra keys not allowed“ beheben

Die Home-Assistant-Fehlermeldung „Message malformed: extra keys not allowed“ klingt zunächst kryptisch. In der Praxis steckt dahinter aber sehr oft ein klarer Strukturfehler in YAML: Ein Schlüssel steht auf der falschen Ebene, ein Block ist falsch eingerückt oder ein Teil einer Aktion wurde versehentlich in eine andere Aktion hineingeschoben.

Im ursprünglichen Gemini-Chat lautete der konkrete Fehler:

Message malformed: extra keys not allowed @ data['sequence'][2]['action']

Der Chat ist ein gutes Beispiel dafür, wie man solche Meldungen systematisch liest – enthält aber auch eine inzwischen veraltete Aussage zur Home-Assistant-YAML-Syntax. Diese korrigiere ich hier anhand der aktuellen offiziellen Dokumentation.

Was bedeutet der Fehlerpfad?

Der Teil:

data['sequence'][2]['action']

sagt dir ziemlich genau, wo Home Assistant beim Validieren hängen bleibt.

  • sequence = die Aktionsfolge eines Scripts
  • [2] = der dritte Eintrag, weil Listen bei 0 beginnen
  • ['action'] = dort wurde ein Schlüssel namens action gefunden, den Home Assistant an dieser Stelle nicht erwartet

Damit musst du nicht den gesamten YAML-Block blind durchsuchen. Konzentriere dich zuerst auf den dritten Schritt der Sequenz.

Der häufigste Grund: falsche Einrückung

YAML verwendet Einrückungen als Struktur. Zwei Zeilen können dieselben Wörter enthalten, aber je nach Einrückung etwas völlig anderes bedeuten.

Ein typisches Fehlerbild ist:

sequence:
  - action: cover.set_cover_position
    target:
      entity_id: cover.jalousie_1
    data:
      position: 100
    wait_for_trigger:
      - trigger: state
        entity_id: cover.jalousie_1
        to: open

Hier wurde wait_for_trigger in denselben Aktionsblock eingerückt. Home Assistant interpretiert es dadurch als zusätzliche Eigenschaft von cover.set_cover_position. Dort ist dieser Schlüssel aber nicht erlaubt.

Richtig: wait_for_trigger als eigener Schritt

wait_for_trigger muss als eigener Eintrag auf derselben Listenebene stehen:

sequence:
  - action: cover.set_cover_position
    target:
      entity_id: cover.jalousie_1
    data:
      position: 100

  - wait_for_trigger:
      - trigger: state
        entity_id: cover.jalousie_1
        to: open

Jetzt sind es zwei getrennte Schritte: zuerst die Aktion, danach das Warten auf einen Zustandswechsel.

Aktuelle Syntax: Automationen verwenden oben Plural

Im alten Gemini-Chat wurde später behauptet, bei Automationen müssten die Hauptbereiche trigger, condition und action im Singular stehen. Das ist für den aktuellen Home-Assistant-Stand nicht mehr richtig.

Die offizielle Dokumentation verwendet 2026 für Automationen:

triggers:
conditions:
actions:

Innerhalb der jeweiligen Listen steht dann beispielsweise:

triggers:
  - trigger: state
    entity_id: binary_sensor.example
    to: "on"

actions:
  - action: light.turn_on
    target:
      entity_id: light.example

Das ist ein wichtiger Unterschied zwischen älteren Tutorials und aktueller UI-generierter YAML.

Script und Automation nicht vermischen

Ein weiterer Fehler im ursprünglichen Verlauf war die Zeile:

sequence: []

zusammen mit einem vollständigen Automation-Block.

Bei einem Script wird die Aktionsfolge unter sequence gespeichert. Bei einer aktuellen Automation stehen die auszuführenden Schritte unter actions.

Wenn du YAML aus unterschiedlichen Editoren oder Beispielen zusammenkopierst, kann genau daraus eine ungültige Mischung entstehen.

Aktuelles Beispiel einer Automation

alias: Beispielautomation
triggers:
  - trigger: state
    entity_id: binary_sensor.example
    to: "on"
conditions: []
actions:
  - action: light.turn_on
    target:
      entity_id: light.wohnzimmer
mode: single

Diese Struktur entspricht dem aktuellen Home-Assistant-YAML-Modell für Automationen.

Aktuelles Beispiel eines Scripts

alias: Beispielscript
sequence:
  - action: light.turn_on
    target:
      entity_id: light.wohnzimmer
  - delay: "00:00:05"
  - action: light.turn_off
    target:
      entity_id: light.wohnzimmer
mode: single

Hier ist sequence korrekt, weil es sich um ein Script handelt.

„extra keys not allowed“ bedeutet nicht automatisch action/action

Der ursprüngliche Chat vermutete zunächst ein doppeltes action:. Das ist eine mögliche Ursache, aber die Fehlermeldung ist allgemeiner. Sie bedeutet: Ein Schlüssel steht an dieser Stelle, obwohl das Schema ihn dort nicht erlaubt.

Das kann betreffen:

  • action
  • target
  • data
  • wait_for_trigger
  • delay
  • condition
  • oder einen integrationsspezifischen Parameter

Doppelte Schlüssel sind ebenfalls problematisch

Im Gemini-Verlauf war später der komplette Metadatenblock doppelt vorhanden:

alias: ...
mode: single
...
sequence:
  ...
alias: ...
mode: single

Solche Dopplungen entstehen schnell beim Kopieren zwischen visuellem Editor, YAML-Editor und Chat. Selbst wenn ein YAML-Parser doppelte Schlüssel akzeptiert, ist das Ergebnis unklar und sollte bereinigt werden.

Die Einrückung muss konsistent sein

Ein weiterer Versuch im Originalchat enthielt:

sequence:
- action: cover.set_cover_position
    target:
      entity_id: cover.jalousie_1

Hier stimmen die Ebenen nicht. Ein übersichtlicher Stil mit zwei Leerzeichen pro Ebene reduziert solche Fehler:

sequence:
  - action: cover.set_cover_position
    target:
      entity_id: cover.jalousie_1

Tabs sollten in YAML vermieden werden.

Listen und Einzelwerte nicht verwechseln

Auch bei Zuständen kann eine unnötige Liste entstehen. Für einen einzelnen Zustand reicht:

to: open

statt:

to:
  - open

Ob Listen zulässig sind, hängt vom jeweiligen Feld ab. Ein aus dem UI kopierter Block sollte deshalb möglichst nicht „vereinfacht“ werden, ohne die Dokumentation zu prüfen.

wait_for_trigger mit Timeout absichern

Die aktuelle Home-Assistant-Script-Dokumentation unterstützt bei wait_for_trigger einen Timeout. Das ist praktisch, damit ein Script nicht unbegrenzt wartet, wenn das Gerät den erwarteten Zustand nie meldet.

- wait_for_trigger:
    - trigger: state
      entity_id: cover.jalousie_1
      to: open
  timeout: "00:00:30"
  continue_on_timeout: false

Dadurch endet die Sequenz nach 30 Sekunden, wenn der Trigger nicht eintritt.

Gerätezustände nicht erraten

Im alten Chat wurde außerdem zwischen close und closed diskutiert. Für Cover-Entitäten ist der gemeldete Zustand typischerweise open oder closed. Trotzdem solltest du die tatsächlichen Zustände deiner Entität in Entwicklerwerkzeuge → Zustände prüfen.

Integrationen können zusätzliche Zustände wie opening oder closing liefern.

Auch die Position logisch prüfen

Ein YAML-Block kann syntaktisch korrekt sein und trotzdem logisch das Falsche tun. Bei Covers steht die Position üblicherweise für einen Prozentwert zwischen vollständig geschlossen und vollständig geöffnet. Prüfe deshalb im konkreten Gerät, was 0 und 100 bewirken, bevor du eine Automatik auf mehrere Jalousien loslässt.

So liest du komplexe Fehlerpfade

Beispiel:

data['actions'][3]['choose'][0]['conditions'][1]

Das liest du von links nach rechts:

  1. actions öffnen
  2. vierten Aktionsschritt wählen: Index 3
  3. dort den choose-Block öffnen
  4. erste Option: Index 0
  5. dort conditions
  6. zweite Bedingung: Index 1

Diese Methode spart viel Zeit gegenüber zufälligem Umformatieren.

Visuellen Editor als Validator nutzen

Wenn du YAML manuell korrigierst, speichere nicht sofort eine große Automation. Füge zunächst nur den problematischen Teil ein und prüfe, ob der visuelle Editor ihn wieder korrekt darstellen kann.

Wenn Home Assistant von YAML zurück in die grafische Ansicht wechseln kann, ist die Struktur meistens bereits plausibel.

Trace nach erfolgreichem Speichern

Eine syntaktisch gültige Automation kann immer noch falsch reagieren. Nach einem Testlauf solltest du deshalb den Trace öffnen. Dort siehst du, welcher Trigger ausgelöst hat, welche Bedingungen erfüllt waren und an welchem Aktionsschritt die Ausführung stand.

Fehlersuche in sinnvoller Reihenfolge

  1. Fehlerpfad genau lesen.
  2. Den genannten Listenindex bestimmen.
  3. Einrückung dieses Blocks prüfen.
  4. Kontrollieren, ob Script und Automation vermischt wurden.
  5. Aktuelle Syntax triggers/conditions/actions beachten.
  6. Unvollständige oder doppelte Blöcke entfernen.
  7. Entitätszustände in Entwicklerwerkzeugen prüfen.
  8. Speichern und anschließend Trace kontrollieren.

Fazit

„Message malformed: extra keys not allowed“ ist meist kein mysteriöser Home-Assistant-Fehler, sondern ein präziser Hinweis auf eine falsche YAML-Struktur. Entscheidend ist, den angegebenen Pfad zu lesen und die Einrückung auf genau dieser Ebene zu prüfen. Besonders wichtig bei älteren Anleitungen: Aktuelle Automationen verwenden oben triggers, conditions und actions. Wer alte und neue Syntax unkritisch mischt, produziert genau die Fehler, die diese Meldung auslösen.