Migration of file notify service - Am I missing something?

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.

Thank you for your input.

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?

my sensors setup

ERROR after migration

Automation

So depends on my location or NFC tag scanned timestamp is recorded like below

How should I convert to the new notify.send_message service call if I cant have my sensors?

add``

homeassistant:
  allowlist_external_dirs:
    - "/config"

to configuration.yaml

Change your automation to

  action:
  - service: notify.send_message
    target: 
      entity_id: notify.nfc_work_log
    data...

and notify.yaml stays the same?

After restarting, once you file notifiers are migrated, you need to remove the file notifiers in notify.yaml

so if its right now this:


and then will be gone/ignored like this:

where do I point in automation to the proper file name to be used (CSV)?

That is done in the migrated file notifier

I don’t get it what’s going on now, I added the

and now it shows

You did not add it under homeassistant:

that solved that issue :joy:
let me restart and work on those automations

Thank you for your help!

Everything looks good now, but when I try to run one off the actions I’m getting an error

and it was perfectly fine before the migration

if you run an automation, there is no trigger, so no trigger.event.data.tag.id. You need to scan a tag.

got it!
I think its just too late now, and my brain is refusing to function anymore :wink:
Once again thank you 4 your help!

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.

I converted my legacy file notifiers to the new method (with success eventually), but I ran into an issue.

My legacy code was:

- name: utility_hourly
  platform: file
  filename: www/utility_hourly.csv

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.

And no, I haven’t been bitten by this one :slight_smile:

The link to your thread isn’t working, it points to https://where-does-notify-notify-put-files/739970/33

One https:// too many ??

Fixed.

Doh!. Works as described…

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.