Groan. What’s that saying: “New and Improved. You can get one, but not both”. In this case we get “new”.
These changes are screwing up what has been quite happily working for a couple of years. With the latest upgrade of HA, I now get repair warnings for my ‘sensor.yaml’ file, and for the life of me I can’t understand what needs to change (or why). (I’m honestly trying to understand the purpose of Home Assistant: Is it an industrial-strength home automation hub, or simply a development environment that needs constant tending? If the former, then all changes should be backward compatible, or at least automated tools should be provided to correct any forced changes.) Don’t get me wrong, I tip my hat to the developers who strive to improve the product, but PLEASE don’t break existing configurations. End of groan.
OK, now the real problem. I have a file named sensors.yaml, which is referenced in configuration.yaml. My sensors.yaml contains the following, but I’m now getting errors on the first two lines. (If I try and paste the ‘suggested’ corrections from the repair messages into either this file or configuration.yaml, I get a whole host of other error messages. (I really don’t want to mess with configuration.yaml if I can avoid it.)
Hopefully @petro will chime in here. But a guess is the usage of template and copying and pasting parts instead of replacing the whole part and remarking out the old part and saving then testing the recommended fix.
Can you added the recommend fix that was proposed to this thread, so we can compare the two?
The entity_id: key was deprecated nearly 5 years ago… the “new” syntax was introduced over 4 years ago for sensors and binary sensors… It seems pretty obvious that you haven’t been “constantly” tending to your config.
But, you’re in luck! This change won’t take effect for 6 months, so you have plenty of time.
Yea, I know I came over as a whiner, but I spent nearly six months getting my HA configuration to look and work as I wanted, and succeeded, only to have it broken. Clearly, I don’t tinker with this system unless absolutely necessary, and I’m not a coder per se. Sorry if I caused offense.
So, this was the ‘suggested’ fix:
Add new template definition inside configuration.yaml:
template:
- sensor:
- unique_id: c7310e44-451b-11ee-be56-0242ac120022
default_entity_id: sensor.garagedoorstatus
icon: "{% if (states('cover.main_garage') == 'closed') %}\n mdi:garage\n{% else
%}\n mdi:garage-open\n{% endif %}"
name: Garage Door Status
state: "{% if (states('cover.main_garage') == 'closed') %}\n All Closed\n{% else
%}\n One Open\n{% endif %}"
What I was doing by having a separate ‘sensor.yaml’ file was trying to reduce the clutter in configuration.yaml (and hence maintain some semblance of readability).
So, I’m assuming I can still keep the above code in sensor.yaml, but need to make changes. I’m just not sure what those changes should be. The recommendations seem to suggest that everything should go in the configuration file :-(.
(I’m also dreading the deprecation of the Switch template in the future, as I’m heavily invested in that too.)
Nothing was broken. Repairs were posted. You have six months to implement the recommended repairs.
Only if your sensor.yaml file contains Template entities exclusively, in “modern” style, and the file is included under the template: key.
Chances are you still have sensor.yaml included under the sensor: key. Even if the file now contains only Template entities in “modern” style, it will fail to load because it’s not under the correct key.
Even if you now have the sensor.yaml file included under the template: key, it will still fail to load if the file contains the configuration of non-Template entities (like that google_wifi sensor in your example).
Everything you need to know about migrating from the “legacy” style of defining Template entities to the “modern” style is described here (same link as the one Didgeridrew recommended).
The “changes” were made several years ago when the legacy style of defining Template entities was deprecated in favor of modern style. The deprecated legacy format continued to be supported but all new features were implemented exclusively in “modern” style. Support for legacy format comes to an end in six months.
The “automated tools” come in the form of the repair which suggests how to convert the legacy configuration. It cannot automatically modify your files directly because, as a general policy, Home Assistant does not alter YAML files.
Thinking in deep sorrow of the AI bots offering five year old solution slurp to existing problems for people that can’t find the documentation posted by the developers, kept up to date, succinct, valid, and clearly signposted in the change logs displayed with each release for breaking changes.