#kelvin -> color_temp_kelvin failed for scripts
summer pelican
Ah its the kelvin key, should have migrated to color_temp_kelvin
Is there a migration supposed to have happened?
pale tartan
When did it rewrite
because the whole service -> action rewrite happened in the frontend
so if you had the old yaml keys in there and you opened the automation in the frontend and you saved it, it would migrate
So with that in mind, I assume this would also happen in the frontend
If not, then @quasi canyon would know
summer pelican
The action stuff changed month ago no?
Actual issue is the kelvin -> color_temp_kelvin migration that didnt happen
Looks like it only failed on my scripts.yaml, not automations.yaml
pale tartan
The action stuff changed month ago no?
Actual issue is the `kelvin` -> `color_...
yes, that happened a while back, but I assume if there's a place where we'd rewrite an action, it'd be in the same place
summer pelican
kelvin -> color_temp_kelvin failed for scripts
Just did a find/replace on my scripts, luckiliy only a few keys needed changing. Was sat in the dark for a while there lol
red falcon
I don't see there was any migration for kelvin
are you sure it wasn't just deprecated and left for users to update?
summer pelican
Do we not validate automations at runtime? if they fail to run, or on load should they not flag as invalid actions?
cedar umbra
we can't really do that, since actions can come and go
we can just validate that the overall autoation structure is sane
There's a lot of light stuff being removed in this version: https://developers.home-assistant.io/blog/2026/02/23/remove-deprecate-light-features/
I want to double check if we warned when actions were called with kelvin before this release
We logged a warning in every call since more than a year back: https://github.com/home-assistant/core/blob/3e8923f10575096edf81d5da7600201cd7d13256/homeassistant/components/light/__init__.py#L331-L335
We don't rewrite scripts, automations, template entities etc. when actions change, it's on users to fix
summer pelican
Might be my blindness to warnings (I get a lot of these from misbehaving devices or disconnections) but these really should be raising an issue/repair as well IMO
cedar umbra
That's a good idea for future deprecations, but I don't think we need to revert the PR which removed kelvin from the light actions?
summer pelican
No need to revert no
golden barn
Do we need to raise issues now, or are the automation already doing that
cedar umbra
Automations don't raise issues when actions fail
I think doing that would be too spammy
they raise issues if automations try to call an action which does not exist though
they also raise issue if the yaml is broken forcing the automation to be disabled
red falcon
You think raising an issue for explicitly actions that use deprecated values during the deprecation period be reasonable or too spammy?
summer pelican
they also raise issue if the yaml is broken forcing the automation to be disable...
Shouldn't this have happened in my case then? Or are extra keys not validated?
summer pelican
You think raising an issue for explicitly actions that use deprecated values dur...
I'd find this reasonable, should probably group them though, like duplicate logs (list the automations/scripts which need updating in the same issue)
cedar umbra
You think raising an issue for explicitly actions that use deprecated values dur...
We should have done that, but we didn't when the deprecation warning was added a year ago
cedar umbra
Shouldn't this have happened in my case then? Or are extra keys not validated?
We raise issues when the configuration can't be parsed or when attempting to call an action which doesn't exist. We don't raise issue when an action fails for whatever reason, including if the parameters passed to the action are wrong
This is for automations. For scripts we don't raise when attempting to call an action which doesn't exist, which is probably an oversight.
golden barn
Yeah my question was if we should raise issues now if we detect the old values in automations