Notify.send_message in 2024.6

Configuration
21

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
22

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

23

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
24

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.

25

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
26

Hello Geoff, that worked. Thank you!

27

As usual, when an integration moves to the UI, you get less features then before.

1 Like
28

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.

3 Likes
29

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.

1 Like
30

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.

31

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.

1 Like
32

you missed the ‘don’t’ in front of use … :wink:

edit: haha you fixed it thanks

33

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?

34

Please format your code, we can’t see, if it is correct or not.

See here:

35

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.

36

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.

image
image1006×137 7.85 KB

37

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?

38

Thank you I used your suggestion and updated my setup and eventually have this working again!

39

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.

40 
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.

1 Like