With a non-blueprint automation, it’s the responsibility of whoever is editing the automation to ensure they are specifying the correct entities.
With a blueprint, that responsibility has shifted to the blueprint’s author. By allowing the user to select inputs interactively (without understanding how those choices are used by the underlying automation), the author must validate them.
Just like any good app, the user’s submitted data must be validated before it’s used.
I understand that part.
The thing that I don’t get is why the functionality of rendering templates has changed in blueprints.
Before I could create an automation containing an invalid template and then save it. Since the template isn’t rendered until run time I can use other conditions to verify that at run time that the template is going to be valid.
While that might not be the most robust way of doing it sometimes it’s the easiest/less complicated way of doing it. And it still works perfectly fine outside of blueprints even now.
In this case it’s not the selection of the incorrect entity per se that is the problem. It’s the change in functionality of the validation of included templates in the blueprint that is the issue.
I suspect we are talking about different things. I was referring to the fact the user selected the wrong entity. As per the screenshot, the instructions direct the user to select a sensor ending with ‘next_timer’ but the user chose one ending with ‘next_alarm’. This resulted in the -1 error because the chosen sensor lacked the required attribute.
Yes, we are but I think they are related since the error in selecting the wrong entity showed an inconsistency in how the config checker handles checking templates in blueprints compared to regular automations.
see the latest posts above for what I’m trying to say.
Glad I could help 
This worked great for about a week and then last week on both my setups in two different homes and separate alexa accounts the sensors for alexa are not available.
Since this is not an issue with this Blueprint, but with the Alexa integration, I recommend asking again at the appropriate place. Basically, I can give you the tip to switch your Amazon account to 2FA and to enter the code for generating the 2FA codes when setting up the Alexa integration. This often solves login problems.
The pain in the ass weekly amazon authorization is not the problem.
All others entities work with the Alexa devices.
I was just wanting to know if anyone else is having the same problem.
Because I am on two totally different HA setups.
Sorry for coming back that late… 
Flashing by calling light.turn_on service works flawless with this:
But my automation does not.
Neither this:
PS: livingcolors_1 = Fernsehlicht
Sorry for German^^
What about manually calling the service?
Manually calling as seen above works with no problems.
Does the sensor change? And I mean use the call service automation action.
Yes, I see the sensor of sensor.andreas_echo_show_next_timer counting down from the starting time.
I mean use this option:
That did the trick! So what is the difference between the two options I tried and the service call?
Shouldnt those other two options then be removed? Or are there other appliances I do not think of for where they are relevant
For some reason, the device triggers aren’t working. I’m not sure why.
Is there a possibility to check all the Alexas in one automation? or do I have to create an automation for every Alexa that I have?
The blueprints works fine but is there a way to let lights flash? So if the timer expires I would like to let the light flash until I said “Alexa turn the timer off” Is there a simple way ? I tried to
For me this is working:
alias: Alexa - Timer zu Ende - Küche
description: ''
use_blueprint:
path: sgr/alexatimer.yaml
input:
echo_device_next_timer: sensor.echo_kuche_next_timer
target_action:
- service: light.turn_on
data:
entity_id: 'light.arbeitsflache,light.dekoration'
flash: long
hi to all, sorry, but if i wont a notification when remider of alexa is exiperd, is it possible