Thank you so much! It’s starting to make sense.
Did I read somewhere that the update to 2024.6.x will be making this change automatically, or is it something I need to do before updating?
Only the move from the notify.yaml (or configuration.yaml) to UI is done automatic, your automations you need to do manually.
1 Like
Good to know, thanks!
Do you know if the migration also creates the needed allowlist_external_dirs entries in configuraiton.yaml?
It did not in my case
1 Like
Do you know if we need to local directories (like config) to the allowlist_external_dirs list? And if so, what the syntax might be?
Hello,
I have also problems with the new file notification.
This is the old working version:
- service: notify.energie
data_template:
message: "{{now().day}}-{{now().month}}-{{now().year}},
{% if now().weekday() in (0,) %}Monday{% elif now().weekday() in (1,) %}Tuesday{% elif now().weekday() in (2,) %}Wednesday{% elif now().weekday() in (3,) %}Thursday{% elif now().weekday() in (4,) %}Friday{% elif now().weekday() in (5,) %}Saturday{% elif now().weekday() in (6,)%}Sunday{% endif %},
{{ states.sensor.energie_meter_dag.state }},
{{ states.sensor.energie_dag_afname.state }},
{{ states.sensor.energie_dag_opbrengst.state }},
{{ states.sensor.energie_meter_nacht.state }},
{{ states.sensor.energie_nacht_afname.state }},
{{ states.sensor.energie_nacht_opbrengst.state }},
{{ states.sensor.energie_meter_zon.state }},
{{ states.sensor.energie_gas.state }},
{{ states.sensor.energy_verw_badk_yesterday.state }}"
I thought this was the new version but apperently, it doesn’t work:
- service: notify.send_message
target:
entity_id: notify.energy
data:
message: "{{now().day}}-{{now().month}}-{{now().year}},
{% if now().weekday() in (0,) %}Monday{% elif now().weekday() in (1,) %}Tuesday{% elif now().weekday() in (2,) %}Wednesday{% elif now().weekday() in (3,) %}Thursday{% elif now().weekday() in (4,) %}Friday{% elif now().weekday() in (5,) %}Saturday{% elif now().weekday() in (6,)%}Sunday{% endif %},
{{ states.sensor.energie_meter_dag.state }},
{{ states.sensor.energie_dag_afname.state }},
{{ states.sensor.energie_dag_opbrengst.state }},
{{ states.sensor.energie_meter_nacht.state }},
{{ states.sensor.energie_nacht_afname.state }},
{{ states.sensor.energie_nacht_opbrengst.state }},
{{ states.sensor.energie_meter_zon.state }},
{{ states.sensor.energie_gas.state }},
{{ states.sensor.energy_verw_badk_yesterday.state }}"
Any idea how to solve it?
E.
What error do you get ?
Never mind, I did something stupid…
entity_id must be notify.energie in stead of notify.energy.
Sorry to disturb you 
Sorry I have been quiet.
@hbradlow - thank you VERY much for your reply. Your fix worked first time. The documentation is very sketchy in this area. A simple example would be so useful.
I added the “allowlist_external_dirs” but I am darned if I can find the documentation for that anywhere.
Once again, thank you!
EDIT: I found the info on allowlist_external_dirs. Google’s crawl of the documentation is out of date and it takes me to
…but that page has been edited recently and the relevent info is at
This worked perfectly @hbradlow . Never would have figured it out in a million years with the available documentation. Thank you!
Hello, I have the problem that the directory and file could not be installed.
I removed the
#notify:
# - name: write_to_csv_energie
# platform: file
# filename: /share/Hermes1/Home_Assistant_Energie.csv
# timestamp: false
# - name: write_to_csv_temperatur
# platform: file
# filename: /share/Hermes1/Home_Assistant_Temperatur.csv
# timestamp: false
# - name: write_to_csv_energie_geraete
# platform: file
# filename: /share/Hermes1/Home_Assistant_Energie_Geraete.csv
# timestamp: false
In automation I changed:
…
action:
- service: notify.send_message
target:
entity_id: notify.write_to_csv_temperatur
data:
…
Before everything worked proper with access to the files.
Where do I have to give the new permission?
What do I have to change?
I downgraded to the backup.
Best regards Helmut
All directories are now protected, and file write access must be granted in the Home Assistant configuration YAML
################## allow list of directories for file integration to write #############################
homeassistant:
allowlist_external_dirs:
- "/share/user_data/tub"
- "/share/user_data/inverter"
- "/share/user_data/battery"
Note that these are directories (not the files) and that part directory paths do not work, hence /config will allow access to the config directory, /config/data will allow access only to the /config/data directory and so on.
In your case, you probably need
homeassistant:
allowlist_external_dirs:
- "/share/Hermes1"
NOTE:
The new file-write notification integration requires all this to be set up (file integration, write access to the directories, and creation / use of the new target entities) and the update automatically sets (most of) this up, however the old YAML “notify” still works! It will be deprecated later this year, but you can still use it if you wish… If you do, you will get a warning notification, but you can ignore that.
1 Like
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
- the file-path directory added to the allowlist_external_dirs (for each directory used by all file writes)
- the file integration added (once) and a new target entity added (for each individual file you want to write to) Set this up as a notification, with the full file path-name, and optionally ‘use timestamp’
- then use the new ‘file notification’ entity in your automations as the target
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}
1 Like
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 )
- loads in the new file integration (which you can’t do manually before the HA update as it is new in this update)
- creates a new entry for each of the platform file notifications, with the file name as given, and the name as given, and the timestamp setting as given
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
- add the necessary and now required access for the file path directory - you have to do that yourself manually (hence the update automatically breaks HA and issues lots of warning messages). My suggestion is that you add these access directory paths FIRST before doing the update
- remove the old yaml config, and you can still call the old service-entity, you will just get another warning message
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
- the integration entry name (which is created as ‘File [/share/my_data/file.txt]’)
- the entity name, which is ‘File’
- the entity id, which is ‘notify.file’
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.
4 Likes
Hello Geoff, that worked. Thank you!
As usual, when an integration moves to the UI, you get less features then before.
1 Like
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
- three line of different yaml code
- a new integration
- hidden and un-editable settings
- three names not one
- an extra two lines of yaml / a setting in all service calls / automations
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.
4 Likes