Go to Integrations Settings and look for “File”. If it’s there, you have a File notifier or sensor set up in your configuration which has been migrated automatically, and you will need to remove the YAML configuration.
For any scripts or automations that use that notifier you will need to convert the service call to use the new notify.send_message service call.
As I mentioned in the original post, I do not have any file integrations, not in YAML, no in the UI. I only have Filesize intergrations, one for measuring the size of the HA database and one for the shopping list. But I understand this Filesize integration is totally different from the File one.
I do not have any automations that write to files.
The automations I have that use the “notify” service are “notify.alexa_media…” and “notify.mobile_app…”, and the ones that apply to my WhatsPie HACS integration.
Could I assume the above mentioned are NOT affected by this new change?
Any additional input on why I still get the repair warning? If this ONLY applies to FILE related automations, could I just dismiss it then?
Yes, currently it’s just core integrations that only use message which have been migrated. Both of those are custom integrations. A.M.P is not eligible since it allows for titles and additional data; and WhatsPie does not seem to have been updated in 2 years.
If you’ve double checked and there are no File notifiers or sensors, I have know idea why you got the warning. You can dismiss the repair warning… worst case scenario should be that in 6 months when YAML configuation for File becomes fully unsupported you’ll get an Error.
so I restore my previous version of HA because my automations stopped working due to that migration, but I would like to go back to the newest HA and fix that issue, so how can I keep my sensors if I remove sensors setup from YAML?
Thanks for your time and feedback, I have continued to search and found nothing that could affect my setup, but I keep getting the warning. I hope nothing really breaks in the future, I have no automations that write to files using the notify service.
In the File Integration, I created an entity with the file name /config/www/myfile.csv and I tested with it with a test automation.
So far, so good, so I wanted to migrate this test entity to my final one. I changed the entity_id name, the Name itself, and I renamed the entry in the Integration, resulting in (after renaming and disabling the migrated entities):
This all seems correct, but when I run the automation again, the message is still written to myfile.csv! If I delete that myfile.csv and run the automation again, the myfile.csv is recreated with the new line added.
And yes, i reloaded everything, and even tried restarting HA, but the data keeps being written to myfile.csv
I have been looking for the place where to change the file name, but I cannot find that place.
I finally used a workaround by creating a new notification service in the File Integration with the correct filename (utility_hourly.csv) and did the renaming again, and then everything ends up in the correct file.
Is there a way to change the target filename of such a file notifier, or did I stumble on a bug or omission?
We seem to be on parallel tracks. Here’s the thread of my progress.
Here is what I found. The call_service is notify.send_message, and the entity_id of each file in the File integration WILL be named:
file
file_2
file_3
file_4 … for as many files as you make an entity for.
No matter what you rename them in the integration IO.
It isn’t a bug, it’s a feature. Really, this is how entities are named. Haven’t you been bitten by the _2 bug when an update of a custom integration recreates your entities? You will spend at the least a few minutes trying to figure out why your automation doesn’t work any longer. (But this is another thread).
Well, I try to use meaningful entity_ids, so I always rename them. If you open the entity in the file integration, you can use the cogwheel to change the name and the id (that is what I do). That works fine, and it makes you aware of the references to an entity. Plus, it is easier to find.
There are two types of Home Assistant users. Those who have had automations stop working because an update to a component changed the entity_id, and those who will. It happens so often that when an automation stops working, this is the first thing I look for.