Automation failure

Configuration
1

I didn’t touch this automation. It’s a simple motion detect occupancy automation that turns on the lights. Absolutely nothing fancy there.

Suddenly, it didn’t work. The motion detection triggered just fine, but the automation that triggered, threw an error:

Logger: homeassistant.components.automation.closet_occupied
Source: helpers/script.py:2098
integration: Automation (documentation, issues)
First occurred: 11 March 2026 at 13:03:45 (3 occurrences)
Last logged: 12:35:29
Closet occupied: Error executing script. Invalid data for call_service at pos 1: extra keys not allowed @ data['color_temp']

I don’t know how to deal with this. This has always worked fine. Maybe something changed around this, and that okay, but if this type of breaking change occurs, it should also automatically migrate over whatever needs migrating.

To be clear, this is not a script I wrote anywhere. This automation was built using the default UI. It was created probably over a year ago.

My HA is on the latest version atm.

2

Remove deprecated light features | Home Assistant Developer Docs

3

iirc your home assitant logs clearly say that this was deprecated for months and i recommend to read the monthly updates.

I know it it super annoying but it saves you alot of headaches when reading the whole changes (especially the breaking changes of each update) and add a routine to get an overview of the errorlogs.

See: "extra keys not allowed @ data['color_temp']" - #2 by NRA

Also: I searched “extra keys not allowed @ data[‘color_temp’]”
here in the forums and i got several Topics about this:

4

But the thing is, I never added color_temp in an automation. I just created an automation, saw that it worked, and that was the end of it.

I know it was deprecated, but I never used that property to my knowledge. I saw it mentioned in the changelogs some time ago, but I literally never gave it any thought, because I never used it.

So how was I supposed to know that the UI buries this property somewhere in the automations? And why was this not fixed automatically as part of an update?

No disrespect to the devs (I’m just being direct, folks!) but you can’t do this to a Joe Average. I’m not him, I know my way around. But there’s a massive amount of people out there who expect things they don’t touch to “just work”. And if something “internal” that is buried in their automations is decided should change, then they rightfully expect that change to be applied as part of the update. They (and I) didn’t manually type out this property, and therefor shouldn’t have to worry about it.

Hope this makes sense. Hope the devs do better next time. I know they can, and I trust they will.

In practical terms right now - what should I do? I still don’t know.

1 Like
5

Did you recently upgrade the HA software for your system?

The upgrade(s) likely introduced the deprecation. If fixing the cause of the deprecation is too much, restore the backup from before the upgrade.

6

You definitely chose a color and that’s what’s causing the issue.

Post the automation and we can help you fix it.

automation.closet_occupied
7

If you’re expecting them to build something that automatically makes changes to your automations, it’s unlikely to happen.

There’s a longstanding policy of not making automatic alterations to anything the user has defined that is stored in YAML format. That includes a lot of things (basically everything defined in configuration.yaml).

Perhaps you forgot. You said it was created almost a year ago.

8

To be fair I didn’t store it in yaml. HA did it for me. My policy would be anything that is generated by the UI, can be migrated by a script.

If I were the project lead, making users dive into a yaml file I would deem unacceptable. The least I would demand is for the devs to include a semi-automatic way to migrate. Press a button, get a diff to approve, and commit.

But I’m not the project lead. I’m just a confused user.

9

Can you please drop it and just post the automation? Arguing isn’t going to solve the problem.

1 Like
10

I get your point about the “joe average” but it still does not change the fact to take a glimpse on the logs/breaking changes and make sure things might become deprecated.

Just like a car you sometimes need to service it and make sure everything is allright and sometimes take a glimpse here and there and not expect it to run and “hope” nothing will happen when a motor control-lamp ignites.

11 
alias: Closet occupied
description: ""
triggers:
  - type: occupied
    device_id: 3187f4e83ab09b4072ee919aacbfd01a
    entity_id: 1ef7134c207ea82b401f3448225d13ec
    domain: binary_sensor
    trigger: device
conditions: []
actions:
  - metadata: {}
    data:
      color_temp: 375
      brightness_pct: 75
      transition: 1
    enabled: true
    target:
      area_id: living_room_closet
    action: light.turn_on
mode: single

Ah yes, the color_temp is right there. Autogenerated by the UI. This is literally the first time I’m seeing the automation like this :slight_smile:

1 Like
12

That’s fine, except it’s not the development team’s policy. Feel free to submit a Feature Request explaining how you believe it should be handled.

13

Change that to color_temp_kelvin and choose the color you want. 375 is roughly equivalent to 2666

for any other instances you have, 100000 / <color_temp> is roughly equal to color_temp_kelvin

1 Like
14

The point is not that things may become deprecated and things needs some TCL every now and again. The problem is that the changelog didn’t really underline the importance of it, what the repercussions will be if left as-is, and what the user should actually go and do (step by step) to prevent it from becoming an issue.

The changelog on this issue was WAY too technical for any normal person to understand. Even I was like “well, probably not an issue, because I don’t manually type out that stuff”.

Again, I hope the dev team will do better.

15

That may be so but it is evidence that you did forget you had set a Color Temperature when you created the automation via the UI.

Now you need to change it, save the automation, and it will work correctly.

16

The existing method of reporting impending changes has worked for the vast majority of people for many years.

Nonetheless, if you do want it modified, submit a Feature Request because talking about it here won’t get the results you want.

17

I get it but i strongly disagree with your claim that untechnical people dont understand it. If I read in logs that something will be deprecated and will be replaced in 6 months I will know that at that time I must change stuff.

Logs told you that long enough (if you dont update every 2 years lol) - i remember that i was reading it and I also didnt understand where the issue in my automations was, but then I was prepared at least and make my research, would be even cooler that it might just list what is shitty, but it is what it is i guess and its better than nothing?

Even reading the update logs is clear for a non techsavvy person that they at least MIGHT be affected

image
image1000×623 33.5 KB

As a protip i strongly recommend you to just parse through the breaking changes and just look if anything might affect you and ask yourself if you use anything from the list they provided and just read through everything that does affect you.

Sorry to derail this and btt:

Im glad though that you learned something and have it fixed.

18

It’s not…

I just tried creating a new automation with both device action and normal action.
None of them adds the color temp.

description: ""
mode: single
triggers: []
conditions: []
actions:
  - action: light.turn_on
    metadata: {}
    target:
      device_id: 511b9c277b0d4549b3b1925b0fc8b9ed
    data:
      brightness_pct: 36
  - action: light.turn_on
    metadata: {}
    target:
      entity_id: light.kokslampa
    data:
      brightness_pct: 41

The color temp only gets added to the yaml if I actually add a selected temperature.

19

Again, I have read through it. And I’m a little bit more savvy than average joe. And I understood fully what it said.

I just had no way of knowing:

  • How it would affect my particular instance
  • What I would need to do, step by step
  • If there was going to be a automigration

I think it’s fair to expect that things will keep working when not touching them.

But I think we’re going around in circles. The people that understand fully everything about HA, do not understand that an average user cannot understand when they need to make a manual change. Meanwhile, an average joe cannot understand why they have to babysit a system that is (or should be) designed to run unattended.

20

Home Assistant has never been that way since its inception. It’s always evolving and some changes will always be breaking changes.

The impending changes are reported and it’s the user’s responsibility to determine if their system is affected.

If the reported changes are unclear, don’t upgrade until they are understood. It’s a simple policy that works for users of any level of experience.

I encourage you to express your opinions as a Feature Request because that’s where developers monitor them. Voicing them here, in the community forum, will produce a discussion but nothing actionable.