#I looked around a bit but didn t find
1 messages · Page 1 of 1 (latest)
The relevant error message is:
Invalid blueprint:
Entity ID Input(name='monitor_entity') is an invalid entity ID for dictionary value @ data['blueprint']['input']['state_active']['selector']['entity_id']. Got None
Entity ID Input(name='monitor_entity') is an invalid entity ID for dictionary value @ data['blueprint']['input']['state_inactive']['selector']['entity_id']. Got None
I assune something is missing from that.
What would that be?
that is just a list of inputs with no trigger or action
Yes, as this is a minimal example of the problem.
But when you look at the error message, it becomes clear that this is not the reason for why it doesn't work.
The problem is rather that entity_id is required for state inputs.
However, this means that you must provide an entity_id, either as a default for the monitor_entity input or a literal with the id of an entity that exists.
I think your starting problem might be that you are not starting with a working automation. A functioning automation (or script) makes it MUCH easier to create a blueprint.

Another good source of writing your own blueorint is the Blueprint Exchange. Hundreds of examples there. But start with a simple turning a light entity on and off automation, and change it to a blueprint by adding the inputs, etc.
It most certainly is not, as I started with a working automation and reduced it to this minimal example demonstrating the (same) problem.
I didn't find any blueprint there, that uses the state selector in this way.
This blueprint doesn't use the state: selector.
I have a bunch of entities in there
Thatwas all that was in the example you gave me
The problem is the state selector, when the entity_id is not known beforehand.
selecting
https://gist.github.com/esclear/0f5807e8c36485391938c27b5d33a04c#file-blueprint-yaml-L18,L24 These are the relevant lines
the first and last selected lines.
ok I'll look at that
ok, gotchya
If you don't already have an entity, there is no way to pick one of the states. I supposed that is true.
The list comes from the entity attributes
I would agree, is that what you mean
It also doesn't pick a default value for the monitor_entity input.
I tried using sensor.time there, as this seems like an entity that many users would have available there, but this doesn't work either.
Well, default values are part of the input, but yes, I did.
The problem is that the UI has to know the entity, and that
that's not linked to the !input until the automation/script runs, so it has no idea
So you are right, that's kind of useless unless you have a pre-made entity
Exactly. This is what i meant, when I wrote that this makes state selectors unfit, when you want to share your blueprint :/
I would prefer them over textual inputs.
I guess that inputs, which are generated ad-hoc using templates are not possible, or are they?
The only way I can think of making it would be to put in the instructions that they need to edit the blueprint with the entity name after they download it.
I intend to use the blueprint often and with different devices / entities.
I think that this kind of reaches a point of diminishing returns, where it would be easier to copy / paste the yaml, if state inputs are really needed.
Or, well, use string inputs for states 🤷♂️
I REALLY wish I could generate an input, but the input is like a secret. It grabs the content from the top of the automation created and plugs it into the functioning part of that automation.
It's only available when the thing is running
not when the UI is rendering
Think of triggers, I'm having the same problem there. If I create an entity within the blueprint, how do I trigger off of it. The name is a template, and that is read as none. !inputs work because they are substitutes from the entries in the automation, chicken or egg.. If I could push a !constant (for instance) to the automation from the variables, then we could pull this off...
Thinking of wriring an FR for that...
I have an idea, not a solution. Do an FR on this problem. You have all the examples and experience. My suggestion would be to eliminate the state selector and merge it as an option to the entity selector. Then when you provide the UI with the entity, the option to include a state selector could be done because the UI knows the entity...
If you have a feature request for the frontend you can open one here, for Home Assistant itself please post on the forum. All other feature requests should be made to the developer of that custom card/component.