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
- 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.
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!
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
Yes the change happened six months ago, so the deprecated but allowed configuration.yaml settings have finally been removed for good.
Just remember, the ‘team’ are striving to make Home Assistant open and easy to use for those of us without a double Masters Degree in Computer Science and Information Technology (not that, in this particular case, you would notice). You can complete the new customer satisfaction survey here…
It is certainly worth adding the file directory access permission first, and also going back and renaming each file-notification-entity, otherwise you have no idea from the name which is which.
Yes the change happened six months ago, so the deprecated but allowed configuration.yaml settings have finally been removed for good.
For good? IMO, for bad.
Just remember, the ‘team’ are striving to make Home Assistant open and easy to use for those of us without a double Masters Degree in Computer Science and Information Technology (not that, in this particular case, you would notice).
In my view this goes in the wrong direction.
Being forced to mix programming-style configurations and and browser-based halfway-intelligent settings creates a non-maintainable mess, in particular for serious users who, for instance, want to version-control their configuration/setup.
Ok if you aim at providing a click-flashy UI, but this should not hamper using the classical style.
[quote=“Biscuit, post:23, topic:737177”]
The old yaml setup still works, but will generate a warning message saying it is obsolete.
I never noticed such a warning message.
Instead, it took me quite some time to partially dig out why the notification entities were no more found after the version upgrade and how to hopefully fix this.
the file-path directory added to the
allowlist_external_dirs
(for each directory used by all file writes)
The documentation of allowlist_external_dirs
- as usual for HA - is poor.
It confuses files and directories and does not mention that relative paths are based on the config directory. It would be good to also add a reminder to Docker users that the paths are local to the container.
the file integration added (once) and a new target entity added (for each individual file you want to write to)
[…]
All that original and helpful info you quoted here is missing from File - Home Assistant
and also going back and renaming each file-notification-entity, otherwise you have no idea from the name which is which.
I did not find how to rename the entities to something useful before deciding in frustration to give up on using the 2024.6+ update.
Instead, users should be enabled to provide the names of their choice right away.
The programming-style configuration is extremely awkward to use not because it should only be for users with double Masters Degree in Computer Science and Information Technology.
It is a nightmare even for me, having a PhD summa cum laude in the area programming language semantics and theorem proving.
It is so mainly for three reasons:
- It is a poorly designed mix of YAML and Python with counter-intuitive bloated syntax and weird semantics, resulting in badly structured and hard-to-maintain code.
- Its documentation is pretty incomplete and of little actual help.
- Its diagnostics output and debugging facilities are insufficient and partly non-digestible and or even misleading.
This results in HA having by far the worst programming environment I encountered in my 40 years of IT experience.
It is simply a mess. I sincerely regret having based on it my non-trivial solar battery automation solution with efficient control,
wasting countless hours and days with trial and error on needlessly weird issues and searching for solutions in forums like this.
‘for good’ as in ‘for ever’ - colloquial English
See my followup post I agree that this particular change is unnecessary, unhelpful, and undocumented.
You probably missed the clunky inbuilt and enforced auto-change from yaml to integration at the time - lucky you!
Yes, the HA forum is a backstop for lack of good documentation. This is never a good situation, but of course being open community the solution is to contribute yourself.
Again, a balance between
‘yes this upgrade could have been done heaps better’
and
‘we don’t pay for this stuff, it is the work of individuals in the community, you are part of the community, the solution is “fix it yourself”’
I spent a lot of time and effort six months ago posting to this thread to try and help those that follow. I share your frustration over this particular change, however this is not a commercial product.
Here is the link to how to contribute. Since you have 40 years of IT experience you out-trump my 20 years of out-dated experience.
My solar automation solution has taken three years so far, and is ongoing, but I keep most of my work in Node-RED with one foot in the HA camp and one foot in Node-RED on a Raspberry Pi 5.
I was being sarcastic. Another horrible English habit. With the constant mess created by updates, HA will never ever go beyond the current niche market of experienced tinkerers.