Hello,
I am now able to write text lines to a log file in automations.
What I can’t do, however, is to configure this in notify.yaml. My previous setup works, but HA acknowledges it with a message about using an obsolete function.
My setup in notify.yaml is:
- name: ha_notifications
service: notify.send_message
platform: file
filename: /config/reports/ha-notifications.txt
timestamp: true
How to change this?
Regards, Eckart
The new ‘file notification’ integration now supersedes any notify.yaml to file configuration.
The old yaml setup still works, but will generate a warning message saying it is obsolete.
The new ‘file integration’ works, but needs
File notification is now done using the service call ‘notify.send-message’, and
to a target (the entity created under file notification)
service: notify.send_message
target:
entity_id: notify.file_battery_event
data:
message: Battery Full (at least 1 hour)
The target entity created as a new entry under the file integration [notify.file_battery_event in my case] now holds the platform (file) and the file pathname in its definition
{and if this all makes sense to anyone, would you be so kind as to explain it back to me so I can understand it myself. Thanks}
Does that mean adding the new allowlist section will be done automatically? Someone suggested that had to be manually added. Also, I think I read that any automations using the notify capability to a file need to be manually updated.
Thank you for the detailed posts, I’m finding the documentation on this change difficult at best.
To be utterly clear (which everything about this particular update is not) as far as I can tell, the HA update automatically (if there is a notify: entry in the config file, with at least one platform: file )
notify:
- name: tub-event
platform: file
filename: /share/user_data/tub/tubtimes.txt
timestamp: true
Thus the above ends up with a new ‘entity’ as notify.file_tub_event as the id.
The auto-update does not
And while on the subject:
If you add new entries (entities) to the file integration once you have it installed, then the integration allows to to select the ‘file notification’ service (rather than a ‘file sensor’). Then you have to provide the file path, and at this point it will complain if access has not been permitted. Hence if you have already added /share as an access directory, any new file can be set up for this directory, but if you want a new file /share/my_data/test then you will need to first add /share/my_data manually to the allowed directory list (in config yaml).
After that, you get a new entry in the config, which is a new entity. There are three ‘names’ for all of this
When you add more of these, the entity id becomes ‘notify.file_2’ and so on.
If you actually want to use these entities, it is necessary to go back in and edit the name and the entity id post creation to sometime more useful.
Also note, that appart from the entry name, there is no way of knowing what the file is or if timestamp is set up, so you have to test each entry entity to see what it does, and there is no way of editing any of the settings, so you will need to delete and re-create them if you want to change the file name or turn on/off the timestamp setting.
Hello Geoff, that worked. Thank you!
As usual, when an integration moves to the UI, you get less features then before.
I am a reasonably seasoned user of Home Assistant (3 years).
I am a reasonably competent coder, and I have worked hard to learn and understand yaml, integrations, addons, automations, entities and the like.
I like HA for the state-engine model, the built in features (display, history etc), for the dashboarding, for the open access via NabuCassa, and for mostly the ease of use and the fact that it works. My Home Assistant Blue is a great little, reliable machine and HA seems to chomp through everything I throw at it.
I have put up with the challenges of updating - I have two HA machines, and I now update on the unimportant one first. This gives me heads up on what is going to break.
I think this update not only broke my HA (for no apparent reason and without any real warning, and yes I did read the release notes) but it also finally broke my patience with the HA update-direction model.
I understand this is all open. I understand that this is mostly community. I understand that we are moving to UI, and to target entity services, and to protected directories. I embrace change.
What I do not understand is why this has to happen in such a way as to forcibly break a system without warning, and why there is no useful documentation either before, during, or after. The current ‘File Integration’ documentation is (now) insufficient and wrong.
This cost me about 1 hour to assess the damage post update, another hour to search the forum and work out how to proceed on my other machine, another hour working out how to fix the issues with the naming and existing automation (and test everything - again), another hour to work out how new entities are created (and how to deal with the problems the c**p naming creates). Plus several hours writing up stuff on the forum, which now seems to be the only way that a significant number of HA users find out about how to fix the damage from updates, and how to use these new integrations going forward.
I have watched, benefited from and contributed to, and continue to see a never ending list of get-forecasts posts from the first of these ‘upheaval’ updates. I am confident that there will now be a long list of ‘how do I write notifications to file’ posts.
And yes, what was five lines of visible and editable yaml code is now
I guess one answer is, as always, contribute to the update direction and the documentation - so I have at the very least taken the time and effort to try and post supportive and helpful comments. (This post is frankly just a rant, I grant you that.)
PS. There is, of course, every possibility that next month this integration will be re-released as ‘write files’ which will replace ‘write file’ and require management of arrays of files rather than just a file. Watch this space.
Geoff, your rant is well justified. You pretty much said exactly what the rant I’ve been composing in my mind would say, but probably much better than I could have.
You’ve also been immensely helpful to those of us who have been with HA long enough to pick up on the (subtle) clues in the release notes and wanted to prepare for this challenge.
A poorly implemented, poorly documented and frankly, pointless change which made the product less functional for no apparent reason. I feel like I’m using a Microsoft product here.
It’s not the first time I’ve seen this attitude, and it seems to be getting worse. There’s already a long list of FRs which document changes that users actually want. You’d think those would be prioritized over change for change’s sake.
I was getting in the settings->update section about migrating from notify to notify_send message. I am using the Andriod companion app. I have 3 groups set up. One for family (wife and I), my wife, and myself. I was getting extra keys not allowed. In searching for what I did wrong, I came across this post. I think it explains what I am seeing. I am on version 2024.6.4. Is it safe to assume that companion apps notifications have not been “phased in”? If so I was just curious when there was something stated in the updates like I needed to do it. Just curious.
Correct, mobile app notifications have not been converted to have notify entities nor to use the notify.send_message service… yet. AFAIK, there isn’t even a public estimated release date yet.
From comments I have read, when it does happen it will be announced prominently in the Release Notes since it will affect about 80% of HA users.
you missed the ‘don’t’ in front of use … 
edit: haha you fixed it thanks
I have a number of services set up in notify.yaml to send email and text via scripts. These all apparently got broken with the 2024.6 update. I tried modifying similar to what you posted here.
My original script was coded like this:
service: notify.gmail_smtp_text
data:
message: “”
title: >-
Frontdoor camera has been triggered {{ now().strftime(“%-m.%-d.%Y %-I:%M:%S
%p”) }}
data:
images:
- /config/www/tmp/FrontdoorCameraMotionTrigger.jpg
I modified it to look like this:
service: notify.send_message
target:
entity_id: notify.gmail_smtp_text
data:
message: “”
title: >-
Frontdoor camera has been triggered {{ now().strftime(“%-m.%-d.%Y %-I:%M:%S
%p”) }}
data:
images:
- /config/www/tmp/FrontdoorCameraMotionTrigger.jpg
Now it errors with this message:
extra keys not allowed @data[‘data’]
Any suggestions how to fix this?
Please format your code, we can’t see, if it is correct or not.
See here:
SMTP has not been converted to use notify.send_message. Nothing discussed in this thread is currently affecting SMTP.
If you are having issues with an existing Gmail SMTP notifier it is more likely that your app password expired or there is some other authentication-related issue.
So most of this thread is about the send_message file implantation. I made the changes and have got ridden of the deprecated messages. I now have a error that failed to initialized notification service file. Are they related? I can’t remember if it was happening before or not. The notification seemed to work.
Thanks for replying. I have all my smtp set up in notify.yaml but a couple weeks ago they all errored as an unknown service. It never gets to try to reach Gmail. Any suggestion where to look for a solution to this issue?
Thank you I used your suggestion and updated my setup and eventually have this working again!
Maybe someone can help me as I am getting this error: The notify actions of File have been migrated. A new notify entity is now available to replace any old notify action. Unfortunately I am not very experienced with scripting.
I had the following code in my configuration.yaml:
notify:
- name: ladehistorie_export
platform: file
filename: /config/www/ladehistorie.csv
And this automation (it should export the sensor states to an external CSV file):
alias: Ladehistorie in CSV exportieren
description: Erfasst Ladezustand, Ladeleistung und Endzeitpunkt in einer CSV-Datei
triggers:
- entity_id: sensor.of_lc185e_charging_power
trigger: state
actions:
- data_template:
message: >-
{{ now().strftime('%Y-%m-%d %H:%M:%S') }}, {{
states('sensor.of_lc185e_state_of_charge') }}, {{
states('sensor.of_lc185e_charging_power') }}, {{
states('sensor.of_lc185e_end_of_charge') }}
action: notify.send_message.ladehistorie_export
mode: single
Would be happy if someone could modify the code in order to make it working. Many thanks.
alias: Ladehistorie in CSV exportieren
description: Erfasst Ladezustand, Ladeleistung und Endzeitpunkt in einer CSV-Datei
triggers:
- entity_id: sensor.of_lc185e_charging_power
trigger: state
actions:
- action: notify.send_message
data:
message: >-
{{ now().strftime('%Y-%m-%d %H:%M:%S') }},
{{ states('sensor.of_lc185e_state_of_charge') }},
{{ states('sensor.of_lc185e_charging_power') }},
{{ states('sensor.of_lc185e_end_of_charge') }}
target:
entity_id: notify.ladehistorie_export
mode: single
The File integration config in your configuration.yaml can be deleted (or commented out)… it is no longer used.
Many thanks!