Notify.send_message in 2024.6

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

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

2 Likes
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
41

Many thanks!

42

This change is in general not sufficient. I still got, e.g.,

2024-12-21 13:51:21.354 ERROR (MainThread) [homeassistant.components.automation.automation_2] automation 4: Error executing script. Service not found for call_service at pos 4: Action notify.power_data not found
2024-12-21 13:51:21.780 WARNING (MainThread) [homeassistant.helpers.service] Referenced entities notify.power_data are missing or not currently available

Looks like since 2024.6 it is not more possible to specify the file location in configuration.yaml, e.g., using

notify:
  - name: power_data
    platform: file
    filename: power.csv

Instead, seems one is forced to use the interactive browser-based setup Link to Integrations: add integration – My Home Assistant which is inflexible and - as usual with HA - very poorly documented.
For instance, trying this out, the entity name happened to be automatically set to silly generic name notify.file (rather than the name that I’d have wanted to keep: notify.power_data).

Rather than spending more and more hours with trial and error after such crappy badly documented incompatible changes, I downgraded to HA 2024.4