ha_config_set_automation returns validation error "extra keys not allowed" when trying to update an automation

[imasaru]

Hello! Grok Code told me to submit the following bug report.
I have included the YAML content in question for reference.
When I manually applied the YAML from the UI automation editor, it saved successfully.

---

🚨 Runtime Bug Report Template

This template was auto-generated by the ha_report_issue tool.
All environment info and logs below were collected automatically.

Submit this report at:
https://github.com/homeassistant-ai/ha-mcp/issues/new?template=runtime_bug.md

📋 Bug Description

ha_config_set_automation returns validation error "extra keys not allowed" when trying to update an automation with a complex if-then sequence containing delay and actions.

🔄 Steps to Reproduce

1. Create an automation with choose structure
2. Try to add if-then block with delay and action in the same then array
3. Call ha_config_set_automation with the JSON config

✅ Expected vs ❌ Actual Behavior

Expected:

The automation should be updated with the new if-then structure including delay and switch actions.

Actual:

API validation error: "extra keys not allowed @ data['actions'][0]['choose'][1]['sequence'][2]['then'][1]['action']"

🔧 Environment

• ha-mcp Version: 6.3.1
• Installation Method: addon
• Platform: Linux 6.12.63-haos (x86_64)
• Python Version: 3.13.11
• Home Assistant Version: 2026.1.3
• Connection Status: Connected
• Entity Count: 655

🚨 Error Messages

"Invalid automation configuration: API error: 400 - Message malformed: extra keys not allowed @ data['actions'][0]['choose'][1]['sequence'][2]['then'][1]['action']"

📊 Recent Tool Calls

Click to expand recent tool calls (auto-filled by ha_report_issue)

  2026-01-26T07:54:03 | ha_config_set_automation | OK | 1160ms
  2026-01-26T07:42:46 | ha_config_set_automation | OK | 28ms
  2026-01-26T07:42:36 | ha_config_set_automation | OK | 21ms
  2026-01-26T07:42:26 | ha_config_set_automation | OK | 18ms
  2026-01-26T07:42:18 | ha_config_set_automation | OK | 17ms
  2026-01-26T07:42:08 | ha_config_set_automation | OK | 24ms
  2026-01-26T07:41:45 | ha_config_set_automation | OK | 20ms
  2026-01-26T07:41:33 | ha_config_get_automation | OK | 63ms
  2026-01-26T07:34:37 | ha_eval_template | OK | 6ms
  2026-01-26T07:34:11 | ha_eval_template | OK | 10ms
  2026-01-26T07:33:47 | ha_config_set_helper | OK | 10ms
  2026-01-26T07:33:08 | ha_config_set_helper | OK | 78ms

💡 Additional Context

The issue appears to be with JSON formatting of complex automation structures. The then array needs separate objects for delay and actions, but the API rejects when both delay and action keys are present in the same object.

Suggested fix: Better JSON serialization in ha_config_set_automation or clearer error messages indicating exact format requirements.

The dynamic charging logic is correct and templates validate, but automation update fails due to formatting issue.

Privacy reminder: Please review and anonymize sensitive information (tokens, IPs, personal names) before submitting.

Manual Fix for Now

Since the MCP tool had validation issues, here's the corrected YAML snippet to apply manually in automations.yaml:

Replace the vacuum_scheduled sequence with:

- conditions:
  - condition: trigger
    id:
    - vacuum_scheduled
  - condition: state
    entity_id: input_boolean.robovac_charge_reservation
    state:
    - 'off'
  sequence:
  - action: input_boolean.turn_on
    metadata: {}
    target:
      entity_id: input_boolean.robovac_charge_reservation
    data: {}
  - variables:
      battery_pct: "{{ states('sensor.robovac_battery') | int(0) }}"
      max_charge: "{{ states('input_number.robovac_pre_run_max_charge_minutes') | float(120) }}"
      charge_min: "{{ [0, ((100 - battery_pct) / 100 * max_charge) | round(0)] | max }}"
  - if:
    - condition: template
      value_template: "{{ charge_min > 0 }}"
    then:
    - action: switch.turn_on
      metadata: {}
      target:
        entity_id: switch.robovac_charging_port
      data: {}
    - delay:
        minutes: "{{ charge_min }}"
    - action: switch.turn_off
      metadata: {}
      target:
        entity_id: switch.robovac_charging_port
      data: {}
  - alias: Notify charge start (continuous)
    action: notify.mobile_app_sc_55b
    data:
      title: "\U0001F916 RoboVac Charging"
      message: 'Charging initiated: Upcoming vacuum event (Battery {{ battery_pct }}%, Charge time: {{ charge_min }} min)'

This will implement the dynamic pre-run charging as requested.

[github-actions]

The issue identified in #498 relates to an "extra keys not allowed" validation error when using ha_config_set_automation with complex nested structures (such as if-then inside choose blocks).

The root cause appears to be two-fold:

1. Aggressive Normalization: The _normalize_automation_config function recursively renames plural keys like actions and triggers to singular forms (action, trigger). While this is helpful at the root level, it can accidentally transform invalid AI-generated keys (like actions inside a delay object) into action, which Home Assistant's API then rejects as an "extra key" because a delay action cannot also be an action (service call). This normalization also risks breaking legitimate plural keys in nested data, such as the actions field used in Home Assistant Mobile App notifications.
2. AI Formatting Errors: AI models sometimes attempt to merge sequential actions (like a delay and a service call) into a single JSON object. Home Assistant requires each step in a sequence to be a separate object in the list. The current tool documentation lacks explicit examples for these complex nested structures, leading the AI to guess the format incorrectly.

🔍 Analysis

The validation error extra keys not allowed @ data['actions'][0]['choose'][1]['sequence'][2]['then'][1]['action'] indicates that the second item in an if-then sequence was interpreted as having both a delay and an action key. Home Assistant requires these to be separate items in the then list.

The ha_config_set_automation tool attempts to be helpful by automatically correcting plural keys (e.g., actions: [...] → action: [...]). However, if an AI model mistakenly includes an actions key inside a delay object (thinking it's a way to group sub-actions), the tool renames it to action. Since Home Assistant does not allow an action key inside a delay action, it throws a validation error. The recursive nature of this normalization is too broad and should be restricted to prevent interference with nested data structures like notification actions.

🛠️ Suggested Steps

1. Split actions into separate objects: When configuring the automation, ensure that every step (the service call, the delay, and the next service call) is its own separate object in the then or action list.
2. Use service instead of action for nested service calls: While action is the new preferred key for service calls in Home Assistant YAML, using the older service key for nested service calls in the JSON payload may help bypass the tool's singularization logic and provide clearer validation errors if the AI merges objects.
3. Verify the JSON structure: Before calling the tool, ensure complex blocks follow this structure:

   "then": [
     { "action": "switch.turn_on", "target": { "entity_id": "..." } },
     { "delay": { "minutes": 5 } },
     { "action": "switch.turn_off", "target": { "entity_id": "..." } }
   ]

📊 Technical Analysis (for maintainers)

Root Cause

The function _normalize_automation_config in src/ha_mcp/tools/tools_config_automations.py applies field mappings (actions -> action, triggers -> trigger) recursively to every dictionary in the configuration.

    field_mappings = {
        "triggers": "trigger",
        "actions": "action",
        "sequences": "sequence",
    }

This causes two issues:

1. False Positives in Errors: If an AI model generates an invalid object like {"delay": {"minutes": 5}, "actions": []}, it becomes {"delay": {"minutes": 5}, "action": []}. The resulting HA error "extra keys not allowed: action" is technically correct but confusing, as it hides the fact that the AI was likely using actions as a mistaken grouping key.
2. Breaking Legitimate Data: It breaks integrations that use actions as a key inside the data payload of a service call, most notably Mobile App notifications which use data.actions for actionable notifications.

Affected Code

• src/ha_mcp/tools/tools_config_automations.py:32 - _normalize_automation_config applies normalization too aggressively across all levels of the dictionary.
• src/ha_mcp/tools/tools_config_automations.py:270 - The docstring for ha_config_set_automation lacks a complex example showing choose or if-then structures, which would help guide AI models to the correct list-based format.

Proposed Fix

Refine the normalization logic to avoid renaming keys inside data blocks or other nested contexts where they might be valid. Additionally, enhance the tool's documentation with a complex example.

--- a/src/ha_mcp/tools/tools_config_automations.py
+++ b/src/ha_mcp/tools/tools_config_automations.py
@@ -66,16 +66,17 @@
     # Process dictionary
     normalized = config.copy()
 
+    # Do not normalize keys inside 'data' or 'target' blocks as they are integration-specific
+    if parent_key in ("data", "target", "input"):
+        return normalized
+
     # Check if this dict is a compound condition block (or/and/not)

Related Issues/PRs

• Fix: Handle missing last_changed timestamps in ha_get_history (#447) #497 - Related fix for history timestamps (mentioned in git log)
• [BUG] ha_get_history returns null last_changed and omits last_updated #447 - History timestamp issue

---

🤖 Automated analysis by Issue Bot

[github-actions]

✅ This issue has been addressed in the dev channel!

A fix for this issue has been merged to master (PR #514) and is available for testing in the dev channel.

Test the fix before the Tuesday release:
📖 Dev Channel Documentation

Quick start

# Run dev version
uvx ha-mcp-dev

# Check version
uvx ha-mcp-dev --version

Docker:

docker pull ghcr.io/homeassistant-ai/ha-mcp:dev
docker run --rm -i \
  -e HOMEASSISTANT_URL=http://your-ha:8123 \
  -e HOMEASSISTANT_TOKEN=your_token \
  ghcr.io/homeassistant-ai/ha-mcp:dev

---

After testing:

• ✅ If it's fixed: Great! Feel free to comment here to confirm
• ❌ If still broken: Open a new issue and reference ha_config_set_automation returns validation error "extra keys not allowed" when trying to update an automation #498
  • Closed issues can't be reopened by reporters
  • A new issue helps us track the problem properly