Trying to generate a simple notification in the integrated system but the message template doesn’t work. With this (that was taken from official doc examples)
I do not get .name or .for values in the message, but just just whole message template as it is (that is, notification shows literally " {{ trigger.to_state.name }} too high!"). Tried with double quotes, single quotes, no quotes.
Also a side question; when I switch from automation yaml edit to ui edit, why does it replace the > symbol with pipe automatically?
Forgot to say that I did try data_template too and with that no message at all shows up. I’m on 0.111.4.
While it’s super nice that HA keeps getting updates at fast pace, it’s also one of the most annoying things in it that basics of configuration keep changing all the time. Like it’s missing any long term planning before execution because “today this seems to make a lot more sense in this context so I’ll just change it like so”.
How did you test if it works? Did you execute the automation manually? If so, it will fail as you don’t have a trigger when you execute it manually.
Home Assistant is Beta software, that’s what you need to accept when you tinker with beta software.
Also, your issue has nothing to do with the change in 0.115, data_template still works in 0.115, but data as you had it didn’t work before 0.115.
As @Burningstone said, you wont get a message when you use the ‘trigger’ button on the automation. This is because the trigger variable doesn’t exist and you’re getting an error message in the logs that states that. To fix that error…
action:
service: persistent_notification.create
data_template:
message: >
{{ trigger.to_state.name if trigger is defined else "Test" }} too high!
using data_template still works in 0.115 and it has no plans for it to be deprecated. So nothing has changed in this regard. So there’s nothing to be annoyed about. You just need to learn how the trigger button for automation works when using the trigger variable. It’s always worked this way.
Thanks guys! That explains. Did not really find any mention that there’s no handle generated for the trigger when manually executing it and with the errors and the editor kinda breaking up too when switching from yaml to UI view (it’s not able to show data_template stuff), I just thought the whole syntax is wrong.
ot:
I know I know it’s free, it’s beta and it’s not meant for grannies but it doesn’t mean I can’t have opinions right? It just sometimes feels it’s too much of a mess of several ideas released too early. Like this transition towards web UI configurability. I really don’t know whether I should try to use it to make the most of the GUI or risk everything blowing up in near future by keeping all in my well controlled self written files.
Forgot the side question. Do you know if it’s just a bug or why this happens in the web editor? If I write “message: >” in yaml view and switch back to UI view, it replaces “>” with “|” and I don’t know why it would want to break the single line rule.
Better get used to the GUI, one of the main goals is to transition as much as possible to the UI to make it more user friendly and accessible to less tech savy people.
But if it doesn’t care whether line breaks are preserved or turned to spaces, why is it needed at all then?
@Burningstone, I just meant this whole config renewal in general. It’s feels really scattered and confusing atm. as like you said, I’m probably better in the long run if I use GUI but not all can be done via GUI and it’s not all clear what is the best practice on what atm.
You mean the general shift from YAML to GUI?
It’s unfortunate, but at one point they had to take this step (when the long term goal is to make it accessible for everyone) and it will take wome time until all the integrations have been moved to be UI configurable, there are over 1500 integrations and I think petro said it’s pretty hard to code a UI config flow and on average they move around 5-10 integrations from YAML to UI per release cycle (every 3 weeks).
Understandable. I guess it wouldn’t matter if both options would be possible but now that some stuff is only available one way and other stuff other way, it gets confusing for stupid people like me.
This has nothing do to with stupidity, your are just new and need to get used to Home Assistant believe me, when I started more than 3 years ago, it was way more difficult and only suitable for computer geeks/tinkeres.
Keeping both options alive is a lot of unnecessary maintenance work.
Think it was 3 or 4 years ago when I started using it too but I’m not that actively updating it so there’s a giant amount of need to know stuff to find every time I do update.
By keeping them both I meant why not just save the UI config in yaml / whatever readable format and that way allowing both to live. It does it now but only partly.
Sounds easy in theory and was proposed multiple times when it was announced that integration configuration will move away from YAML, but unfortunately it’s not that easy. Anyway this has been discussed to death and decidee, so either you have to accept it or search for another home automation platform.
believe me, when I started more than 3 years ago, it was way more difficult and only suitable for computer geeks/tinkeres.